401 error with sipgate while registered!

I want to configure Asterisk as SIP client. When a call is made towards the DID (from sipgate), I want to route the call to a local user (6000). I have configured sipgate.de and when I execute sip show registry in the console, it shows:

Host dnsmgr Username Refresh State
Reg.Time
sipgate.de:5060 N 2394288 1785 [color=red]Registered[/color]
Sun, 27 Sep 2009 16:21:34
1 SIP registrations.

When I look at the peers, I see 3:
Name/username Host Dyn Nat ACL Port Status
2394288/2394288 217.10.79.9 N 5060 Unmonitored
6000/xlite 10.164.4.46 D 50886 Unmonitored
incoming 217.10.79.9 5060 Unmonitored
3 sip peers [Monitored: 0 online, 0 offline Unmonitored: 3 online, 0 offline]

I have traced the SIP messages, and see the following, when I call my DID number:

<— SIP read from UDP://217.10.79.9:5060 —>
INVITE sip:2394288@10.131.1.0:5060 SIP/2.0
Record-Route: sip:217.10.79.9;lr=on;ftag=as2fe2de1e
Record-Route: sip:172.20.40.2;lr=on
Record-Route: sip:217.10.79.9;lr=on;ftag=as2fe2de1e
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK8659.b7356ef2.0
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK8659.b7356ef2.0
Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK6115a311
Via: SIP/2.0/UDP 217.10.67.13:5060;branch=z9hG4bK6115a311;rport=5060
From: “” <sip:@sipgate.de>;tag=as2fe2de1e
To: sip:004924153807890@sipgate.de
Contact: <sip:@217.10.67.13>
Call-ID: 6f21e9585b435f3c0a22ea8b0a7445ab@sipgate.de
CSeq: 102 INVITE
Max-Forwards: 67
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 363

v=0
o=root 22417 22417 IN IP4 217.10.67.13
s=session
c=IN IP4 217.10.67.13
t=0 0
m=audio 15022 RTP/AVP 8 0 3 97 112 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:112 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------->
— (18 headers 17 lines) —
== Using SIP RTP CoS mark 5
Sending to 217.10.79.9 : 5060 (no NAT)
Using INVITE request as basis request - 6f21e9585b435f3c0a22ea8b0a7445ab@sipgate
.de
[color=red]Found peer ‘2394288’ for ‘’[/color] from 217.10.79.9:5060
ac-vm-brink-linux1*CLI>
<— Reliably Transmitting (NAT) to 217.10.79.9:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK8659.b7356ef2.0;received=217.10.
79.9
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK8659.b7356ef2.0
Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK6115a311
Via: SIP/2.0/UDP 217.10.67.13:5060;branch=z9hG4bK6115a311;rport=5060
From: “” <sip:@sipgate.de>;tag=as2fe2de1e
To: sip:004924153807890@sipgate.de;tag=as0abe516b
Call-ID: 6f21e9585b435f3c0a22ea8b0a7445ab@sipgate.de
CSeq: 102 INVITE
Server: Asterisk PBX 1.6.1.6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="34ff43e4"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog '6f21e9585b435f3c0a22ea8b0a7445ab@sipgate.d
e’ in 32000 ms (Method: INVITE)
ac-vm-brink-linux1*CLI>
<— SIP read from UDP://217.10.79.9:5060 —>
ACK sip:2394288@10.131.1.0:5060 SIP/2.0
Max-Forwards: 10
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK8659.b7356ef2.0
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK8659.b7356ef2.0
From: “” <sip:@sipgate.de>;tag=as2fe2de1e
Call-ID: 6f21e9585b435f3c0a22ea8b0a7445ab@sipgate.de
To: sip:004924153807890@sipgate.de;tag=as0abe516b
CSeq: 102 ACK
Content-Length: 0
X-hint: rr-enforced

<------------->
— (10 headers 0 lines) —

My extensions.conf:

