Voicemail and Star Codes

[dbdoshi]

Hi there, I have OBI 202 at firmware 3.2.2 (Build: 5921EX). I have Callcentric on SP2 (GV on SP1 and is the PL) and I can check my voicemails on it by dialing "*86" via SP2. I went through some old threads and I understand that I can simply re-code the definition (or action) of "*86" in Star Code Profile A (My only Ph uses profile A) without changing any DMs or OCR. I got that working by changing the action of "*86" line to:

"*86(<sp2(*86)>), Callcentric VM, call($Code)". Thanks, @azrobert.

I also got it working by changing the DMs and OCR (I re-coded "*86" in the Star Code Profile A to call my cell phone for testing). I added these:

ITSB Profile A DM: |<**2>*86|
ITSB Profile B DM: |*86|
PH OCR:               {*86:sp2}

The above rules work and the "*86" star code action (to call my cell) is never invoked and I can connect to my CC VM.

I wanted to take it further by NOT re-purposing "*86", but using my custom sequence to get to the CC's VM. I picked "#22". I had a choice of 2 options.

OPTION 1: Validate & Replace "#22" in ITSB DMs and pass the correct dialing number to PH OCR. I added these:

ITSB Profile A DM: |<#22:**2*86>|
ITSB Profile B DM: |<#22:*86>|
PH OCR:               {*86:sp2}

OPTION 2: Just validate "#22" in ITSB DMs and change it to the correct dialing number to PH OCR. I added these:

