Limited Length of DigitMap??

[quanttrom]

I have been looking into implementing a DigitMap like so but it seems like the device barfs on the long series of OR'ed 3 digit numbers.
Those are the area codes for Canada. I would like to route some Canada bound calls through one provider and the rest through another. What's the limit?

([69]11 <:#> | 519 [2-9]xx xxxx <:#> | 1 (204|226|236|249|250|289|306|343|365|403|416|418|431|437|438|450|506|514|519|579|581|587|604|613|639|647|672|705|709|778|780|807|819|825|867|873|902|905) [2-9]xx xxxx <:#>)

Thanks

[Stewart]

The manual p.60 specifies a limit of 511 characters for digit maps in ITSP Profiles A and B.  Unfortunately, it does not comment on digits maps in other contexts.  Does your digit map work properly if you make a test case with, say, only four area codes?  Also, I'm curious between which two providers you are choosing, and whether based on cost or on quality.

[quanttrom]

Yeah if you select only a reasonably sized set it will work just fine. Right now I am using it with 10 area codes or so. Works fine.

It doesn't seem to produce any errors(in syslog level 7) when it's processing the string so I didn't expect to see any issues.

I am selecting "line" or sip provider. It makes sense to select line because this is hooked up to my cell which has unlimited canadawide calling.
I managed to get the OBi 110 and the Xlink playing along nicely but had to fiddle with a whole bunch of "advanced' settings in their xwizard app.Trial and error.

[Stewart]

I have no idea what's going on, but:

1. When it fails, if you view the digit map setting in the OBi web interface, is it truncated?  If so, you can determine the maximum length.

2. If the limit is on a particular string, rather than total storage, you could put a section of the map into each of several User Defined Digit Maps, then reference those from the Line Digit Map.

3. If you can't get that to work, including only the area codes you call the most will probably account for >95% of traffic, so it wouldn't cost significantly more.

4. Though cost would be higher, simply using an inexpensive VoIP provider for outbound calls would give you some advantages:  higher quality (you'd eliminate two stages of gratuitous A/D and D/A conversion, eliminate the compression codec if calling other than a cell phone, likely have lower latency), much faster setup time, and the ability to have concurrent calls (assuming that you have another SIP device).  If you are a heavy user, take a look at Voxbeam (premium route), US$0.0025/min. to most Canadian destinations.

[RonR]

Only the first 511 characters of DigitMaps, OutboundCallRoutes, etc. are stored.  Because there is no error checking in the OBi, and depending on what gets lost (leaving mis-matched operators, etc.), the way the OBi reacts is very unpredictable, often resulting in endless reboot loops.

[quanttrom]

The string itself does NOT get truncated. The OBi 110 will save it and display it just fine.

When you try dialing it will just fail to interpret it and won't dial anything for you.

I like your idea of splitting it into multiple user DigitMaps very nice !

You are right about the area codes and the majority of my traffic. I just did it for completeness sake.

[RonR]

The string itself does NOT get truncated. The OBi 110 will save it and display it just fine.

You're right.  Prior to v1.3, they used to get truncated.  Now they don't get trunctated but the OBi obviously gets badly corrupted internally.  In my case, after setting the LINE Port DigitMap to 530 characters, providers on SP1 and SP2 won't even register.

Sloppy programming.

[quanttrom]

The map string was only 151 chars anyways. Maybe it's the large number of OR operators..

[RonR]

([69]11 <:#> | 519 [2-9]xx xxxx <:#> |...)

What's with the '<:#>' additions to your DigitMap?  That will append a '#' to the number sent to the service provider.  I know of no service providers that want that (certainly not Google Voice).

[Stewart]

What's with the '<:#>' additions to your DigitMap?  That will append a '#' to the number sent to the service provider.  I know of no service providers that want that (certainly not Google Voice).

I'm reasonably certain that's correct for the OP's case.  See http://www.myxlink.com/xlink_bttn.aspx .

[RonR]

It appears there's a bug in the Digit Map Processor (DMP).

With the following DigitMap, everything is fine:

(1(204|226|236|249|250|289|306|343|365|403|416|418|431|437|438|450|
506|514|519|579|581|587|604|613|639|647|672|705)[2-9]xxxxxx)

With the following DigitMap, service providers fail to register:

(1(204|226|236|249|250|289|306|343|365|403|416|418|431|437|438|450|
506|514|519|579|581|587|604|613|639|647|672|705|709)[2-9]xxxxxx)

[quanttrom]

What's with the '<:#>' additions to your DigitMap?  That will append a '#' to the number sent to the service provider.  I know of no service providers that want that (certainly not Google Voice).

I'm reasonably certain that's correct for the OP's case.  See http://www.myxlink.com/xlink_bttn.aspx .

yeah it gets rid of a small delay. Works fine. I've tried without it as well.

[OBiSupport]

The last rule is too long. The problem can be solved by breaking it up into multiple rules. Here the last DigitMap rule is broken up into two rules.


([69]11 <:#> | 519 [2-9]xx xxxx <:#> | 1 (204|226|236|249|250|289|306|343|365|403|416|418|431|437|438|450|506|514|519) [2-9]xx xxxx <:#>) | 1 (579|581|587|604|613|639|647|672|705|709|778|780|807|819|825|867|873|902|905) [2-9]xx xxxx <:#>)

[quanttrom]

The last rule is too long. The problem can be solved by breaking it up into multiple rules. Here the last DigitMap rule is broken up into two rules.


([69]11 <:#> | 519 [2-9]xx xxxx <:#> | 1 (204|226|236|249|250|289|306|343|365|403|416|418|431|437|438|450|506|514|519) [2-9]xx xxxx <:#>) | 1 (579|581|587|604|613|639|647|672|705|709|778|780|807|819|825|867|873|902|905) [2-9]xx xxxx <:#>)

What's the limit? How long is too long? Is it based on characters ?

[RonR]

I didn't try to figure out whether it's characters or elements or what.