News:

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

Main Menu

Help with complex digit map

Started by xpr722946ghd, May 05, 2017, 12:27:04 AM

Previous topic - Next topic

xpr722946ghd

Hi Folks.  New Obi202 user here.  Migrating from a Sipura.

Using 1 provider, I typically make calls to North America (where I am based) and the UK.

I want to be able to dial North America by 1 followed by area code & number.  Also without the 1 if I want.

BUT, I also want to be able to dial UK numbers beginning with 01, 02 or 07 just as if I was in the UK. I set up a great dial plan on the Sipura that has worked perfectly for over 10 years.  When I dial 01xxx xxxxxx for example, it transforms to 044441xxx xxxxxx.  Here is the Sipura plan (which has provision for a couple of other features too) :

(*xxxx|1xx|<:1780>[2-9]xxxxxx|<:1>[2-9]xx[2-9]xxxxxx|1[2-9]xx[2-9]xxxxxx|<07:011447>xxxxxxxxx|<0:04444>[1-2]xxxxxxxxx|<44:04444>[1-2]xxxxxxxxx|011[2-9]x.|310xxxxS0)

I had hoped transposing this into the Obi Digit Map would work.  However it doesn't.  I modified it to the following for the Obi Digit Map :

(*xxxx|1xx|<:1780>[2-9]xxxxxx|<:1>[2-9]xx[2-9]xxxxxx|1[2-9]xx[2-9]xxxxxx|<07:011447>xxxxxxxxx|<0:04444>[1-2]xxxxxxxxx|<44:04444>[1-2]xxxxxxxxx|011[2-9]x.|310xxxxS0|(Mipd)|[^*]@@.)

When I dial a 01 or 02 UK number, I get the Obi 404 message saying the call to 01xxx xxxxxx didn't not go through.  It is almost as if the 01 didn't get transformed into 044441.

Dialing 44xxxx xxxxxx yeilds error code 603.

North America numbers are working fine.  Service Provider is voip.ms but I'm certain this is not a provider issue but a digit map problem.

Is there some kind of restriction on transforming numbers that begin with 0?  But then why would the 44 prefixed calls be giving me an error (albeit a different one)?

Your help would be most welcome!
Thanks guys.
Rob

drgeoff

#1
You can log in to the OBi's on board web server GUI and click on Status and then on Call History to see what digits were actually sent to the Service Provider.

Your bit of the plan for UK 07 mobile numbers looks OK. Do they connect OK? If yes,  try repeating that but changing the 7 to 1 and 2 in the two places. Remove the other sections you entered.

There is an excellent tutorial on digit maps and routeing to be found in the Docs and Downloads page at obihai.com.

xpr722946ghd

Quote from: drgeoff on May 05, 2017, 01:50:10 AM
You can log in to the OBi's on board web server GUI and click on Status and then on Call History to see what digits were actually sent to the Service Provider.

Your bit of the plan for UK 07 mobile numbers looks OK. Do they connect OK? If yes,  try repeating that but changing the 7 to 1 and 2 in the two places. Remove the other sections you entered.

There is an excellent tutorial on digit maps and routeing to be found in the Docs and Downloads page at obihai.com.

Thanks for the reply, and tip to check the Call Log.  I hadn't realized that would show me what was being sent out.
As expected, the digit transformation is not happening.  The extra digits are not being added.

Call log shows the actually number I typed into the phone.  Same with the UK mobile 07 numbers as with the geographical 01 and 02 numbers.

Thanks for pointing out the digit map tutorial.  I had been studying it furiously for about an hour, while experimenting, before posting on the forum.

BTW, the 044 code is the voip.ms way of forcing an international call via a premium route when value international calls are the account default.  So 04444 is the equivalent of dialing 01144 via premium routing. Interestingly when I dial 04444 28xx xxxxxx or 04444 1xxx xxxxx from the handset the calls go through just fine.

