Benny Prijono wrote: > On Mon, Aug 11, 2008 at 5:53 PM, Pedro Gon?alves > <pedro.pandre at gmail.com <mailto:pedro.pandre at gmail.com>> wrote: > > Hi! > > I updated to the latest SVN version, and unfortunately, this problem > persists. > > I've attached the log. > > > Erm, I didn't see the attachment. > > -benny Here are other logs, using the latest SVN version, but with the extra debug information you requested: 11:31:55.569 on_stun_request_complete 11:31:55.593 stun_sess=11BBA83C, status=0 tdata=1158EC5C, check->tdata=114FAC5C 11:31:55.650 Gotcha! 11:31:55.671 src_addr=172.18.0.133:1080 11:31:55.690 tdata message: 11:31:55.720 STUN Binding request Hdr: length=76, magic=2112a442, tsx_id=00001d1469525f902cd672ae Attributes: PRIORITY: length=4, value=31 (0x1f) ICE-CONTROLLED: length=8, data=2213260d6b89030a USERNAME: length=17, value="39b32d12:301c0bdb" MESSAGE-INTEGRITY: length=20, data=3ff0fe5f06c0469ee71829e1045466741b4984f0 FINGERPRINT: length=4, value=3253085308 (0xc1e6247c) 11:31:55.753 check->tdata message: 11:31:55.784 STUN Binding request Hdr: length=76, magic=2112a442, tsx_id=00001d1416496df12cd672af Attributes: PRIORITY: length=4, value=31 (0x1f) ICE-CONTROLLED: length=8, data=2213260d6b89030a USERNAME: length=17, value="39b32d12:301c0bdb" MESSAGE-INTEGRITY: length=20, data=a810d57b65fa949484f84dd2b7ea1ee618267c7b FINGERPRINT: length=4, value=2348830834 (0x8c005072) 11:31:55.813 response: 11:31:55.847 STUN Binding success response Hdr: length=68, magic=2112a442, tsx_id=00001d1469525f902cd672ae Attributes: XOR-MAPPED-ADDRESS: length=8, IPv4 addr=172.18.0.130:65245 SERVER: length=19, value="pj_stun-0.9.0-trunk" MESSAGE-INTEGRITY: length=20, data=4d63814ec963c46178ef489e8ce382fe4805bb6e FINGERPRINT: length=4, value=3978620332 (0xed24edac) 11:31:55.874 Dude, you're gonna crash! Have you noticed that the problematic simultaneous checks' binding requests, that above translate to tdata message and check->tdata message, always have transaction ids that end in *cd672ae* and *cd672af*? Question: Probably there's a good explanation to what I'm asking, but why can't we replace the pj_assert(tdata == check->tdata); with something that would simply ignore the response, like if ((tdata != check->tdata) { return; } ? Cheers Pedro Gon?alves -------------- next part -------------- A non-text attachment was scrubbed... Name: tdata_assert_error.pcap Type: application/octet-stream Size: 116744 bytes Desc: not available Url : http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080812/95bc7e78/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/20080812/95bc7e78/attachment-0001.pl
