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

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

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

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