Ovidiu, That makes sense. If you're right, this feature has never worked? Ticket<https://github.com/OpenSIPS/opensips/issues/134>submitted (#134). Thanks for your help.
- Jeff On Tue, Nov 19, 2013 at 12:18 PM, Ovidiu Sas <[email protected]> wrote: > I think this is something that will require some coding ... > There are two tm transactions: > - a UAS transaction for the received INVITE; > - a UAC transaction for the newly generated INVITE. > > The AVPs are stored by the first tm transaction and invisible for the > second tm transaction. > The authentication is happening on the second tm transaction and since > the AVPs are invisible, the authentication cannot be performed. > The parameter based authentication credentials are visible on both > transactions and therefor the authentication process is successful. > > Again, this is what I think ... I haven't had a chance to check the > code in detail. > Best thing to do is open a bug report. > > Regards, > Ovidiu Sas > > On Mon, Nov 18, 2013 at 9:37 PM, Jeff Pyle <[email protected]> > wrote: > > 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 <[email protected]> > 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@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 <[email protected]> > >>> 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 <[email protected]> > >>> 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 <[email protected]> > >>> > 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 <[email protected]> > >>> >> 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 < > [email protected]> > >>> >>> 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 > >> [email protected] > >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >> > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > -- > VoIP Embedded, Inc. > http://www.voipembedded.com > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