So the problem seems to be the 07 is not being converted to 011447.
Any ideas why the transformation is not taking place?  From what I can tell my syntax is correct.

azrobert

I don't see any errors. If you made any Phone Port DigitMap changes, please post them. A wild guess is to try the following digit map:

(*xxxx|1xx|<:1780>[2-9]xxxxxx|<:1>[2-9]xx[2-9]xxxxxx|1[2-9]xx[2-9]xxxxxx|<07:011447>xxxxxxxxx|<0:04444>[1-2]xxxxxxxxx|<44:04444>[1-2]xxxxxxxxx|011[2-9]x.|310xxxxS0|04444x.)

xpr722946ghd

Quote from: azrobert on May 05, 2017, 09:12:05 AM
I don't see any errors. If you made any Phone Port DigitMap changes, please post them. A wild guess is to try the following digit map:

(*xxxx|1xx|<:1780>[2-9]xxxxxx|<:1>[2-9]xx[2-9]xxxxxx|1[2-9]xx[2-9]xxxxxx|<07:011447>xxxxxxxxx|<0:04444>[1-2]xxxxxxxxx|<44:04444>[1-2]xxxxxxxxx|011[2-9]x.|310xxxxS0|04444x.)


Yeah, I don't see any errors either.  And the Sipura was happy running on that dial plan for years. 
Not sure what you've modified, but I will give that digit map a go.  Just waiting on an incoming call so can't reboot the Obi to try it just yet.

I tried removing the international dial plan part (just in case the 011 was conflicting.  Made no difference.  Call logs still showed no transformation happening to the numbers.

Have made no changes to the phone port digit map or outgoing call routing maps.  That will start once I get this digit map nailed down  ;)

drgeoff

I know it is unlikely but just in case.  The 202 has two phone ports and there are independent digit maps for each one.  Are you modifying the digit map for the phone port you are dialling from?

xpr722946ghd

Quote from: drgeoff on May 05, 2017, 09:38:51 AM
I know it is unlikely but just in case.  The 202 has two phone ports and there are independent digit maps for each one.  Are you modifying the digit map for the phone port you are dialling from?

The only digit map I've altered is the ITSP A General one. 

I MAY HAVE IDENTIFIED THE PROBLEM - but don't know how what is causing this behaviour.

I enter the custom digit map (any of the ones listed above), click Submit.  When I return to the config page I can see the changes.  Then I reboot the router.
It never struck me to check the digit map after reboot.  What I have discovered is that the digit map does not display my newly saved entries after reboot.  It is going back to

(*75xx|*xx|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*]@@.)
which I assume is the voip.ms default.  Even though it returns to this, the default box is unchecked.

So it seems to save my entry, but upon reboot, looses my custom digit plan.  That's why the calls were not working, and why the plan looks right.

I just don't know why it won't keep the custom plan upon reboot.  Any ideas?

drgeoff


xpr722946ghd

Quote from: drgeoff on May 05, 2017, 10:41:37 AM
Quote from: xpr722946ghd on May 05, 2017, 10:37:33 AM
I just don't know why it won't keep the custom plan upon reboot.  Any ideas?
Yes, the #1 gotcha for noobs!

http://www.obitalk.com/forum/index.php?topic=61.msg109#msg109

