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