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 <[email protected]> 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 <[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
