PJSIP trunk to another Asterisk 13 server unable to authenticate unless I set from_user = username

Asterisk Asterisk SIP
1

I am trying to connect two Asterisk 13 servers via PJSIP. Both behind a NAT firewall with ports open.
Server A registers to server B but calls only work B to A.

When calling from A to B I am getting below error on the CLI of B:

[2018-03-28 13:09:11] NOTICE[84068]: res_pjsip/pjsip_distributor.c:649 log_failed_request: Request 'INVITE' from '"Soft Client" <sip:4301@10.4.35.10>' failed for '203.0.113.1:5160' (callid: 82aea23e-f0f7-4430-839b-7c8604eba2af) - No matching endpoint found
[2018-03-28 13:09:11] NOTICE[129569]: res_pjsip/pjsip_distributor.c:649 log_failed_request: Request 'INVITE' from '"Soft Client" <sip:4301@10.4.35.10>' failed for '203.0.113.1:5160' (callid: 82aea23e-f0f7-4430-839b-7c8604eba2af) - No matching endpoint found
[2018-03-28 13:09:11] NOTICE[129569]: res_pjsip/pjsip_distributor.c:649 log_failed_request: Request 'INVITE' from '"Soft Client" <sip:4301@10.4.35.10>' failed for '203.0.113.1:5160' (callid: 82aea23e-f0f7-4430-839b-7c8604eba2af) - Failed to authenticate

If I however set from_user=username for server A in pjsip.conf, the call goes through, and shows the username as CallerID then.

Why would my call get denied without it?

One thing I noticed, the IP address in the From Header is the private IP of server A and not the external IP like it would be in chansip, not sure if this is an error.
Also the Invite contact header is Contact: <sip:asterisk@203.0.113.1:5160> Why is the “Asterisk” in there, shouldn’t this rather be the calling party <sip:4301@203.0.113.1:5160? In chansip it is.

Here is a SIP trace from Server A.

<--- Transmitting SIP request (944 bytes) to UDP:204.1.129.12:5160 --->
INVITE sip:5314@204.1.129.12:5160 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5160;rport;branch=z9hG4bKPj6c1c92c6-412c-4bb4-b832-d129dea04995
From: "Soft Client" <sip:4301@10.4.35.10>;tag=8e746a23-b936-42f0-a35d-e5897608275c
To: <sip:5314@204.1.129.12>
Contact: <sip:asterisk@203.0.113.1:5160>
Call-ID: 722491cd-8cda-4769-8dea-b76a90b37ffe
CSeq: 11207 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-13.0.194.5(13.19.1)
Content-Type: application/sdp
Content-Length:   265

v=0
o=- 1693146580 1693146580 IN IP4 203.0.113.1
s=Asterisk
c=IN IP4 203.0.113.1
t=0 0
m=audio 18192 RTP/AVP 9 0 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (592 bytes) from UDP:204.1.129.12:50233 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 203.0.113.1:5160;rport=5160;received=203.0.113.1;branch=z9hG4bKPj6c1c92c6-412c-4bb4-b832-d129dea04995
Call-ID: 722491cd-8cda-4769-8dea-b76a90b37ffe
From: "Soft Client" <sip:4301@10.4.35.10>;tag=8e746a23-b936-42f0-a35d-e5897608275c
To: <sip:5314@204.1.129.12>;tag=z9hG4bKPj6c1c92c6-412c-4bb4-b832-d129dea04995
CSeq: 11207 INVITE
WWW-Authenticate: Digest  realm="asterisk",nonce="1522258077/eaafde63e93f520c4490671a3d2fe562",opaque="18aa96de790c91e3",algorithm=md5,qop="auth"
Server: FPBX-13.0.194.5(13.18.3)
Content-Length:  0


<--- Transmitting SIP request (450 bytes) to UDP:204.1.129.12:5160 --->
ACK sip:5314@204.1.129.12:5160 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5160;rport;branch=z9hG4bKPj6c1c92c6-412c-4bb4-b832-d129dea04995
From: "Soft Client" <sip:4301@10.4.35.10>;tag=8e746a23-b936-42f0-a35d-e5897608275c
To: <sip:5314@204.1.129.12>;tag=z9hG4bKPj6c1c92c6-412c-4bb4-b832-d129dea04995
Call-ID: 722491cd-8cda-4769-8dea-b76a90b37ffe
CSeq: 11207 ACK
Max-Forwards: 70
User-Agent: FPBX-13.0.194.5(13.19.1)
Content-Length:  0


