asterisk users - Mar 2013 - SIP account registration fails after upgrade to 1.8

Hi folks,

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, so 
it must be that they no longer have the same basic requirements.

The relevant part of my sip.conf looks like this:

[general]
context=incoming-j
canreinvite=no
dtmfmode=inband
qualify=yes
srvlookup=no
disallow=all
allow=alaw
allow=ulaw
allow=g722
allow=g726
allow=g729
insecure=port,invite
register => <telno>:<password>@sip.xs4all.nl/<telno>

Does anyone know of any new variables that have been introduced since 
Asterisk 1.6.2.9, that apply here and might be causing this problem?

Thanks,

Jaap

hi,
try srvlookup=yes

On Tue, Mar 19, 2013 at 3:15 AM, Jaap Winius <jwinius at umrk.nl> wrote:
> Hi folks,
>
> 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, so
> it must be that they no longer have the same basic requirements.
>
> The relevant part of my sip.conf looks like this:
>
> [general]
> context=incoming-j
> canreinvite=no
> dtmfmode=inband
> qualify=yes
> srvlookup=no
> disallow=all
> allow=alaw
> allow=ulaw
> allow=g722
> allow=g726
> allow=g729
> insecure=port,invite
> register => <telno>:<password>@sip.xs4all.nl/<telno>
>
> Does anyone know of any new variables that have been introduced since
> Asterisk 1.6.2.9, that apply here and might be causing this problem?
>
> Thanks,
>
> Jaap
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20130319/d659c71f/attachment.htm>

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.

On Thu, 21 Mar 2013 16:35:16 +0000, Jaap Winius wrote:
> ... 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]
 
Actually, I have to correct myself here. Not only was the SIP server at 
sip.xs4all.nl changing the lower case letters of the IPv6 section in any  
Call-IDs to upper case, it was also expanding the addresses, like so:

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

So, that SIP server was (and still is as of this writing) actually making 
two mistakes instead of just one.

My apologies for not being entirely accurate the first time around.

Cheers,

Jaap