Douglas Garstang writes:
Juha, not sure I understand you. It sounds like your suggesting exactly the scenario I described in my post, which really seems like a less than ideal what to do it. It means a lot of unecessary rows in the lcr table.
if you need to add those rows by hand (i.e., you don't have any management system) then check if carrierroute module could be a better match for you.
-- juha
Juha, I spent some time trying to understand and get the carrierroutefunctionality working today, and it looks like it doesn't solve myproblem either.
It appears that the default carrier cannot be changed during a call,which is no good. If we assumed that the domain was our carrier, thenit might be ok because we can call lc_rewrite_uri to switch domains,but once we've selected a new carrier, the gateways are selected basedon the 'prob' column in the db. This also isn't what we need. We needmore control than that.
The LCR module actually works better. It the gatways had a priority, we'd be happy!
I'm surprised no one has written a better module for this. In the realworld, you have multiple POPs, your carriers also have multiple POP's,multiple gateways. In the event you get a failure with one carrier, youprobably want to switch to the next cheapest carrier, not anothergateway within the same carrier (as it will probably just fail again).When selecting a carrier gateway, you need to choose the best POP touse before you select the trunk.
Doug.
____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Douglas Garstang wrote:
Douglas Garstang writes:
The LCR module actually works better. It the gatways had a priority, we'd be happy!
You have the source, go add support for priorities...
Should be as simple as tweaking the SQL statement ----> 'ORDER BY priority'
Jeremy McNamara
On Mon, Mar 24, 2008 at 7:27 PM, Jeremy McNamara jj@nufone.net wrote:
Douglas Garstang wrote:
Douglas Garstang writes:
The LCR module actually works better. It the gatways had a priority, we'd be happy!
You have the source, go add support for priorities...
Should be as simple as tweaking the SQL statement ----> 'ORDER BY priority'
Which version of openser are you using? The SQL statements are gone since 1.2 afair.
Regards, Ovidiu Sas
Douglas Garstang writes:
The LCR module actually works better. It the gatways had a priority, we'd be happy!
douglas,
in lcr module, gws belong to groups. for example, an operator could have for a city one gw group with three gws each of which being able to serve calls to that city.
we have been thinking to add weight to gws so that a bigger gateway within a group could get selected with higher probability than a smaller gw, but that has not been done yet.
I'm surprised no one has written a better module for this. In the realworld, you have multiple POPs, your carriers also have multiple POP's,multiple gateways. In the event you get a failure with one carrier, youprobably want to switch to the next cheapest carrier, not anothergateway within the same carrier (as it will probably just fail again).When selecting a carrier gateway, you need to choose the best POP touse before you select the trunk.
you make in above the assumption that if one gw in a gateway group fails, the other gateways in the same group are likely to fail too. lcr module has been designed to try another gateway in the same group before going to other (lower priority) groups. the idea has been that one of the gws in a group may simply be busy or broken whereas another gw in the group could still be able to serve the call.
if this design does not fit you, then it seems to me that you need to look for other solutions. i don't see how adding a priority to a gateway in a group could help you.
-- juha
Douglas Garstang writes:
I'm surprised no one has written a better module for this. In the realworld, you have multiple POPs, your carriers also have multiple POP's,multiple gateways. In the event you get a failure with one carrier, youprobably want to switch to the next cheapest carrier, not anothergateway within the same carrier (as it will probably just fail again).When selecting a carrier gateway, you need to choose the best POP touse before you select the trunk.
it might be possible for you to achieve what you describe using existing lcr module by having only one gw per group and then assign priorities in lcr table in such a way that for prefix +xx highest priority is gw group 1 of the cheapest carrier, then gw group 1 of second cheapest carrier, then gw group 2 of cheapest carrier and finally gw group 2 of second cheapest carrier (assuming two carriers serving +xx).
-- juha
On Monday 24 March 2008, Douglas Garstang wrote:
Juha, I spent some time trying to understand and get the carrierroutefunctionality working today, and it looks like it doesn't solve myproblem either.
It appears that the default carrier cannot be changed during a call,which is no good. If we assumed that the domain was our carrier, thenit might be ok because we can call lc_rewrite_uri to switch domains,but once we've selected a new carrier, the gateways are selected basedon the 'prob' column in the db. This also isn't what we need. We needmore control than that.
Douglas,
first of all, there is no such thing like a 'call' in OpenSER, at least without the help dialog module. What you basically do is to route INVITEs to certain GWs. So i don't understand your complain here. If you need more control as possible at the moment, then perhaps you can extend the code? I guess that many people on this list just do this, instead of complaining.
I'm surprised no one has written a better module for this. In the realworld, you have multiple POPs, your carriers also have multiple POP's,multiple gateways. In the event you get a failure with one carrier, youprobably want to switch to the next cheapest carrier, not anothergateway within the same carrier (as it will probably just fail again).When selecting a carrier gateway, you need to choose the best POP touse before you select the trunk.
Carrierroute is used in 'real world' scenarios to route traffic for several million customers. We've a similar scenario like you describes. Ovidiu also give you some details about his usage. If you have a failure in the first domain, then you just skip to the next domain for the same carrier. If you don't like this, than you could do either:
- wait for release 1.4, with an improved carrierroute failure handling - hack yourself some solution on top of the available code - or try to come up with a db setup that implement a reasonable solution with the available release
Best regards,
Henning
-
Douglas Garstang -
Henning Westerholt -
Jeremy McNamara -
jh＠tutpro.com -
Ovidiu Sas