<--- Transmitting SIP request (1249 bytes) to UDP:204.1.129.12:5160 --->
INVITE sip:5314@204.1.129.12:5160 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5160;rport;branch=z9hG4bKPjd7ba004f-39fc-44d5-a0a4-41ee4891cdaa
From: "Soft Client" <sip:4301@10.4.35.10>;tag=8e746a23-b936-42f0-a35d-e5897608275c
To: <sip:5314@204.1.129.12>
Contact: <sip:asterisk@203.0.113.1:5160>
Call-ID: 722491cd-8cda-4769-8dea-b76a90b37ffe
CSeq: 11208 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-13.0.194.5(13.19.1)
Authorization: Digest username="TrunkAB", realm="asterisk", nonce="1522258077/eaafde63e93f520c4490671a3d2fe562", uri="sip:5314@204.1.129.12:5160", response="9348bb4fc7275fd011cdc2a96e27e0ad", algorithm=md5, cnonce="6bc73fdd-2d3d-4c5a-bb72-7e57bb3962fe", opaque="18aa96de790c91e3", qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length:   265

v=0
o=- 1693146580 1693146580 IN IP4 203.0.113.1
s=Asterisk
c=IN IP4 203.0.113.1
t=0 0
m=audio 18192 RTP/AVP 9 0 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (592 bytes) from UDP:204.1.129.12:50233 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 203.0.113.1:5160;rport=5160;received=203.0.113.1;branch=z9hG4bKPjd7ba004f-39fc-44d5-a0a4-41ee4891cdaa
Call-ID: 722491cd-8cda-4769-8dea-b76a90b37ffe
From: "Soft Client" <sip:4301@10.4.35.10>;tag=8e746a23-b936-42f0-a35d-e5897608275c
To: <sip:5314@204.1.129.12>;tag=z9hG4bKPjd7ba004f-39fc-44d5-a0a4-41ee4891cdaa
CSeq: 11208 INVITE
WWW-Authenticate: Digest  realm="asterisk",nonce="1522258077/eaafde63e93f520c4490671a3d2fe562",opaque="53ecc463222c0597",algorithm=md5,qop="auth"
Server: FPBX-13.0.194.5(13.18.3)
Content-Length:  0


<--- Transmitting SIP request (450 bytes) to UDP:204.1.129.12:5160 --->
ACK sip:5314@204.1.129.12:5160 SIP/2.0
Via: SIP/2.0/UDP 203.0.113.1:5160;rport;branch=z9hG4bKPjd7ba004f-39fc-44d5-a0a4-41ee4891cdaa
From: "Soft Client" <sip:4301@10.4.35.10>;tag=8e746a23-b936-42f0-a35d-e5897608275c
To: <sip:5314@204.1.129.12>;tag=z9hG4bKPjd7ba004f-39fc-44d5-a0a4-41ee4891cdaa
Call-ID: 722491cd-8cda-4769-8dea-b76a90b37ffe
CSeq: 11208 ACK
Max-Forwards: 70
User-Agent: FPBX-13.0.194.5(13.19.1)
Content-Length:  0


[2018-03-28 10:27:57] WARNING[175371]: res_pjsip_outbound_authenticator_digest.c:190 digest_create_request_with_auth_from_old: Endpoint: 'TrunkAB': Authentication credentials not accepted by server.
2

Config Server A:

[TrunkAB]
type=endpoint
transport=0.0.0.0-udp
context=from-internal
disallow=all
allow=g722,ulaw
aors=TrunkAB
language=en
outbound_auth=TrunkAB
auth=TrunkAB
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[TrunkAB]
type=aor
qualify_frequency=60
contact=sip:TrunkAB@204.1.129.12:5160

[TrunkAB]
type=auth
auth_type=userpass
password=password
username=TrunkAB

