hmm - so I really need to start considering migration plans to 3.X!! :-/

Talking about ugly solutions - maybe this could work: The from_uri in lcr always shows the domain name I have given to my customers - to where they send calls. So I could create a new domain name (pointing to the same IP), and then ask the customer to send to this domain - and then in lcr I would put the new domain in the from_uri, and make prefix with no failover for that domain. So there would be a `fail-over-free` solution if calls are sent to a specific domain. Would that work?

Thanks again!

On Fri, Aug 27, 2010 at 5:17 PM, Iñaki Baz Castillo ibc@aliax.net wrote:

2010/8/27 Anders vaerge@gmail.com:

...

Hi,

I some calls to a specific `sub-region` that I want to limit to a specific trunk. Example.

Region 1: prefix 55, trunk 1, priority 10 Region 1: prefix 55, trunk 2, priority 20 Sub-region A: prefix 5512, trunk 1, priority 30

I do not want the calls to prefix 5512 to fail-over to trunk 2 in case of 404, 503 or the like. So I have tried to put priority 30 on sub-region A and a lower priority on Region 1, but it still fails over to trunk 2 - can I prevent this?

That is not possible with lcr in 1.5.X, but AFAIK it's possible in 3.X by setting the "stopper" flag to the rule with prefix 5512 (so no other rules are loaded after this one).

A workaround would be setting a specific value in the "From" field of the rule (i.e. "no-failover") and calling "load_gws" using such stirng as parameter. But it's a bit ugly (very ugly) as requires modifying the script.

-- Iñaki Baz Castillo ibc@aliax.net

This whole 3.X migration is starting to sound quite appealing!

But back to solving the immediate issue: You say I would have to have the from_uri defined for each rule. What about the ones that are current null, would they be included in any from_uri definition? Meaning that after trying with the rule where the from_uri matches, it would fail-over to where the from_uri is null? (maybe I should stop asking questions and do the test!)

//Anders

On Fri, Aug 27, 2010 at 6:13 PM, Juha Heinanen jh@tutpro.com wrote:

Anders writes:

...

Talking about ugly solutions - maybe this could work: The from_uri in lcr always shows the domain name I have given to my customers - to where they send calls. So I could create a new domain name (pointing to the same IP), and then ask the customer to send to this domain - and then in lcr I would put the new domain in the from_uri, and make prefix with no failover for that domain. So there would be a `fail-over-free` solution if calls are sent to a specific domain. Would that work?

it would, but only if you would have from pattern defined for each rule.

3.x also allows to you define lcr instances, which are totally independent from each other.  you could assign an lcr instance to the request based on from which customer the request comes from.

-- juha

...

Talking about ugly solutions - maybe this could work: The from_uri in lcr always shows the domain name I have given to my customers - to where they send calls. So I could create a new domain name (pointing to the same IP), and then ask the customer to send to this domain - and then in lcr I would put the new domain in the from_uri, and make prefix with no failover for that domain. So there would be a `fail-over-free` solution if calls are sent to a specific domain. Would that work?

So the client should use a specific From domain when it calls to 5512 prefix and another From domain when it calls to other 55 prefix. Unfeasible and weak solution IMHO as it fully depends on the client behavior.

That's why I called it ugly ;-). It could be a temporary fix though, until I am 3.x ready. The client is a VoIP providers, so he has the platform capability to do it - wouldn't really complicate his setup much.

What I really suggested in my mail (for the 1.5.X version) is ignoring the From domain of the INVITE and specify a "from" value as *parameter* when calling "load_gws()".

Yes, I kind-of understand it...just trying too see if I could find an easier way around.

Thanks for all the input!!

--Anders