Voicemail to SP4

[threehappypenguins]

Okay, I give up. I tried search and trying different things and I still can't get this to work.

I am using Obi Expert config and I can't figure out how to make *98 to go to SP4 to access that SP's voicemail services. It is definitely *98 that I need to use.

I have FPL set up as my Primary Line on SP1 (free, unlimited phone calls), and AcroVoice set up on SP4 (it is my local number, but limited in minutes because that's cheaper). FPL I'm not worried about accessing voicemail because I set it up so that when I get a voicemail it sends it via email and deletes it off the system. But AcroVoice keeps it off the system and I really need to clear the voicemails out of there before I run out of room!

I have tried changing various digit maps to "route" *98 to SP4. It never works. And I check the history and it won't even show a call attempt or anything in the history.

The latest thing I tried was putting *98, Voice Mail, call($spd[21]) into code28 of Speed Dial Profile A (I need to use profile A, I checked), and then sp4(*98) into the 3rd line for the speed dial list.

Then I get this message when I try:

"There is no call route available to complete your call."

Someone please help!

[ianobi]

At default settings your OBi swallows *98 because *98 is a "Star Code" used by your OBi for the Blind Transfer function. To forward *98 to your sp4 provider you need to do several things:

1. Delete *98 from the OBi:
Star Codes > Star Code Profile A > Code28 – delete and leave blank.
If you want to keep the Blind Transfer function, then you could change it to *99.

2. Add *98 as follows (I'm using the default DigitMap, yours may differ):
Service Providers > ITSP Profile D > General > DigitMap:
(*98|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

At this stage to send *98 out of sp4 you need to dial **4*98.

3. To automatically route without dialling the **4 then add a rule to the front of your Primary Line digit map as follows:
Service Providers > ITSP Profile A > General > DigitMap:
(<**4>*98|1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)


The above are just example digit maps. If the above does not work, then post your actual ITSP A and B digit maps and I'll have a look for possible conflicts.

Good luck!

[azrobert]

I got your method to work by changing Star code 28 to:
*98, Voice Mail, call($spd[60])

and

Speed dial 60 to:
sp2(*98)

I have an OBi110.

You said:
sp4(*98) into the 3rd line for the speed dial list

Does this mean you're using speed dial #3?
if yes, then why are you using '21' in your star code 28?

You can also just dial the speed dial number without any star code changes.

[ianobi]

Both methods work, but I have to admit the threehappypenguins / azrobert solution looks like a better answer.

I think we should be more creative with our use of Star Codes. They don't even have to start with a "*". Another set of ideas to think about - but maybe not today   

[azrobert]

After getting threehappypenguins' method working I was determined to improve it by eliminating the speed dial.

Here is my solution:
*98(<sp1(*98)>), Voice Mail, call($Code)

It took me a few tries before my success.

The following is my 1st test, but it failed:
*98, Voice Mail, call(sp1(*98))

I then thought to automatically set a speed dial and then call out using this speed dial. There are some star codes that execute two commands. If this worked I was going to use a different viable to replace the speed dial. My 1st step was to test setting a speed dial with following:
*98, Voice Mail, set($Spd[99],sp1(*98))

This set speed dial99 to sp1(*98
This looks like a bug. It seem the OBi stops scanning when it detects the 1st ).
I wonder if my 1st test failed because of the same bug.

To test if my concept would work if the bug was fixed, I set speed dial60 to sp1(*98). I then tried:
*98, Voice Mail, set($Spd[99],sp1(*98), call($Spd[60])

This also failed and I almost gave up, but then the light bulb came on with the above solution.

[ianobi]

azrobert,

That's clever thinking! I really must look deeper into Star Codes - seems they are a digit map with actions before digits are passed to the Phone Port DigitMap.

I don't quite understand the function of "< >" would this not work:

*98(sp1(*98)), Voice Mail, call($Code)

[azrobert]

azrobert,

That's clever thinking! I really must look deeper into Star Codes - seems they are a digit map with actions before digits are passed to the Phone Port DigitMap.

I don't quite understand the function of "< >" would this not work:

*98(sp1(*98)), Voice Mail, call($Code)

ianobi,

Like I said in my previous post, I think there is a bug where the OBi ignores the 2nd right paren. Therefore, I wanted a solution without two adjacent right parens.

Since there is zero documentation on star code, the following is my guess based on the default Star Codes and my testing.

You can dial extra digits after the star code, but it must pass the Star Code DigitMap.
If the extra digits pass the DigitMap, they are placed in variable $Code.
The Star Code DigitMap is immediately after the star code between parentheses.

You can test with this:
*98(xxxxxxx), Set Speed Dial, set($Spd[99],$Code)

Dial *981234567
Then look at speed dial#99.

I'm not dialing any extra digits with my solution. Anything between the < > will be added to the variable $Code, the same concept as a Phone Port DigitMap. My solution dials out immediately and never gets to the Phone Port DigitMap.

If you dial more digits than the Star Code DigitMap allows, the extra digits will be sent to the Phone Port DigitMap.

In my example test above:
Dial *9812345678
Speed Dial#99 will be set to 1234567 and
8 will be sent to the Phone Port DigitMap
Speed Dial#8 will be executed.

I hope the above is correct.

Bob

[ianobi]

Bob,

I have been doing some of what RonR called "empirical testing". When I do it, it's "trial and error" with lots of error   

Case 1 - *98(<sp1(*98)>), Voice Mail, call($Code)
Your method achieves genuine "Trunk Dialling".  *98 is sent out of sp1 with no reference to any digit map or OutboundCallRoute. I'm sure that this is not what Obihai intended, but seems to me to be extremely useful.

With Star Codes I believe that Obihai intended that the Phone Port DigitMap should not be used, but any resulting "calls" should be processed throught the Phone Port OutboundCallRoute. If *98 is a rule in the ITSP Profile A DigitMap (Msp1), then the following work:

Case 2 - *98, Voice Mail, call(**1*98)
**1*98 can be seen leaving the Phone Port and is processed through the Phone Port OutboundCallRoute in the normal way and *98 goes out on sp1.

Case 3 - *98(*98), Voice Mail, call(sp1($Code))
Exactly the same as Case 2. call(sp1($Code)) is transformed into call(**1*98) and **1*98 can be seen leaving the Phone Port.


Case 3 is where I was confused. I thought that call(sp1($Code)) is intended to use genuine "Trunk Dialling", but this is not the case. sp1 is transformed into **1 and used to route through the Phone Port OutboundCallRoute.

This thread has certainly added to my "OBi Knowledge Base". Thanks for pointing me towards Star Codes!

Ian

[azrobert]

Ian,

I'm not getting the results as you describe.

When I added *98 to the Phone Port DigitMap the *98 Star Code stopped working.

It appears the sequence of events after dialing a star code is:
Phone Port DigitMap, if this fails then Star Code DigitMap.

I setup the following test without *98 in the Phone Port DigitMap:
*98(*98), Set Speed Dial, set($Spd[99],$Code)

After dialing *98 I got a busy signal
After dialing *98*98 Speed Dial#99 was set to *98

It appears the 1st *98 is not sent to the Star Code DigitMap.

Bob

[ianobi]

Bob,

I believe that the Phone Port DigitMap is ignored by Star Codes, assuming that a Star Code exists for that number. My tests indicated that *98 needs to be in the Phone Port OutboundCallRoute for Cases 2 & 3 to work. It does not need to be in the Phone Port DigitMap.

I believe that Star Codes are processed first and if a match is found, then it is acted upon and if "call" is the action, then the number is passed to the Phone Port OutboundCallRoute for transforming and routing.

Your format *98(<sp1(*98)>), Voice Mail, call($Code) ignores the standard rules and sends the call out directly, to sp1 in this case. This is very useful as it does not matter what is in the Phone Port DigitMap or OutboundCallRoute.

This may be a case of the two of us heading towards the same answer by different routes  

Ian

[azrobert]

I had a test with the following speed dial and *98 in my Phone Port DigitMap:
*98, Set Speed Dial, set($Spd[99],99)

When I dialed *98, it was sent out SP2 and Speed Dial#99 was unchanged.

I removed *98 from the Phone Port DigitMap and reran the test.

Nothing went out SP2 and Speed Dial#99 was set to 99.
I verified this by just looking at Speed Dial#99.

The only explanation for the above behavior is that Phone Port DigitMap gets control FIRST and then the Star Code DigitMap.

Retry your Case 2 with the following mod:

Case 2 - *98, Voice Mail, call(**1*44)

I bet *98 will be sent out SP1 and not *44

[azrobert]

Retry your Case 2 with the following mod:

Case 2 - *98, Voice Mail, call(**1*44)

I bet *98 will be sent out SP1 and not *44

Just want to clarify what I think will happen with above suggestion.

If *98 is NOT in your PP DigitMap **1*44 will be sent to the PP outbound route.
If *98 is in your PP DigitMap *98 will be sent to the PP outbound route.

I don't think your Case3 will get a match after dialing *98.
The Star Code DigitMap checks for extra digits dialed after *98.
You would have to dial *98*98 to get a match.

[ianobi]

Retry your Case 2 with the following mod:

Case 2 - *98, Voice Mail, call(**1*44)

I bet *98 will be sent out SP1 and not *44

I was all ready to collect the $1000 bet money     then things got confusing   

Case 2 - *98, Voice Mail, call(**1*44)
In my case *44 is sent out of sp1 as I would expect. This works every time so long as token in call(token) can be matched in my Phone Port OutboundCallRoute.

My problem now is that I cannot make Case 3 work at all even the way I had it yesterday!


I still believe that Star Codes are processed before digits get to the Phone Port DigitMap. However, there may be some subtle differences in the way OBi deals with different Star Codes. Here's a quote from the AdminGuide:

Star Code Script Actions (ACT)
The general format of an action: ACT(par, par, ....)
The following actions are supported:
 set(VAR,token) = Set the given VAR to the value represented by token.
 call(token) = Call the number represented by token.
o PHONE Port::OutboundCallRoute will be applied when making the call (but not the DigitMap)
 rpdi(token) = repeat dial the number represented by token
 coll(VAR) = collect a number from the user and store it as the value of the parameter(s) represented by VAR.
o The number is collected with PHONE Port::DigitMap applied
 say(token) = announce the value represented by token
o Values are announced as a list of alphabets or numbers
where token can be a literal (such as 1234) or another variable (such as $CFAN or SP1($CFBN))

It seems that "call" is dealt with in one way and "coll" the number is dealt with differently. There's a lot more here to think about!

I will come back to the whole subject of precedence - phone port / star codes / speed dials / trunk dialling - what digits get processed first etc? I'm busy with non-OBi stuff for a few days, so that will have to wait.

One of us should start a new thread "Star Codes - Some Observations". We seem to have hijacked this one for our own purposes! I wonder if threehappypenguins found the answer she was looking for!