@Richard, By SIP server, I mean SIP Proxy, something like Kamailio, OpenSER, ... I'm not using ICE and TURN.
>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). How does the SIP proxy know whether to use rtpproxy or not ? On Fri, Mar 1, 2013 at 5:14 AM, Richard Barnes <[email protected]> wrote: > 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 > > -- 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
