News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Use of Trunk Group (TGn) for call route fallback

Started by lk96, July 05, 2013, 05:07:35 PM

Previous topic - Next topic

lk96

I glanced a bit over past posts and read the documentation but I'm still not clear if and how
I can accomplish the following:

I use a provider that allow calls to be sent over different routes by adding a specific
prefix infront of the number. So for example there is premium route and a default/standard route.
So if <1231231234> is the number I wanted to call, the number that needs to be dialed in order for the call to be routed over the corresponding routes for example will be:
789 1231231234 (for standard route)
790 1341231234 (for premium route)

The problem I experienced recently is that the premium route could not complete my calls
but the standard route could. So I was thinking that it would be very nice that
when my premium route started failing, the obito automatically switch over calls on the standard route.
My trunk group would contain vg1 and vg2 as the two gateways to use.

But the digits to be dialed have to be different on each one of those gateways.
The fields used in the trunk definition though allow for a single trunk group digitmap.

Any ideas on how to generate two different set of numbers to be dialed and used on
different members of a trunk group  even though the definition of the trunk group allows
the specification of a single digitmap ?

thanks

L.

lk96

I think I found a way to do what I described by using a simple custom digitmap to work around
some of the formatting I needed.

So now I have tg1 made of vg3 and vg4.
At this moment the route/service provider for vg3 returns a 404 error (cannot reach destination).
vg4 is a fully functional route/service.

when I place a call over tg1 though, when obi tries to place the call over vg3 (which is
the first member of the trunk) I still get the same 404 error and the 2nd route in the trunk
is not even attempted.

May be to ask a bit differently what I want to do: is there a simple way to fork an outgoing call
over 2 routes/interfaces ?

btw, the syntax of the InboundCAllRoute allows (and I'm using it heavily) to fork an incoming call to
multiple destinations. What about a call though that is placed through the phone itself. Is there a way
to accomplish the same ?

ianobi

#2
A simple Trunk Group would work like this:

Voice Services > Gateways and Trunk Groups > Trunk Group1 >
TrunkList: sp1,sp2
DigitMap: (Msp1)

If sp1 registration failed or if all sessions for sp1 are in use, then outgoing calls will pass over to sp2. Registration failure may take a few minutes to be detected by the OBi, so for a time it won't know that sp1 has failed. Most voip providers allow at least two sessions (calls) on each trunk, so if sp1 has two simultaneous calls ongoing, then a third call will then pass on to sp2.

Your first problem is that I think you have only one provider – you don't say if it needs registration or not. If not, then the OBi will never know if it has failed.

I'm guessing that you are pointing vg3 and vg4 at the same provider on spX. Your OBi has no way of telling if vg3 or vg4 has failed as they are designed for outgoing use only and never require registration.


QuoteI still get the same 404 error and the 2nd route in the trunk
is not even attempted.

The 404 message is coming from your voip provider. You may wish to check Call History to make sure that the digits sent to the provider are correct for that service.

QuoteMay be to ask a bit differently what I want to do: is there a simple way to fork an outgoing call
over 2 routes/interfaces ?

OBi devices do not allow call forking on outbound calls. The only not simple way is to make the calls from a softphone/OBiAPP or OBiON, routing the calls through your OBi, which then makes them incoming calls to the OBi which can then be forked.


Sorry to give you so much bad news! Some of my assumptions about your setup may be wrong, so post back more details if you think something can be made to work.

I use trunk groups and find them very useful. They are not just useful for "failover" situations. When used as part of an InboundCallRoute, they can add a second stage to call routing similar to how Phone Port DigitMap and OutboundCallRoute works.

lk96

thanks much. I think you clarified the missing pieces.

My service provider does not require registration, in fact, it doesn't support registration. So registration
will always fail. However,  I do have the "enable registration" active because I found
(and this was another recent posting) I was getting one way audio because the obi would send
the local IP address as opposed to my public IP address.

And your understanding is correct: I'm trying to use the same provider for the two "routes".

Yes, I know that the 404 is sent from the provider. In fact I filed a ticket with them
and they confirmed that the specific route was down/blocked (read the PS below for the reason they took it down).

So I'm basically looking for functionality found normally in more complete PBXs/Asterisk/Freeswitch where
upon certain errors like the above, the switch may attempt automatically an alternate route.

Based on what you said this is not possible.

So my stopgap manual solution will be to use different VGs, that I can access through a **N code manually.

thanks for the response

L.

PS: if you are curious why my so called "direct" trunk was down: My SIP trunk is
from a wholesale VOip provider. As such, they post their termination rates fairly often (about weekly).
If for some reason their negotiated rates increase between postings, it seems that they simply don't want
to lose $$$ and they want also to not handle calls at a price that is higher to what
they committed to the end user/customer.
And for that reason they block all calls whose effective rate would have exceeded the wholesale
rates posted. The presumed handling on the user side is that you normally have more than one
SIP/voip providers and as such whenever you get a completion error like the one I got, the SIP adaptor/softswitch/etc will try silently an alternate route to complete the calls.
In my case it so happens that the lower cost trunks
were fully operational. But I couldn't really access them until I modified my digitmaps.

ianobi

Interesting setup you have there!

"Retry number on alternative trunk after error code received" may be one for "Feature Requests". It could be set up using the Trunk Group function.

lk96

yep exactly, that's the feature I was looking for. And you worded it perfectly.

btw, I did consider using a single stage/two stage dialing by looping back calls through the obitalk network
(may be using a 2nd obi) so that I can use the forking capability of the inboundcallroute. But then
the setup gets convoluted and prone to errors as it involved more links and more obis. So I'm not
going to bother going that way.

btw2: have the Obi people ever consulted or supported any of the feature requests posted on that part
of this forum ?

L.


giqcass

Quote
btw2: have the Obi people ever consulted or supported any of the feature requests posted on that part
of this forum ?

I got one of my feature request filled but it happened so quickly I believe they were working on it before I requested it.

Long live our new ObiLords!

ianobi

Quotebtw2: have the Obi people ever consulted or supported any of the feature requests posted on that part of this forum ?

Sadly, not much evidence of that. However, I notice that Obihai now use the "Oleg Method" in some of their standard setups. I believe that they picked that up from this forum.

Shale

#8
Quote from: ianobi on July 06, 2013, 12:07:36 PM
Quotebtw2: have the Obi people ever consulted or supported any of the feature requests posted on that part of this forum ?

Sadly, not much evidence of that. However, I notice that Obihai now use the "Oleg Method" in some of their standard setups. I believe that they picked that up from this forum.
Most interesting.  They may not use the same method for each of their supported SIP providers. I look forward to doing some editing.

I just did a test. Indeed, when in the Expert Mode I undid the override on my OBiTalk Settings for my Anveo SP, the   X_InboundCallRoute was modified to the Oleg method. While I had put my own value there, the replacement value did not use the optional single quotes that I had used. I am not certain that copying the AuthUserName to the X_InboundCallRoute will work for every provider, but I expect OBi will determine that for each.

This is a really good development. The majority of users will no longer be plagued by SIP scanners. I made an interim change to http://www.obitalk.com/forum/index.php?topic=5467.0 to reflect this discovery.