Inbound call rejected on SIP trunk

Asterisk Asterisk Support
1

I have Asterisk 11.9.0 and Free PBX 12.0.18 on CentOS.
I have a SIP trunk connected to a Digium G200 Gateway. Inbound calls fail and I get following error:

WARNING[2443][C-00000275]: chan_sip.c:16491 check_auth: username mismatch, have <2365>, digest has
[2014-12-12 15:00:52] NOTICE[2443][C-00000275]: chan_sip.c:25611 handle_request_invite: Failed to authenticate device "▒Jonathan Klein " sip:2365@10.1.1.125;tag=as4a614331

These are my peer details in outgoing settings in free PBX:
host=10.1.1.125
type=friend
context=from-trunk
insecure=very
defaultuser=Cloud
secret=…

Inbound settings are empty.
Strangely, I had had it working with these settings for a while. Didn’t know what changes I made apart from upgrading Free PBX.
Can you help?

2

The bit in square brackets is important.

However, the normal reason for this is neither using insecure=invite, nor using remotesecret instead of secret. insecure=very was deprecated and may well have been discontinued.

3

Thank you.
I have changed the peer details. Still no inbound calls with same error message. Any other ideas?
host=10.1.1.125
type=friend
context=from-trunk
insecure=invite
defaultuser=Cloud
remotesecret=…

[2014-12-12 18:08:26] WARNING[2443][C-000002ac]: chan_sip.c:16491 check_auth: username mismatch, have <2365>, digest has
[2014-12-12 18:08:26] NOTICE[2443][C-000002ac]: chan_sip.c:25611 handle_request_invite: Failed to authenticate device "▒Jonathan Klein " sip:2365@10.1.1.125;tag=as3b386d47

4

The bit in square brackets is important. It should match one of two identifiers given and I want to know which.

With insecure=invite, Asterisk should not send 401, so there should be no authentication data. Maybe the peer is sending authentication data without being properly challenged for it.

In any case, you need to provide the first INVITE, any 401 and any second INVITE.

5


[2014-12-12 18:08:26] WARNING[2443][C-000002ac]: chan_sip.c:16491 check_auth: username mismatch, have <2365>, digest has

On the trunk setting in your freepbx replace Cloud name for 2365… This would fix the issue

6

Thinking more about this, I suspect you are seeing why using type=friend is usually a bad thing. Your incoming calls are probably showing the same callerID as a local extension, and therefore matching the entry for a local extension in the type=user role of type=friend.

Unfortunately, you have generally insisted on providing too little information to see what was going on (e.g. seeing that the trunk device name wasn’t 2385 would have been a good clue), so one could not confirm this from the information you have provided. Like blind use of insecure=very, blind use of type=friend is so common that one often tends to ignore it’s questionable use.

7

Thanks to all of you for your helpful comments. I will try to give you all the info that you need to help me solve the problem.
My SIP trunk is connected to a Digium G200 gateway, which connects to another PBX on ISDN trunks. When I make a call from my other PBX to an Asterik extension over the SIP trunk, the call gets rejected with below error. “2365” in that case is the extension I am calling from, and “Cloud” is the username of the SIP endpoint on the G200, and also part of the register string Cloud:secret@10.1.1.125.
So Asterisk confuses the extension number that I am calling from with the username of the SIP endpoint of the gateway.
Setting type to “user” in peer settings, returns the same error.
I also have H.323 trunks between the two PBXs and everything works there.
I noticed, when I disable sending callerID on the ISDN trunk to the gateway, my call completes.

David55, I would like to provide you the first INVITE, any 401 and any second INVITE. Where do I get that information exactly?
(Relatively new to Asterisk)

8

The correct setting is type=peer. user causes it only to match based on the From header, but the From header is being used for the remote caller ID, not the local line identity. You must use this on the local devices. The name will still be used for matching registrations.

sip set debug on.

or, wireshark, etc.

9

Here is some info from SIP debug. Hope that helps.
Changed to “Peer” in trunk settings.

<— SIP read from UDP:10.1.1.125:5060 —>
INVITE sip:5314@10.1.1.184:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.125:5060;branch=z9hG4bK02f2999a
Max-Forwards: 70
From: “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9
To: sip:5314@10.1.1.184:5060
Contact: sip:2250@10.1.1.125:5060
Call-ID: 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
CSeq: 102 INVITE
User-Agent: Digium Gateway
Date: Sun, 14 Dec 2014 15:51:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Remote-Party-ID: “O.Jennifer” sip:2250@;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 402

v=0
o=root 2006111532 2006111532 IN IP4 10.1.1.125
s=Digium Gateway
c=IN IP4 10.1.1.125
t=0 0
m=audio 10836 RTP/AVP 0 8 9 111 18 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------->
— (15 headers 18 lines) —
Sending to 10.1.1.125:5060 (no NAT)
Sending to 10.1.1.125:5060 (no NAT)
Using INVITE request as basis request - 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
Found peer ‘2250’ for ‘2250’ from 10.1.1.125:5060

