BUG REPORT: Bug processing Sx directive in digit map

[Ad_Hominem]

I've discovered a bug in the processing of digit maps.  Although I reported the bug to Obi tech support, they ignored the report and instead gave me generic instructions on how to configure an Obi device to work with a VOIP provider.

Here's the issue:  The Obi digit map has a feature that allows you to append S and the a number to the end of a digit map sequence to decrease the interdigit timer when there is a match.  Most of the time it works properly, but when appended to a string that starts with a "x.", it has a strange bug.

Here's an example of how it is suppose to work.  With this digit map:

(911S0|x.)

You can dial any number with a 10 second dialing delay, but if you dial 911, the call will go through immediately.  You can shorten that 10 second delay by making another modification to the digit map:

(911S0|x.S3)

Now, calls to 911 will go out immediately, and all other calls will go out in 3 seconds.

BUT- there's a bug here as well.  If you pick-up the phone and wait more than 3 seconds before dialing, then the "x." portion of the digit map WILL BE IGNORED and the call will fail.

If you change the S3 to an S5, you'll experience the same issue after 5 seconds.

Now, if you use this instead:

(911S0|1x.S3)

Then you can call 911, which will go out immediately, or you can dial 1+any number and it will go out within 3 seconds.  However, unlike the example above, if you pick up the phone and wait more than 3 seconds, the 1x. portion of the digit map WILL BE PROCESSED and the call will go through.

Can anyone tell me how I might bring this to Obi's attention?

[Ad_Hominem]

There is a workaround.  Instead of this:

(x.S2)

You can use this:

(xS2|xxS2|xx.S2)

It has the same result, but without the bug.

[azrobert]

You fixed the problem before I posted.
Here is an explanation.

I don't think this is a bug.
x.S3 will match ZERO or more digits, so dialing nothing after 3 seconds will match the rule and then fail in the outbound call route.
If the call fails in the DigitMap you will get a fast busy.
If my theory is correct, then you are receiving a message something like "no routes available' indicating the call failed in the outbound call route.
Try rule xx. instead of x. which will match 1 or more digits.
Now dialing nothing will not match the rule and will now fail at 10 seconds, not 3.

[Ad_Hominem]

That explanation isn't what is actually happening, however.  Calls do not fail at 2 seconds with the original digit map.  Rather, what happens is that the particular digit map IS IGNORED if you take more than 2 seconds (or whatever Sx is set to in that part of the digit map) to finish dialing.  As long as you complete dialing before the digit map timeout, you can complete your dialing, but that portion of the digit map will be ignored when processing your call.  If you complete dialing before 2 seconds (or Sx), then that part of the digit map will be processed.

And, as noted, if you do xS3, xxS3, and xx.S3 instead of x.S3, then everything works fine.

You fixed the problem before I posted.
Here is an explanation.

I don't think this is a bug.
x.S3 will match ZERO or more digits, so dialing nothing after 3 seconds will match the rule and then fail in the outbound call route.
If the call fails in the DigitMap you will get a fast busy.
If my theory is correct, then you are receiving a message something like "no routes available' indicating the call failed in the outbound call route.
Try rule xx. instead of x. which will match 1 or more digits.
Now dialing nothing will not match the rule and will now fail at 10 seconds, not 3.

[OzarkEdge]

I would not be too quick to declare a bug in digit map processing.  In my experience, this processing is subject to many conditions and is not always absolute by design... the DMP timers can force an undesired result despite the conditions, and some conditions just can't be resolved to satisfaction, either because they are unresolvable or because the DMP algorithms are not capable/able to process the mass of digit map rules/constructs thrown at it.

I suggest you recognize and accept these limitations and try to design your dial plan to respect them.  For instance, the default digit map timers give the DMP the recommended time to resolve its decision making process.  I would only alter these to force a particular outcome where no other adjustment can help.  Loading a dial plan up with S0 or other such timer settings is not necessary nor helpful, imo.  A well-designed dial plan will/should match the digits dialed in 4 seconds.  This is not an eternity and will deliver a consistent dialing experience to the user.  Playing with the timers can give immediate feedback and a sense of control over the dial plan, but I suggest that this is a false sense of control and ultimately counterproductive to building a better dial plan.

If you are shortening a DMP timer to force a wildcard rule to timeout, you should reconsider your dial plan design to match the digits dialed in the default 4 seconds without having to use an open-ended wildcard rule.  A wildcard rule should be the dial plan's last resort for matching the digits dialed, for when no other more determinate/more literal rule can be used.

OE