Benny Prijono wrote: > On Wed, Jul 16, 2008 at 8:54 PM, Pedro Gon?alves > <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote: > > Hi! > > I am using ICE in voice calls, using a "smart" SIP server, > developed by > our company. > I say that it is "smart" because when he receives an INVITE or a > 200 OK > INVITE he changes the client's SDP so that each client thinks that > he is > speaking with the other, when in fact both are talking with the server > (it serves as a media relay). > > However, in order to make ICE to work with this mechanism, I had > to make > a little trick at the server, ir order to avoid ice-mismatch: the > server > adds relayed candidates, as the clients will check if the "m=" and > "c=" > lines represent one of the candidates. > > This way, the clients are able to check connectivity between each > other, > using ICE as usual. > > > 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. 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). > > > The initial offer and answer go as scheduled, and at this point the > clients are talking through the SIP server. > Then, ICE checks go as expected and the caller / controller sends the > updated offer, telling the callee / controller the candidates that he > will use and the ones the callee will use. > > > 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. 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. 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. (strangely, only callee is sending data, caller is just receiving - I don't know why this happens) 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. 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? > > > > From this moment on, the callee no longer uses the SIP server, using > callee's candidates instead. > > > I'm confused with this statement. I think it is better explained above. Basically what I meant is that after the whole negotiation the caller doesn't send data to the server, it uses the caller's IP and ports. > > > 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). > > > Any idea why the calee doesn't stop using the server (the address > in the > initial offer?). > > > And in fact this as well. Once again, I think that this is explained above, but the question can be reformulated as: why doesn't the callee stop to using the IP and ports negotiated in the initial offer / answer when it receives the subsequent offer. Cheers Pedro Gon?alves