<— Reliably Transmitting (no NAT) to 10.1.1.125:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.1.1.125:5060;branch=z9hG4bK02f2999a;received=10.1.1.125
From: “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9
To: sip:5314@10.1.1.184:5060;tag=as3ea3f58c
Call-ID: 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
CSeq: 102 INVITE
Server: FPBX-12.0.18(11.9.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="22dc9bde"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060’ in 6400 ms (Method: INVITE)

<— SIP read from UDP:10.1.1.125:5060 —>
ACK sip:5314@10.1.1.184:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.125:5060;branch=z9hG4bK02f2999a
Max-Forwards: 70
From: “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9
To: sip:5314@10.1.1.184:5060;tag=as3ea3f58c
Contact: sip:2250@10.1.1.125:5060
Call-ID: 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
CSeq: 102 ACK
User-Agent: Digium Gateway
Content-Length: 0

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

<— SIP read from UDP:10.1.1.125:5060 —>
INVITE sip:5314@10.1.1.184:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.125:5060;branch=z9hG4bK0a7ec00b
Max-Forwards: 70
From: “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9
To: sip:5314@10.1.1.184:5060
Contact: sip:2250@10.1.1.125:5060
Call-ID: 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
CSeq: 103 INVITE
User-Agent: Digium Gateway
Authorization: Digest username=“Cloud”, realm=“asterisk”, algorithm=MD5, uri=“sip:5314@10.1.1.184:5060”, nonce=“22dc9bde”, response="68a41ab03e06864827b36cd125d2b4a2"
Date: Sun, 14 Dec 2014 15:51:32 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Remote-Party-ID: “O.Jennifer” sip:2250@;party=calling;privacy=off;screen=no
Content-Type: application/sdp
Content-Length: 402

v=0
o=root 2006111532 2006111533 IN IP4 10.1.1.125
s=Digium Gateway
c=IN IP4 10.1.1.125
t=0 0
m=audio 10836 RTP/AVP 0 8 9 111 18 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------->
— (16 headers 18 lines) —
Sending to 10.1.1.125:5060 (no NAT)
Using INVITE request as basis request - 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
Found peer ‘2250’ for ‘2250’ from 10.1.1.125:5060
[2014-12-14 10:51:32] WARNING[23625][C-000000bf]: chan_sip.c:16491 check_auth: username mismatch, have <2250>, digest has
[2014-12-14 10:51:32] NOTICE[23625][C-000000bf]: chan_sip.c:25611 handle_request_invite: Failed to authenticate device “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9

<— Reliably Transmitting (no NAT) to 10.1.1.125:5060 —>
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.1.1.125:5060;branch=z9hG4bK0a7ec00b;received=10.1.1.125
From: “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9
To: sip:5314@10.1.1.184:5060;tag=as3ea3f58c
Call-ID: 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
CSeq: 103 INVITE
Server: FPBX-12.0.18(11.9.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060’ in 6400 ms (Method: INVITE)

<— SIP read from UDP:10.1.1.125:5060 —>
ACK sip:5314@10.1.1.184:5060 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.125:5060;branch=z9hG4bK0a7ec00b
Max-Forwards: 70
From: “O.Jennifer” sip:2250@10.1.1.125;tag=as0535b0c9
To: sip:5314@10.1.1.184:5060;tag=as3ea3f58c
Contact: sip:2250@10.1.1.125:5060
Call-ID: 1fff11d67fe5f14c1b6604f05212992e@10.1.1.125:5060
CSeq: 103 ACK
User-Agent: Digium Gateway
Content-Length: 0

10

Change 2250 to peer.

11

2250 is an analog phone on my old PBX. The digits get send on an ISDN trunk to a SIP gateway, from there to Asterisk. If I turn send CallerID off on the ISDN trunk, the call completes. With send CallerID on, it fails.

12

Change 2250 to be type=peer.

13

Unfortunately there is no way to change 2250 to type=peer.
2250 is the extension on an analog phone on an Avaya PBX.
The only thing I can think of is to change the settings on the SIP endpoint on the Digium gateway to something equivalent of peer, but don’t find any settings to tweak. Have basically tried everything.
Someone here in the forum familiar with Digium ISDN to SIP gateways?

14

Asterisk is behaving as though there were a [2250] in sip.conf and it was set up as user or friend.

Found peer '2250' for '2250' from 10.1.1.125:5060

15

Any other idea what I could do about that? When I initially set this up, I had the same problem which I solved by adding insecure=very (now insecure=invite) to the peer details of the trunk. I don’t know what changed, but for a few weeks it hasn’t been working anymore.