append_brach() is needed on failure_route(). This was discussed several times on the mailing list.

Regards, Ovidiu Sas

On Mon, Aug 18, 2008 at 2:54 PM, Elena-Ramona Modroiu ramona@rosdev.ro wrote:

Jonathan K. Creasy wrote:

...

I have this block in my configuration:

<excerpt from failure_route[1]>

if(!cr_rewrite_uri("1", "call_id")){ t_reply("403", "$fU@$fd Not allowed"); } else { # In case of failure, re-route the request prefix("+"); t_on_failure("2"); if (is_method("INVITE")) t_on_reply("1"); # Relay the request to the gateway t_relay(); }

The output in my log file:

Aug 18 18:41:29 lab02b /usr/local/sbin/openser[5622]: INFO: carrierroute:carrier_rewrite_msg: uri 8909 was rewritten to sip: 8909@gateway_one Aug 18 18:41:29 lab02b /usr/local/sbin/openser[5626]: INFO: Failure Route Started Aug 18 18:41:29 lab02b /usr/local/sbin/openser[5626]: INFO: carrierroute:carrier_rewrite_msg: uri 8909 was rewritten to sip: 8909@gateway_two Aug 18 18:41:29 lab02b /usr/local/sbin/openser[5626]: ERROR: tm:t_forward_nonack: no branch for forwarding Aug 18 18:41:29 lab02b /usr/local/sbin/openser[5626]: ERROR: tm:w_t_relay: t_forward_nonack failed

What am I missing that I need to do prior to calling t_relay()?

I haven't used carrierroute module, but seems it doesn't add the new uri as branch. After the line prefix("+") add append_branch() and see if it work now.

Regards, Ramona

...

-Jonathan

---

Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

I just remembered that long time ago I got tired about this question and I built a simple sample config. Here it is: http://voipembedded.com/resources/openser_cr.cfg

Regards, Ovidiu Sas

On Mon, Aug 18, 2008 at 3:09 PM, Jeremy McNamara jj@nufone.net wrote:

Ovidiu Sas wrote:

...

append_brach() is needed on failure_route(). This was discussed several times on the mailing list.

Smells like a high visiablity blog entry needs to be made on this topic then :)

---

Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

The config there is for openser 1.3. It needs to be upgraded to 1.4. carrierroute seems to be the only module that had an API change, everything else should be working as is.

Regards, Ovidiu Sas

On Tue, Aug 19, 2008 at 5:20 AM, sergejf serge@elasticall.com wrote:

Hi Ovidiu,

I just had a look at http://voipembedded.com/resources/openser_cr.cfg and noticed that it uses cr_tree_rewrite_uri(tree, domain) which seems to have been superseded by cr_route(tree, domain, "$rU", "$rU", "call_id"). Is that correct? Are there other parts of the cfg file that need to be updated?

Serge

Ovidiu Sas-3 wrote:

...

I just remembered that long time ago I got tired about this question and I built a simple sample config. Here it is: http://voipembedded.com/resources/openser_cr.cfg

Regards, Ovidiu Sas

-- View this message in context: http://www.nabble.com/failure-route-configuration-tp19037695p19046933.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

---

Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

carrierroute has a specific way of dealing with errors, see cr_next_domain(). http://www.kamailio.net/docs/modules/1.4.x/carrierroute.html#id2452857 You will need to populate two tables: - carrierroute - carrierfailureroute

Form the examples given on the README file it seems that you will need to use different domains for failure route. In the end, it is a matter of populating the cr tables in order to properly control the traffic.

Regards, Ovidiu Sas

On Tue, Aug 19, 2008 at 10:27 AM, sergejf serge@elasticall.com wrote:

We're using OpenSER 1.3 so this should be fine.

However, I'm looking at the failure routes and notice that what you are doing is selecting a new domain when the initial routing attempt returns an error. Assuming I have three gateways "G1" to "G3" in the same domain "D1" and the hash function causes the initial INVITE to be transmitted to "G1" which is saturated (503 returned), how can I sequentially try "G2" and "G3" in the failure routes? Am I going to need two failure routes with two additional domains "D2" and "D3", changing the hash_index of each gateway in the domains? E.g. if "G1" hash_index = 1 in "D1", then should I put "G2" hash_index = 1 in "D2" and "G3" hash_index = 1 in "D3"?

The Dispatcher had an elegant way of dealing with post-failure re-routing by returning the destination set resulting from the first load balancing operation and allowing the script to then remove the last tried destination from the set and making another routing attempt on the reduced set. It seems that CarrierRoute doesn't support this, not even in its 1.4 incarnation.

Ovidiu Sas-3 wrote:

...

The config there is for openser 1.3. It needs to be upgraded to 1.4. carrierroute seems to be the only module that had an API change, everything else should be working as is.

Regards, Ovidiu Sas

-- View this message in context: http://www.nabble.com/failure-route-configuration-tp19037695p19050540.html Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

---

Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

On Wednesday 20 August 2008, sergejf wrote:

The issue is that upon hitting a routing failure to a specific gateway in a domain, we do not want to try the next domain but instead the next gateway in the current domain, and so on until no gateway remains and we return a 503 message. This is a common way of handling failure routes in the Dispatcher but it doesn't seem that the CarrierRoute supports it.

Hi sergejf,

you can implement something like this with the carrierfailureroute table, but its probably a little bit more work. Take a look at the example 1.47 in the 1.4.0 documentation.

Perhaps something similar to this will work even without duplicating to much routing entries in the carrierfailureroute table. You can store the destination in an AVP (see cr_route, dstavp parameter), and check before doing the relay in the failure route that the "new" host is not equal the old. If there are equal, try a new route attempt, and just bail out after a few tries in the loop. Not sure if this work, not tested.

Of course its also possible to just change the code to achieve the wanted behaviour. But if you don't need that much routing rules, perhaps the easiest way is just using the dispatcher module.

Cheers,

Henning