[code]
[general]
exten => _0.,1,NoOp(Call via sipgate.de)
exten => _0.,2, Ringing
exten => _0.,3,SetCallerID(Jan van den Brink)
exten => _0.,4,Dial(SIP/${EXTEN:1}@2394288,60)
exten => _0.,5,Hangup

[incoming]
exten => 2394288,1,NoOp(— ${CALLERID} calling on sipgate (${EXTEN}) —)
exten => 2394288,2,Ringing
exten => 2394288,3,Wait(1)
exten => 2394288,4,Dial(SIP/6000,30)

this context is specified in sip.conf:

[general]
port=5060
bindaddr=0.0.0.0
context=default
register=>2394288:<password>@sipgate.de/2394288

[2394288]
type=peer
username=2394288
fromuser=2394288
secret=<password>
context=default
host=sipgate.de
fromdomain=sipgate.de
insecure=port,invite
caninvite=no
canreinvite=no
nat=yes
externip=62.134.199.226
localnet=10.131.1.0/255.255.254.0
quality=yes
disallow=all
allow=ulaw
allow=alaw

[incoming]
type=peer
fromdomain=sipgate.de
host=sipgate.de
context=incoming
disallow=all
allow=ulaw
allow=alaw

Any idea?

Possibly because you have specified a domain name, but they have specified an IP address?

Thanks for your reply! This SIP provider doesn’t require a domain or IP address. It uses my account from any PC (using a softphone), with only my account settings (user ID and password). Registration seems to go OK, according to logging?

Asterisk needs to be able to locate the peer section according to address information in the incoming INVITE. I’m not entirely sure where it takes that address from, without checking the RFC, but I suspect it is ending up failing to match and therefore falling back to trying to authenticate as a user (even though you may have no users configured).

Hi

Couple of things

[2394288]
type=peer
username=2394288
fromuser=2394288
secret=
context=default <<<<<<<<try changing this to incoming
host=sipgate.de
fromdomain=sipgate.de
insecure=port,invite
caninvite=no <<<<<<<<<<Whats this ?
canreinvite=no
nat=yes
externip=62.134.199.226 <<<<<<<<<<These should be in
localnet=10.131.1.0/255.255.254.0<<<<<<your General section
quality=yes <<<<<<<do you mean qualify ?
disallow=all
allow=ulaw
allow=alaw

Ian

Hi all,

Many thanks but still no success. I’ve made all changes (indeed quality needs to be qualify) and changed the context into “incoming” for peer 2394288. In the logging, I see the following:

Found peer '2394288' for '0031xxxxxxxxx' from 217.10.79.9:5060

But still I’m getting a 401 error right after this log message, after I’ve reloaded the configuration. The invites I see afterwards doesn’t show any externip (62.134.199.226) info, only the sipgate addresses (217.x.x.x) and my internal address (10.131.1.0):

INVITE sip:2394288@10.131.1.0:5060 SIP/2.0
Record-Route: <sip:217.10.79.9;lr=on;ftag=as3d4ad0ed>
Record-Route: <sip:172.20.40.2;lr=on>
Record-Route: <sip:217.10.79.9;lr=on;ftag=as3d4ad0ed>
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK9c24.a5f91ba6.0
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK9c24.a5f91ba6.0
Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK65973af3
Via: SIP/2.0/UDP 217.10.67.142:5060;branch=z9hG4bK65973af3;rport=5060
From: "0031xxxxxxxxx" <sip:0031xxxxxxxxx@sipgate.de>;tag=as3d4ad0ed
To: <sip:004924153807890@sipgate.de>
Contact: <sip:0031xxxxxxxxx@217.10.67.142>
Call-ID: 7472df747c06916f5af69195459914ba@sipgate.de
CSeq: 102 INVITE
Max-Forwards: 67
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 367

Please ignore what I said about not matching on the address, as the trace does show that it has matched the entry.

Looking at the description of insecure=, I wonder if it is matching on the user name in the INVITE header and therefore ignoring the insecure= settings.

Also, there is something weird about the routing of this call. What’s 172.20.40.2? I think that might be sinking the 401.

in your general section add nat=yes

