No subject

identical to the INVITE it is canceling (without some headers that
aren't useful in a cancel like Supported)
It seems that the "branch=3D...." , a "Magic Cookie", on the top most
via line is a turbo lookup to finding the transaction. That matches
the original INVITE and all is well. If it is not there then it has to
compare all the pertinent headers between invite and cancel.

So if you can't get them to send the proper stuff, you could modify
the previous hack to store the branch=3D... that opensips put in the via
header it added (probably can't see it when sending the invite but it
is in the 1xx response to your invite.
Actually I just found one better I think. Use the exec module to
execute MI command t_uac_cancel
(http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id294623)
All it needs are callid and cseq num, which I hope at least they are
the same as the INVITE, which you can use the CANCEL's parsed vars for
the params. I you will probably need to send back a negative response
to the bad CANCEL like 400 Bad Message (look up appropriate
code/message). And I think the t_uac_cancel will also push into
failure_route a 487 response, which if you don't choose anything else
specifically, will be sent back to the originator.
You will want to verify it with packet captures and see how it affects
your cdrs.

Let me know the outcome.

Dave

On Mon, Feb 14, 2011 at 11:05 AM, Dave Singer =
<dave.singer at wideideas.com>
wrote:
> 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.=A0 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{
>>
>> .....
>>
>> =A0 =A0 =A0if (is_method("CANCEL") ) {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0route(5); # drop media proxy
>>
>> =A0 =A0 =A0 =A0 =A0 =A0if (t_check_trans()){ # this always fails =
after a do_routing()
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0xlog("L_INFO","CANCEL
>> Transaction[$fd/$fu/$rd/$ru/$si/]\n");
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0t_relay();
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exit;
>>
>> =A0 =A0 =A0 =A0 =A0 =A0} else {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ( cache_fetch("local", =
"tran_dest_$ci",
>> "$avp(s:next_hop)") ) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$rd =3D $avp(s:next_hop);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0t_relay();
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> =A0 =A0 =A0 =A0 =A0 =A0exit;
>>
>> =A0 =A0 =A0}
>>
>> }
>>
>>
>> on_reply[main] {
>> =A0 =A0cache_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? =A0$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.=A0 OpenSIPS uses information =
from
>> that contact header to figure out where to relay the incoming message
(BYE
>> in my case, CANCEL in yours).=A0 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{
>>>>
>>>> .....
>>>>
>>>> =A0=A0=A0=A0=A0 if (is_method("CANCEL") ) {
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 route(5); # drop media proxy
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (t_check_trans()){ # this =
always fails after a
>> do_routing()
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
xlog("L_INFO","CANCEL
>> Transaction[$fd/$fu/$rd/$ru/$si/]\n");
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 t_relay();
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exit;
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 };
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exit;
>>>>
>>>> =A0=A0=A0=A0=A0 }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> route[4] {
>>>>
>>>> =A0=A0=A0=A0=A0 xlog("L_INFO","Route4 [$fd/$fu/$rd/$ru/$si/]\n");
>>>>
>>>>
>>>>
>>>> =A0=A0=A0=A0=A0 $avp(i:102)=3D1; # Default dr-group
>>>>
>>>> =A0=A0=A0=A0=A0 route(10); # Do custom stuff
>>>>
>>>> =A0=A0=A0=A0=A0 t_on_failure("4");
>>>>
>>>> =A0=A0=A0=A0=A0 if (do_routing("$avp(i:102)")){
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 xlog("L_INFO","Route4 Route to =
Dyna Group:
>> $avp(i:102)[$fd/$fu/$rd/$ru/$si/]\n");
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 t_newtran();
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 route(1);
>>>>
>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 exit;
>>>>
>>>> =A0=A0=A0=A0=A0 };
>>>>
>>>> =A0=A0=A0=A0=A0 xlog("L_INFO","Route4 No Route to =
Host[$fd/$fu/$rd/$ru/$si/]\n");
>>>>
>>>> =A0=A0=A0=A0=A0 sl_reply_error();
>>>>
>>>> =A0=A0=A0=A0=A0 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
>>
>

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users