UA is Sipura2000/Snom190/UnidenUIP200/etc.
I am running rtpproxy in verbose mode (to be precise, as "rtpproxy -f -l <internal ip>/<external ip> )
The core problem is, - SER sends rtpproxy the port from the SDP (which in what the UA generated *behind* the NAT) - The UA is sending/receiving media on a *different* port to rtpproxy. - How does one get rtpproxy to "point" at the NAT port, and not at the SDP port?
cheers
Matt Schulte wrote:
Yes it can do this, RTPproxy is just that, a proxy. It has the ability to use whatever port it pleases, try running rtpproxy command line mode (rtpproxy -f ) to see if it's passing any errors. What kind of device is the UA? Be sure that the device has "NAT mode" on, this sounds like a problem I was having early on.
-----Original Message----- From: Kanakatti Mahesh Subramanya [mailto:mahesh@aptela.com] Sent: Sunday, November 21, 2004 5:00 PM To: serusers@lists.iptel.org Subject: [Serusers] SER + RTPProxy and Client behind NAT
I'm having a strange problem with getting SER+RTPProxy to work when the
UA is behind NAT Setup is as follows
UA --> NAT1 --> SER+RTPProxy --> NAT2 --> Asterisk
I've got RTPProxy running in "bridge" mode, gatewaying 'tween Asterisk and the Public Internet
SIP traffic all routes perfectly. STUN enabled clients work perfectly.
The problem is that if the outbound port on NAT1 for the RTP stream is *different* from the outbound port from the UA, then RTPProxy persists in sending the packets to the UA port, *not* the NAT1 port.
e.g. if the SDP payload from the UA contains
c=IN IP4 192.168.5.100 m=audio 16396 RTP/AVP....
but NAT1 sends the RTP stream out on port 64003, then rtpproxy sends the
media from Asterisk back to port 16393 at NAT1, instead of to port 64003
at NAT1!
Is it supposed to do this? Am I missing something really obvious?
The relevant section from ser.cfg is as follows
if (nat_uac_test("3")) { if (method == "REGISTER" || ! search("^Record-Route:")) { fix_nated_contact(); # Rewrite contact with source IP of signalling if (method == "INVITE") { fix_nated_sdp("1"); # Add direction=active to SDP }; setflag(6); # Mark as NATed }; };
rewritehostport("........"); if (force_rtp_proxy("FEI")) { t_on_reply("4"); }; . . . onreply_route[4] { if (!(status=~"183" || status=~"200")) { break; }; fix_nated_contact(); force_rtp_proxy("F"); break; }
I don't know if this will help, but I posted my entire ser.cfg the other day with the following subject:
Re: [Serusers] Revisted Error: force_rtp_proxy2: can't extractbodyfrom the message
This ser.cfg uses ser-0.8.99-dev17 + rtpproxy/nathlper and works very well. We've tested it with Cisco PIX, iptables, 2Wire DSL, and a few other firewalls. The only thing we're not using is Asterisk.
The UAs that we've tested include:
Cisco 7960G Cisco ATA 186 Grandstream BT100 Grandstream ATA 486 X-Ten Pro X-Ten Lite Sipura3000 UTstarcom iAN-02EX WorldAccxx TA200
Regards, Paul
--- Kanakatti Mahesh Subramanya mahesh@aptela.com wrote:
UA is Sipura2000/Snom190/UnidenUIP200/etc.
I am running rtpproxy in verbose mode (to be precise, as "rtpproxy -f -l <internal ip>/<external ip> )
The core problem is, - SER sends rtpproxy the port from the SDP (which in what the UA generated *behind* the NAT) - The UA is sending/receiving media on a *different* port to rtpproxy. - How does one get rtpproxy to "point" at the NAT port, and not at the SDP port?
cheers
Matt Schulte wrote:
Yes it can do this, RTPproxy is just that, a proxy. It has the ability to use whatever port it pleases, try running rtpproxy command line mode (rtpproxy -f ) to see if it's passing any errors. What kind of device is the UA? Be sure that the device has "NAT mode" on, this sounds like a problem I was having early on.
-----Original Message----- From: Kanakatti Mahesh Subramanya [mailto:mahesh@aptela.com] Sent: Sunday, November 21, 2004 5:00 PM To: serusers@lists.iptel.org Subject: [Serusers] SER + RTPProxy and Client behind NAT
I'm having a strange problem with getting SER+RTPProxy to work when the
UA is behind NAT Setup is as follows
UA --> NAT1 --> SER+RTPProxy --> NAT2 --> Asterisk
I've got RTPProxy running in "bridge" mode, gatewaying 'tween Asterisk and the Public Internet
SIP traffic all routes perfectly. STUN enabled clients work perfectly.
The problem is that if the outbound port on NAT1 for the RTP stream is *different* from the outbound port from the UA, then RTPProxy persists in sending the packets to the UA port, *not* the NAT1 port.
e.g. if the SDP payload from the UA contains
c=IN IP4 192.168.5.100 m=audio 16396 RTP/AVP....
but NAT1 sends the RTP stream out on port 64003, then rtpproxy sends the
media from Asterisk back to port 16393 at NAT1, instead of to port 64003
at NAT1!
Is it supposed to do this? Am I missing something really obvious?
The relevant section from ser.cfg is as follows
if (nat_uac_test("3")) { if (method == "REGISTER" || ! search("^Record-Route:")) { fix_nated_contact(); # Rewrite contact with source IP of signalling if (method == "INVITE") { fix_nated_sdp("1"); # Add direction=active to SDP }; setflag(6); # Mark as NATed }; };
rewritehostport("........"); if (force_rtp_proxy("FEI")) { t_on_reply("4"); }; . . . onreply_route[4] { if (!(status=~"183" || status=~"200")) { break; }; fix_nated_contact(); force_rtp_proxy("F"); break; }
begin:vcard
fn:Kanakatti Mahesh Subramanya n:Subramanya;Kanakatti org:Aptela, Inc. adr:;;1616 Anderson Road;McLean;VA;22102;USA email;internet:mahesh@aptela.com title:CTO tel;work:800.979.4638x9100 tel;fax:800.979/4638 tel;home:312.491.1909 tel;cell:773.220.6484 x-mozilla-html:TRUE url:http://www.aptela.com version:2.1 end:vcard
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Well, after much heartburn, heartache, and general angst, I've come to the following conclusion -
- If rtpproxy is running in "bridge" mode, it *only* pays attention to the initial port that was passed to it via SER (i.e., port extracted from SDP body) - If rtpproxy is *not* running in bridge mode, it waits to start getting the packets from the endpoints to figure out what the actual RTP ports are.
Soln - stop running it in bridge mode...
cheers
--- Kanakatti Mahesh Subramanya mahesh@aptela.com wrote:
UA is Sipura2000/Snom190/UnidenUIP200/etc.
I am running rtpproxy in verbose mode (to be precise, as "rtpproxy -f -l <internal ip>/<external ip> )
The core problem is,
- SER sends rtpproxy the port from the SDP (which in what the UA
generated *behind* the NAT)
- The UA is sending/receiving media on a *different* port to rtpproxy.
- How does one get rtpproxy to "point" at the NAT port, and not at
the SDP port?
cheers
Matt Schulte wrote:
Yes it can do this, RTPproxy is just that, a proxy. It has the ability to use whatever port it pleases, try running rtpproxy command line mode (rtpproxy -f ) to see if it's passing any errors. What kind of device is the UA? Be sure that the device has "NAT mode" on, this sounds like a problem I was having early on.
-----Original Message----- From: Kanakatti Mahesh Subramanya [mailto:mahesh@aptela.com] Sent: Sunday, November 21, 2004 5:00 PM To: serusers@lists.iptel.org Subject: [Serusers] SER + RTPProxy and Client behind NAT
I'm having a strange problem with getting SER+RTPProxy to work when the
UA is behind NAT Setup is as follows
UA --> NAT1 --> SER+RTPProxy --> NAT2 --> Asterisk
I've got RTPProxy running in "bridge" mode, gatewaying 'tween Asterisk and the Public Internet
SIP traffic all routes perfectly. STUN enabled clients work perfectly.
The problem is that if the outbound port on NAT1 for the RTP stream is *different* from the outbound port from the UA, then RTPProxy persists in sending the packets to the UA port, *not* the NAT1 port.
e.g. if the SDP payload from the UA contains
c=IN IP4 192.168.5.100 m=audio 16396 RTP/AVP....
but NAT1 sends the RTP stream out on port 64003, then rtpproxy sends the
media from Asterisk back to port 16393 at NAT1, instead of to port 64003
at NAT1!
Is it supposed to do this? Am I missing something really obvious?
The relevant section from ser.cfg is as follows
if (nat_uac_test("3")) { if (method == "REGISTER" || ! search("^Record-Route:")) { fix_nated_contact(); # Rewrite contact with source IP of signalling if (method == "INVITE") { fix_nated_sdp("1"); # Add direction=active to SDP }; setflag(6); # Mark as NATed }; };
rewritehostport("........"); if (force_rtp_proxy("FEI")) { t_on_reply("4"); }; . . . onreply_route[4] { if (!(status=~"183" || status=~"200")) { break; }; fix_nated_contact(); force_rtp_proxy("F"); break; }
begin:vcard
fn:Kanakatti Mahesh Subramanya n:Subramanya;Kanakatti org:Aptela, Inc. adr:;;1616 Anderson Road;McLean;VA;22102;USA email;internet:mahesh@aptela.com title:CTO tel;work:800.979.4638x9100 tel;fax:800.979/4638 tel;home:312.491.1909 tel;cell:773.220.6484 x-mozilla-html:TRUE url:http://www.aptela.com version:2.1 end:vcard
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com