You mean I have fallen into the same hole a million other people have?  That's humiliating  :'(

Reading that post I'm not sure what to do next.  Here's my thinking.

I definitely want to be able to use a custom digit map, and I eventually want the device to automatically select which line to route calls too.  I don't mind unlinking it from ObiTalk portal.  However, I do want to sign up for one of the special Anveo accounts which I have to do through the ObiTalk portal.

Can I unlink, and still sign up for Anveo?
Or do I need to sign up for Anveo first before unlinking?
Or do I use the local web intercafe and disable ITSP Provisioning from there?
Or ditch the local web interface, and do everything through the ObiTalk web interface (assuming I can access the same level of functionality as through the local web interface?

Thanks for your patience with me!

drgeoff

Ditch the local web interface, and do everything through the ObiTalk web interface EXPERT MODE.

You can still use the local mode to LOOK at settings, but not modify them.

xpr722946ghd

Quote from: drgeoff on May 05, 2017, 11:08:03 AM
Ditch the local web interface, and do everything through the ObiTalk web interface EXPERT MODE.

You can still use the local mode to LOOK at settings, but not modify them.

BINGO  ;D

Using the Expert Settings part of the web interface has done the trick.  The following digit map is working perfectly!
(*xxxx|1xx|<:1780>[2-9]xxxxxx|<:1>[2-9]xx[2-9]xxxxxx|1[2-9]xx[2-9]xxxxxx|<07:011447>xxxxxxxxx|<0:04444>[1-2]xxxxxxxxx|<44:04444>[1-2]xxxxxxxxx|011[2-9]x.|310xxxxS0|(Mipd)|[^*]@@.)

Thank you so much to all contributors for helping me get this sorted.

Now that has been accomplished, we move on to phase 2  ;)  Directing calls to different providers automatically.

The goal :
UK calls (07, 01, 02) numbers get routed to SP1
Canadian calls (all area codes) routed to SP2
US calls (all non-Canadian or non-toll-free North American area codes) routed to SP4 (My GV account)
UK toll free calls (0800, 0808, 0500) routed via SP3
CAN & US toll free calls routed to SP1
International calls (outside of UK & North America) routed via SP1

Initially 911 calls need to route via SP1 until I have E911 services configured on SP2.

Having this fully automated would be very cool.

According to the tutorial I can handle this via Outbound Call Routes in the phone port section.

When writing the Outbound Call Route digit map, do I represent the number as dialled (e.g. 02xxx xxxxxx for a UK number) or what the service provider sees after transformation according to the digit map above (e.g. 044442xxx xxxxxx)?

I realize this might take a bit of scripting to come up with, but if anyone has any examples of separating Canadian / US calls for example, that would be most helpful.

I am wondering if I can create a list of Canadian area codes which get routed to SP2, and all other codes beginning with a 1 (with the exception of toll free) can be sent to SP4.

Any advice / suggestions / ways of doing this I haven't thought of?
Rob

drgeoff

#11
I suggest that you use the digit map under each ITSP to determine what dialled numbers that ITSP will handle.  You then refer to that digit map in the Phone Port's OutboundCallRoute.

I'm in the UK and don't need to differentiate between US and Canadian numbers so I don't know if there is an easy way to do that other than by listing all the Canadian area codes. (https://www.allareacodes.com/canadian_area_codes.htm) OutboundCallRoutes are processed left to right and the first successful match wins, so if you have the Canadian map early in the rules it will catch all the Canadian ones before the general rule for the whole NANP gets the remaining (USA) ones.

You may need to refer to the Admin Guide http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf, page 195.

Yes, the OutBoundCallRoute sees the mangled version of whatever a phone port digit map does to the number dialled on the phone.

A tip: When dealing with long digit maps or call routes, do all the editing in a text editor on your computer.  Then copy and paste into the small field in the web browser page.

xpr722946ghd

Quote from: drgeoff on May 05, 2017, 01:52:25 PM
I suggest that you use the digit map under each ITSP to determine what dialled numbers that ITSP will handle.  You then refer to that digit map in the Phone Port's OutboundCallRoute.

I'm in the UK and don't need to differentiate between US and Canadian numbers so I don't know if there is an easy way to do that other than by listing all the Canadian area codes. (https://www.allareacodes.com/canadian_area_codes.htm) OutboundCallRoutes are processed left to right and the first successful match wins, so if you have the Canadian map early in the rules it will catch all the Canadian ones before the general rule for the whole NANP gets the remaining (USA) ones.

You may need to refer to the Admin Guide http://www.obihai.com/docs/OBiDeviceAdminGuide.pdf, page 195.

Yes, the OutBoundCallRoute sees the mangled version of whatever a phone port digit map does to the number dialled on the phone.

A tip: When dealing with long digit maps or call routes, do all the editing in a text editor on your computer.  Then copy and paste into the small field in the web browser page.

Thanks for pointing out the larger admin guide.  Just read through the pages now.
I think I'll set up the user digit maps for Canadian numbers.  That will help the Outbound Call Route dialog be more readable.

As for your tip, I do just that.  I keep several generations of amended digit maps in Evernote, so should I need to revert after breaking something, it is a simple copy / paste operation  :)

