Hi Bogdan: After patching the failure route the way you said, the problem seems to be solved. About your question, as far as I know, no branches are created, implicitly or explicitly. $bR is <null> before the t_relay. Thanks: Francisco
2009/5/25 Bogdan-Andrei Iancu <[email protected]> > Hi Francisco, > > First of all, please in the begining of any failure route: > > failure_route[x] { > if (t_was_cancelled()) { > exit; > } > ..... > } > > This will capture the calls which were cancelled by the caller and avoid > any bogus processing on the cancelled call. > > > Now, in regards to the "Contact" stuff, before the t_reply("3xx"), do you > use create any new branch (via append_branch or other functions that do it > internally)? I'm asking because when you do a 3xx reply, automatically, the > newly set ruri and any created branches are used in the reply contact. To > check this, you may print the "*$bR* " var from the script, before the > t_relay(); > > Regards, > Bogdan > > > Francisco Javier Lizaran Vilches wrote: > >> Hi: >> I caught the failure again with logs enabled. First of all, I've >> realized that I made a mistake explaining the issue before. There is no >> problem with forward busy at all as I said. The problem appears with forward >> on no answer only, so this is the part of the script to take into account: >> >> route[3] { >> ... >> t_on_failure("1"); >> ... >> # forward on no answer >> if (is_avp_set("$avp(s:fwdnoanswer)/s")) { >> if ($ru==$avp(s:fwdnoanswer)) { >> sl_send_reply("603", "Decline"); >> return; >> }; >> setflag(24); >> }; >> ... >> } >> >> failure_route[1] { >> if ((isflagset(24)) && (t_check_status("408"))) { >> xlog("L_NOTICE", "Fwdnoanswer: $avp(s:fwdnoanswer) \n"); >> if (avp_pushto("$ru", "$avp(s:fwdnoanswer)")) { >> avp_print(); >> t_reply("302","Moved Temporarily"); >> return; >> }; >> }; >> }; >> ... >> } >> >> So, for example, user 20173 calls user 20346 which has a fwd to 20559. >> After ring timeout expires, the proxy sends back to user 20173 a 302 >> response. In the contact header appears 20559 and another uri appended: >> Contact: sip:[email protected] <sip%[email protected]> <mailto: >> sip%[email protected] <sip%[email protected]>>, >> <sip:[email protected]:5060;transport=udp>;q=0 >> >> This uri is included along all the forwardings on no answer performed >> in the system. >> Looking at the log, there is no trace of such uri in the avp list: >> openser[11278]: Fwdnoanswer: >> sip:[email protected]<sip%[email protected]><mailto: >> sip%[email protected] <sip%[email protected]>> >> ... >> openser[11278]: INFO:avpops:print_avp: p=0xb57356a8, flags=0x0083 >> openser[11278]: INFO: name=<fwdnoanswer> >> openser[11278]: INFO: >> val_str=<sip:[email protected]<sip%[email protected]><mailto: >> sip%[email protected] <sip%[email protected]>> / 23> >> ... >> >> Searching through the log back in time I have seen the last call to uri >> 66012... openser[11278]: ERROR:tm:t_forward_nonack: discarding fwd for a >> cancelled/6xx transaction >> openser[11278]: ERROR:tm:w_t_relay: t_forward_nonack failed >> openser[11278]: T_RELAY ERROR: remote URI: >> sip:[email protected]:5060;transport=udp >> That time there was a correct forward no answer to this number, but >> t_relay got an error after cancelling. Probably it is related with later >> issues when forwarding. >> Regards: >> Francisco >> >> 2009/5/4 Francisco Javier Lizaran Vilches <[email protected]<mailto: >> [email protected]>> >> >> Hi Bogdan: >> >> I will try to print the avp next time it occurs. >> >> Thanks: >> >> Francisco >> >> 2009/4/30 Bogdan-Andrei Iancu <[email protected] >> <mailto:[email protected]>> >> >> >> Hi Francisco, >> >> First of all, maybe it will be a good idea to upgrade to >> OpenSIPS 1.5.1 - along the versions many bugs were fixed and >> 1.2 is a really old one. >> >> Have you tried to place an xlog and print the fwdbusy avp just >> before the avp_pushto() ? >> >> Regards, >> Bogdan >> >> >> Francisco Javier Lizaran Vilches wrote: >> >> Hi all: >> Have running this script on Openser 1.2.3-notls version >> managing forwards this way: >> >> route[3] { >> ... >> t_on_failure("1"); >> if avp_db_load("$ru", "*") { >> if (is_avp_set("$avp(s:fwdbusy)/s")) { >> setflag(23); >> }; >> ... >> >> failure_route[1] { >> ... >> if ((isflagset(23)) && (t_check_status("486"))) { >> if (avp_pushto("$ru", "$avp(s:fwdbusy)")) { >> t_reply("302","Moved Temporarily"); >> return; >> }; >> }; >> ... >> >> User A calls user B and B has fwdbusy parameter set in >> user preferences; if B is busy, proxy sends 302 message >> back to A with contact set to $avp(s:fwdbusy) value. This >> setup usually works fine. However, sometimes the proxy >> shows a strange behaviour. It starts to append an >> arbitrary contact to the contact header in every >> forwarding it does. The contact appended has nothing to do >> with A or B or the uri set in the avp. The same uri is >> appended in all call forwardings performed in the system. >> If the proxy is restarted, the problem disappears. >> >> Example: >> >> SIP/2.0 302 Moved Temporarily >> Via: SIP/2.0/UDP 10.100.2.254:5060;branch=z9hG4bK51461DD5 >> From: <sip:[email protected] <sip%[email protected]> >> <mailto:sip%[email protected] <sip%[email protected]>> >> <mailto:sip%[email protected] <sip%[email protected]> >> <mailto:sip%[email protected]<sip%[email protected]> >> >>>;tag=92DAB388-EE7 >> To: <sip:[email protected] <sip%[email protected]> <mailto: >> sip%[email protected] <sip%[email protected]>> >> <mailto:sip%[email protected] <sip%[email protected]> >> <mailto:sip%[email protected] <sip%[email protected]> >> >>>;tag=880a5593aeb097bc75600b31d6e17107-78ac >> Call-ID: [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> CSeq: 101 INVITE >> Contact: sip:[email protected] <sip%[email protected]> >> <mailto:sip%[email protected] <sip%[email protected]>> >> <mailto:sip%[email protected] <sip%[email protected]> >> <mailto:sip%[email protected] <sip%[email protected]> >> >>, >> <sip:[email protected]:5060;transport=udp>;q=0 >> >> Server: OpenSER (1.2.3-notls (i386/linux)) >> Content-Length: 0 >> >> >> <sip:[email protected]:5060;transport=udp>;q=0 is added >> in all forwardings done the system. >> >> Unfortunately I have no debug info cause it happens in >> production environment. I couldn't reproduce the problem >> in test environment. Have you got any idea on what could >> make it happen? >> >> Thanks a lot: >> Fran Lizaran >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> [email protected] <mailto:[email protected]> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> -- Fran Lizaran >> Comprometido con el Derecho a Vivir >> http://derechoavivir.org >> >> >> > -- Fran Lizaran Comprometido con el Derecho a Vivir http://derechoavivir.org
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
