My trunk and setup needs to see the from header with the port. I have tried various option setting in the from domain option pjsip > advances such as FQDN:5060 and this is when the brackets appear. If I remove the 5060 its normal. I am getting a 403 unauthorized
Not really sure wht I need to change at this point
f: @[MyDomain:5060]
It is being treated as an IPV6 address, because of the “:”. I don’t know it is FreePBX, or Asterisk/PJProject that is doing that. You also seem to have an empty user part followed by “@” which is not valid.
I have a feeling that specifying a port in From is not considered good practice.
The port will be added based on the transport being used. What port is chan_pjsip listening on? Is it 5060?
Yes 5060. Transport is udp
Then we need to see some debugs on why the 403 is happening. Doing pjsip set logger on will start a SIP debug that you can copy and paste for us.
What I aam seeing now is the 407 is changing
It is coming in, the trunk is chalanging and my invite to the challange is incorrect. This from the isp
The Proxy-Authorization string doesn’t mention the algorithm used for hashing (md5), used to send the response.
Client URI (mentioned in your first post) affects only registration, not calls.
This could only occur on an outbound call attempt. Which is your present problem, registration or calling?
At the Asterisk command prompt, type
pjsip set logger on
and either wait for a registration attempt or make a failing outbound call. Paste the Asterisk log for the attempt or call at pastebin.com and post the link here. If you are too new to post links, just post the last 8 characters of the URL.
What they are referring to is a missing algorithm=MD5
Missing below. I sort of dont buy it. The Trnk is up and registering fine. Its the outbound that failes. Inbound is working
Try setting From User to the same value you have in Username and retest.
If it still fails, please paste a more complete log of the outgoing INVITE and the response.
IMO, the provider’s complaint is BS. First, RFC 7616: HTTP Digest Access Authentication page 7 says:
algorithm
A string indicating an algorithm used to produce the digest and an
unkeyed digest. If this is not present, it is assumed to be
"MD5".
Second, pjsip doesn’t supply the algorithm tag on REGISTER, either, and the provider accepted that.
Responding to what? This immediately follows a posting about a response from FreePBX, and there is no mention of a challenge from FreePBX.
This is a SIP call, not HTTP, I am assuming this is the same in either or.
I will look at the RFC. Pasting or placing items here is tough as I get warned I cant
the SIP RFC 3261 states pretty much the same thing. Anyway to point below is the sequence from Phone | Asterisk | ISP
As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty
string, or: H(entity-body) = MD5(“”) = “d41d8cd98f00b204e9800998ecf8427e”
#############
From Phone
#############
Via: SIP/2.0/UDP 10.10.50.11;rport=5060;received=172.16.1.3;branch=z9hG4bK507c1b92A8BFFDBC
Call-ID: 149ff4c418630b6798f71b476e4452ac
From: "Motoman 393" <sip:[email protected]>;tag=AC30F192-1085320B
To: <sip:[email protected];user=phone>;tag=z9hG4bK507c1b92A8BFFDBC
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1682939633/f329881416f76f219da24fc8464a3dfb",opaque="34073f3f708403ed",algorithm=MD5,qop="auth"
Server: FPBX-16.0.40(18.16.0)
Content-Length: 0
Via: SIP/2.0/UDP 10.10.50.11;branch=z9hG4bKaa23741a3746D421
From: "Motoman 393" <sip:[email protected]>;tag=AC30F192-1085320B
To: <sip:[email protected];user=phone>
CSeq: 2 INVITE
Call-ID: 149ff4c418630b6798f71b476e4452ac
Contact: <sip:[email protected]>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
User-Agent: PolycomVVX-VVX_411-UA/6.4.3.5156
Accept-Language: en
Supported: replaces,100rel
Allow-Events: conference,talk,hold
Authorization: Digest username="393", realm="asterisk", nonce="1682939633/f329881416f76f219da24fc8464a3dfb", qop=auth, cnonce="HPkJM3OgTieFFzA", nc=00000001, opaque="34073f3f708403ed", uri="sip:[email protected];user=phone", response="145d2ea3d11ec0272b92e2ff17b49e47", algorithm=MD5
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 348
################
From Asterisk
################
<--- Received SIP request (956 bytes) from UDP:172.16.1.3:5060 --->
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 10.10.50.11;branch=z9hG4bK507c1b92A8BFFDBC
From: "Motoman 393" <sip:[email protected]>;tag=AC30F192-1085320B
To: <sip:[email protected];user=phone>
CSeq: 1 INVITE
Call-ID: 149ff4c418630b6798f71b476e4452ac
Contact: <sip:[email protected]>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
User-Agent: PolycomVVX-VVX_411-UA/6.4.3.5156
Accept-Language: en
Supported: replaces,100rel
Allow-Events: conference,talk,hold
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 348
<--- Transmitting SIP response (515 bytes) to UDP:172.16.1.3:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.10.50.11;rport=5060;received=172.16.1.3;branch=z9hG4bK507c1b92A8BFFDBC
Call-ID: 149ff4c418630b6798f71b476e4452ac
From: "Motoman 393" <sip:[email protected]>;tag=AC30F192-1085320B
To: <sip:[email protected];user=phone>;tag=z9hG4bK507c1b92A8BFFDBC
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1682939633/f329881416f76f219da24fc8464a3dfb",opaque="34073f3f708403ed",algorithm=MD5,qop="auth"
Server: FPBX-16.0.40(18.16.0)
Content-Length: 0
<--- Received SIP request (1247 bytes) from UDP:172.16.1.3:5060 --->
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 10.10.50.11;branch=z9hG4bKaa23741a3746D421
From: "Motoman 393" <sip:[email protected]>;tag=AC30F192-1085320B
To: <sip:[email protected];user=phone>
CSeq: 2 INVITE
Call-ID: 149ff4c418630b6798f71b476e4452ac
Contact: <sip:[email protected]>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
User-Agent: PolycomVVX-VVX_411-UA/6.4.3.5156
Accept-Language: en
Supported: replaces,100rel
Allow-Events: conference,talk,hold
Authorization: Digest username="393", realm="asterisk", nonce="1682939633/f329881416f76f219da24fc8464a3dfb", qop=auth, cnonce="HPkJM3OgTieFFzA", nc=00000001, opaque="34073f3f708403ed", uri="sip:[email protected];user=phone", response="145d2ea3d11ec0272b92e2ff17b49e47", algorithm=MD5
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 348
#############
Sent to ISP
#############
2023/05/01 11:13:53.597 FINE com._FQDNISP.sip.transport.udp [[send: /192.xxx.xxx.18:5060-->/162.xxx.xxx.119:6466
|INVITE sip:[email protected] SIP/2.0
v: SIP/2.0/UDP 192.xxx.xxx.18:5060;branch=z9hG4bKatofTSKthQZ52680fc5f53f53fb85610ac12b692b596, SIP/2.0/UDP 47.xxx.xxx.225:5060;rport=5060;branch=z9hG4bKPj17f88b25-7349-4a2e-884e-c63172fab94c;received=47.xxx.xxx.225
f: <sip:166xxxxxx40@FQDNISP>;tag=b0367d57-5bef-4b0b-bcec-0f90206186d3
t: <sip:166xxxxx56@FQDNISP>
m: <sip:[email protected]:5060>
i: ab3612d6-c0ce-48ee-8a42-c2e2c2f4689a
CSeq: 16330 INVITE
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REFER
k: 100rel, timer, replaces, norefersub, histinfo
x: 1800
Min-SE: 90
Max-Forwards: 69
User-Agent: FPBX-16.0.40(18.16.0)
Proxy-Authorization: Digest username="24xxxxxxxxxxx39", realm="FQDNISP.net", nonce="ZE+e8YkcgK89aVdC6Y7tA6DbDEQA", uri="sip:166xxxxxx56@FQDNISP:5060", response="45ab7d80e5295625c3871e872c01c8c7"
Remote-Party-ID: <sip:[email protected]>;party=calling;privacy=off;screen=no
c: application/sdp
l: 239
Record-Route: <sip:[email protected]:5060;lr;id=7193577892bc1ab7daa356a932d9a378>
History-Info: <sip:[email protected]>;index=1
What you are mainly, as a new user, being prevented from pasting is links. You can avoid that problem with proper markup, using the </> formatting button. This will also stop file content being mangled. You can even post full pastebin links and mark them up to prevent them being served as links (the main concern with links is that people plant them to boost page rank ratings, and Google will ignore links that are not actually HTML linkis.
If a trunk can register and receive calls but outbound calls fail, there are three common issues:
Authentication. Some providers require an account number, ‘pilot’ phone number or other identifier in the From header, which is why I suggested setting From User. What happened when you tried that (no change, different error, call went through but no audio, etc.)?
Called number format. You are sending 11 digits which is usually accepted, but look at the To header for an incoming call and match that format if different.
Caller ID format. Remote-Party-ID is fairly uncommon these days. Try setting Send RPID/PAI to Both, as PAI may be required and the superfluous header should be ignored.
If you still have trouble, please post the response to the failing INVITE (not the 407, the response after Authorization sent).
Issue found. Authentication is not based on User/password challenge but by DID, appears the DIDs assigned are missing in the DB to autheticate. Inbound works, however sending out fails as it cannot match the DIDs assign.
Thanks for all the assistance
Issue is as well What is being sent to ISP is not MD5. Need to change it as md5 is apha numeric only
nonce=“ZE+e8YkcgK89aVdC6Y7tA6DbDEQA”
That is the nonce which is a onetime token. The response value is what would be used, which is actually not even the password. The actual password is never transmitted during the authentication process.
That’s not true. MD5 checksums are 128 bit binary numbers. For certain purposes, they may be represented as 32 byte hexadecimal numbers, which are a subset of alphanumeric, and it looks like digest authentication is one of those cases.
This is the only part that is actually MD5:
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.