[Serusers] SER + RTPProxy and Client behind NAT

[Kanakatti Mahesh Subramanya]

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 at 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 at aptela.com] 
>>>Sent: Sunday, November 21, 2004 5:00 PM
>>>To: serusers at 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 at 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 at 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 
> 
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20041130/3f057115/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mahesh.vcf
Type: text/x-vcard
Size: 332 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20041130/3f057115/attachment.vcf>