[OpenSIPS-Users] AVP-based uac_auth in b2bua

[Jeff Pyle]

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.
>> >
>> > The AVPs do work if I use the uac_auth() function in a failure_route
>> instead
>> > of the B2BUA top hiding.
>> >
>> > Is there a trick I'm missing?
>> >
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Mon, Nov 11, 2013 at 11:09 AM, Jeff Pyle <jpyle at fidelityvoice.com>
>> wrote:
>> >>
>> >> Hello,
>> >>
>> >> I have uac_auth() working with AVPs in a proxy configuration on v1.10.
>> >> This is important because I need to choose the authentication username
>> and
>> >> password based on the usr_preferences of the source IP of the call.
>>  Is it
>> >> possible choose the credentials at call-time (like the AVPs allow) in
>> a B2B
>> >> top-hiding scenario?
>> >>
>> >> The scenario authenticates properly if I statically specify a
>> >> "credentials" modparam for uac_auth.  It does not work, however, if I
>> set
>> >> AVPs prior to calling b2b_init_request("top hiding").  Is there
>> another way
>> >> to approach this?
>> >>
>> >>
>> >> Regards,
>> >> Jeff
>> >>
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>>
>>
>> --
>> 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/b52f542b/attachment.htm>