Issue with extension registration

FreePBX Endpoints
,
1

Hi everyone,

First a little bit of context, I’m brand new in the FreePBX world and I would like to setup a small IP phone network (4 to 5 devices) for our company.
What do I run:
I’m running FreePBX v17.0.19.23 with Asterisk 21.4.3 on a virtual machine (HP Proliant running XCP-ng) and purchased 2 inexpensive Grandstream GXP1620 to test the setup. Firmware versions of the phone are the latest (1.0.7.70)
My problem is:
I created two pjsip extensions (201 & 202) and configured the IP phones accordingly. For extension 201, the phone can register without any issue, but I can’t register extension 202 for some reason.

What I already tried:

  • Deleting the extension and recreate a new one → Same result
  • Configure the working extension on the non-working phone and vice-versa → No differences, 201 can still register but not 202. So I don’t think the issue is related to the phone configuration.
  • Change the password to only numbers in FreePBX and in the phone configuration → No difference.
  • Rebooting the PBX server and the phones but no changes.
  • Since my phones aren’t in the same subnet than the server, edited the value of “Match (Permit)” to “192.168.0.0/24,192.168.2.0/24”
  • Swearing and cursing it, but so far no changes :stuck_out_tongue_winking_eye:

Configuration / log
Here are the meaningful phone settings (or at least those I think are :wink:)

{68F1236E-F72E-4B22-884D-946F6994ADC9}
{68F1236E-F72E-4B22-884D-946F6994ADC9}744×750 27.3 KB

{79EF9BFC-4238-4474-8187-F130C32DEBDE}
{79EF9BFC-4238-4474-8187-F130C32DEBDE}612×843 28.2 KB

{757EACBC-7AA6-45B3-8257-F1399C8C7810}
Extension 202 have the same parameters, except for the different credentials.
When I look at the registration exchange for extension 202, I have the following:

2025/01/29 11:58:54.750623 192.168.0.40:5060 → 192.168.2.55:5060
REGISTER sip:192.168.2.55 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.40:5060;branch=z9hG4bK1150044087;rport
From: sip:[email protected];tag=278030927
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 2000 REGISTER
Contact: sip:[email protected]:5060;reg-id=1;+sip.instance=“urn:uuid:00000000-0000-1000-8000-C074ADE5AE11”
Max-Forwards: 70
User-Agent: Grandstream GXP1620 1.0.7.70
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

2025/01/29 11:58:54.751958 192.168.2.55:5060 → 192.168.0.40:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;received=192.168.0.40;branch=z9hG4bK1150044087
Call-ID: [email protected]
From: sip:[email protected];tag=278030927
To: sip:[email protected];tag=z9hG4bK1150044087
CSeq: 2000 REGISTER
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1738148334/42e0d7a594e879d0d602e847fc8e6e9e”,opaque=“060b736c4642da5d”,algorithm=MD5,qop=“auth”
Server: FPBX-17.0.19.23(21.4.3)
Content-Length: 0

2025/01/29 11:58:54.790113 192.168.0.40:5060 → 192.168.2.55:5060
REGISTER sip:192.168.2.55 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.40:5060;branch=z9hG4bK9040555;rport
From: sip:[email protected];tag=278030927
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 2001 REGISTER
Contact: sip:[email protected]:5060;reg-id=1;+sip.instance=“urn:uuid:00000000-0000-1000-8000-C074ADE5AE11”
Authorization: Digest username=“202”, realm=“asterisk”, nonce=“1738148334/42e0d7a594e879d0d602e847fc8e6e9e”, uri=“sip:192.168.2.55”, response=“6bc6b1
f08c93df9569be2a09c346ef63”, algorithm=MD5, cnonce=“13300045”, opaque=“060b736c4642da5d”, qop=auth, nc=00000001
Max-Forwards: 70
User-Agent: Grandstream GXP1620 1.0.7.70
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

