REFER (application "deflect") with a wrong username in the Digest authorization

alberto.zanon · July 23, 2023, 4:54pm

Hi all,

I have a problem using “REFER” with my supplier.
I’m using FS 1.10.6 on Debian stretch.
First of all, I have two registered gateways with this supplier on the same sip profile.
Account “A” is defined:

<gateway name="account-A">
	<param name="username" value="username-A"/>
	<param name="password" value="pwd-A"/>
	<param name="caller-id-in-from" value="true"/>
	<param name="extension" value="username-A"/>
	<param name="extension-in-contact" value="true"/>
	<param name="from-user" value="username-A"/>
	<param name="from-domain" value="supplier-IP"/>
	<param name="realm" value="supplier-IP"/>
	<param name="proxy" value="supplier-proxy-IP"/>
	<param name="expire-seconds" value="3600"/>
	<param name="register" value="true"/>
	<param name="retry-seconds" value="120"/>
	<variables>
	    <variable name="absolute_codec_string" value="PCMA" direction="outbound"/>
	</variables>
</gateway>

Account “B” is:

<gateway name="account-B">
	<param name="username" value="username-B"/>
	<param name="password" value="pwd-B"/>
	<param name="caller-id-in-from" value="false"/>
	<param name="extension" value="username-B"/>
	<param name="extension-in-contact" value="true"/>
	<param name="from-user" value="username-B"/>
	<param name="from-domain" value="supplier-IP"/>
	<param name="realm" value="supplier-IP"/>
	<param name="proxy" value="supplier-proxy-IP"/>
	<param name="register" value="true"/>
	<param name="expire-seconds" value="3600"/>
	<param name="retry-seconds" value="10"/>
	<variables>
	    <variable name="absolute_codec_string" value="PCMA" direction="outbound"/>
	</variables>
</gateway>

I want to use “REFER” in inbound calls on the gateway “B”. When I receive an inbound call,
I try to “REFER” and redirect the supplier to another phone number:

<action application="deflect" data="sip:<phone number>@<supplier-IP>" />

The supplier then refuses the request (“401 Unauthorized”) because I send a wrong “username” in the digest when the supplier asks me to authenticate the request: the “username” I see in logs is the one of account “A” !
Here the anonymized tcpdump logs of the SIP Packets:

—> :
INVITE sip:@:5060;transport=udp;gw= SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK+91888dca442029dc679ef65fff9b3dcc1+sip+1+a8a98ba1
From: <sip:@>;tag=+1+57e61ffd+6fa0aa35
To: <sip:@>
CSeq: 936088610 INVITE
Expires: 180
Content-Length: 195
Call-Info: <sip::5060>;method=“NOTIFY;Event=telephone-event;Duration=2000”
Supported: resource-priority,siprec, 100rel
Contact: <sip:348119058f18c3bf663d903ee42568ab@:5060>
Content-Type: application/sdp
Allow-Events: message-summary,refer,dialog,line-seize,presence,call-info,as-feature-event,calling-name,ua-profile
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
Organization:
Max-Forwards: 57
Accept: application/sdp, application/dtmf-relay

v=0
o=- 32375680073557 32375680073557 IN IP4
s=-
c=IN IP4
t=0 0
m=audio 49604 RTP/AVP 8 18 96
a=rtpmap:96 telephone-event/8000
a=fmtp:18 annexb=no
a=ptime:20
—> :
SIP/2.0 100 Trying
Via: SIP/2.0/UDP :5060;branch=z9hG4bK+91888dca442029dc679ef65fff9b3dcc1+sip+1+a8a98ba1
From: <sip:@>;tag=+1+57e61ffd+6fa0aa35
To: <sip:@>
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
CSeq: 936088610 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.10.6-release-18-1ff9d0a60e~64bit
Content-Length: 0
—> :
SIP/2.0 200 OK
Via: SIP/2.0/UDP :5060;branch=z9hG4bK+91888dca442029dc679ef65fff9b3dcc1+sip+1+a8a98ba1
From: <sip:@>;tag=+1+57e61ffd+6fa0aa35
To: <sip:@>;tag=yv060KpHQFa1m
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
CSeq: 936088610 INVITE
Contact: <sip:@:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.10.6-release-18-1ff9d0a60e~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 215
Remote-Party-ID: “” <sip:@>;party=calling;privacy=off;screen=no