ITSB Profile A DM: |<**2>#22>|
ITSB Profile B DM: |<#22>|
PH OCR:               {(<#22:*86>):sp2} and  {(<**2#22:*86>):sp2}

None of options 1 or 2 work. In Option 1, I noticed that it is blowing up while doing DM validation and I don't see any entries in the Call log. When using Option 2, the call is logged, but OBI is sending "#22" to SP2 and not "*86", meaning the PH OCR does not replace the "#22" (or its "**2#22" variant) to "*86" before the handover to SP2. Any ideas? Thanks.

EDIT: I add these rules to the start of the respective DMs and OCR. Also, I have tested with "##22", "###22" and "#86". Same no go. (When using "#86", I simply replace "#" to "*" in both options 1 and 2. Something like "<#:*>86", and not worrying about "22")

[azrobert]

You're making it too complicated.

PH DM:    #22|
PH OCR:   {#22:sp2(*86)},

[azrobert]

The PH DM validates the dialed number
The last rule in the PH DM (Mpli) includes the PL DM

ITSB Profile A DM: |<**2>*86|
ITSB Profile B DM: |*86|
PH OCR:               {*86:sp2}

When PH DM validates *86, it's transformed to **2*86
{*86:sp2} doesn't match the transformed number and does nothing
(Msp2) contains *86
{(<**2:>(Msp2)) matches **2*86 and routes the call to SP2

ITSB Profile A DM: |<#22:**2*86>|
ITSB Profile B DM: |<#22:*86>|
PH OCR:               {*86:sp2}

A DM transforms the number to **2*86
(Msp2) Doesn't contains *86, so {(<**2:>(Msp2)) doesn't match **2*86 and fails

[dbdoshi]

You're making it too complicated.

PH DM:    #22|
PH OCR:   {#22:sp2(*86)},

Unfortunately, that does not work. Get a fast busy as soon as I am done dialing #22

[dbdoshi]

The PH DM validates the dialed number
The last rule in the PH DM (Mpli) includes the PL DM

ITSB Profile A DM: |<**2>*86|
ITSB Profile B DM: |*86|
PH OCR:               {*86:sp2}

When PH DM validates *86, it's transformed to **2*86
{*86:sp2} doesn't match the transformed number and does nothing
(Msp2) contains *86
{(<**2:>(Msp2)) matches **2*86 and routes the call to SP2

ITSB Profile A DM: |<#22:**2*86>|
ITSB Profile B DM: |<#22:*86>|
PH OCR:               {*86:sp2}

A DM transforms the number to **2*86
(Msp2) Doesn't contains *86, so {(<**2:>(Msp2)) doesn't match **2*86 and fails

Got the 2nd part. It is the SECOND pass over ITSB B's DM (invoked by PH's OCR) that was the problem, correct? The FIRST pass invoked by PH's DM was good.

So adding "*86|" to ITSB B's DM took care of the problem, though your solution of modifying PH DM and OCR seems more cleaner (not sure what is going wrong). The modification of *86's star code action is very clean as well.

[azrobert]

I just tried my suggested changes and it worked for me. An immediate busy indicates a problem with the PH DM. Are you sure you placed it correctly? Maybe you put it before the beginning parenthesis?

This is what you need for the other method:
ITSP Profile A DM: |<#22:**2*86>|
ITSP Profile B DM: |*86|

There is no wrong method as long as it works, but I don't like placing code in the A DM to route calls to SP2.  You could move the code to the PH DM.

[dbdoshi]

I just tried my suggested changes and it worked for me. An immediate busy indicates a problem with the PH DM. Are you sure you placed it correctly? Maybe you put it before the beginning parenthesis?

This is what you need for the other method:
ITSP Profile A DM: |<#22:**2*86>|
ITSP Profile B DM: |*86|

There is no wrong method as long as it works, but I don't like placing code in the A DM to route calls to SP2.  You could move the code to the PH DM.

Yep, the two ITSP DMs you listed works if you dial "#22". If you ALSO want to handle "**2#22", I think it needs an extra rule in the ITSB B's DM: |<#22:*86>|

[ProfTech]

You can make it even simpler. Just remove *86 from the star code section and add *86 to the phone port map and outbound call route. You can also change the *86 code [if it exists] to *86, Voice Mail, call(17771234567). Just make sure it points to the correct sp. Use your own CC number.

[azrobert]

You can make it even simpler. Just remove *86 from the star code section and add *86 to the phone port map and outbound call route. You can also change the *86 code [if it exists] to *86, Voice Mail, call(17771234567). Just make sure it points to the correct sp. Use your own CC number.

There are 2 problems with your solution. The OP's Primary Line is SP1, so "call(17771234567)" will send the call to SP1 and not SP2.

I have Callcentric on SP2 (GV on SP1 and is the PL)

"call(**217771234567)" would work.

I just tried calling my Callcentric number and the call failed with "Busy Here".

The OP could define a Star Code like this:
#22(<sp2(*86)>), Voicemail, call($Code)

Star Codes don't have to begin with a Star.
Just dial #22 and *86 will be sent to SP2

[ProfTech]

  I have no idea what the OP primary line is. That was why I said to make sure it goes to the correct sp. I haven't tested recently but I'm pretty sure you can specify sp2 by using *86, Voice Mail, call(sp2(17771234567)). I've accessed CC voice mail by dialing my own number for years. That is a standard feature of most voice mail systems. May depend on your configuration at CC. I found it easier to simply put it in the phone digit map and Outbound call route and skip the whole speed dial thing. dialing *123 is also valid for CC, if you put it in your call flow.

*edited* I took a look at my 110 and I was thinking about the speed dial pages. You can specify a sp there but maybe not in the star code page. I would have to experiment. My bad.

[SteveInWA]

How hard could it possibly be to simply pick up the phone and key in **2*123 or **2*86 to access Callcentric voicemail?  No digit map manipulation required.

[zapattack]

Wouldn't 2 Speed Dial numbers be simpler?

[azrobert]

How hard could it possibly be to simply pick up the phone and key in **2*123 or **2*86 to access Callcentric voicemail?  No digit map manipulation required.

It would be very easy to dial "**2*86", but it won't work. You must manipulate the ITSP B DigitMap, adding "*86" to get it to work.

"**2(Msp2)" is the Phone DigitMap that would validate an "**2" prefixed number.
(Msp2) points to the ITSP B DigitMap and must contain a rule that matches "*86".
This is the default ITSP DigitMap:
(1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)
"xx." only matches digits
"[^*#]@@." won't match a string beginning with an *
Nothing else comes close to matching *86

The same problem occurs in the OutboundCallRoute

Even if it did work, why not make a simple 1 or 2 line change to eliminate dialing **2 for the rest of your life?

[ProfTech]

My apologies to AZRobert. After re-reading the original post I can see the OP has a good grasp of the syntax and usage of the OCR. Like Robert, I don't like to put code in the OCR but did make a simple exception recently in conjunction with usage of the Obi with Asterisk. The default call routing capabilities of the Obi are fairly simple but are too clunky to meet the WAF so I discarded them immediately in order to make dialing as much the same as we were dialing before as possible. The Obi is extremely flexible and for a small price can be made to play the part as a mini PBX easily.

[SteveInWA]

It would be very easy to dial "**2*86", but it won't work

Yes, it works.  I tried it immediately before I posted.

[dbdoshi]

You're making it too complicated.

PH DM:    #22|
PH OCR:   {#22:sp2(*86)},

Unfortunately, that does not work. Get a fast busy as soon as I am done dialing #22

I wanted to close the loop on this. @Azrobert, it does work. My DM syntax was wrong

SP1 is GV (For US Calls), SP2 is CC (For emergency calls & US Calls), SP3 is GV (For International calls).

Anyways, my final strings are as follows:

ITSB A: (1[2-9]xxxxxxxxxS0|<1>[2-9]xxxxxxxxxS0)
ITSB B: (911S2|933S2|<#22:*86>|*86|1[2-9]xxxxxxxxxS0|<1>[2-9]xxxxxxxxxS0)
ITSB C: (01191[2-9]xxxxxxxxxS2|011xx.S4)

For PH DM, I add this at the start (Msp1)|(Msp2)|(Msp3)|(Msp4) to the default.
For PH OCR, I add this at the start {(Msp1):sp1},{(Msp2):sp2},{(Msp3):sp3},{(Msp4):sp4} to the default.

I wonder why OBI does not have the above extra strings (rules) I listed above for PH DM and PH OCR as default? I think they are intuitive and they follow the same logic that OBI has for numbers dialed with explicit trunks.

Example rule in default PH DM:   **1(Msp1)
Example rule in default PH OCR: {(<**1:>(Msp1)):sp1}

I see its advantage as any new "type of call" handling needs to be coded in the particular ITSB only, and not touch the PH DM or PH OCR. So no duplication of rules among ITSBs and PH DM. Another advantage I see is that one don't even have to think about "Primary Line" concept if they are new to DMs and OCR...

Is there a "gotcha problem" to this that I am not seeing with my strings for PH DM and PH OCR?

[azrobert]

The OCR is processed left to right, so your config will always route 10 and 11 digits to SP1 and never to SP2.

The default config allows routing the same numbers to any SP by using an **n prefix.

[dbdoshi]

The OCR is processed left to right, so your config will always route 10 and 11 digits to SP1 and never to SP2.

The default config allows routing the same numbers to any SP by using an **n prefix.

Yep, I understand that I need to dial the trunk ID if I want to route US calls via SP2. I did learn the hard way to remove the "xx." rule from all ITSBs and only explicitly put rules in ITSB DMs to the type of calls I want via each ITSB