2025/01/29 11:58:54.790958 192.168.2.55:5060 → 192.168.0.40:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;received=192.168.0.40;branch=z9hG4bK9040555
Call-ID: [email protected]
From: sip:[email protected];tag=278030927
To: sip:[email protected];tag=z9hG4bK9040555
CSeq: 2001 REGISTER
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1738148334/42e0d7a594e879d0d602e847fc8e6e9e”,opaque=“5e51ff4659346c34”,algorithm=MD5,qop=“auth”
Server: FPBX-17.0.19.23(21.4.3)
Content-Length: 0

It does that a couple of time and then the IP gets ban by the fail2ban.
If I look at the registration for extension 201, I have the same exchange, however when it sends the “Authorization” block the second time, I receive a 200 answer instead of the 401 and registration is successful.

The extensions are created as followed in FreePBX (identical):

{7F3DBDD7-BA83-4352-AA82-33D05215FF17}
{7F3DBDD7-BA83-4352-AA82-33D05215FF17}1302×719 105 KB

And the pgsip.auth.conf file is:

[0]
#include pjsip.auth_custom.conf
[201-auth]
type=auth
auth_type=userpass
password=MyPassword
username=201

[202-auth]
type=auth
auth_type=userpass
password=MyOtherPassword
username=202
(I tried to set only numerical password just in case, but didn’t change anything).

I’m probably missing something stupid but I can’t figure it out. Any idea of what I could do to make it work ?
I hope I provided enough for you to help me, if not let me know.

Many thanks,

2

The phone is resending the REGISTER request unchanged, which means that it is failing to see the 401 response. You need to trace the network to find where that 401 is getting lost.

Note that it is resending rather quickly, so, just from the log provided, it is possible that not enough time has been allowed for the 401, in which case I am assuming that a more complete log would show it continuing to send with the same values

3

Hi David,

Thanks for the reply. Indeed, it resend the REGISTER request rather quickly, but there’s a change between the first request and the second one, after receiving the first answer, it adds the “Authorization” block:

Authorization: Digest username=“202”, realm=“asterisk”, nonce=“1738148334/42e0d7a594e879d0d602e847fc8e6e9e”, uri=“sip:192.168.2.55”, response=“6bc6b1
f08c93df9569be2a09c346ef63”, algorithm=MD5, cnonce=“13300045”, opaque=“060b736c4642da5d”, qop=auth, nc=00000001

And if I look on the phone syslog, I see it has indeed receive the answer from the server:

