Hope this is not coming too late, and apologize if so. Your query had
slipped in between a few mails and I've only noticed it today.
Anton Petrusevich wrote:
I don't understand how it works. Well, it kind of works, but i don't
understand how and why. I am talking about SIP, SDP and STUN here.
My understanding how this should work:
1. Get mapping for local (IP+port) -> public (IP+port) for SIP (L-SIP, P-SIP)
2. Get mapping for local (IP+port) -> public (IP+port) for audio RTP data (and
video if desired) (L-RTP, P-RTP)
3. Get mapping for local (IP+port) -> public (IP+port) for audio RTCP (and
video if desired) (L-RTPC, P-RTPC)
4. Send INVITE request with: Contact: <user@P-SIP>
m=audio P-RTP-port RTP/AVP <format-list>
Am I right?
Mostly yes, although in practice you only really need this for the media
bindings and not SIP. A very short explanation for this could look like
First, with most major server implementations today you don't really
need STUN as your provider would detect the presence of a NAT (most
often by comparing the addresses you indicated in your messages with the
sources of your UDP packets) and change your SDP description replacing
the private address with that of a media relay (which often coincides
with the SIP server).
One of the main reasons for using STUN would therefore be to avoid
relaying media streams through your core net servers. Media streams have
relatively high bandwidth consumption especially if there's video
involved, so it is likely that you'd prefer to spare your servers from
having to relay many conversations.
SIP on the other hand requires significantly less bandwidth to worry
about relaying it. Besides, whether you are using STUN or not most of
the SIP traffic would go through the server anyway. A look at the common
SIP trapezoid would explain why:
Many clients, including SIP Communicator, would therefore not bother
with STUN for the signaling.
What does SIP Communicator 1.0-alpha3-0.build.by.SVNLinux?
m=audio 5000 RTP/AVP 0 3 5 4
And that's it! Nothing more. Nor Via, nor Contact, nor "connection" in the SDP
body contains my public IP, only my private. I don't understand that. The
funny thing is that works.
It works most probably because your server is detecting the presence of
a NAT and is placing itself in the middle of the conversation as a media
relay (as explained above).
I am asking this because when I am changing anything, it breaks.
If by "changing anything" you mean "enabling STUN" then one reason that
it may break is that your NAT is mapping local ports for your outgoing
packets in a way that depends on the remote host and port. Check out the
following for more details on address and port dependent mapping:
To make a long story shot this really means that the binding you
obtained from your STUN server was only valid for that server and your
NAT assigned a different port for the packets you send to your SIP
server. What makes things worse is that when seeing public addresses in
your messages your SIP server is no longer able to detect the presence
of a NAT between you two so it won't try to act as a media proxy. In
other words the STUN NAT traversal technique actually breaks NAT
traversal in quite a few cases.
This is the reason why, for better or worse, the IETF went on to design
ICE. This is also the reason why SIP Communicator ships with STUN disabled.
Hope this clarifies things a little bit
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com