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 -------------- next part -------------- A non-text attachment was scrubbed... Name: tdata_assert_error.pcap Type: application/octet-stream Size: 16820 bytes Desc: not available Url : http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080808/f2381173/attachment-0001.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tdata_assert_error.log Url: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080808/f2381173/attachment-0001.pl
