[OpenSIPS-Users] cache_fetch on failure route issue

Newlin, Ben Ben.Newlin at inin.com
Tue Mar 29 17:23:29 CEST 2016


In on_reply_route all pseudo-variables are evaluated by default in the context of the reply, but in failure_route they are evaluated by default in the context of the request. I think you are probably getting a different value for $si than you are expecting in the failure_route case and there is no entry in the cache so it returns <null>. You can check this by printing your key values ("bran$ci$rd” and "bran$ci$si”)before each use to see if they are all the same. I think they will be different.

You can use the <reply> context, but I’m not sure if it will work for $si. See this: http://www.opensips.org/Documentation/Script-CoreVar-2-1

Ben Newlin

From: <users-bounces at lists.opensips.org<mailto:users-bounces at lists.opensips.org>> on behalf of Arsen <arsen.semionov at gmail.com<mailto:arsen.semionov at gmail.com>>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Date: Tuesday, March 29, 2016 at 11:08 AM
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Subject: [OpenSIPS-Users] cache_fetch on failure route issue

Hi guys,

We have an issue with cache_fetch function.

In the per_branch_route I store destination numbers as following (we have multiple choice gateways here):

cache_store("local","bran$ci$rd","$rU",90);

In the on_reply_route in case of 200-OK I can successfully fetch the destination number:

cache_fetch("local","bran$ci$si", $avp(cached_dst));

But in case of the failed call the same function always return <null>

failure_route[FAILURE_REDIR] {

  if (!t_check_status("[1|2|3][0-9][0-9]")) {

     cache_fetch("local","bran$ci$si", $avp(cached_dst));

  }

}

Can we use cache_fetch in the on_failure route?

Please advice

Thanks,

--
Regards,
Arsen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160329/056ec3af/attachment-0001.htm>


More information about the Users mailing list