Hi Daniel, Thanks for the report. It looks like the re-INVITE uses the same Via branch value as the first INVITE? This is wrong of course, but I also don't like the fact that an assertion is raised rather than returning some error. I just registered a ticket for this: http://trac.pjsip.org/repos/ticket/965 Cheers Benny On Tue, Oct 6, 2009 at 4:15 PM, Daniel Nanassy <Daniel.Nanassy at ygomi.com> wrote: > Hi, > > > > I just downloaded and complied pjsip 1.4. It works fine, but an assertion > failure is issued when it gets a reinvite: > > The assertion failure is: > > > > --------------------------- > > Microsoft Visual C++ Runtime Library > > --------------------------- > > Assertion failed! > > > > Program: ... > > File: c:\work\sei\nextgen development\...\sip_tr...ction.c > > Line: 551 > > > > Expression: pj_hash_get( mod_tsx_layer.htable, tsx->transaction_key.ptr, > tsx->transaction_key.slen, ((void *)0)) == ((void *)0) > > > > For information on how your program can cause an assertion > > failure, see the Visual C++ documentation on asserts > > > > (Press Retry to debug the application - JIT must be enabled) > > --------------------------- > > Abort?? Retry?? Ignore > > --------------------------- > > > > The method when the assertion comes from is (in sip_transaction.c): > > static pj_status_t mod_tsx_layer_register_tsx( pjsip_transaction *tsx) > > { > > ... > > pj_assert(pj_hash_get( mod_tsx_layer.htable, > > ??????????????????????????????????? ?? tsx->transaction_key.ptr, > > ??????????????????????????????????? ?? tsx->transaction_key.slen, > > ??????????????????????????????????? ?? NULL) == NULL); > > ... > > } > > > > In the previous versions the code looked like this: > > pj_assert(pj_hash_get( mod_tsx_layer.htable, > > ??????????????????????????????????? ?? &tsx->transaction_key.ptr, > > ??????????????????????????????????? ?? tsx->transaction_key.slen, > > ??????????????????????????????????? ?? NULL) == NULL); > > > > (the address of tsx->transaction_key.ptr was taken). > > Which is obviously erroneous, but it probably prevented causing the > assertion failure. > > > > Here are the two INVITEs sent by the Asterisk server (and relevant > transaction log entries (I enabled transaction logging)): > > > > 09:22:49.815?? pjsua_core.c? RX 837 bytes Request msg INVITE/cseq=102 > (rdata046B034C) from UDP 10.66.19.8:5060: > > INVITE sip:10.66.19.13:6060 SIP/2.0 > > Via: SIP/2.0/UDP 10.66.19.8:5060;branch=z9hG4bK1301b3bd;rport > > Max-Forwards: 70 > > From: "unknown" <sip:10661913@10.66.19.8>;tag=as30f37e0f > > To: <sip:10.66.19.13:6060> > > Contact: <sip:10661913 at 10.66.19.8> > > Call-ID: 6a679e9e1eb9e92b0d3c21fb4d221a08 at 10.66.19.8 > > CSeq: 102 INVITE > > User-Agent: Asterisk PBX 1.6.1.0 > > Date: Tue, 06 Oct 2009 07:22:49 GMT > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > Supported: replaces, timer > > Content-Type: application/sdp > > Content-Length: 304 > > > > v=0 > > o=root 589438590 589438590 IN IP4 10.66.19.8 > > s=Asterisk PBX 1.6.1.0 > > c=IN IP4 10.66.19.8 > > t=0 0 > > m=audio 12574 RTP/AVP 0 3 8 101 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:3 GSM/8000 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-16 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > > > 09:22:49.815 sip_transactio? Finding tsx for request, hkey=0x483A05DA and > key=s$z9hG4bK1301b3bd, found 00000000 > > 09:22:49.831 sip_transactio? Transaction 0471F30C registered with > hkey=0x483A05DA and key=s$z9hG4bK1301b3bd > > ... > > 09:22:52.581?? pjsua_core.c? RX 792 bytes Request msg INVITE/cseq=103 > (rdata046B034C) from UDP 10.66.19.8:5060: > > INVITE sip:10.66.19.13:6060 SIP/2.0 > > Via: SIP/2.0/UDP 10.66.19.8:5060;branch=z9hG4bK1301b3bd;rport > > Max-Forwards: 70 > > From: "unknown" <sip:10661913@10.66.19.8>;tag=as30f37e0f > > To: <sip:10.66.19.13:6060>;tag=d3996b5ed0c94504a1b0115301a0a07d > > Contact: <sip:10661913 at 10.66.19.8> > > Call-ID: 6a679e9e1eb9e92b0d3c21fb4d221a08 at 10.66.19.8 > > CSeq: 103 INVITE > > User-Agent: Asterisk PBX 1.6.1.0 > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > Supported: replaces, timer > > Content-Type: application/sdp > > Content-Length: 259 > > > > v=0 > > o=root 589438590 589438591 IN IP4 10.66.19.13 > > s=Asterisk PBX 1.6.1.0 > > c=IN IP4 10.66.19.13 > > t=0 0 > > m=audio 49230 RTP/AVP 0 101 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-16 > > a=silenceSupp:off - - - - > > a=ptime:20 > > a=sendrecv > > > > 09:22:52.581 sip_transactio? Finding tsx for request, hkey=0x483A05DA and > key=s$z9hG4bK1301b3bd, found 0471F30C > > 09:22:52.768??? udp046B2C68? Remote RTP address switched to > 10.66.19.13:49230 > > 09:22:52.768??? udp046B2C68? Remote RTCP address switched to > 10.66.19.13:49231 > > 09:22:54.081 sip_transactio? Transaction 0471DAEC registered with > hkey=0x483A05DA and key=s$z9hG4bK1301b3bd > > > > The second INVITE causes the assertion failure, but the transaction is > registering with the same hash key. > > Ignoring the assertion seems causing no problem (so I could comment it out), > but I do not think it is the good solution. > > Could someone help me with this problem (maybe who fixed the code which > issues the assertion failure)? > > > > Thanks, > > Daniel Nanassy > > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >
