Hey! 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: [Fwd: Re: Exceptions when using ICE functionalities] Date: Fri, 08 Aug 2008 18:39:13 +0100 From: Pedro Gon?alves <pedro.pandre@xxxxxxxxx> 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
