[pjsip] [Fwd: Re: [Fwd: Re: Exceptions when using ICE functionalities]]

Pedro Gonçalves pedro.pandre at gmail.com
Fri Aug 8 14:15:20 EDT 2008


I have just found something that I find very weird:
when the assert fails in assert(tdata == check->tdata),
*tdata->next* is equal to *check->tdata->prev*

Does this help us in understanding the problem?

Best regards
Pedro Gonçalves

-------- Original Message --------
Subject: 	Re: [pjsip] [Fwd: Re: Exceptions when using ICE functionalities]
Date: 	Fri, 08 Aug 2008 18:39:13 +0100
From: 	Pedro Gonçalves <pedro.pandre at gmail.com>
To: 	pjsip list <pjsip at lists.pjsip.org>
References: 	<489C533F.7010605 at gmail.com> 
<1879720d0808081020x41fc017tcca066dd3eaf74ef at mail.gmail.com>

Benny Prijono wrote:
> On Fri, Aug 8, 2008 at 3:07 PM, Pedro Gonçalves 
> <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote:
>     BTW, sometimes check->tdata is NULL.
>     There must be a reason why it is NULL.
>     Can you explain this?
> The check->tdata is set to NULL once that particular connectivity 
> check completes (i.e. on_stun_request_complete() has been called for 
> that check).
> The assertion is put there to make sure that 
> on_stun_request_complete() is not called more than once for the same 
> check.
>  -benny
OK. So basically if for some reason we receive 2 Binding Responses to 
the same Binding Request, we'll get an assert error. Is this desirable? 
Should'nt the subsequent Binding Responses to an already completed 
transaction be simply ignored?

However, what about in the case where neither tdata nor check->tdata are 
null, and they are simply different from each other?
What can cause this?
I am including the application log and the capture I made when this 
exception happened.

In the last lines of the log we can see that a Binding success response 
was received.
I've also added some debug in functions pj_stun_session_on_rx_pkt (), 
on_incoming_response(), pj_stun_client_tsx_on_rx_msg(), 
stun_tsx_on_complete(), in which we can see that
tdata and check->tdata were already different, thus causing the 
assertion error.

Any help will be greatly apreciated.

Best Regards
Pedro Gonçalves

More information about the pjsip mailing list