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
