1. Yes, briefly looking on UAC documentation these functions should work for you.
2. Yes, UAC module enables some SBC features on kamailio. 2014-08-25 16:36 GMT+04:00 Yuriy Gorlichenko <[email protected]>: > Hmmm... So if I cath 407 Kamailio works with Invite that Send from > Asterisk to Provider before I changed It. > > About changing from/to: > UAC mode have uac_replace_from()/uac_replace_to() for rewriting headers . > Must I use this functions instead my changes? > > About Breaking RFC: > so UAC do it breaking RFC? And second - What write way to send packet to > provider through kamailo if providers registrates on It? > > Thanks! > > > > 2014-08-25 16:19 GMT+04:00 Alekzander Spiridonov <[email protected]>: > > Hi, >> >> First of all, changing From\To headers on proxy breaks the RFC =) So >> that's the initial problem of your set up I guess. >> >> About your qustion, check out the wiki about failure_route: >> > Note that in 'failure_route' is processed the request that initiated >> the transaction, not the reply. >> >> The only workaround you may want to check is to update the request and >> apply lumps before you create a transaction. >> >> >> 2014-08-25 16:03 GMT+04:00 Yuriy Gorlichenko <[email protected]>: >> >>> Hello. At first- I think header of my message doesn't explain my porblem >>> but I can not say about it with different terms) >>> >>> So. I have construction Asterisk --> Kamailio --> Providers >>> >>> My provisers registered with UAC modure and stored at UACREG table. >>> >>> Problem scenario is: >>> >>> I ring from asterisk to provider >>> >>> Asterisk --> Kamailio --> Providers >>> >>> Call from asterisk come to kamailio with >>> furi(Asterisk_clinet_local_number@asterisk) >>> turi(external_number@kamailio) >>> >>> Then, to forward INVITE to provider that Needed I use some manipulations >>> to choose provider (it does not matter, it is only sql_queryes to some >>> tables), and then modify invite with this code: >>> >>> #$var(prov) - my.provider.ip >>> #$var(trunk) - name_of_trunk >>> >>> $rd=$var(prov); >>> $rp="5060"; >>> $fU=$var(trunk); >>> $fd=$var(prov); >>> $td=$var(prov); >>> >>> remove_hf("Contact"); >>> append_hf("Contact:<$var(trunk)@my.kamailio.domain:5068>\n","Contact"); >>> >>> >>> So -after this manipulation I have write packet, that goues to my >>> provider. >>> >>> Then Provier sends me 407 answer and packet goes to failure_route >>> >>> if (t_check_status("401|407")){ >>> xlog("L_INFO", "Reply from provider on failure: $rs"); >>> >>> if (uac_auth()){ >>> #my query to get avp for uac >>> #modparam("uac","auth_realm_avp","$avp(s:realm)") >>> #modparam("uac","auth_username_avp","avp(s:uname)") >>> >>> #modparam("uac","auth_password_avp","$avp(s:passwd))") >>> >>> sql_pvquery("ca","select auth_username, auth_password, realm from >>> uacreg where auth_username='$fU'","$var(uname), $var(passwd), >>> $var(realm)"); >>> xlog("L_INFO", "username=$var(uname), >>> password=$var(passwd), realm=$var(realm) for {$fU}"); >>> >>> pv_printf("$avp(s:uname)","$var(uname)"); >>> pv_printf("$avp(s:passwd)","$var(passwd)"); >>> pv_printf("$avp(s:realm)","$var(realm)"); >>> >>> >>> xlog("L_INFO", "UAC_AUTH(): $rs"); >>> append_branch(); >>> t_relay(); >>> >>> } >>> } >>> if (t_is_canceled()) { >>> exit; >>> } >>> So After changes Before Provider answer 407 my $fU = name_of_trunk, >>> but at failure route my fU is Asterisk_clinet_local_number and it so >>> strange because I see this packet at TCPDUMP and it have trunkname at fU >>> Because of It I can not take from table needed vars for auth and avp`s >>> Have 0. >>> >>> So packet for Auth (407) goes to Asterisk (with trunkname!!!! at fU), >>> but t must stops at kamailio and must be ralayed to provider. >>> >>> So this my problem- I can not understand: Why fU at reply 407 have old >>> parameters? >>> >>> >>> >>> _______________________________________________ >>> sr-dev mailing list >>> [email protected] >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> >>> >> >> >> -- >> Best regards, >> Alekzander Spiridonov >> >> >> _______________________________________________ >> sr-dev mailing list >> [email protected] >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >> > > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > -- Best regards, Alekzander Spiridonov
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