also try a full sip capture and look at it in wireshark.
howto at cyber-cottage.co.uk/site/images/ … kdebug.pdf

Ian

If the description of insecure in TFOT is correct, I think the fact that the contact address doesn’t match the one address returned by nslookup sipgate.de may be preventing the insecure match. I think I would need to read the code to be sure whether TFOT is correct on this point, for current versions.

OK

Follow this secure.sipgate.de/faq/index.php … 540&id=257

I think the issue si that you have set a peer up as well as regetring.
so when the call comes in its ound by the peer and trys to authenticate with sipgate

Set it up as per the howto and see how it goes

If I have my German incomings and outgoings the right way round, https://secure.sipgate.de/faq/index.php?do=displayArticle&article=1185&id=257 specifically relates to the problem.

Annoyingly, they have anti-deep linking measures, so you will need re-enter the URL once you have a cookie!

Looks like you need to be a friend, not just a peer, for 1.6 plus.

Hi

There were changes to how sip peers and friends work in 1.6

heres a snippet

; * The type=peer also handles both incoming and outbound calls. On inbound calls, ; Asterisk only matches on IP/port, not on names. This is mostly used for SIP ; trunks.

with sipgate you dont actually need the peer defined at all. I have a test trunk thats used for incoming only and it just has the register line in the sip.conf and works fine.

Hi all, thanks for the suggestions! I made all the suggested changes, added nat=yes to the general section and installed tshark on my ubuntu server. Did a tshark trace, and could see the SIP messages. Below the output after selecting follow UDP stream:

== From Asterisk ==
....OPTIONS sip:sipgate.de SIP/2.0
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK6f5f5c2c;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@62.134.199.226>;tag=as0d0a3e1a
To: <sip:sipgate.de>
Contact: <sip:asterisk@62.134.199.226>
Call-ID: 301ebb1f01d842f346dec3d91501e8b1@62.134.199.226
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.6.1.6
Date: Wed, 30 Sep 2009 01:49:19 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

== From sipgate ==
SIP/2.0 200 OK
Record-Route: <sip:217.10.79.9;lr=on;ftag=as0d0a3e1a>
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK6f5f5c2c;rport=53481
From: "asterisk" <sip:asterisk@62.134.199.226>;tag=as0d0a3e1a
To: <sip:sipgate.de>;tag=4fa8f7eb71cc68cca91a14abea886308.70b6
Call-ID: 301ebb1f01d842f346dec3d91501e8b1@62.134.199.226
CSeq: 102 OPTIONS
Accept: */*
Accept-Encoding: 
Accept-Language: en
Supported: 
Content-Length: 0

== From Asterisk ==
....REGISTER sip:sipgate.de SIP/2.0
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK7da6682f;rport
Max-Forwards: 70
From: <sip:2394288@sipgate.de>;tag=as1be5b012
To: <sip:2394288@sipgate.de>
Call-ID: 6b914a4e26863309556416724fbd850e@127.0.1.1
CSeq: 112 REGISTER
User-Agent: Asterisk PBX 1.6.1.6
Authorization: Digest username="2394288", realm="sipgate.de", algorithm=MD5, uri="sip:sipgate.de", nonce="4ac267629ecf6f675100295864337ce9c8b49207", response="76f59f4d5e299333b8cbcdc8c7cdb6c5"
Expires: 1800
Contact: <sip:2394288@62.134.199.226>
Content-Length: 0

== From sipgate ==
SIP/2.0 200 OK
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK7da6682f;rport=53481
From: <sip:2394288@sipgate.de>;tag=as1be5b012
To: <sip:2394288@sipgate.de>;tag=8367f0f887e3954243ec30fa0f5db288.9802
Call-ID: 6b914a4e26863309556416724fbd850e@127.0.1.1
CSeq: 112 REGISTER
Contact: <sip:2394288@62.134.199.226>;expires=600;received="sip:10.131.1.0:5060"
Content-Length: 0

== From Asterisk ==
OPTIONS sip:sipgate.de SIP/2.0
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK3f558830;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@62.134.199.226>;tag=as738e4303
To: <sip:sipgate.de>
Contact: <sip:asterisk@62.134.199.226>
Call-ID: 70f97c16288c6290262126f623f1539b@62.134.199.226
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.6.1.6
Date: Wed, 30 Sep 2009 01:49:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

== From sipgate == 
SIP/2.0 200 OK
Record-Route: <sip:217.10.79.9;lr=on;ftag=as738e4303>
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK3f558830;rport=53481
From: "asterisk" <sip:asterisk@62.134.199.226>;tag=as738e4303
To: <sip:sipgate.de>;tag=4fa8f7eb71cc68cca91a14abea886308.4ccc
Call-ID: 70f97c16288c6290262126f623f1539b@62.134.199.226
CSeq: 102 OPTIONS
Accept: */*
Accept-Encoding: 
Accept-Language: en
Supported: 
Content-Length: 0

