PJSIP Registering to NEC PABX Fails with 403 (works with chan_sip)

Hi there,

Pretty new to Asterisk and I’m trying to SIP register to an NEC PABX. I can do it with chan_sip but I’d really prefer to use PJSIP. I’m getting a 403 forbidden. Any help would be much appreciated. I captured the interaction below. IP addresses etc have been obfuscated.

REGISTER sip:10.54.211.19:5060 SIP/2.0
Via: SIP/2.0/UDP 10.61.161.134:5060;rport;branch=z9hG4bKPj5fb58123-febe-4b2e-9478-65f10d9d2588
From: <sip:90658@10.54.211.19>;tag=55ec7acf-42c2-43f1-9e53-4dfb343a9269
To: <sip:90658@10.54.211.19>
Call-ID: c03a7a5c-96f6-4c05-ba7d-e1a9ce2a3bea
CSeq: 15008 REGISTER
Contact: <sip:90658@10.61.161.134:5060>
Expires: 3600
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Max-Forwards: 70
User-Agent: Asterisk PBX 14.4.0
Content-Length:  0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.61.161.134:5060;rport;branch=z9hG4bKPj5fb58123-febe-4b2e-9478-65f10d9d2588
From: <sip:90658@10.54.211.19>;tag=55ec7acf-42c2-43f1-9e53-4dfb343a9269
To: <sip:90658@10.54.211.19>;tag=09ee9ecc
Call-ID: c03a7a5c-96f6-4c05-ba7d-e1a9ce2a3bea
CSeq: 15008 REGISTER
WWW-Authenticate: Digest realm="insiph@ippbx0a44c303.com", nonce="62fc0645ee9daac4ef278bb26f966401", opaque="a271cac4fdef6bb07e36e958b668264e", stale=FALSE, algorithm=MD5, qop="auth"
User-Agent: Enterprise IP-PBX (InSIPH)
Allow: INVITE, ACK, REGISTER, BYE, OPTIONS, INFO, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Length: 0

REGISTER sip:10.54.211.19:5060 SIP/2.0
Via: SIP/2.0/UDP 10.61.161.134:5060;rport;branch=z9hG4bKPj296c53b3-6ef6-433c-8626-1009f6217ced
From: <sip:90658@10.54.211.19>;tag=55ec7acf-42c2-43f1-9e53-4dfb343a9269
To: <sip:90658@10.54.211.19>
Call-ID: c03a7a5c-96f6-4c05-ba7d-e1a9ce2a3bea
CSeq: 15009 REGISTER
Contact: <sip:90658@10.61.161.134:5060>
Expires: 3600
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Max-Forwards: 70
User-Agent: Asterisk PBX 14.4.0
Authorization: Digest username="90658", realm="insiph@ippbx0a44c303.com", nonce="62fc0645ee9daac4ef278bb26f966401", uri="sip:10.54.211.19:5060", response="5744963f4b45722de961bca69d2e2252", algorithm=MD5, cnonce="792214f2-6a4a-4734-aeac-5640e20cc476", opaque="a271cac4fdef6bb07e36e958b668264e", qop=auth, nc=00000001
Content-Length:  0

SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.61.161.134:5060;rport;branch=z9hG4bKPj296c53b3-6ef6-433c-8626-1009f6217ced
From: <sip:90658@10.54.211.19>;tag=55ec7acf-42c2-43f1-9e53-4dfb343a9269
To: <sip:90658@10.54.211.19>;tag=09edc595
Call-ID: c03a7a5c-96f6-4c05-ba7d-e1a9ce2a3bea
CSeq: 15009 REGISTER
User-Agent: Enterprise IP-PBX (InSIPH)
Allow: INVITE, ACK, REGISTER, BYE, OPTIONS, INFO, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Length: 0

My pjsip.conf contains the following:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

[transport-tcp]
type=transport
protocol=tcp
bind=0.0.0.0


;========================NEC  Registration======================

[nec-siptrunk-auth]
type=auth
auth_type=userpass
username=90658
password=

[nec-siptrunk-aor]
type=aor
contact=sip:10.54.211.19:5060

[nec-siptrunk]
type=endpoint
context=from-nec
disallow=all
allow=alaw
;allow=g722
;allow=ulaw
;allow=g729
outbound_auth=nec-siptrunk-auth
aors=nec-siptrunk-aor


[nec-siptrunk-registration]
type=registration
transport=transport-udp
outbound_auth=nec-siptrunk-auth
server_uri=sip:10.54.211.19:5060
client_uri=sip:90658@10.54.211.19
contact_user=90658
retry_interval=60

[nec-siptrunk-identify]
type=identify
match=10.54.211.19
endpoint=nec-siptrunk

Thanks,
Rhys

What is the equivalent chan_sip configuration, and have you compared the resulting packets between the two to see if there’s anything evidently different?

Hey, thanks for the reply. Here is the capture and the config for chan_sip. It looks like the auth registration that pjsip sends in response to the 401 is a bit different.

Note the cnonce - for pjsip is 36 chars long with hyphens but for chan_sip is only 8 chars long.

