[Serusers] B2BUA and NAT.

[Alex Mack]

Hi Amos!

STUN would also work with cascaded NATs. The STUN client gets the public 
IP of the last NAT. That's the IP the STUN server "sees" as the 
originating IP of the STUN request. But your limited to the most 
restricted NAT in the path - if there's a symmetric NAT involved, no 
media (without RTP relay) will work.

RTP Proxying or relaying forces the UAs to send their RTP streams 
actively to a RTP relay (with public IP) reachable by both parties. 
After the first packet of each party has arrived the relay knows which 
way to send the packets back in order to reach the UAs. This way you can 
traverse any NAT-type (even cascaded) if the clients support symmetric 
RTP (sending and recieivng over the same port number).

Alex Mack

Amos Nungu schrieb:

> Thanks Alex.
>
> Just wondering...
> I know that STUN won't solve cascading NATs (e.g. 2 nats in front of a 
> UA), How about RTP Proxying (rtp/media proxy)? How?
>
>
> ----- Original Message ----- From: "Alex Mack" <amack at fhm.edu>
> To: "Amos Nungu" <iw03_amn at it.kth.se>
> Cc: <serusers at lists.iptel.org>
> Sent: Friday, April 15, 2005 12:51 PM
> Subject: Re: [Serusers] B2BUA and NAT.
>
>
>> Hi Amos!
>>
>>> 1.Does it solve NAT because it stays in the middle and proxy 
>>> everything (+ media) or
>>> 2.can it be involved in the call only when NAT is detected like rtp 
>>> proxy ?
>>
>>
>> You can always put a B2BUA in the media path, not just for NAT 
>> traversal. Other applications like billing or privacy service are 
>> also common. Downsides are media quality, scalability and 
>> representing a single point of failure.
>>
>>> 3. iF 2, THEN how does it work in corporation with SER or any SIP 
>>> Server?
>>
>>
>> B2BUA means a system standing in the signalling AND the media path.
>> So a proxy in the normal SIP message path could "catch" the session, 
>> i.e. terminating the incoming call ("picking up the receiver") and 
>> build up new outgoing call to the target. Then it relays the voice 
>> from one call the other. It can change codec and other information as 
>> well on the way.
>>
>> In this respect SER isn't a B2BUA and will never be.
>> SER itself just can handle and mangle SIP messages very good but can 
>> have only influence on the media *routing* with e.g. 
>> nathelper/rtpproxy or mediaproxy. It doesn't terminate SIP 
>> transactions or media sessions.
>> If you're looking for a real B2BUA you might want to trake a look at 
>> Asterisk.
>>
>>> 4. Which situation will rtp proxy (rtpproxy/mediaproxy) fail to 
>>> solve NAT issues
>>
>>
>> RTP relay seems to be a cure-all regarding NAT problems - desipte the 
>> disadvantages. The only clients not working with RTP relay where 
>> those who didn't support symmetric SIP and symmetric RTP (i.e. 
>> sending and receiving data on the same port).
>> Another set of clients not working are more than two STUN clients 
>> behind the same NAT and the NAT not supporting hairpin of media. In 
>> this situation SER assumes both UAs to have public adresses (i.e. not 
>> being behind a NAT) and to be able to communicate with each other, 
>> which isn't the case with the lack of hairpin of media. Signalling 
>> would work but you wonÄt hear voice.
>>
>> Alex Mack 
>
>
>
>