News:

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

Main Menu

Incorrect Speed Dial Behavior

Started by RonR, February 23, 2011, 12:49:55 PM

Previous topic - Next topic

RonR

Using:


Phone Port Primary Line : SP1 Service

Phone Port DigitMap : ([1-9]|[1-9][0-9]|911|**0|***|(Mpli)|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp))

Phone Port OutboundCallRoute : {911:li},{**0:aa},{***:aa2},{(<**1:>[x*].):sp1},{(<**2:>[x*].):sp2},{(<**8:>[x*].):li},{(<**9:>[obx*].):pp},{([x*].):pli}

SIP1/ITSPA DigitMap : (*xxx[x*].|<#:>xx[x*].|<:0>x[x*].)


Dialing 1 - 99 followed by a # should be interpreted as a Speed Dial, but is instead being sent to the SP1/ITSPA provider (with a leading 0 added as would be proper if it was intended to go to this provider).  If no terminating # is entered, it is properly treated as a Speed Dial.

(This prolem also occurs using the original/default Phone Port OutboundCallRoute.)


From page 115 of the OBi Device Administration Guide:

The best matched rule is the one that has the most specific literals matching the input digit sequence. For example, the input sequence 1234 matches the rule 123x better than 1xxx. On the other hand, an EM rule is always selected over an IM rule.


The [1-9]|[1-9][0-9] rule should be in an EM state whereas the <:0>x[x*]. rule should be in an IM state, regarless of whether the interdigit timer expired naturally or was forced to expire with a terminating # key.

There appears to be a bug in the OBi110 Digit Map Processor and/or internal Speed Dial recognition logic.

obi-support2

Thank you for verifying the [x*]. syntax with the test load.

I can reproduce the problem you reported, and have alerted the engineering team
to look into that.

Meanwhile, a work around would be:
- modify the last rule in the digit map to ...|<:0>x[x*][x*][x*].) OR
- remove (Mpli) from PHONE DigitMap (hence you must dial **1)
to avoid the ambiguity.

Thanks,
- Obihai Support Team

OBIHAI Support Staff

RonR

A much easier workaround (for me at least) until you get the problem fixed is too simply not terminate Speed Dials with a # key.  That doesn't require any changes to my OBi configuration.   :)

I now have my OBi enabled for Automatic Firmware Updates (only), so please feel free to push a test version if you'd like me to verify that it's fixed.

In a few minutes, I will be posting another, possibly related scenario, in this thread of another Digit Map Processor problem related to using a terminating # key.

Thank you very much for your attention to these problems.  The OBi is a fantastic product.

RonR

Using:


Phone Port Primary Line : SP2 Service

Phone Port DigitMap : ([1-9]|[1-9][0-9]|911|**0|***|(Mpli)|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp))

Phone Port OutboundCallRoute : {911:li},{**0:aa},{***:aa2},{(<**1:>[x*].):sp1},{(<**2:>[x*].):sp2},{(<**8:>[x*].):li},{(<**9:>[obx*].):pp},{([x*].):pli}

SIP2/ITSPB DigitMap : (1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1870>xxxxxxx|011xx.|xx.)


Dialing 1234567 with or without a terminating # key works properly and sends 18701234567 to the SIP2/ITSPB provider (Google Voice).

If S4 is added to the third term of the SIP2/ITSPB DigitMap (<1870>xxxxxxxS4), using a terminating # key causes the Digit Map Processor to return only 1234567 which is sent to the SIP2/ITSPB provider (Google Voice).


From page 116 of the OBi Device Administration Guide:

(xx.|<1408>xxxxxxxS4)

In this case the DMP behaves exactly the same as the last, except that the short interdigit timer the DMP uses upon receiving the 7th digit is overridden by a 4s timer; hence the user will have up to 4s instead of 2 to dial the 8th digit.


Adding an interdigit timer override should not alter the value returned by the rule when a terminating # key is used.

Using the original/default Phone Port OutboundCallRoute, the problem does not appear to occur, but in reality, it does.  It's simply masked by the fact that the SIP2/ITSPB DigitMap is envoked a second time from the Phone Port OutboundCallRoute, this time without the terminating # key, and the desired value is returned and sent to the SIP2/ITSPB provider (Google Voice).

You can observe all of the behavior described above in the Phone Port LastDialedNumber field.

There appears to be a bug in the OBi110 Digit Map Processor.

RonR

Obihai Support Team,

Were you also able to reproduce the second DMP problem (Sn plus terminating # key, reported in the posting immediately preceding this one)?

Thanks,

Ron

OBi-Guru

Support team is still verifying this ... and all other digit issues you are reporting.

RonR