Yes, Asterisk sends the re-INVITE with the same Via branch. Here is a short excerpt from the RFC-3261 (SIP): 8.1.1.7 Via ... The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. ... Do you think Asterisk should send re-INVITE with another branch? If so, I write to the asterisk-dev list. Thanks, Daniel -----Original Message----- From: Benny Prijono [mailto:bennylp@xxxxxxxxx] Sent: Wednesday, October 07, 2009 8:57 AM To: pjsip list Subject: Re: reinvite causes assertion failure 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 >
