Synchronization of device configuration with OBiTalk and OBiExpert Configuration

[azrobert]

said by restamp

I *wish* there was a way of maintaining separate speed dials for each device

I have separate speed dials because I configure my OBi's locally, but this is not a viable option for you.

You could create your own 3 digit speed numbers. Define a User Defined DigitMap ud1 as:
(<100:8005551212>|<101:8005551313>|..........)

Add rule (Mud1)| to the phone digit map.

You can use the same technique to create 1 or 2 digit speed numbers, but the corresponding real Speed Dial number must be blank.

[restamp]

Thanks for the suggestion, Robert.  I basically follow your protocol of keeping ObiTalk.com locked out of my own OBi and administering it via its LAN web interface.  Thus, I maintain my own speed dials that way and the only one in the ObiTalk.com pool that I leave set is #1, which is permanently set to the soft phone number.  In a way, I suppose there's little need for anything more, as the external OBis I maintain belong to people who are not VoIP-literate and don't want to venture into the programming side of things, even for this.  Rather, they generally use the speed-dial facility in their phones and are happy with that approach.

I see you've crossed out your statement in your last comment to the effect that the corresponding Speed Dials must be blank, so can we infer that your User Defined DigitMap takes precedence over the Speed Dials?

[azrobert]

The Speed Dial processing takes place between the DigitMap and the OutboundCallRoute processing. What I suggested actually changes the dialed number to 10 digits in the DigitMap, so the OBi won't recognize it as a speed dial. If you want to send 1 or 2 digits to the service provider then you must blank the corresponding speed dial.

[restamp]

Robert, one final question concerning your earlier code for getting AA2 access:  In the OBi Device Admin Guide, on page 181, they have a section entitled "Using Speed Dial Number as Ad Hoc Gateway".  My reading of this section is that if I have a speed dial (say "8") set to an OBi number, and have that OBi set up to send "0" to AA2, then I can touch tone in "8*0" from my OBi and it should connect me to the AA2 on the remote device.  However, this doesn't work on my OBi; My OBi is sending the entire "8*0" string to my Primary Line.  Should it work?

[azrobert]

I'm not sure what you mean by "if I have a speed dial (say "8") set to an OBi number".
The speed dial should be in the format of pp(OBi_num) or **9OBi_num
I never tried just the OBi number.
In any case I don't think the call should be routed to the primary line.
You need phone digit map rule [1-9]x?*(Mpli)
and phone outbound route rule {([1-9]x?*(Mpli)):pp}

[restamp]

I'm not sure what you mean by "if I have a speed dial (say "8") set to an OBi number".
The speed dial should be in the format of pp(OBi_num) or **9OBi_num
I never tried just the OBi number.

I meant speed dial 8 was programmed with the sequence "pp(OBi_num)".

In any case I don't think the call should be routed to the primary line.
You need phone digit map rule [1-9]x?*(Mpli)
and phone outbound route rule {([1-9]x?*(Mpli)):pp}

I have the above entries in the digit map and outbound route descriptors for the active phone.  Here's what resolved the problem, although I don't understand why:

The original ISTP Profile Digitmap for the Primary Line attached to the phone I was using was:

Code Select Expand

(*xx|1xxxxxxxxxx|<1614>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|<911:NumberElided>S0|xx.|(Mipd)|[^*]@@.)
This entry is for a Google Phone.  When I simplified the Digitmap and replaced it with this:

Code Select Expand

(0|1?[2-9]xx[2-9]xxxxxx|<614>[2-9]xxxxxx|<911:NumberElided>S0)
it works.  I can now touchtone in "8*0" and it connects to the remote system's AAA2.  Before this, it would always send in the entire string I touchtoned in to Google.  One might think that the original Mpli would not accept a '0' as a legitimate number, but it seems to me that the "xx." entry covers it.  Interestingly, if I stored the entire sequence in a speed dial (Speed dial 8 = "pp(OBi_number*0)", it would work correctly even with the original Digitmap, leading me to believe that speed dials bypass some of the checks imposed by the Digitmaps.  If I touchtone in the entire ObiTalk number, even with the revised Digitmap, that still doesn't work.

Any ideas as to why the original, albeit less than optimal, Digitmap doesn't work?

Addendum:  Success!
I modified the Phone Digitmap by adding the additional clause "xxxxxxxxx*(Mpli)|" and the Outbound Route map by similarly adding "{(xxxxxxxxx*(Mpli)):pp}," and now I can touchtone in a 9-digit OBiTalk number, followed by a star zero, and it takes it.  (Well, in retrospect, that makes sense!)  Entering the speed dial number for the remote Obi, followed by star zero, also works (but then it was working after my first change above), as does the speed dial with the star zero contained in it.

I still don't understand why the original ISTP Profile Digitmap didn't work, but I've learned in life that sometimes it is easiest to plow around the stumps.

What am I missing by leaving the "|(Mipd)|[^*#]@@." clauses out of the ISTP Digitmap?

[azrobert]

Any ideas as to why the original, albeit less than optimal, Digitmap doesn't work?

I don't see the problem. As you said, "xx." should match zero and then "{([1-9]x?*(Mpli)):pp}" should route the call to OBiTalk. Since this failed {(Mpli):pli} routed the call to GV because "8*0" matched "[^*#]@@.".  

This is how I do it:
OBiTalk DigitMap
(222222222|(<2:200222222>|<3:610333333>)*xx.)
Phone OutboundCallRoute
{(Mpp):pp}

I dial "2*0" and the digit map changes 2 to the correct OBi number. No speed dials involved. My phone digit map doesn't alter the dialed number and has a better check than "xx.".  

What am I missing by leaving the "|(Mipd)|[^*#]@@." clauses out of the ISTP Digitmap?

(Mipd) will match an IP address 192*168*1*100 and change it to 192.168.1.100
[^*#]@@. is meant to match an SIP URI (anything@company.com), but will match any 2 or more characters not beginning with * or #

Edit:

leading me to believe that speed dials bypass some of the checks imposed by the Digitmaps.

It depends on how the speed dial is coded. If you define the speed dial with a trunk like "pp(510123456)", the number is sent directly to the trunk bypassing both the digit map and the outbound route.  My memory isn't the best and it's been a long time since I tested this stuff, but I think when you don't specify the trunk like "**9510123456" the DigitMap processing is bypassed and the number is only processed by the outbound route.

[restamp]

Again, thanks for your insights, Robert.

One nit that I have with the way the remote gateway checks are implemented by default is that there is a presumption that the TT sequences that are acceptable to the remote trunk are the same as what is defined by the DigitMap of the local PLI.  That's not always the case, although the alternative is to allow just about any sequence to follow the '*', and that may not be wise either.