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
