Thanks to the folks at mantis, this field was increased to 128 characters for the 1.2 branch; SIP was re-written for 1.4/trunk and this isn’t supposed to be an issue.
We are using Asterisk (1.2.9.1) as a media server for a commercial conferencing application. Before reaching Asterisk, calls go from a SIP phone through a B2BUA (itself based on a commercial SipServer). 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 greater 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]. 256 might be overkill, but 80 was certainly too small.
Testing after the recompile showed that Asterisk associated the ACKs from the SIP phone with the original INVITE.
I have checked the chan_sip.c code in Asterisk version 1.2.10, and the 80 character limit for callid is there too.
Has any one else run into this? Are there any recommendations?
Thanks,
psatcs