Sorry, didn't realize that you probably had rtpproxy behind NAT as well.
Have a look at this thread for mediaproxy:
I also posted a patch for rtpproxy.
AFAIK, none of them have been included in recent versions of
rtpproxy/mediaproxy and both patches are for older versions.
As for HT486, you are describing a very important breach of the RFC...
Either that, or it does not recognize your ser as a loose router and
believes it is a strict router (check for lr or lr=on in the Record-Route).
g-)
----- Original Message -----
From: "Soner Tari" <list(a)kulustur.org>
To: <serusers(a)lists.iptel.org>
Sent: Wednesday, November 02, 2005 10:25 PM
Subject: Re: [Serusers] SER/SEMS behind NAT, advertised_address,
sdp_mangle_ip
Thank you Greger for the reply. I took the original
ser.cfg after first
install and did what you suggest. However, with advertised_address I still
have problems. SER keeps using SER's local IP in Contact and SDP o and c
fields in the first OK after INVITE. So HT486 insists in using that local
IP in ACK and BYEs (SJphone has no problems with the same OK message from
SER, so I am trying to find a workaround for HT486).
Following is from the syslog debug from HT486, please pay attention to 200
OK from SER, it has SER's local IP (192.168.0.11) in 3 places, and then
see the ACK from HT486, it is sent to that address instead of SER's public
IP:
INVITE sip:8883630570@<SER.public.IP> SIP/2.0 Via: SIP/2.0/UDP
<HT486.public.IP>;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari"
<sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To:
<sip:8883630570@<SER.public.IP>> Contact:
<sip:8883630571@<HT486.public.IP>> Supported: replaces, timer Call-ID:
96900515ab0729c3(a)10.0.0.6 CSeq: 54703 INVITE User-Agent: Grandstream
HT487 1.0.7.11 Max-Forwards: 70 Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
Content-Type: application/sdp Content-Length: 340 v=0 o=8883630571
8000 8000 IN IP4 <HT486.public.IP> s=SIP Call c=IN IP4 <HT486.public.IP>
t=0 0 m=audio 5004 RTP/AVP 18 4 97 8 0 101 a=sendrecv a=rtpmap:18
G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30
a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101
telephone-event/8000 a=fmtp:101 0-11
SIP/2.0 100 Trying -- just wait a minute ! Via: SIP/2.0/UDP
10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari"
<sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To:
<sip:8883630570@<SER.public.IP>> Call-ID: 96900515ab0729c3(a)10.0.0.6
CSeq: 54703 INVITE Server: Sip EXpress router (0.9.4 (x86_64/linux))
Content-Length: 0 Warning: 392 192.168.0.11:5060 "Noisy feedback tells:
pid=18295 req_src_ip=<HT486.public.IP> req_src_port=5060
in_uri=sip:8883630570@<SER.public.IP>
out_uri=sip:8883630570@<SER.public.IP> via_cnt==1"
SIP/2.0 180 ringing Via: SIP/2.0/UDP
10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari"
<sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To:
<sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Call-ID:
96900515ab0729c3(a)10.0.0.6 CSeq: 54703 INVITE Contact:
<sip:8883630570@192.168.0.11> Server: Sip EXpress router (0.9.4
(x86_64/linux)) Content-Length: 0 Warning: 392 192.168.0.11:5060 "Noisy
feedback tells: pid=18292 req_src_ip=<HT486.public.IP> req_src_port=5060
in_uri=sip:8883630570@<SER.public.IP>
out_uri=sip:8883630570@<SER.public.IP> via_cnt==0"
SIP/2.0 200 OK Via: SIP/2.0/UDP
10.0.0.6:5060;branch=z9hG4bK84f0b75c7e2ae685 From: "Soner Tari"
<sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To:
<sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Call-ID:
96900515ab0729c3(a)10.0.0.6 CSeq: 54703 INVITE Contact:
<sip:8883630570@192.168.0.11> Content-Type: application/sdp Server: Sip
EXpress router (0.9.4 (x86_64/linux)) Content-Length: 149 Warning: 392
192.168.0.11:5060 "Noisy feedback tells: pid=18292
req_src_ip=<HT486.public.IP> req_src_port=5060
in_uri=sip:8883630570@<SER.public.IP>
out_uri=sip:8883630570@<SER.public.IP> via_cnt==0" v=0 o=username 0 0
IN IP4 192.168.0.11 s=session c=IN IP4 192.168.0.11 t=0 0 m=audio 1592
RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=30
ACK sip:8883630570@192.168.0.11 SIP/2.0 Via: SIP/2.0/UDP
<HT486.public.IP>;branch=z9hG4bKee2f9acde120c42b From: "Soner Tari"
<sip:8883630571@<SER.public.IP>>;tag=d7c932122fa923b1 To:
<sip:8883630570@<SER.public.IP>>;tag=00004DDB2E71DE97 Contact:
<sip:8883630571@<HT486.public.IP>> Call-ID: 96900515ab0729c3(a)10.0.0.6
CSeq: 54703 ACK User-Agent: Grandstream HT487 1.0.7.11 Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
Content-Length: 0
That's why I'm trying to use sdp mangler.
Btw, I need double record route as a workaround for another HT486 problem.
I think it seems like there is a bug in HT486 record route processing
(firmware 1.0.7.11, but also 1.0.6.7), it works like FIFO, when in fact it
should work like LIFO, i.e. it uses the oldest Record-Route to reply a
message. Using double record route, I am able to place the public IP of
SER as the oldest Record-Route in 200 OK messages to fake HT486. I can
quite easily replicate this issue and fake HT486 to use whatever IP I want
by placing it as the last Record-Route. Stupid, I know.
Any comments?
Thanks,
Soner
----- Original Message -----
From: "Greger V. Teigre" <greger(a)teigre.com>
To: "Soner Tari" <list(a)kulustur.org>rg>; <serusers(a)lists.iptel.org>
Sent: Monday, October 31, 2005 8:40 AM
Subject: Re: [Serusers] SER/SEMS behind NAT, advertised_address,
sdp_mangle_ip
Our SER
server is behind NAT, so we are having all sorts of NAT
problems. I have tried to read all the information I was able to find on
documents, maillist archives, and onsip and by googling. And I believe
that I were able to solve SIP signalling problems by record routing,
NAThelper and rtpproxy, and some tricks (double record routing) for
HT486. So SIP signalling seems fine now.
A few months back I posted a short how-to on that and people reported
back that it worked, AFAIK. I don't really see why you need fouble record
routing for HT486 unless you have an ALG in your NAT.
But when UAs are connected to sems, they send RTP
messages to the local
IP of SER. I also tried to use another ser instance dedicated to sems,
but still the same. So I thought it's time to ask a couple of questions
to the list.
To solve SIP problems, I tried to use advertised_address, but I could
not see any effect of it, SER still advertises its local IP, afaics. I
also tried mhomed. Apparently, I don't know how to use this parameter, I
thougth it would function similar to externip/localnet parameters on
Asterisk. So I tried solutions mentioned above, with success, as far as
I can see. But ser.cfg becomes quite complicated. I wish I could use
advertised_address properly.
adverstised_address should be used, it changes the IP address used in the
Via header. mhomed is to be used if your box has two interfaces where one
is public-facing and one is private and routing is done across.
To solve RTP problems, I tried to use mangler.
But I need to manipulate
messages sent from SER to the UA, for example 200 OK messages with SDP
info. But, again I guess I don't know where to use sdp_mangle_ip
function. I tried to use it in onreply_route without success. Where
should I place it in ser.cfg? I guess I am missing something obvious.
Would advertised_address solve this also, if I could have it working for
me?
I'm not sure why sems send to SER's IP address. Unless you call
force_rtp_proxy or use_media_proxy, the SDP address should not be
changed.
To summarize, I don't care too much about
connections from local network
(btw, I've set SER as DMZ), it's OK if SER forgets its local IP and
always advertises its public IP. I want SER to put its public IP
everywhere in every message (SIP/SDP) it sends out. Is there anyway to
achive this?
advertised_address=public_ip
You also need to make sure that you have an alias statement for both the
local IP and the public.
If you want to use rtpproxy on all calls to sems, you can just make sure
that you call force_rtp_proxy() on all INVITEs and OK (onreply) to/from
sems.
g-)
I've done all these on both SER 0.9.4 and
0.10.99 (CVS HEAD a week from
now), the server is a CentOS 4.1 x86_64.
I would appreciate any help.
Sincerely,
Soner Tari
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers