Hi all,
I had a weird problem with a Swiss voip provider (Netvoip) where I was unable to receive incoming calls, while it worked for other providers. I think the problem lies in Asterisk (I’m using 1.2.3) - under certain circumstances the REGISTRY-packet contains a wrong “Contact:” header. Below the details:
In sip.conf I have the following registry lines (I add the one of another provider Citytel, where everything works fine):
register=>4132xxxxxxx:yyyy@voipgateway.org/FromCitytel
register=>031xxxxxxx:yyyy#@sip.netvoip.ch/FromNetvoip
Note that I add a mnemonic string behind “/” that I re-use in extensions.conf to make things easier to read. Normally a good idea, but not in this case… Normally, Asterisk should forward this strung as “Contact:” header at registration. This works finw for Citytel:
REGISTER sip:voipgateway.org SIP/2.0
Via: SIP/2.0/UDP 217.162.x.x:5060;branch=z9hG4bK1c0b5b1c;rport
From: <sip:4132xxxxxxx@voipgateway.org>;tag=as14896e5b
To: <sip:4132xxxxxxx@voipgateway.org>
Call-ID: 5bb69b17643cf4230c26ede767c38c33@10.1.1.1
CSeq: 102 REGISTER
User-Agent: unknown
Max-Forwards: 70
Expires: 600
Contact: <sip:FromCitytel@217.162.x.x>
Event: registration
Content-Length: 0
As you can see, “FromCitytel” appears under “Contact:”. But the Netvoip registration packet looks different:
REGISTER sip:sip.netvoip.ch SIP/2.0
Via: SIP/2.0/UDP 217.162.x.x:5060;branch=z9hG4bK36a730fd;rport
From: <sip:031xxxxxxx@sip.netvoip.ch>;tag=as096d8708
To: <sip:031xxxxxxx@sip.netvoip.ch>
Call-ID: 7099da115a0cd9fb6bf066b5574ee273@10.1.1.1
CSeq: 102 REGISTER
User-Agent: unknown
Max-Forwards: 70
Expires: 600
Contact: <sip:031xxxxxxx@217.162.x.x>
Event: registration
Content-Length: 0
As you can see, Asterisk now puts the default username instead of the string I gave above into the Contact header! I didn’t check the code, but the only reason I could imagine while this is happening is the fact, that Netvoip uses numbers as usernames that start with a zero. Ths only solution for this problem is to use also this usernumber and no mnemonic inside extensions.conf… no big deal, IF you find that out… Still, it would be nicer to have it fixed.