<div dir="ltr">Ovidiu,<div><br></div><div>That makes sense. If you're right, this feature has never worked? <a href="https://github.com/OpenSIPS/opensips/issues/134">Ticket</a> submitted (#134). Thanks for your help.</div>
<div><br></div><div><br></div><div>- Jeff</div><div><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 12:18 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think this is something that will require some coding ...<br>
There are two tm transactions:<br>
- a UAS transaction for the received INVITE;<br>
- a UAC transaction for the newly generated INVITE.<br>
<br>
The AVPs are stored by the first tm transaction and invisible for the<br>
second tm transaction.<br>
The authentication is happening on the second tm transaction and since<br>
the AVPs are invisible, the authentication cannot be performed.<br>
The parameter based authentication credentials are visible on both<br>
transactions and therefor the authentication process is successful.<br>
<br>
Again, this is what I think ... I haven't had a chance to check the<br>
code in detail.<br>
Best thing to do is open a bug report.<br>
<br>
Regards,<br>
Ovidiu Sas<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Nov 18, 2013 at 9:37 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>> wrote:<br>
> Yes:<br>
><br>
> # ----- tm params -----<br>
> modparam("tm", "fr_timer", 2)<br>
> modparam("tm", "fr_inv_timer", 118)<br>
> modparam("tm", "disable_6xx_block", 1)<br>
> modparam("tm", "restart_fr_on_each_reply", 0)<br>
> modparam("tm", "onreply_avp_mode", 1)<br>
><br>
><br>
> - Jeff<br>
><br>
><br>
> On Mon, Nov 18, 2013 at 7:36 PM, Ovidiu Sas <<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>> wrote:<br>
>><br>
>> Did you set the onreply_avp_mode for tm:<br>
>> <a href="http://www.opensips.org/html/docs/modules/devel/tm.html#id293972" target="_blank">http://www.opensips.org/html/docs/modules/devel/tm.html#id293972</a><br>
>><br>
>><br>
>> On Monday, November 18, 2013, Jeff Pyle wrote:<br>
>>><br>
>>> It's 1.10 pulled from git a few hours ago. Debian 7 64-bit.<br>
>>><br>
>>> The AVPs are set prior to calling the b2b scenario:<br>
>>><br>
>>> modparam("uac_auth","auth_realm_avp", "$avp(auth_realm)")<br>
>>> modparam("uac_auth","auth_username_avp","$avp(auth_user)")<br>
>>> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")<br>
>>> #modparam("uac_auth","credential","UserName:AuthRealm123:SuperS33cret")<br>
>>><br>
>>> route {<br>
>>> ...<br>
>>> $avp(auth_user) := "UserName";<br>
>>> $avp(auth_pass) := "SuperS33cret";<br>
>>> $avp(auth_realm) := "AuthRealm123";<br>
>>><br>
>>> b2b_init_request("top hiding/t105");<br>
>>> ...<br>
>>> }<br>
>>><br>
>>><br>
>>> debugs:<br>
>>><br>
>>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback: Received reply<br>
>>> [407] for dialog [0x7ff941c13268], method [INVITE]<br>
>>> Nov 18 18:07:55 [26004] DBG:tm:t_unref_cell: UNREF_UNSAFE:<br>
>>> [0x7ff941c18448] after is 1<br>
>>> Nov 18 18:07:55 [26004] DBG:b2b_entities:b2b_tm_cback:<br>
>>> dlg=[0x7ff941c13268], uac_tran=NULL<br>
>>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:<br>
>>> <realm>="AuthRealm123" state=2<br>
>>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body:<br>
>>> <nonce>="528a9de900013e5f13fe985df4a9848356a1f937207ecfe4" state=3<br>
>>> Nov 18 18:07:55 [26004] DBG:core:parse_authenticate_body: <qop>="auth"<br>
>>> state=1<br>
>>> Nov 18 18:07:55 [26004] DBG:b2b_logic:b2bl_parse_key: hash_index = [472]<br>
>>> - local_index= [0]<br>
>>><br>
>>><br>
>>><br>
>>> The following (successful) debugs occur if I uncomment the credential<br>
>>> modparam visible above:<br>
>>><br>
>>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:<br>
>>> dlg=[0x7f8a06744c30], uac_tran=NULL<br>
>>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:<br>
>>> <realm>="66.94.76.24" state=2<br>
>>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body:<br>
>>> <nonce>="528a9fbf00014297ef8f2335679f0310537c85fe2b007186" state=3<br>
>>> Nov 18 18:15:45 [26118] DBG:core:parse_authenticate_body: <qop>="auth"<br>
>>> state=1<br>
>>> Nov 18 18:15:45 [26118] DBG:uac_auth:build_authorization_hdr: auth_hdr is<br>
>>> <Proxy-Authorization: Digest username="UserName", realm="AuthRealm123",<br>
>>> nonce="528a9fbf00014297ef8f2335679f0310537c85fe2b007186",<br>
>>> uri="sip:2165551212@domain", qop=auth, nc=00000001, cnonce="3105687311",<br>
>>> response="ef047011046690b6eea99c7848de499a", algorithm=MD5<br>
>>> ><br>
>>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback:<br>
>>> [Proxy-Authorization: Digest ...]<br>
>>> Nov 18 18:15:45 [26118] DBG:b2b_entities:b2b_tm_cback: uri [...]<br>
>>><br>
>>><br>
>>><br>
>>> I tried to follow the source to isolate the failing mechanism. I arrived<br>
>>> at modules/uac_auth/auth.c. In get_avp_credential() at line 199:<br>
>>><br>
>>> avp = search_first_avp( realm_avp_type, realm_avp_name, &val, 0);<br>
>>> if ( avp==NULL || (avp->flags&AVP_VAL_STR)==0 || val.s.len<=0 )<br>
>>> return 0;<br>
>>><br>
>>> In my case I've discovered avp==NULL so the if-statement returns 0.<br>
>>> avp==NULL because in the search_first_avp() at line 346 of usr_avp.c:<br>
>>><br>
>>> if (*crt_avps==0)<br>
>>> return 0;<br>
>>><br>
>>> And it's game over. I can't discern what causes this. I'm already way<br>
>>> in over my pay grade. :)<br>
>>><br>
>>><br>
>>> - Jeff<br>
>>><br>
>>><br>
>>> On Mon, Nov 18, 2013 at 6:02 PM, Ovidiu Sas <<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>><br>
>>> wrote:<br>
>>><br>
>>> Can you post the debug logs and let us know which version of opensips<br>
>>> are you running?<br>
>>> Also, make sure that you set the credentials in AVPs before invoking<br>
>>> the b2b call.<br>
>>><br>
>>> Thanks,<br>
>>> Ovidiu<br>
>>><br>
>>> On Mon, Nov 18, 2013 at 5:11 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>><br>
>>> wrote:<br>
>>> > This functionality has become key for my configuration. I've done some<br>
>>> > digging today. Here's what I know.<br>
>>> ><br>
>>> > b2b_entities' auth call gets to around line 347 of usr_avp.c and fails:<br>
>>> ><br>
>>> > if (*crt_avps==0)<br>
>>> > return 0;<br>
>>> ><br>
>>> > Programming is not my strength. Any thoughts what might cause this<br>
>>> > condition, or how it might be related b2b_entities' ability to process<br>
>>> > an<br>
>>> > auth request?<br>
>>> ><br>
>>> ><br>
>>> > - Jeff<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Wed, Nov 13, 2013 at 6:03 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Hi Ovidiu,<br>
>>> >><br>
>>> >> It does not. At least not for me. Here are some snippets of my<br>
>>> >> config<br>
>>> >> file:<br>
>>> >><br>
>>> >> modparam("uac_auth","auth_realm_avp", "$avp(auth_realm)")<br>
>>> >> modparam("uac_auth","auth_username_avp","$avp(auth_user)")<br>
>>> >> modparam("uac_auth","auth_password_avp","$avp(auth_pass)")<br>
>>> >><br>
>>> >><br>
>>> >> #modparam("uac_auth","credential","valid-username:appropriate-realm:valid-password")<br>
>>> >><br>
>>> >> route {<br>
>>> >><br>
>>> >> ... sanity checks, etc ...<br>
>>> >><br>
>>> >> $avp(auth_realm) := "appropriate-realm";<br>
>>> >> $avp(auth_user) := "valid-username";<br>
>>> >> $avp(auth_pass) := "valid-password";<br>
>>> >><br>
>>> >> if !(b2b_init_request("top hiding/t105")) {<br>
>>> >> xlog("L_ERR", "** b2b_init failed - - S=$si:$sp T=$tU<br>
>>> >> F=$fU C=$ci\n");<br>
>>> >> send_reply("500", "Internal Server Error");<br>
>>> >> }<br>
>>> >> exit;<br>
>>> >> }<br>
>>> >><br>
>>> >><br>
>>> >> Configured like this, the 407 gets passed back to the client. If I<br>
>>> >> uncomment the 'credential' modparam, the B2B will send an INVITE with<br>
>>> >> the<br>
>>> >> correct auth.<br>
>>> >><br>
>>> >> The same uac_auth config with the same AVPs work correctly if I use<br>
>>> >> uac_auth() on a failure_route in a pure proxy config. That's why I'm<br>
>>> >> confused about it not working with the B2B. I looked through the<br>
>>> >> source and<br>
>>> >> as best I can tell the same functions are called the same way for<br>
>>> >> each.<br>
>>> >><br>
>>> >> Ok, let me be specific on that last point. The client to this B2B<br>
>>> >> instance is another Opensips instance with proxy-only commands, most<br>
>>> >> notably<br>
>>> >> rtpproxy. That's where I have uac_auth() working today. With that I<br>
>>> >> call<br>
>>> >> the scenario here as "top hiding/at105" (note the "a") to<br>
>>> >> intentionally pass<br>
>>> >> the 407 back to the proxy config. It works. Ideally, I'd prefer the<br>
>>> >> B2B<br>
>>> >> scenario here field the 407.<br>
>>> >><br>
>>> >><br>
>>> >> - Jeff<br>
>>> >><br>
>>> >><br>
>>> >> On Wed, Nov 13, 2013 at 4:34 PM, Ovidiu Sas <<a href="mailto:osas@voipembedded.com">osas@voipembedded.com</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>> If you set the AVPs before creating the b2b call, it should work on<br>
>>> >>> 1.10.<br>
>>> >>><br>
>>> >>> Regards,<br>
>>> >>> Ovidiu Sas<br>
>>> >>><br>
>>> >>> On Tue, Nov 12, 2013 at 11:16 PM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>><br>
>>> >>> wrote:<br>
>>> >>> > I was about to let this one go when I found "B2B module gets<br>
>>> >>> > visibility<br>
>>> >>> > to<br>
>>> >>> > credentials defined via AVPs" on the About Version 1.10 page. In<br>
>>> >>> > my<br>
>>> >>> > case it<br>
>>> >>> > works only if I define the 'credential' modparam for uac_auth.<br>
>>> >>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> VoIP Embedded, Inc.<br>
>> <a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
<br>
<br>
<br>
--<br>
VoIP Embedded, Inc.<br>
<a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div></div>