SteveInWA

Quote
The goal :
UK calls (07, 01, 02) numbers get routed to SP1
Canadian calls (all area codes) routed to SP2
US calls (all non-Canadian or non-toll-free North American area codes) routed to SP4 (My GV account)
UK toll free calls (0800, 0808, 0500) routed via SP3
CAN & US toll free calls routed to SP1
International calls (outside of UK & North America) routed via SP1

Rather than spend a lot more time, adding this additional layer of complexity to your digit maps, why don't you re-think the need for 4 different service providers, with logic to select between them?  I don't think you've told us which providers are provisioned on each SPx, so I will simply point out that all calls to Canada are free via Google Voice, as are all US toll-free calls.  Google Voice also has supposedly competitive rates to the UK:

https://support.google.com/hangouts/answer/3187125

https://www.google.com/voice/b/0/rates?p=hangout#U


xpr722946ghd

Quote from: SteveInWA on May 06, 2017, 10:58:12 PM

Rather than spend a lot more time, adding this additional layer of complexity to your digit maps, why don't you re-think the need for 4 different service providers, with logic to select between them?  I don't think you've told us which providers are provisioned on each SPx, so I will simply point out that all calls to Canada are free via Google Voice, as are all US toll-free calls.  Google Voice also has supposedly competitive rates to the UK:

The quickest answer to your question is, "I'm a sucker for punishment!"  I also know it is possible to do this and am a bit of a geek so would like to see it up and running!

Voip.ms is on SP1.  Been with them for years, and love their service.  Their calls to the UK are lower than Google Voice on a premium routing which is of excellent quality.  Their IVR stuff is great, and I can have multiple sub accounts and extensions which I use.  I can send any Caller ID I like - which enables my family in 3 different Countries to see my local DID to them.  Their infrastructure is amazing - offering geographic POP in several areas of Canada.  The lowest latency (22ms) to me is Vancouver which allows me to make use of 311 and 310-xxxx services in my area.

Anveo is on SP2.  I've just signed up to evaluate their service and quality compared to Voip.ms.  Some of their services are more competitively priced.  Specifically incoming DIDs here in Canada.  Through the ObiTalk deal I've been able to move E911 to them, and so am paying less for my DID than with Voip.ms. I'll probably port over my main mumber from Voip.ms if I find the service good. International calls are a little more expensive than Voip.ms but Canadian calls are bundled in the price.  That is why I want the Obi to be able to select the correct provider on outbound calls.  I can also present the correct Caller ID with Anveo after verification.  I set that up yesterday and it is working well.

Sipgate is on SP3.  They provide an incoming DID from the UK.  This is a backup DID to safeguard against failure of the other 3 DIDs that route to my IVR at Voip.ms.  The provider of the UK DIDs experienced an outage last week which was most inconvenient when my Mum tried to let me know my father had gone into hospital.  I won't use SP3 for outbound calls except for freephone UK numbers very occasionally.

Google Voice on SP4.  US calls only.  Why?  Because they are free.  Why not use them for Canadian calls?  Because I am unable to manipulate the Caller ID.  That's the biggest drawback.  I also can't point my UK DIDs to a GV account because they are not SIP based.  My brother in the US calls my GV number which is local to him.

