ICE's Re-INVITE not completely changing ports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 18, 2008 at 6:09 PM, Pedro Gon?alves <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
> s=pjmedia
> c=IN IP4 192.168.102.1
> t=0 0
> m=audio 4000 RTP/AVP 0 101
> a=rtcp:4001 IN IP4 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 50839 typ host
> a=candidate:H 1 UDP 39 192.168.102.1 50839 typ host
> a=candidate:H 1 UDP 39 192.168.1.1 50839 typ host
> a=candidate:H 1 UDP 39 172.18.0.68 50839 typ host
> a=candidate:H 2 UDP 38 172.18.0.31 50840 typ host
> a=candidate:H 2 UDP 38 192.168.102.1 50840 typ host
> a=candidate:H 2 UDP 38 192.168.1.1 50840 typ host
> a=candidate:H 2 UDP 38 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080719/c96b8308/attachment.html 


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux