[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Cannot hear voice with symmetric NAT and STUN
From:       Richard Barnes <rbarnes () bbn ! com>
Date:       2013-02-28 22:14:15
Message-ID: A46A5D3C-2BB0-4C30-9977-A517D763F560 () bbn ! com
[Download RAW message or body]

When you say "SIP server", do you mean a proxy, or something like a B2BUA?

If you use ICE, there shouldn't be any need for the "SIP server" to modify the SDP.  \
The endpoints should be able to exchange and test candidates directly.



On Feb 28, 2013, at 11:57 AM, Khoa Pham <onmyway133@gmail.com> wrote:

> Hi Richard, thanks for the response.
> 
> When A call B. The INVITE message will go through SIP server. And this SIP server \
> can modify the media address in SDP. 
> When both A, B use STUN. The INVITE message SDP contains the media address A \
> obtained through STUN, and SIP server does not modify it. So that B will then send \
> rtp packet to this address, hence cause no voice 
> But when either A or B use STUN. This SIP server modify the the media address to \
> the address of RTP server. This case A can hear B and vice versa 
> Why is that ?
> 
> 
> On Thu, Feb 28, 2013 at 8:59 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> Hi Khoa,
> 
> > Hi, I have Kamailio as SIP server and RTP server. Client is PJSIP.
> > 
> > I read that STUN is for non-symmetric NAT, and RTP server is for symmetric
> > NAT.
> 
> You are correct that an "RTP server" (also called a "TURN server") is usually \
> necessary in the case of symmetric NAT.  For some illustrations, see this slide \
> deck: <http://www.viagenie.ca/publications/2008-09-24-astricon-stun-turn-ice.pdf>
> 
> Your client will have to gather TURN candidates and send them to the other side \
> during ICE negotiation. 
> 
> > Supposed A calls B.
> > 
> > If A, B both use symmetric NAT and STUN, they cannot hear each other
> 
> In this case, if you only use STUN, media will fail.  (I assume "they cannot hear \
> each other" means RTP isn't going end to end.)  You need to use an RTP server (== \
> TURN server). 
> 
> > If A or B use non-symmetric NAT and NOT using STUN, they cannot hear each
> > other.
> 
> In the case of non-symmetric NAT, you still need to use STUN.  NOT using STUN will \
> only work if there are no NATs. 
> 
> > I read http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt
> > for Prediction Failure, is that related to this problem ?
> 
> That is a very old document, and does not look technically sound.  In particular, \
> predicting next port numbers will usually not work, because NATs can assign port \
> numbers in any order they want.  I would start with the ICE RFC, and work from \
> there: <http://tools.ietf.org/html/rfc5245>
> 
> Good luck!
> 
> --Richard
> 
> 
> 
> -- 
> Khoa Pham
> HCMC University of Science
> Faculty of Information Technology


_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]