14 Apr
2005
14 Apr
'05
8:42 p.m.
Hi.
I can't find enough info regarding B2BUA, and how it works.
At least I know that it is not scalling and it breaks SIP peer2peer
functionality. BUT, it is said that it can handle NAT, HOW?
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 ?
3. iF 2, THEN how does it work in corporation with SER or any SIP Server?
4. Which situation will rtp proxy (rtpproxy/mediaproxy) fail to solve NAT
issues
NB. I just need to expand my knowledge regarding options.
I'm using rtpproxy, it works fine in every respect only if I start it in
foreground
Regards.
15 Apr
15 Apr
2:51 p.m.
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
4:22 p.m.
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(a)fhm.edu>
To: "Amos Nungu" <iw03_amn(a)it.kth.se>
Cc: <serusers(a)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
4:33 p.m.
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(a)fhm.edu>
To: "Amos Nungu" <iw03_amn(a)it.kth.se>
Cc: <serusers(a)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
7149
days inactive
7150
days old
3 comments
2 participants
participants (2)
-
Alex Mack -
Amos Nungu