SIP/2.0 401 Unauthorized response when dial 7777 to Asterisk

Hello:

I’m newbie in asterisk, please help me.

My context is as follows:
192.168.4.2 --> Asterisk 11.13.1 complied from source
192.168.4.4 --> Yeastar NeoGate TG100 GSM gateway

When I call from a GSM cell phone, my TG100 GSM gateway answers and dials extension 7777 (configured as a hotline on TG100) to asterisk server, but asterisk server sends me “SIP/2.0 401 Unauthorized” response, I think it’s a matter of contexts but I didn’t find the problem.

Below are sip.conf, extensions.conf and debug from 192.168.4.4 (TG100 GSM gateway).

Thanks in advance.

SIP.CONF

[general]
context = incoming-call
allowguest = yes
srvlookup = no
udpbindaddr = 0.0.0.0
tcpenable = no
qualify = yes

office
type = friend
host = dynamic
context = from-office-call
dtmfmode = auto
disallow = all
allow = g722
allow = alaw
allow = ulaw

201
description = grandstream-gxp2160
secret = 201

202
description = grandstream-dp715
secret = 202

203
description = grandstream-dp710
secret = 203

301
description = grandstream-gxp2130
secret = 301

401
description = grandstream-gxp2160
secret = 401

[11111111]
description = audiocodes-fxo-port5
type = friend
host = 192.168.4.3
secret = 11111111
context = incoming-call
canreinvite = no
dtmfmode = auto
disallow = all
allow = g722
allow = alaw
allow = ulaw

[555555555]
description = yeastar-neogate-tg100
type = friend
host = 192.168.4.4
secret = 555555555
context = incoming-call
canreinvite = no
dtmfmode = auto
disallow = all
allow = g722
allow = alaw
allow = ulaw

EXTENSIONS.CONF

[globals]

[incoming-call]
exten => _11111111,1,Goto(main-menu,start,1)
exten => _555555555,1,Goto(main-menu,start,1)
exten => _7777,1,Goto(main-menu,start,1)

[outgoing-call]
exten => _[24]XXXXXXX,1,Dial(SIP/${EXTEN}@11111111)
exten =>_09XXXXXXX,1,Dial(SIP/${EXTEN}@555555555)

[from-office-call]
exten => 0,1,Goto(main-menu,start,1)
exten => 201,1,Dial(SIP/201)
exten => 202,1,Dial(SIP/202)
exten => 203,1,Dial(SIP/203)
exten => 301,1,Dial(SIP/301)
exten => 401,1,Dial(SIP/401)
include => outgoing-call

[main-menu]
exten => start,1,Answer()
same => Wait(5)
same => n,Background(enter-ext-of-person)
same => n,WaitExten(20)
exten => 1,1,Dial(SIP/201,20)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => 2,1,Dial(SIP/202,20)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => 3,1,Dial(SIP/203,20)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => 4,1,Dial(SIP/301,20)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => 5,1,Dial(SIP/401,20)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => i,1,Playback(pbx-invalid)
same => n,Goto(main-menu,start,1)
exten => t,1,Playback(vm-goodbye)
same => n,Hangup()

DEBUG

<— SIP read from UDP:192.168.4.4:5060 —>
INVITE sip:7777@192.168.4.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:5060;branch=z9hG4bK0b7c4652;rport
Max-Forwards: 70
From: “999999999” sip:999999999@192.168.4.4;tag=as67354416
To: sip:7777@192.168.4.2:5060
Contact: sip:999999999@192.168.4.4
Call-ID: 12663beb04ae514f10c4b3a145368d5c@192.168.4.4
CSeq: 102 INVITE
User-Agent: TG100
Date: Wed, 12 Nov 2014 10:13:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 281

v=0
o=root 1426707418 1426707418 IN IP4 192.168.4.4
s=Asterisk PBX 1.6.2.6
c=IN IP4 192.168.4.4
t=0 0
m=audio 10048 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<------------->
— (14 headers 13 lines) —
Sending to 192.168.4.4:5060 (no NAT)
Sending to 192.168.4.4:5060 (no NAT)
Using INVITE request as basis request - 12663beb04ae514f10c4b3a145368d5c@192.168.4.4
Found peer ‘555555555’ for ‘999999999’ from 192.168.4.4:5060

<— Reliably Transmitting (no NAT) to 192.168.4.4:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.4.4:5060;branch=z9hG4bK0b7c4652;received=192.168.4.4;rport=5060
From: “999999999” sip:999999999@192.168.4.4;tag=as67354416
To: sip:7777@192.168.4.2:5060;tag=as16de6e5c
Call-ID: 12663beb04ae514f10c4b3a145368d5c@192.168.4.4
CSeq: 102 INVITE
Server: Asterisk PBX 11.13.1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="72011a6b"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘12663beb04ae514f10c4b3a145368d5c@192.168.4.4’ in 6400 ms (Method: INVITE)

<— SIP read from UDP:192.168.4.4:5060 —>
ACK sip:7777@192.168.4.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.4.4:5060;branch=z9hG4bK0b7c4652;rport
Max-Forwards: 70
From: “999999999” sip:999999999@192.168.4.4;tag=as67354416
To: sip:7777@192.168.4.2:5060;tag=as16de6e5c
Contact: sip:999999999@192.168.4.4
Call-ID: 12663beb04ae514f10c4b3a145368d5c@192.168.4.4
CSeq: 102 ACK
User-Agent: TG100
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘6e9eab843b74d0860b108ed13a5d22c9@192.168.4.4’ Method: OPTIONS
Really destroying SIP dialog ‘12663beb04ae514f10c4b3a145368d5c@192.168.4.4’ Method: ACK
uc*CLI>

That is normal behaviour for a device which requires authentication. What happens next is what is important. If nothing happens, or the cycle repeats, it means that the gateway hasn’t been told that it needs to use a password.

Note: canreinvite is deprecated and allowguest=yes is normally a bad idea.

401 Unauthorized

The request requires user authentication. This response is issued by
UASs and registrars,

It is normal to get 401 and then retry with the right credentials.

Hello:

Thanks for both replies, I solved my issue by changing type=friend with type=peer in [555555555] section, afterwards, googling I’ve found this article that explain me why:

forums.digium.com/viewtopic.php?t=79338#p161214

[b]Re: type=friend is bad for you

Postby thor » Tue Aug 02, 2011 11:24 am
Another little known fact about the difference between peer and friend:
Friend will challenge INVITEs. When making outbound calls from a registered phone/peer another challenge will be issued.

This means type=friend requires second INVITE with authentication credentials, while peer will accept INVITE without challenge.

In other words type=friend does not care about the phone registration status and always tries to authenticate as if the phone never registered.[/b]