[OpenSIPS-Users] FW: CANCELs with no transaction
Juri Nysschen
juri at greydotelecom.com
Mon Feb 14 08:36:20 CET 2011
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
More information about the Users
mailing list