[OpenSIPS-Users] FW: CANCELs with no transaction

[Dave Singer]

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 <juri at 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-bounces at lists.opensips.org
> [mailto:users-bounces at lists.opensips.org] On Behalf Of Dave Singer
> Sent: Monday, February 14, 2011 9:03 AM
> To: tyler at 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 <tyler at 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
> <rbierschbach at 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: rbierschbach at telepointglobal.com, im: rbierschbach at hotmail.com
>>>
>>>
>>>
>>> From: users-bounces at lists.opensips.org
> [mailto:users-bounces at lists.opensips.org] On Behalf Of Juri Nysschen
>>> Sent: Friday, February 11, 2011 7:44 AM
>>> To: users at 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 at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>