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 <o...@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 <jp...@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 <jp...@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 <o...@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 <jp...@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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users