[asterisk-users] SIP account registration fails after upgrade to 1.8

[Jaap Winius]

On Tue, 19 Mar 2013 02:15:10 +0000, Jaap Winius wrote:

> Following an upgrade from Debian squeeze to wheezy, and Asterisk 1.6.2.9
> to 1.8.13, my server is no longer able to register a connection to a SIP
> account at my ISP (XS4ALL in the Netherlands). At the same time, it is
> still able to register a different account with another SIP provider...

To answer my own question, this turned out to be due to a bug in the SIP 
server at XS4ALL. I discovered it after using tcpdump to examine the 
exchange of packets during my registration attempts and noticing that 
Asterisk 1.8.13.1 was using an IPv6 address in the Call-ID instead of an 
IPv4 address as before. According to the specification for SIP 2.0 (RFC 
3261) this is perfectly legal, just as long as both parties treat the 
entire Call-ID as a string and never make any changes to it.

However, I discovered that is was exactly what the SIP server at XS4ALL 
is doing. For example, if my server sends it a SIP packet with a register 
request and a Call-ID that looks like this:

   Call-ID: 4991f57656d159925b296e5b3b06496b@[2001:888:abcd:1::a]

... somewhere along they line they end up changing it to this:

   Call-ID: 4991f57656d159925b296e5b3b06496b@[2001:888:ABCD:1::A]

In other words, it is treating the latter part of the Call-ID not as a 
string, but as an IPv6 address and has taken it upon itself to change all 
of the letters in that address to upper case. This changes the Call-ID 
and thus my registration attemp cannot be completed. Of course, this 
won't affect you if you happen to have an IPv6 address without any 
letters in it.

This situation is in contrast to another SIP provider that I use, 
sip.internetcalls.com, with which I currently have no problems because 
they leave such Call-IDs unchanged. I don't know what kind of SIP server 
software they use, but XS4ALL appears to be using Cirpack 4.42a.

This bug is very similar to another one described in this forum exchange:

   http://forums.asterisk.org/viewtopic.php?f=1&t=84603&start=0

Here, a SIP server at an ISP was taking the IPv6 address at the end of a 
Call-ID and expanding it, e.g. from ::1 (the IPv6 loopback address) to 
0:0:0:0:0:0:0:1. In both that case and in mine, we get the same result: 
an altered Call-ID that leads to endless timeouts and no registration.

Hopefully, my ISP will see fit to squash this bug ASAP.