Star Code Wars

[restamp]

I have a niggling little problem that I have been unsuccessful at devising a good answer to, yet I suspect it is something that must have come up before:  Recently, I've been playing around with an Asterisk server and one of the SPx routes on my OBi is currently a SIP connection to the server, configured as an Asterisk extension.  Works fine, except that many of the Star Codes on the OBi conflict with the Star Codes on the server.  What I'd like to do is essentially turn off the OBi's Star Codes for that route so I have free access to the underlying Asterisk codes, but I don't want to deactivate them completely as I use them in other contexts (i.e., in the other routes).  And, I *really* don't want to attempt a complete remap in an effort to resolve all the conflicts.  (Besides, many of these Star Codes are pretty standard and I'd hate to change them on this one box.)

Does anyone have a slick solution or work-around to this problem?  I suppose with an OBi202, you could dedicate the 2nd phone port as a Star-Code-Free portal, but that introduces its own problems.  Or is this one of those things that simply has no good solution.

I'm all ears.

[azrobert]

You can use a # prefix then convert it to an * when the call is routed to Asterisk.

[restamp]

Thanks, Robert.  I was actually considering using some prefix that could be stripped at some point in the Dial Plans and used for getting around the OBi codes accessing the underlying Asterisk ones.  I never seriously considered using "#" because it seemed problematic in that it supports other important functionality (including denoting the end of a dialed number to short-circuit the timers -- something I tend employ a lot) and I didn't want to cause problems elsewhere that might potentially go unnoticed for a while.  But, you persuaded me to try it, and it works like a champ.

If you have a second, I'd like to make sure I understand correctly what is happening in the DigitMaps here.  What I did was add the string "*xx.S3|<#:*>xx.S3|" to my ITSP Profile B DigitMap.  This Profile is associated with SP2, which is also the Primary Line.  So...

1. When parsing the Ph1 DigitMap, "(Mpli)" pulls in the above, and I presume the conversion of '#' to '*' takes place at this point.

2. Following this, the original string (as opposed to the converted string) is checked against the Star Codes.  Since there are not Star Codes which begin with a '#', there is no match.

3. Following this, the Speed Dials are checked, using the converted string.  Again, there is no match.

4. Following this, the Ph1 OutboundCallRoute is parsed.  The first (and only) item in this list that matches is the last item: "{(Mpli):pli}", and here it matches against the "*xx.S3" component, since the dialstring has already been converted.  Because of this, the dialed digits get sent to "pli" or SP2.

5. SP2's ITSP Profile B's DigitMap is parsed next, and of course it again matches on "*xx.S3", so the converted string get sent to the Asterisk server.

Is this analysis essentially correct?

(Thanks again!)

[azrobert]

I see 1 error in your logic. Step 5 is not correct and does not apply. After Step 4 the call is routed to Asterisk, end of processing. You can test this by removing the * code from (Msp2) and placing it into the Phone DigitMap. Then add {(*xx):sp2} to the outbound route. (Msp2) will be ignored and the call will go out SP2. Only Trunk Groups automatically check the trunk's DigitMap.

FYI when using *xx in the DigitMap and dialing *82 the Star Code profile has priority and the call won't go to the service provider. I don't understand this logic.

[restamp]

That's interesting:  So, with the exception of Trunk Groups, the Service Provider's DigitMap is only used indirectly for outgoing calls, right?  (i.e., it only comes into play when it is pulled into another DigitMap via an "(M...)" reference.)  I suppose that makes sense to me now that I think about it.

Is the Star Code processing really done after the first DigitMap is parsed?  It almost seems to me as if it is the first thing done, even before the DigitMaps are examined.

Two final questions:  If you have a reference like "**2(Msp2)" in a DigitMap, but the dialstring doesn't start with "**2" so there can never be a match, is the "(Msp2)" expanded (and any conversions in it performed on the dialstring) anyway, or not?

If you specify a conversion like "9<1>" in, say, the "pli" DigitMap.  Would this conversion be performed in both the Phone DigitMap and OutboundCallRoute, or just once?  Would a single digit "9" be converted to "91" or "911"?

Thanks again Robert.  I really appreciate your presence here.

[azrobert]

Is the Star Code processing really done after the first DigitMap is parsed?  It almost seems to me as if it is the first thing done, even before the DigitMaps are examined.

If you define a star code in the DigitMap, the Star Code processing is skipped and it will be sent to the service provider, so I would think the Star Code processing is done after the DigitMap and before the OutboundCallRoute.

Two final questions:  If you have a reference like "**2(Msp2)" in a DigitMap, but the dialstring doesn't start with "**2" so there can never be a match, is the "(Msp2)" expanded (and any conversions in it performed on the dialstring) anyway, or not?

The dialed number must match the **2 prefix plus a rule in (Msp2), so no conversion is done.

If you specify a conversion like "9<1>" in, say, the "pli" DigitMap.  Would this conversion be performed in both the Phone DigitMap and OutboundCallRoute, or just once?  Would a single digit "9" be converted to "91" or "911"?

The DigitMap is processed twice. It is converted to 91 on the first pass. On the second pass 91 doesn't match "9<1>", so no further conversion is done.