2025-01-29T15:50:17.968775+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] snd_message:SIPStack.cc(7589)->sip log: (551); REGISTER sip:192.168.2.55 SIP/2.0…Via: SIP/2.0/UDP 192.168.0.40:5060;branch=z9hG4bK891437991;rport…From: sip:[email protected];tag=1811015688…To: sip:[email protected]…Call-ID: [email protected]…CSeq: 2000 REGISTER…Contact: sip:[email protected]:5060;reg-id=1;+sip.instance=“urn:uuid:00000000-0000-1000-8000-C074ADE5AE11”…Max-Forwards: 70…User-Agent: Grandstream GXP1620 1.0.7.70…Supported: path…Expires: 3600…Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE…Content-Length: 0…
2025-01-29T15:50:17.970105+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] snd_message:SIPStack.cc(7663)->tpark, send here, hostname: 192.168.2.55, port: 5060
2025-01-29T15:50:17.971653+01:00 GXP1620_PHONE USER.INFO [c0:74:ad:e5:ae:11][1.0.7.70] resolve:MessageChannel.cc(90)->Hop::resolve(), host resolving: 192.168.2.55
2025-01-29T15:50:17.972670+01:00 GXP1620_PHONE USER.INFO [c0:74:ad:e5:ae:11][1.0.7.70] resolve:MessageChannel.cc(130)->Hop::resolve(), host resolved
2025-01-29T15:50:17.974138+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] snd_message:SIPStack.cc(7754)->tpark, snd_message(), found 0
2025-01-29T15:50:17.975141+01:00 GXP1620_PHONE USER.INFO [c0:74:ad:e5:ae:11][1.0.7.70] resolve:MessageChannel.cc(90)->Hop::resolve(), host resolving: 192.168.2.55
2025-01-29T15:50:17.976310+01:00 GXP1620_PHONE USER.INFO [c0:74:ad:e5:ae:11][1.0.7.70] resolve:MessageChannel.cc(130)->Hop::resolve(), host resolved
2025-01-29T15:50:17.978124+01:00 GXP1620_PHONE USER.INFO [c0:74:ad:e5:ae:11][1.0.7.70] sendRequest:SIPTransaction.cc(1869)->SIPClientTransaction::sendRequest: Request 55 is sent
2025-01-29T15:50:17.979449+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] performRegistration:SigControl.cc(4944)->JF::performRegistration| curr m_registeredIP : 0
2025-01-29T15:50:17.982796+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] snd_message:SIPStack.cc(8096)->SIPStack::snd_message: trying to send message
2025-01-29T15:50:17.985376+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] snd_message:SIPStack.cc(8142)->SIPStack::snd_message(): rc: 0
2025-01-29T15:50:17.985822+01:00 GXP1620_PHONE USER.DEBUG [c0:74:ad:e5:ae:11][1.0.7.70] receiveMessage:SIPStack.cc(3347)->sip log: Received message: (476)SIP/2.0 401 Unauthorized…Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;received=192.168.0.40;branch=z9hG4bK891437991…Call-ID: [email protected]…From: sip:[email protected];tag=1811015688…To: sip:[email protected];tag=z9hG4bK891437991…CSeq: 2000 REGISTER…WWW-Authenticate: Digest realm=“asterisk”,nonce=“1738162217/335fbfad17b2b1b9b8c8eddf0210ad88”,opaque=“190b594d558f4014”,algorithm=MD5,qop=“auth”…Server: FPBX-17.0.19.23(21.6.0)…Content-Length: 0…

And you’re right after that initial change, the following REGISTER request sent are all the same (except for some sequence numbers and message identifier I assume).
Longer log here https://pastebin.freepbx.org/view/9fba1b68
But after the PBX server stops sending answer, the phone waits for a timeout before resending.

Also, if there was a communication issue between the phone and the server, wouldn’t it also fail the registration for the other extension right ?

Thanks,

4

Apologies. I seem to have read the wrong CSEQ line.

5

No problem, very nice of you to take the time to help :smile:

6

Take out any settings related to Match (Permit). In Asterisk SIP Settings, set Local Networks to
192.168.0.0 / 16
After Submit and Apply Config, restart Asterisk.
Test. If still trouble, paste the Asterisk log for an attempted registration, with pjsip logger turned on.

7

The cnonce parameter is missing. RFC 2617 says it must be present if qop is present, and that is superseded by RFC 7616, which says that both qop and cnonce must be set.

8

Hi Stewart,

That worked! Many thanks :grinning:. Just for me to understand, what is the Match (Permit) setting use for then ? I thought that was for allowing an authentication when the device was on another subnet than the server.

9

It is used to generate a type=identify section. which is used to determine the endpoint, from the IP address. The “permit” part of the name is misleading, and I can’t think of a case where it is valid.

If you don’t set it, FreePBX sets it to be the same as the Server setting.

In this case, it is probably causing the extension to match against one of the trunks, as the FreePBX default is to prefer IP matches over user name matches.

10

I was indeed mislead by the name. I didn’t imagine that was such a deep subject with that level of customization when starting working on this.

Anyway, thanks to both of you for the help!

11

I made an issue[1] since it’s bothered me for awhile too.

[1] [improvement]: "Match (Permit)" is confusing for PJSIP and misleading · Issue #637 · FreePBX/issue-tracker · GitHub

12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.