I was half expecting that kind of result. I don't know what exactly opensips uses to match transactions. I believe Call-id and CSeq headers being the same but I'm quite sure there is more like maybe from tag? I don't know.
Can anyone else chime in on what opensips is checking to match a transaction. Dave. On Sun, Feb 13, 2011 at 11:36 PM, Juri Nysschen <j...@greydotelecom.com> wrote: > 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: users-boun...@lists.opensips.org > [mailto:users-boun...@lists.opensips.org] On Behalf Of Dave Singer > Sent: Monday, February 14, 2011 9:03 AM > To: ty...@fonality.com; 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 <ty...@fonality.com> 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 > <rbierschb...@telepointglobal.com> 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: rbierschb...@telepointglobal.com, im: rbierschb...@hotmail.com >>> >>> >>> >>> From: users-boun...@lists.opensips.org > [mailto:users-boun...@lists.opensips.org] On Behalf Of Juri Nysschen >>> Sent: Friday, February 11, 2011 7:44 AM >>> To: users@lists.opensips.org >>> 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 >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users