Hi again! I'm not exactly sure why, but now the subsequent answer is sent correctly (at least only the candidates which are going to be used are included in SDP). Here is an example of a (correct?) subsequent answer: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.18.0.170:5060;received=172.18.0.170;branch=z9hG4bKb073b212195d8a13bdd73b3d46240a42 Call-ID: 5f94a72c36884cdc908d538809d8f2ee From: <sip:(...);type=voicecall>;tag=fb4956c20f654d91a2f338e54a4c4e93 To: <sip:(...);type=voicecall>;tag=f0331d51a7c346abb8bc6d8b3c6eec1a CSeq: 26501 INVITE Contact: <sip:172.18.1.61:6060> Allow: PRACK, SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE Supported: 100rel Content-Type: application/sdp Content-Length: 385 v=0 o=- 3426256239 3426256210 IN IP4 192.168.102.1 s=pjmedia c=IN IP4 172.18.1.61 t=0 0 m=audio 57525 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:57526 IN IP4 172.18.1.61 a=candidate:H 1 UDP 39 172.18.1.61 57525 typ host a=candidate:H 2 UDP 38 172.18.1.61 57526 typ host It matches the remote candidate indicated by the caller / controller: a=remote-candidates:1 172.18.1.61 57525 2 172.18.1.61 57526 However, I still have the problem that started this discussion: the re-INVITE doesn't completely replace the IP/ports negotiated in the initial offer/answer: after the initial offer / answer, both caller and answerer use the first set of IP/ports to communicate, but after the re-INVITE, the answerer doesn't fully update the media IP/ports, as it keeps sending media data to the IP/ports negotiated in the initial offer / answer (which are no longer valid), even after the call is hangup (after BYE)! Maybe I am missing something when receiving the subsequent offer on the answerer (in method *on_rx_offer()*). What I am doing now is: -Call *pjmedia_endpt_create_sdp* (Note: I am using the received *pjsip_inv_session inv*'s pool) to get the local sdp; -Call *pjmedia_transport_encode_sdp* (Note: I am using the received *const pjmedia_sdp_session offer*) -Call *pjsip_inv_set_sdp_answer* (Note: I am using the received *pjsip_inv_session inv*'s pool and the *pjmedia_sdp_session local_sdp* created with pjmedia_endpt_create_sdp). Am I missing something? I see that a similar procedure is being used in pjsua_call.c's pjsua_call_on_rx_offer() method. Best Regards Pedro Gon?alves -------- Original Message -------- Subject: Re: ICE's Re-INVITE not completely changing ports Date: Mon, 28 Jul 2008 12:47:33 +0100 From: Pedro Gon?alves <pedro.pandre@xxxxxxxxx> To: pjsip list <pjsip at lists.pjsip.org> References: <487E51FF.1090101 at gmail.com> <1879720d0807161447r6ab55c20x9ad1978798e7adf6 at mail.gmail.com> <48805B71.4080609 at gmail.com> <1879720d0807180507g1a868eeei739e0ebb6b3e64a3 at mail.gmail.com> <4880CE63.3080407 at gmail.com> <1879720d0807190947k3c539bcan8ae1e77295fd6886 at mail.gmail.com> Benny Prijono wrote: > On Fri, Jul 18, 2008 at 6:09 PM, Pedro Gon?alves > <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote: > > > Hi! > I changed the server, and now it doesn't mess with subsequent > offer and > subsequent answer. > However, I realized that I am experiencing a problem in the > answerer: it > seems like his ICE connectivity tests are taking more time to complete > that the caller's tests: I can see that the subsequent offer > arrives (at > on_rx_offer) *before* his on_ice_complete() gets called with > ice_strans_op = PJ_ICE_STRANS_OP_NEGOTIATION. > > > That's probably normal. Connectivity checks in the two hosts may not > complete at the same time. > > > > This way, as in on_rx_offer() I call *pjmedia_endpt_create_sdp*, > *pjmedia_transport_encode_sdp* and *pjsip_inv_set_sdp_answer*, the > subsequent offer is sent, but it doesn't seem correct, because it is > including again all the candidates, instead of only the candidates > selected bu the caller. > > > That's normal again. When ICE is still running, the endpoint needs to > list all of its candidates. > > > > Here is an example of a subsequent answer sent by the answerer: > > v=0 > o=- 3425387269 3425387237 IN IP4 192.168.102.1 <http://192.168.102.1> > s=pjmedia > c=IN IP4 192.168.102.1 <http://192.168.102.1> > t=0 0 > m=audio 4000 RTP/AVP 0 101 > a=rtcp:4001 IN IP4 192.168.102.1 <http://192.168.102.1> > 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.31 <http://172.18.0.31> 50839 typ host > a=candidate:H 1 UDP 39 192.168.102.1 <http://192.168.102.1> 50839 > typ host > a=candidate:H 1 UDP 39 192.168.1.1 <http://192.168.1.1> 50839 typ host > a=candidate:H 1 UDP 39 172.18.0.68 <http://172.18.0.68> 50839 typ host > a=candidate:H 2 UDP 38 172.18.0.31 <http://172.18.0.31> 50840 typ host > a=candidate:H 2 UDP 38 192.168.102.1 <http://192.168.102.1> 50840 > typ host > a=candidate:H 2 UDP 38 192.168.1.1 <http://192.168.1.1> 50840 typ host > a=candidate:H 2 UDP 38 172.18.0.68 <http://172.18.0.68> 50840 typ host > > I think that the problem is related to the fact that the answerer > hasn't > yet completed its tests. > > > Yes. > > > > In order to deal with that I added some code in on_rx_offer() to wait > for ICE to complete > > while (ice_is_not_complete && nr_tries < MAX_TRIES) { > log("on_rx_offer waiting for ice to complete"); > pj_thread_sleep(sleep_time); > nr_tries++; > } > > However, no matter how long I wait, the ice will always completes > after > this cicle completes, which leads me to believe that on_rx_offer() > should be running in the same thread used to perform the ICE > connectivity checks. > > Am I wrong? Is this waiting cycle really needed? > > > I don't think what you said is true about thread, but frankly I don't > know what you are doing there (and probably don't want to know :) ). > As far as I'm concerned, PJSIP seems to be running okay. > > Cheers > Benny Hi again I understand that PJSIP runs OK and that the problem most probably is in my application. I am just asking for advice from you and other PJSIP experts, who have a greater understanding in PJSIP/ICE procedures than I do. Maybe I haven't explained myself clearly: everything seems to be running OK until the answerer gets its *on_rx_offer()* method called. In that moment, the subsequent answer is supposed to be sent using *pjmedia_endpt_create_sdp* (Note: I am using the received pjsip_inv_session *inv's pool), *pjmedia_transport_encode_sdp* (Note: I am using the received const pjmedia_sdp_session *offer) and *pjsip_inv_set_sdp_answer* (Note: I am using the received pjsip_inv_session *inv's pool and the pjmedia_sdp_session *local_sdp created with pjmedia_endpt_create_sdp). The answer is sent, but the problem is that it is sent *before* the ICE checks complete (before *on_ice_complete()* is called with ice_strans_op == PJ_ICE_STRANS_OP_NEGOTIATION). So, I tried to make a pj_thread_sleep() while the on_ice_complete() wasn't called, but no matter how long the sleep took, the ICE negotiation always ends after the subsequent answer is sent. Any idea on how to solve this issue? Regards Pedro Gon?alves
