On Fri, Jul 18, 2008 at 9:59 AM, Pedro Gon?alves <pedro.pandre at gmail.com> wrote: > Benny Prijono wrote: > > That sounds tricky. > > > > I'm not clear about what you're trying to achieve there. If you do > > want both clients to talk via the server, then actually you will want > > ICE mismatch to happen. > > > We are using our application, which makes use of PJSIP at low levels > (PJNATH / PJMEDIA and not PJSUA-LIB) to handle the communication. > Before my developments, if two clients wanted to communicate, they would > have to use our SIP server as a media relay (the server would simply > replace the IPs and ports in the INVITE/200 OK SDP with its own IP and > ports). This way the media (RTP / RTCP) would be relayed by the server, > in order to handle NAT traversal problems. As you can see, this is > similar to TURN. > Okay. > > However, my job is to improve the application by turning on PJSIP's ICE > support. > I want to use ICE all the time, except the cases where ICE can't > establish peer-to-peer communication between caller and callee (ex: > Symmetric NAT to Symmetric NAT) - in this case I want the media to be > relayed by the server (basically I want to be able to fallback to our > "TURN" solution when ICE negotiation fails). > > That's quite neat actually. It adds relay capability to ICE without having to implement TURN server. But as you can see below, your server needs to be more clever than that. ;-) > > Why are you sending updated offer? It seems that you're using your own > > application here and not pjsua. That will make this troubleshooting > > difficult since we can't be sure if the problem is with the server or > > the client. Use pjsua instead. > > :) > I can't use PJSUA, because, as I said, my job is to turn on PJSIP's ICE > functioaality in our application, which is already successfully using > PJSIP without ICE support. Of course you will integrate ICE into your application, I was just saying that since this is still early in your development phase, it seems make more sense to use a stable client (i.e. pjsua) to test your server first, especially since I don't see anything specifics that requires your application to be used. Since I know pjsua well, certainly this will help me a lot in helping you. :-) > > With your and the rest of PJSIP's list users' aid, I've been able to > have the clients (2 running instances of my application) to run ICE > procedures. > As I said, the initial offer and the initial answer go as scheduled. > > I will demonstrate this by showing the SDP exchanged between the > clients. Caller is 172.18.0.46 <http://172.18.0.46/>, callee has several > IPs (172.18.0.11 <http://172.18.0.11/> - this will be used to > communicate with calller, 172.18.0.10 <http://172.18.0.10/> and > 192.168.102.1 <http://192.168.102.1/>) > > Here is the initial answer when received at callee: > v=0 > o=- 3425224958 3425224958 IN IP4 172.18.0.46 <http://172.18.0.46/> > s=pjmedia > c=*IN IP4 192.168.1.91 <http://192.168.1.91/>* > t=0 0 > m=audio *5072* RTP/AVP 0 8 101 > a=rtcp:*5073* IN IP4 192.168.1.91 <http://192.168.1.91/> > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ice-ufrag:235022ee > a=ice-pwd:4b405878 > a=candidate:H 1 UDP 39 172.18.0.46 <http://172.18.0.46/> 1383 typ host > a=candidate:H 1 UDP 39 10.0.0.200 <http://10.0.0.200/> 1383 typ host > a=candidate:H 2 UDP 38 172.18.0.46 <http://172.18.0.46/> 1384 typ host > a=candidate:H 2 UDP 38 10.0.0.200 <http://10.0.0.200/> 1384 typ host > *a=candidate:Rac1200d4 1 UDP 0 192.168.1.91 <http://192.168.1.91/> 5072 > typ relay raddr 172.18.0.46 <http://172.18.0.46/> 4002* > *a=candidate:Rac1200d4 2 UDP 0 192.168.1.91 <http://192.168.1.91/> 5073 > typ relay raddr 172.18.0.46 <http://172.18.0.46/> 4003* > > I've put in *bold* the things that the server changed in SDP, which are > the c= and m= lines (basically replacing client's IP and ports to > server's IP and ports) and the relayed candidates. > > The initial answer, when received at caller, is: > > v=0 > o=- 3425224759 3425224760 IN IP4 192.168.102.1 <http://192.168.102.1/> > s=pjmedia > c=IN IP4 *192.168.1.91 <http://192.168.1.91/>* > t=0 0 > m=audio *5070* RTP/AVP 0 101 > a=rtcp:*5071* IN IP4 192.168.1.91 <http://192.168.1.91/> > a=rtpmap:0 PCMU/8000 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ice-ufrag:301c0bdb > a=ice-pwd:56ae0732 > a=candidate:H 1 UDP 39 172.18.0.11 <http://172.18.0.11/> 50033 typ host > a=candidate:H 1 UDP 39 192.168.102.1 <http://192.168.102.1/> 50033 typ > host > a=candidate:H 1 UDP 39 192.168.1.1 <http://192.168.1.1/> 50033 typ host > a=candidate:H 1 UDP 39 172.18.0.10 <http://172.18.0.10/> 50033 typ host > a=candidate:H 2 UDP 38 172.18.0.11 <http://172.18.0.11/> 50034 typ host > a=candidate:H 2 UDP 38 192.168.102.1 <http://192.168.102.1/> 50034 typ > host > a=candidate:H 2 UDP 38 192.168.1.1 <http://192.168.1.1/> 50034 typ host > a=candidate:H 2 UDP 38 172.18.0.10 <http://172.18.0.10/> 50034 typ host > *a=candidate:Rac1200d4 1 UDP 0 192.168.1.91 <http://192.168.1.91/> 5070 > typ relay raddr 192.168.102.1 <http://192.168.102.1/> 4000* > *a=candidate:Rac1200d4 2 UDP 0 192.168.1.91 <http://192.168.1.91/> 5071 > typ relay raddr 192.168.102.1 <http://192.168.102.1/> 4001* > > As you can see, server has replaced caller's IP and addresses with its > own's and added the relayed candidates. > Okay (I didn't check the details though). > After this moment, the clients start to communicate using the relayed > server (because after all, it's the server's IP and ports that are being > used in the c= and m= lines. Yes (I was wrong last time when I said that ice_strans will drop outgoing packets before connectivity checks complete). > > (strangely, only callee is sending data, caller is just receiving - I > don't know why this happens) Dunno either. Like I said, if you use pjsua then I probably can explain a bit, but since this is your application and I don't know what it's doing, I really can't say anything. > They also start ICE connectivity checks. > When those checks are complete, caller sends the subsequent offer. Here > it is as received by callee > > v=0 > o=- 3425224958 3425224959 IN IP4 172.18.0.46 <http://172.18.0.46/> > s=pjmedia > c=IN IP4 *192.168.1.91 <http://192.168.1.91/>* > t=0 0 > m=audio `*5076* RTP/AVP 0 8 101 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ice-ufrag:235022ee > a=ice-pwd:4b405878 > a=rtcp:*5077* IN IP4 192.168.1.91 <http://192.168.1.91/> > a=candidate:H 1 UDP 39 172.18.0.46 <http://172.18.0.46/> 1383 typ host > a=candidate:H 2 UDP 38 172.18.0.46 <http://172.18.0.46/> 1384 typ host > a=remote-candidates:1 172.18.0.11 <http://172.18.0.11/> 50033 2 > 172.18.0.11 <http://172.18.0.11/> 50034 > > As you can see, caller has included its selected candidates > (172.18.0.46:1383 <http://172.18.0.46:1383/> and 172.18.0.46:1384 > <http://172.18.0.46:1384/>) and the remote candidates (72.18.0.11:50033 > <http://72.18.0.11:50033/> and 172.18.0.11:50034 > <http://172.18.0.11:50034/>). > However, the server is still interfering and changing the IPs and ports. > That's really is a bad idea. See more below. > > The caller then receives the subsequent answer: > > v=0 > o=- 3425224781 3425224761 IN IP4 192.168.102.1 <http://192.168.102.1/> > s=pjmedia > c=IN IP4 *192.168.1.91 <http://192.168.1.91/>* > t=0 0 > m=audio *5074* RTP/AVP 0 101 > a=rtpmap:0 PCMU/8000 > a=sendrecv > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > a=ice-ufrag:301c0bdb > a=ice-pwd:56ae0732 > a=rtcp:*5075* IN IP4 192.168.1.91 <http://192.168.1.91/> > a=candidate:H 1 UDP 39 172.18.0.11 <http://172.18.0.11/> 50033 typ host > a=candidate:H 2 UDP 38 172.18.0.11 <http://172.18.0.11/> 50034 typ host > *a=candidate:Rac1200d4 1 UDP 0 192.168.1.91 <http://192.168.1.91/> 5074 > typ relay raddr 172.18.0.11 <http://172.18.0.11/> 50033* > *a=candidate:Rac1200d4 2 UDP 0 192.168.1.91 <http://192.168.1.91/> 5075 > typ relay raddr 172.18.0.11 <http://172.18.0.11/> 50034* > > At this moment, caller communicates from its IP(172.18.0.46 > <http://172.18.0.46/>) and ports ( 1383 and 1384) to callee's > IP(172.18.0.11 <http://172.18.0.11/>) and ports (50033 and 50034). > > The only problem is that the callee doesn't stop communicating with the > server (basically it continues to send data to the server, which relays > it to caller). However, the callee does send data to the caller, via the > negotiated addresses and ports. > > Any idea on why this is happening? > > Yeah, your server is messing up ICE (again). :) The rule regarding putting ICE in SDP is different for *initial* offer-answer and *subsequent* offer-answer. You only put selected candidate in subsequent offer/answer, and definitely you must use matching candidate in your c= and a=rtcp line. Doing it like above confuses the answerer, since the c= line mismatch, but at the same time the a=ufrag and a=passwd lines don't change so ICE restart procedure can't happen (and we can't restart ICE in the answer anyway). So bottom line, you really need to understand ICE before modifying PJSIP offer-answer SDP like that. If in doubt, re-read it again. :) > > > > > However, the callee will keep sending data to the server, and to the > > callee as well. > > > > > > And this as well. > > I think it is better explained above. Basically what I meant is that > after the whole negotiation the callee sends data to the caller's IP and > ports (negotiated in the subsequent offer) *but* doesn't stop sending > data to the server (negotiated in the initial answer). > > Well you said "callee will keep sending data to *callee*". Cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080718/406e14a1/attachment-0001.html