I did a test with the 3cx softphone (which works) and that includes a cnonce which is 32 chars long with no hyphens.

I guess there is something with the digest authentication that the NEC doesn’t like.

I note that pjsip says it supports AKAv1 and AKAv2 I wonder if it’s something to do with that? Although I couldn’t see a way to select the version so I’m probably barking up the wrong tree.

Cheers,
Rhys

chan_sip capture:

REGISTER sip:10.54.211.19 SIP/2.0
Via: SIP/2.0/UDP 10.61.161.134:5060;branch=z9hG4bK4ad13d0e
Max-Forwards: 70
From: <sip:90658@10.54.211.19>;tag=as2b5025bb
To: <sip:90658@10.54.211.19>
Call-ID: 4da8dcd33c04c79c742ee1681790e564@[fe80::7768:e9a9:ecab:dcab]
CSeq: 102 REGISTER
Supported: replaces
User-Agent: Asterisk PBX 14.4.0
Expires: 120
Contact: <sip:90658@10.61.161.134:5060>
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.61.161.134:5060;branch=z9hG4bK4ad13d0e
From: <sip:90658@10.54.211.19>;tag=as2b5025bb
To: <sip:90658@10.54.211.19>;tag=4eeb61b2
Call-ID: 4da8dcd33c04c79c742ee1681790e564@[fe80::7768:e9a9:ecab:dcab]
CSeq: 102 REGISTER
WWW-Authenticate: Digest realm="insiph@ippbx0a44c303.com", nonce="a4accc569251b32fa4c88bf1657dc370", opaque="6654ee4fed866949dc52ecbd736a5b98", stale=FALSE, algorithm=MD5, qop="auth"
User-Agent: Enterprise IP-PBX (InSIPH)
Allow: INVITE, ACK, REGISTER, BYE, OPTIONS, INFO, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Content-Length: 0

REGISTER sip:10.54.211.19 SIP/2.0
Via: SIP/2.0/UDP 10.61.161.134:5060;branch=z9hG4bK3954450f
Max-Forwards: 70
From: <sip:90658@10.54.211.19>;tag=as2b5025bb
To: <sip:90658@10.54.211.19>
Call-ID: 4da8dcd33c04c79c742ee1681790e564@[fe80::7768:e9a9:ecab:dcab]
CSeq: 103 REGISTER
Supported: replaces
User-Agent: Asterisk PBX 14.4.0
Authorization: Digest username="90658", realm="insiph@ippbx0a44c303.com", algorithm=MD5, uri="sip:10.54.211.19", nonce="a4accc569251b32fa4c88bf1657dc370", response="6503b7be283e137d0e3410b7c22ed617", opaque="6654ee4fed866949dc52ecbd736a5b98", qop=auth, cnonce="0ea94db6", nc=00000001
Expires: 120
Contact: <sip:90658@10.61.161.134:5060>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.61.161.134:5060;branch=z9hG4bK3954450f
From: <sip:90658@10.54.211.19>;tag=as2b5025bb
To: <sip:90658@10.54.211.19>;tag=032b16e2
Call-ID: 4da8dcd33c04c79c742ee1681790e564@[fe80::7768:e9a9:ecab:dcab]
CSeq: 103 REGISTER
Contact: <sip:90658@10.61.161.134:5060>;expires=1800
User-Agent: Enterprise IP-PBX (InSIPH)
Expires: 1800
Allow: INVITE, ACK, REGISTER, BYE, OPTIONS, INFO, CANCEL, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE
Date: Mon, 01 May 2017 19:45:41 GMT
Supported: timer
Allow-Events: message-summary
Content-Length: 0

sip.conf:

[general]
context=internal
register => 90658:@10.54.211.19/90658
allowoverlap=no


udpbindaddr=0.0.0.0            ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
bindport=5060
bindaddr=0.0.0.0
tcpenable=yes                  ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=0.0.0.0            ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)

srvlookup=yes
disallow=all
allow=ulaw

session-timers=refuse
externrefresh=15
localnet=10.0.0.0/255.0.0.0
notifyhold = yes

[NEC]
type=friend
username=90658
secret=
host=10.54.211.19
context=from-nec
dtmfmode=rfc2833
disallow=all
allow=ilbc
allow=gsm
allow=alaw
allow=ulaw
canreinvite=no
insecure=invite,port

AKAv1 and AKAv2 aren’t supported in our PJSIP usage. As for why it’s not working nothing does stand out besides what you’ve mentioned, and it’d be really strange if that was the cause.

Thanks jcolp, not sure what else to try. I can’t do debugging on the NEC side. Are you able to contact a pjsip developer?
I’d be happy to spend the time and do what ever testing is required if a dev wants to dig into this - not just for me but to improve the product in general.

In the meantime I’ll just carry on my project with chan_sip.

Thanks again,
Rhys

You can file an Asterisk issue on the issue tracker[1] but there’s no timeframe of when we would be able to look at it, and no telling if we could fix it. There’s no way to know precisely why it’s rejecting it.

[1] https://issues.asterisk.org/jira