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 <[email protected]> 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
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to