Technical : DigitMaps and the OutboundCallRoute
RonR:
Quote from: plugger2 on March 28, 2011, 12:47:13 am
So we agree on something! ;-)
I think we're going to agree on more, but I'm not sure if it's going to be everything. :)
There are a number of omissions in the OBi documentation regarding not only syntax but also operation of the OutboundCallRoute:
1. Terminal can be VGx. This is non-controversial and appears to work as expected.
2. It appears that terminal can be a comma separated list of trunks or endpoints. For example:
{(xxxxxxxS4|1xxxxxxxxxx|xx.):sp1,sp2}
3. Terminal can be TGx. But here's where the water gets a little murky. I would think that
{(...):tg1} would simply be replaced by {(...):sp1,sp2}. If it is, this actually works due to item 2 above and no special TGx handler is needed. The only problem is the order isn't preserved. SP2 is always tried first, followed by SP1 if SP2 is unavailable. Since the order is preserved when using a real TGx but not when a simulated TGx is tested, there's still a missing link somewhere. It's possible there's a special TGx handler that's used to avoid this problem.
Here's where we'll probably part company. None of this discussion about trunk groups causes me to want to change a single word in my original post. I'm still convinced it holds true, whether trunk groups are implemented via a simple substitution or a more sophisticated 'trunk/endpoint emulator' routine.
What does need to be corrected (and I will add the necessary strike-outs shortly) is my speculation in the third post of this thread that OutboundCallRoute processing doesn't stop when a port with a matching rule is found but the port is not available. Processing stops when a matching rule is found, period. If that port is not available, you get an error message.
While it's a little unclear exactly how trunk group processing is implemented at the lowest level, I don't believe the details are germane to the overall discussion of how DigitMaps and the OutboundCallRoute play together in the OBi.
It would be nice, however, if obi-support2 chimed in with a detailed description of exactly how trunk group processing is, in fact, implemented.
obi-support2:
Just to confirm your observation/interpretation...
1. PHONE Port - DigitMap is the first gate that processes the digits dialed from the PHONE Port. Once the digits are accepted (and properly transformed by the digitmap, if applicable), the resulting number is used to determine the route to place the call, using the OutboundCallRoute.
The Digitmap on each trunk does not come into play, unless they are explicitly referenced in
PhonePort's digitmap
2. OutboundCallRoute may transform the number again based on the digit-map used in the matching routing rule. Note that OutboundCallRoute does not allow forking at present; so only 1 trunk can be selected to place the call. Again the digitmap on each trunk does not play a role here, unless they are explicitly referenced in the PhonePort's OutboundCallRoute.
(Only inboundCallRoute allows forking to up to 4 destinations)
3. If the resulting trunk from #2 is NOT a trunk group, then the number from #2 will be used to call out on that trunk. That would be the end of it.
4. If the resulting trunk from #2 is a trunk group, OBi indeed will apply each member trunk's digit map to select a usable trunk member to place the call. It's a valid point that this may not be quite consistent with the non-trunk-group case, in the sense that the digitmap on each trunk now plays a role in the trunk-selection; but it makes trunk group more useful w/o introducing new syntax.
RonR:
Quote from: obi-support2 on March 28, 2011, 04:41:11 pm
Note that OutboundCallRoute does not allow forking at present; so only 1 trunk can be selected to place the call.
Multiple terminal specifiers in an OutboundCallRoute rule currently behave more like a single target 'hunt' than a multiple target 'fork'.
Whether intended or not, with (xx.) as the only PHONE Port DigitMap rule and {(xx.):sp1,sp2} as the only OutboundCallRoute rule, the call goes out SP2 if SP2 is available or SP1 if it's not.
I state this only as an observation, not to make any particular point.
Navigation
[0] Message Index
[*] Previous page