[TrunkAB]
type=registration
transport=0.0.0.0-udp
outbound_auth=TrunkAB
retry_interval=60
max_retries=10
expiration=3600
auth_rejection_permanent=yes
server_uri=sip:204.1.129.12:5160
client_uri=sip:TrunkAB@204.1.129.12:5160

[TrunkAB]
type=identify
endpoint=TrunkAB
match=204.1.129.12

[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5160
external_media_address=203.0.113.1
external_signaling_address=203.0.113.1
allow_reload=yes
local_net=10.4.32.0/19
3

Config Server B:

[TrunkAB]
type=endpoint
transport=0.0.0.0-udp
context=from-internal
disallow=all
allow=g722,ulaw
aors=TrunkAB
language=en
outbound_auth=TrunkAB
auth=TrunkAB
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[TrunkAB]
type=aor
qualify_frequency=60
max_contacts=1

[TrunkAB]
type=auth
auth_type=userpass
password=password
username=TrunkAB

[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5160
external_media_address=204.1.129.12
external_signaling_address=204.1.129.12
allow_reload=yes
local_net=10.1.0.0/19
4

The config on server B has no IP based matching, so it is using user based authentication. The default for user based authentication is to match the endpoint based on the user portion of the From header. There is also the possibility of using the authentication username by using “auth_username” in the endpoint identifier order. Finally for callerid P-Asserted-Identity or Remote-Party-ID should be used, using the send_pai and send_rpid options respectively. To trust it you would need trust_id_inbound set to yes.

1 Like
5

If server B is being registered to, is there then no way to use IP based matching?

6

PJSIP does not currently supporting using a registered IP address to do inbound IP based matching.

7

Thanks.

What does the “asterisk” mean in the contact header, is that desired or indicating an error? I have never seen that in chansip.

8

It’s just the address at which in-dialog requests should go into. There is no error or problem with that.

9

The IP address in the From header is the private IP of the server.
In chansip it’s the external IP.

Desired or error?

10

That also doesn’t matter. It’s not used by Asterisk, and in the cases of ITSPs the from_domain option should be set to specify what they expect if needed.

11

Is there documentation somewhere explaining how and what headers Asterisk is using specifically?

12

I believe there’s documentation on the wiki about using the From header to match endpoint. Otherwise stuff is used in a general SIP fashion so there’s nothing explicit (like using PAI or RPID for callerid).

13

And you said that the auth_username= parameter would go into the identify section?
Like this?

[TrunkAB]
type=identify
endpoint=TrunkAB
match=204.1.129.12
auth_username=TrunkAB

I don’t see that value in pjsip show identify TrunkAB

localhost*CLI> pjsip show identify TrunkAB

 Identify:  <Identify/Endpoint...........................................................>
      Match:  <criteria...........................>
==========================================================================================

 Identify:  TrunkAB/TrunkAB
      Match: 204.1.129.12/32


 ParameterName : ParameterValue
 =============================================
 endpoint      : TrunkAB
 match         : 204.1.129.12/255.255.255.255
 match_header  :
 srv_lookups   : true
14

No, it’s set in the global section[1].

[1] https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L995

15

How do I then set it per endpoint?

16

There is an identify_by option on the endpoint[1] but you must put it in the endpoint identifier order as well.

[1] https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L633

17

Let me see if I understand this.
The endpoint identifier order must be in the global section.
E.g.:

[global]
type=global
endpoint_identifier_order=ip,auth_username,username,anonymous

In the endpoint section I put in identify_by=auth_username
Like this:

[TrunkAB]
type=endpoint
transport=0.0.0.0-udp
identify_by=auth_username

Then where is the actual auth_username= value set for each endpoint?

18

There is no auth_username= value. We challenge for authentication, the remote side responds with authentication details which include an authentication username in it. We use that username to look up the endpoint. That is the purpose of auth_username.

19

I currently don’t have a endpoint_identifier_order in the global section but when I do pjsip show identifiers, I get this, which I guess shows me the current default identifier order from top to bottom:

localhost*CLI> pjsip show identifiers
Identifier Names:
name not specified
name not specified
ip
username
anonymous
auth_username

Now I am wondering if I change the order, and that can only be done globally, will that have any adverse effects to other PJSIP endpoints not using auth_username?

20

It probably won’t impact things at all.