Synchronization of device configuration with OBiTalk and OBiExpert Configuration
restamp:
Quote from: azrobert on March 08, 2016, 12:55:20 pm
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)".
Quote
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:
(*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:
(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:
Quote
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.".
Quote
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:
Quote
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.
Navigation
[0] Message Index
[*] Previous page