This feature never worked. It was in the TODO list, but it never reached the top :)
-ovidiu On Tue, Nov 19, 2013 at 12:39 PM, Jeff Pyle <[email protected]> wrote: > Ovidiu, > > That makes sense. If you're right, this feature has never worked? Ticket > 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 > -- VoIP Embedded, Inc. http://www.voipembedded.com _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
