Some PBX implementations (e.g. 3cx) seem to use the From header when evaluating authentication (specifically: requiring the From header to point to a valid extension within the system, and the username from the Proxy-Authorization header to match the authentication ID of the extension), which causes authentication to fail because the default From header is set to the user agent and not the username/extension. Most/all other implementations populate it with the extension. The behavior of sipgo/diago doesn't seem to conform to RFC3261 § 20.20, which specifies that the From header is meant to identify the initiator of the request.
Example SIP trace:
INVITE sip:destination@pbx SIP/2.0
From: "sipgo" <sip:sipgo@pbx>;tag=...
To: <sip:destination@pbx>
...
<-- 407 Proxy Authentication Required
INVITE ...
From: "sipgo" <sip:sipgo@pbx>;tag=...
Proxy-Authorization: Digest username="authuser", ...
<-- 404 User unknown
Modifying the UA opts to set the user agent string to the user (extension number) makes it work:
uaOpts := []sipgo.UserAgentOption{
sipgo.WithUserAgent(cfg.SipUser),
}
INVITE sip:destination@pbx SIP/2.0
From: "123" <sip:123@pbx>;tag=...
To: <sip:destination@pbx>
...
<-- 407 Proxy Authentication Required
INVITE ...
From: "123" <sip:123@pbx>;tag=...
Proxy-Authorization: Digest username="authuser", ...
<-- 100 Trying
...
This can also be reproduced with gophone like gophone dial -username authuser -password authpw 'sip:destination@pbx'. There seems to be somewhat conspicuous lack of of "from" option in the gophone dial CLI as well. I assume other PBX systems simply look at the auth user and force the call on the associated extension.
Besides cross-referencing this with SIP traces from hardphones I also checked the behavior of pjsip using pjsua, which populates the From header as shown as well and correctly interoperates with 3cx for both REGISTER and INVITE.
Some PBX implementations (e.g. 3cx) seem to use the
Fromheader when evaluating authentication (specifically: requiring theFromheader to point to a valid extension within the system, and the username from theProxy-Authorizationheader to match the authentication ID of the extension), which causes authentication to fail because the default From header is set to the user agent and not the username/extension. Most/all other implementations populate it with the extension. The behavior of sipgo/diago doesn't seem to conform to RFC3261 § 20.20, which specifies that theFromheader is meant to identify the initiator of the request.Example SIP trace:
Modifying the UA opts to set the user agent string to the user (extension number) makes it work:
This can also be reproduced with gophone like
gophone dial -username authuser -password authpw 'sip:destination@pbx'. There seems to be somewhat conspicuous lack of of "from" option in the gophone dial CLI as well. I assume other PBX systems simply look at the auth user and force the call on the associated extension.Besides cross-referencing this with SIP traces from hardphones I also checked the behavior of pjsip using pjsua, which populates the
Fromheader as shown as well and correctly interoperates with 3cx for bothREGISTERandINVITE.