v=0
o=FreeSWITCH 1689828723 1689828724 IN IP4
s=FreeSWITCH
c=IN IP4
t=0 0
m=audio 10828 RTP/AVP 8 96
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
—> :
ACK sip:@:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK+afab92be374fb9a5c0df27fa433ac5fa1+sip+1+a8a98ba7
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
From: <sip:@>;tag=+1+57e61ffd+6fa0aa35
To: <sip:@>;tag=yv060KpHQFa1m
CSeq: 936088610 ACK
Contact: <sip:348119058f18c3bf663d903ee42568ab@:5060>
Content-Length: 0
Allow-Events: message-summary,refer,dialog,line-seize,presence,call-info,as-feature-event,calling-name,ua-profile
Max-Forwards: 69
Organization:
—> :
REFER sip:348119058f18c3bf663d903ee42568ab@:5060 SIP/2.0
Via: SIP/2.0/UDP ;rport;branch=z9hG4bK2e19HpD1Q4tDg
Max-Forwards: 70
From: <sip:@>;tag=yv060KpHQFa1m
To: <sip:@>;tag=+1+57e61ffd+6fa0aa35
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
CSeq: 70365985 REFER
Contact: <sip:@:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.10.6-release-18-1ff9d0a60e~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Refer-To: <sip:@>
Referred-By: <sip:>
Content-Length: 0
—> :
SIP/2.0 401 Unauthorized
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
CSeq: 70365985 REFER
From: <sip:@>;tag=yv060KpHQFa1m
To: <sip:@>;tag=+1+57e61ffd+6fa0aa35
Via: SIP/2.0/UDP ;received=;rport=5060;branch=z9hG4bK2e19HpD1Q4tDg
Content-Length: 0
Supported: resource-priority,siprec, 100rel
Contact: <sip:348119058f18c3bf663d903ee42568ab@:5060>
WWW-Authenticate: Digest realm=“”,nonce=“5c5f97279303”,stale=false,algorithm=MD5,qop=“auth”
Server: DC-SIP/2.0
Organization:
—> :
REFER sip:348119058f18c3bf663d903ee42568ab@:5060 SIP/2.0
Via: SIP/2.0/UDP ;rport;branch=z9hG4bK40KUNcF8Hp7jQ
Max-Forwards: 70
From: <sip:@>;tag=yv060KpHQFa1m
To: <sip:@>;tag=+1+57e61ffd+6fa0aa35
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
CSeq: 70365986 REFER
Contact: <sip:@:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.10.6-release-18-1ff9d0a60e~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Authorization: Digest username=“”, realm=“”, nonce=“5c5f97279303”, cnonce=“Om6BaKF1EjyF2wBQVrZs6Q”, algorithm=MD5, uri=“sip:348119058f18c3bf663d903ee42568ab@:5060”, response=“059d639033cae6173ba79c470033fb93”, qop=auth, nc=00000001
Refer-To: <sip:@>
Referred-By: <sip:>
Content-Length: 0
—> :
SIP/2.0 401 Unauthorized
Call-ID: 0gQAAC8WAAACBAAALxYAAMZ/y12tb8zRK+Un4D1YTwlzaiEgmd/4HlVEH6rUJFCI@
CSeq: 70365986 REFER
From: <sip:@>;tag=yv060KpHQFa1m
To: <sip:@>;tag=+1+57e61ffd+6fa0aa35
Via: SIP/2.0/UDP ;received=;rport=5060;branch=z9hG4bK40KUNcF8Hp7jQ
Content-Length: 0
Supported: resource-priority,siprec, 100rel
Contact: <sip:348119058f18c3bf663d903ee42568ab@:5060>
WWW-Authenticate: Digest realm=“”,nonce=“5c5f972e930a”,stale=false,algorithm=MD5,qop=“auth”
Server: DC-SIP/2.0
Organization:

As you can see, Freeswitch replies to the authorization digest with the wrong “username”: “”. Then the supplier refuses the request.
If I switch off (“killgw”) the gateway “account-A”, it works!
When I switch on again (“startgw”) “account-A”, the problem raises again.
I tried to set channel vars like “sip_auth_username” or “auth-username” in the dialplan.
I tried also to set the same channel vars but in the gateway definition.
I tried to add in the gateway “account-B” the param “auth-username”.
Nothing changes.

Could you help me?
Thanks in advance

Alberto

BrianWest-SW · July 24, 2023, 2:51pm

You’ll need to make sure to set the auth data you want it to use, there is no magic to select it on deflect. sip_auth_username and sip_auth_password I believe are the variables you’ll need to set, possibly also sip_auth_realm

/b

alberto.zanon · July 26, 2023, 3:05pm

Thanks Brian,

the problem raises when I don’t explicit set “sip_auth_password”.
As I wrote, I was focused on “username” and “realm”.
Thanks!

Alberto

Topic		Replies	Views
Help with context/variables in gateway configuration FreeSWITCH	3	280	May 9, 2023
FS doesn't save registration to db in case of TLS + unusual param order in sip contact header FreeSWITCH	2	16	November 13, 2024
"IP association no match, user not registered" Troubleshooting	4	246	October 4, 2023
How to send SIP requests to the IP and port in the Record-Route header? Troubleshooting sip , how-to	0	336	February 28, 2024
How to personalize P-Asserted-Identity message FreeSWITCH how-to	0	10	December 11, 2024

REFER (application "deflect") with a wrong username in the Digest authorization

Related topics