Hi Dave, Thanks this method is very successful in delivering the CANCEL downstream, over multiple hops, unfortunately the PSTN also doesn't see the transaction id and therefore the call keeps ringing. The key is finding the reason why the transaction id disappears or at least be able to put it back when delivering the CANCEL downstream.
Regards Juri Nysschen -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Singer Sent: Monday, February 14, 2011 9:03 AM To: [email protected]; OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] FW: CANCELs with no transaction Juri, You say it only happens after a do_routing(). To be clear, you mean that you used do_routing on the invite and not that you already tried do_routing for the cancel earlier in the script. (I'm not sure it would make any difference) The hack to store the destination in a variable is one you would want to strongly avoid. But sometimes hacks are unavoidable and a stop gap until you can really resolve the problem. I believe $avp's are retained per transaction and if the t_check_trans() fails then the $avp created in the reply would also not be available. $var also would not work most of the time since it is persistent per process. You would need to use core functions cache_store and cache_fetch using either local_cache or memcached backend depending if you need persistant between opensips reboot. Example: route{ ..... if (is_method("CANCEL") ) { route(5); # drop media proxy if (t_check_trans()){ # this always fails after a do_routing() xlog("L_INFO","CANCEL Transaction[$fd/$fu/$rd/$ru/$si/]\n"); t_relay(); exit; } else { if ( cache_fetch("local", "tran_dest_$ci", "$avp(s:next_hop)") ) { $rd = $avp(s:next_hop); t_relay(); } exit; } } on_reply[main] { cache_store("local", "tran_dest_$ci", "$si", 500); } Dave On Sun, Feb 13, 2011 at 5:15 AM, Tyler Merritt <[email protected]> wrote: > > Why not use an $avp and grab the Call ID header on the inbound packet and then create some routing logic that checks the $avp against the return packet Call ID header to validate it's the same thing? $avps can be made available onreply with a modparam though forgive me if it's a bit late at night and I don't have the link handy. > An avp can store more than a single value but they index in reverse order as written if I recall correctly. > > On Sat, Feb 12, 2011 at 5:05 AM, Russell Bierschbach <[email protected]> wrote: >> >> I have a similar problem, but not solution, my probably is actually occurring because the originating UA is ignoring a contact header that is sent back during a 183 progress message. OpenSIPS uses information from that contact header to figure out where to relay the incoming message (BYE in my case, CANCEL in yours). It seems like it would be possible for OpenSIPS to use a call-id or tag to determine where to relay the message though. >> >> >> >> Russell Bierschbach >> >> em: [email protected], im: [email protected] >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf Of Juri Nysschen >> Sent: Friday, February 11, 2011 7:44 AM >> To: [email protected] >> Subject: [OpenSIPS-Users] FW: CANCELs with no transaction >> >> >> >> Hi All, >> >> >> >> Need help with a nagging issue: >> >> >> >> UA->Opensips 1->Opensips 2->PSTN >> >> >> >> UA sends an invite on Opensips 1, and is routed via do_routing() to Opensips 2, Opensips 2 uses do_routing to get to the PSTN, call starts ringing. >> >> >> >> UA cancels call before answer, but now t_check_trans fails and the CANCEL is not passed onto the PSTN, with the result that the call rings forever and can only be terminated by the remote answering and dropping the call or through a timeout. >> >> >> >> The scripts on Opensips 1 & Opensips 2 is virtuall identical: >> >> >> >> How do I get the CANCEL to the PSTN ? >> >> >> >> route{ >> >> ..... >> >> if (is_method("CANCEL") ) { >> >> route(5); # drop media proxy >> >> if (t_check_trans()){ # this always fails after a do_routing() >> >> xlog("L_INFO","CANCEL Transaction[$fd/$fu/$rd/$ru/$si/]\n"); >> >> t_relay(); >> >> exit; >> >> }; >> >> exit; >> >> } >> >> } >> >> >> >> >> >> route[4] { >> >> xlog("L_INFO","Route4 [$fd/$fu/$rd/$ru/$si/]\n"); >> >> >> >> $avp(i:102)=1; # Default dr-group >> >> route(10); # Do custom stuff >> >> t_on_failure("4"); >> >> if (do_routing("$avp(i:102)")){ >> >> xlog("L_INFO","Route4 Route to Dyna Group: $avp(i:102)[$fd/$fu/$rd/$ru/$si/]\n"); >> >> t_newtran(); >> >> route(1); >> >> exit; >> >> }; >> >> xlog("L_INFO","Route4 No Route to Host[$fd/$fu/$rd/$ru/$si/]\n"); >> >> sl_reply_error(); >> >> exit; >> >> } >> >> >> >> Regards >> >> Juri Nysschen >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ 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
