[Serusers] B2BUA and NAT.
Alex Mack
amack at fhm.edu
Fri Apr 15 12:51:53 CEST 2005
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
More information about the sr-users
mailing list