== From Asterisk ==
....................OPTIONS sip:sipgate.de SIP/2.0
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK79f273be;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@62.134.199.226>;tag=as4c62751a
To: <sip:sipgate.de>
Contact: <sip:asterisk@62.134.199.226>
Call-ID: 7e94211964b2a899438ec28f78755517@62.134.199.226
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.6.1.6
Date: Wed, 30 Sep 2009 01:50:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

== From sipgate ==
SIP/2.0 200 OK
Record-Route: <sip:217.10.79.9;lr=on;ftag=as4c62751a>
Via: SIP/2.0/UDP 62.134.199.226:5060;branch=z9hG4bK79f273be;rport=53481
From: "asterisk" <sip:asterisk@62.134.199.226>;tag=as4c62751a
To: <sip:sipgate.de>;tag=4fa8f7eb71cc68cca91a14abea886308.9b99
Call-ID: 7e94211964b2a899438ec28f78755517@62.134.199.226
CSeq: 102 OPTIONS
Accept: */*
Accept-Encoding: 
Accept-Language: en
Supported: 
Content-Length: 0

....INVITE sip:2394288@62.134.199.226 SIP/2.0
Record-Route: <sip:217.10.79.9;lr=on;ftag=as5c792f69>
Record-Route: <sip:172.20.40.2;lr=on>
Record-Route: <sip:217.10.79.9;lr=on;ftag=as5c792f69>
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6338.0a7e78a3.0
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6338.0a7e78a3.0
Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK62bff2db
Via: SIP/2.0/UDP 217.10.67.141:5060;branch=z9hG4bK62bff2db;rport=5060
From: "0031341260450" <sip:0031341260450@sipgate.de>;tag=as5c792f69
To: <sip:004924153807890@sipgate.de>
Contact: <sip:0031341260450@217.10.67.141>
Call-ID: 0a35bda10dcb22ed717c9d5b5b835d2f@sipgate.de
CSeq: 102 INVITE
Max-Forwards: 67
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 404

v=0
o=root 10939 10939 IN IP4 217.10.67.141
s=session
c=IN IP4 217.10.77.20
t=0 0
m=audio 46432 RTP/AVP 8 0 3 18 112 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:112 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=direction:active
a=nortpproxy:yes

== From Asterisk ==
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6338.0a7e78a3.0;received=217.10.79.9
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6338.0a7e78a3.0
Via: SIP/2.0/UDP 217.10.79.9:5060;received=217.10.68.226;branch=z9hG4bK62bff2db
Via: SIP/2.0/UDP 217.10.67.141:5060;branch=z9hG4bK62bff2db;rport=5060
From: "0031341260450" 
sip:0031341260450@sipgate.de>;tag=as5c792f69
To: <sip:004924153807890@sipgate.de>;tag=as3bd85dda
Call-ID: 0a35bda10dcb22ed717c9d5b5b835d2f@sipgate.de
CSeq: 102 INVITE
Server: Asterisk PBX 1.6.1.6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4fbd8bca"
Content-Length: 0

== From sipgate ==
ACK sip:2394288@62.134.199.226 SIP/2.0
Max-Forwards: 10
Via: SIP/2.0/UDP 217.10.79.9:5060;branch=z9hG4bK6338.0a7e78a3.0
Via: SIP/2.0/UDP 172.20.40.2;branch=z9hG4bK6338.0a7e78a3.0
From: "0031341260450" <sip:0031341260450@sipgate.de>;tag=as5c792f69
Call-ID: 0a35bda10dcb22ed717c9d5b5b835d2f@sipgate.de
To: <sip:004924153807890@sipgate.de>;tag=as3bd85dda
CSeq: 102 ACK
Content-Length: 0
X-hint: rr-enforced

Still Asterisk is sending the 401 error, after the INVITE from the SIP gateway.

Looks like TFOT is wrong/out of date on this.

The match logic is find the first fit of:

  1. match by From: user field, only for users and friends
    2)match by source IP address only for peers and friends
  2. match Contact header address field by IP address for peers and friends.
  3. match “default” if permitted.

Once it has the structure, it makes local copies of the secret and md5secret, then destroys them if insecure has invite set. If these copies are null, it passes the peer as authenticated without challenging it. The insecure= line looks good and I cannot see anything wrong with the code.

However, what I’ve just realised is that you have two peers in sip.conf with host=sipgate.de! The search for the IP address is only going to find one of them, and which one may not be the obvious first one. The second section, [incoming], doesn’t have an insecure option.

This configuration is unsafe, because two peers match the same address, however it still leaves some questions, as the trace is reporting the name of the peer that does have insecure and the [incoming] peer doesn’t have any secrets.

Thanks for the explanation. It makes more sense now, so I’ve changed the configuration a bit and I’m focussing now completely on the incoming traffic (calls from sipgate). The config looks now like:

[general]
port=5060
bindaddr=0.0.0.0
context=incoming
register=>2394288:<password>@sipgate.de/2394288
externip=62.134.199.226
localnet=10.131.1.0/255.255.254.0
qualify=yes
nat=yes
srvlookup=yes
autodomain=yes
insecure=port,invite
disallow=all
allow=ulaw
allow=alaw

[2394288]
type=peer
username=2394288
fromuser=2394288
secret=<password>
context=incoming
host=sipgate.de
fromdomain=sipgate.de
insecure=port,invite
nat=yes
qualify=yes
disallow=all
allow=ulaw
allow=alaw

If I reload, I see the following notice:

[Sep 30 14:57:12] NOTICE[15141]: chan_sip.c:23281 reload_config: Can't add wildcard IP address to domain list, please add IP address to domain manually.

I also found an interesting note on voip-info.org:

This configuration still gives the same 401 error. I thought that adding srvlookup would help with finding the correct IP/domain stuff. Should I add a domain statement too?

The warning is the result of specifying both bindaddr=0.0.0.0 and specifying localnets. I don’t think it is relevant.

Hi

As we are using 1.6 here , most old and published knowledge on how sip peers work is obsolete, so we need to go through the settings.

No we see that autodomain=yes is set, this warning is refered to in the bugtracker…

Also as its set we need to check th edomains

so run

sip show domains

and

sip show settings

using the autodomain setting is the same as setting a domain

see

[quote]sip.conf domain=
With the domain statement you may handle more than one domain on an asterisk server. In section general you may add

domain=,

Calls to will go to context [], overriding (!) the general and peer default context.
You may have several domain= lines in your sip.conf.

Note: If you have registered with a remote service (and obtained e.g. a DID that way) the incoming call will be sent to your extension@ip, not to extension@domain. It appears that in the case of an IP Asterisk applies the default context (or does it do so for any incoming call that does not match one of the specified domains?) [/quote]

I would set it to no restart asterisk and then see whats happening.

It works!!! Thank you all for your help on this, really appreciate a lot! Give me a ping whenever you come to Holland, and I’ll buy you a Heineken!

Hi

Ill remember that :smiley:

Ian

Not just the old documentation. I was actually using the source code comments on the exact version in use, and assumed that code actually did what they said.

Admittedly, I did wonder about the if (autodomain) in the code itself.