Once my complex maps are set up, the user at home can dial any UK number without needing international codes.  They can also dial US / Canadian numbers which will route at the least cost, presenting the correct caller ID for which ever Country the call is arriving in.  That will be a pretty slick system.  Since the Obi202 supports 4 Service Providers, I thought I would give it a go!  Previously I have been unable to use GV reliably (they stopped validating Canadian numbers, so I more or less stopped using them for the last several years).

The digit map side of things is running well now.  If I was only using line 1, it would be fine.  It handles the number transformation nicely allowing me to dial UK 01, 02 & 07 numbers, as well as 10 & 11 digit North American numbers.

Now comes the task of splitting those calls to the different providers.  I've started another thread abut that part of the operation because I'm really not clear on the Outbound Call Routing at all.

Taoman

Quote from: xpr722946ghd on May 07, 2017, 01:35:28 PM

Voip.ms is on SP1.  Been with them for years, and love their service.  Their calls to the UK are lower than Google Voice on a premium routing which is of excellent quality.  Their IVR stuff is great, and I can have multiple sub accounts and extensions which I use.  I can send any Caller ID I like - which enables my family in 3 different Countries to see my local DID to them.  Their infrastructure is amazing - offering geographic POP in several areas of Canada.  The lowest latency (22ms) to me is Vancouver which allows me to make use of 311 and 310-xxxx services in my area.

Anveo is on SP2.  I've just signed up to evaluate their service and quality compared to Voip.ms.  Some of their services are more competitively priced.  Specifically incoming DIDs here in Canada.  Through the ObiTalk deal I've been able to move E911 to them, and so am paying less for my DID than with Voip.ms. I'll probably port over my main mumber from Voip.ms if I find the service good. International calls are a little more expensive than Voip.ms but Canadian calls are bundled in the price.  That is why I want the Obi to be able to select the correct provider on outbound calls.  I can also present the correct Caller ID with Anveo after verification.  I set that up yesterday and it is working well.

Interesting post. I also use VoIP.ms and love their services. But I also have had a free Anveo account for years that I use strictly as a backup route via SIR URI. Anveo has been very reliable as has VoIP.ms.

I'd be interested in your comparison of the two providers after your evaluation of Anveo. I'd be real interested in your opinion of the visual call flow tool.

Since you signed up for Anveo thru Obitalk do you even have access to your Anveo SIP credentials?


xpr722946ghd

Quote from: Taoman on May 07, 2017, 01:57:44 PM

Interesting post. I also use VoIP.ms and love their services. But I also have had a free Anveo account for years that I use strictly as a backup route via SIR URI. Anveo has been very reliable as has VoIP.ms.

I'd be interested in your comparison of the two providers after your evaluation of Anveo. I'd be real interested in your opinion of the visual call flow tool.

Since you signed up for Anveo thru Obitalk do you even have access to your Anveo SIP credentials?


The SIP credentials are unavailable.  Kind of.  If you log into the Obi device directly (not via the website), you can view most of them.  The only one that is obscured is the password.  I'm sure there is some way that can be read / unmasked. That said, for Anveo running on the Obi this isn't an issue.  However the Anveo ObiTalk account has other limitations.  An example being the inability to create other inbound SIP trunks  :'(  I had not realized this would be unavailable, and that means it won't be possible for me to move fully away from Voip.ms as I would like to be able to route incoming DIDs in multiple ways.

In fact I can't seem to find the SIP URI for the my call flow.  1555 + account number simply rings through to the Obi, completely bypassing the call flow.  I need to be able to send incoming calls to the Call Flow, not direct to an extension.

Of course if I upgraded to one of their more expensive packages, I could probably do this by adding additional SIP trunks.

I have only created one experimental Call Flow so far. It was simple enough to create a recorded message (I used the robotalk feature) and then hang up.  Haven't tried an interactive thing yet, as I have with Voip.ms.

I haven't made any calls yet to assess the quality.  The biggest hindrance for me will likely be the latency.  However 91ms to sip.ca.anveo.com isn't terrible.  It may not even be an issue.