| Summary: | ASTERISK-07477: callid[80] too small when using B2BUA | ||
| Reporter: | Peggy Shepard (pssatcs) | Labels: | |
| Date Opened: | 2006-08-07 12:30:47 | Date Closed: | 2006-08-08 12:06:05 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | In our installation calls go from a SIP phone through a B2BUA before reaching Asterisk. The B2BUA concatenates the original Call-ID with one that it generates. As such, the Call-ID on the SIP INVITE that actually reaches Asterisk is larger than 80 characters. The callid stored within chan_sip.c (for both sip_pvt and sip_registry) is char callid[80]; /*!< Global CallID */ The SIP INVITE is processed correctly and Asterisk replies with 1xx and finally 200/OK messages. These messages are passed correctly through the B2BUA and matched by the SIP phone. When the SIP phone replies with an ACK, it is not matched with the original call in Asterisk. The byte-for-byte match (as specified in rfc3261) of the stored 80 character callid and the longer-than-80-character callid in the ACK fails.(chan_sip.c, find_call(), line 13476). We were able to work around this problem by defining a constant, CALL_ID_LEN equal to 256, then changing the size of callid[80] in sip_pvt and callid[80] in sip_registry to callid[CALL_ID_LEN]. Testing after the recompile showed that Asterisk associated the ACKs from the SIP phone with the original INVITE. Can callid be set to a larger value than 80 without introducing new problems? Is there a problem with using 256? Can this modification be included in Asterisk (so we don't have to use a home-grown version, even though the change is small)? Thanks for your help. ****** ADDITIONAL INFORMATION ****** I verified that the code in 1.2.10 contains this limitation on callid. | ||
| Comments: | By: Olle Johansson (oej) 2006-08-07 15:00:03 What does the RFCs say? By: Olle Johansson (oej) 2006-08-07 15:04:09 In svn trunk (coming version 1.4) this limitation does not exist any more. How long is the actual Call ID you have here? By: Peggy Shepard (pssatcs) 2006-08-07 15:13:23 Note 2: That's great news about 1.4. I think the call-id we're using is about 100 characters (give or take a few). Here's a sample: xyzzy524a20150123b6e5b9042a0234498b76(99CA4F51-5476-453B-BD49-96C1DD3E477D:10.1.1.77)@10.1.1.77 Note 1: Here are excerpts from the RFC. We weren't able to find a specific limitation, but they did include things like "byte-by-byte" comparison. 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. <... deleted ...> Call-IDs are case-sensitive and are simply compared byte-by-byte. and from the BNF (section 25): word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" ) Call-ID = ( "Call-ID" / "i" ) HCOLON callid callid = word [ "@" word ] By: Russell Bryant (russell) 2006-08-08 12:06:04 I increased the buffer size in 1.2 to 128, since that should be enough to accomidate your situation. Thanks | ||