News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Star Codes

Started by azrobert, October 07, 2013, 04:05:29 PM

Previous topic - Next topic

azrobert

ianobi and I hijacked a thread and were debating how Star Codes work. He suggested one of us start a new thread specifically on Star Codes. Here it is.

The following is how I believe things work.

After dialing a Star Code the following sequence of events happen:

The Phone Port DigitMap gets control first and tries to verify the Star Code dialed.

If the verification succeeds the Star Code is passed to the Phone Port OutboundCallRoute bypassing the Star Code Profile.

If the verification fails (no match) the Star Code Processor gets control and looks for a match in the Star Code Profile.

I will use these examples to explain the Star Code processing:
*81, Block Caller ID, set($Bci,1)
*76([1-9]|[1-9]x), Clear Speed Dial, set($Spd[$Code],)
*98(<sp1(*98)>), Voice Mail, call($Code)

A Star Code entry can have a DigitMap associated with it. It immediately follows the Star Code and is enclosed with parentheses.

If you dial *81 you will get a match with my first example and variable $Bci will be set to 1.

If you dial extra digits, these digits will be passed to the Phone Port DigitMap.
If you dial *818005551212 variable $Bci will be set to 1 and 8005551212 will be sent to the Phone Port Digitmap.

My next example has a DigitMap and is looking for a number between 1 and 99 to get a match. If there is a match the number is stored in variable $Code.
If you dial *7699, "99" is stored in variable $Code and Speed Dial#99 is cleared.
If you dial *7699805551212, Speed Dial#99 is cleared and 8005551212 will be sent to the Phone Port Digitmap.

My next example the DigitMap is not comparing for anything and you will get a match by dialing *98. sp1(*98) will be stored in variable $code and the Call command will send *98 to SP1.


Firmware bug:

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

The above should send *98 to SP1, but it doesn't. The scanning stops when firmware detects the first ) and the Call command sends sp1(*98 to the Phone Port OutboundCallRoute. I determined this by putting {@@.:sp1} in my Phone Port OutboundCallRoute and sp1(*98 was sent to SP1.


azrobert

#1
ianobi said:
QuoteI 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!
If the verification fails (no match) the Star Code Processor gets control and looks for a match in the Star Code Profile.

The above Case 2 is consistent with my understanding if you don't have *98 in your Phone Port DigitMap.

*98 will fail in the Phone Port DigitMap and Case 2 will send *44 out SP1.

Your Case 3 will not get a match by dialing *98. You must dial *98*98 to get a match. The only way it appeared to work is if you had *98 in your PP DigitMap bypassing the Star Code Profile.

If you were going to collect $1000, do I get £'s?    

If anyone is interested with the rest of the debate see:
http://www.obitalk.com/forum/index.php?topic=6727.0

ianobi

azrobert,

Time has been short for setting up tests etc lately, but I have come up with one simple one, which is interesting.

I set up a Star Code as follows:
1234, test, say(1234)

Mpli is in both Phone Port DigitMap and OutboundCallRoute.

Case 1 – Mpli = (xxxx|xxxxxxxx) – dial 1234
Star Code operates and says "1234". 1234 does not get passed to the OutboundCallRoute via the DigitMap. Any other four digit number does go out to Primary Line service.

Case 2 – Mpli = (xxxx|xxxxxxxx) – dial 12345678
If you dial slowly or pause after the "4", then Star Code operates and says "1234". If you dial quickly, or as a string from a dect phone etc, then 12345678 is matched in the DigitMap and OutboundCallRoute and goes out to Primary Line service.

I deduce from the above that the number passes through the Star Code DigitMap first. However, there is something like an "S2" interdigit delay – more like S1 in practice. If you dial 12345678 slowly then 1234 operates the Star Code. If you dial 12345678 quickly, then the number is seen as 12345678 and does not match the Star Code so it gets matched by the Phone Port DigitMap.

So here's another complication – it depends how fast you dial! I think we can both keep our $$$$ and ££££ in our pockets for now   :)

Shale

OBi202.  I decided to create my first star code to cancel echo cancellation on the next call . In slot 36 in start code profile A and B both (just in case), I entered
*91, Disable Echo Canceller For One Call, set($Noec1,1)
and saved it.  This is the same as the *99 example in the Administration Guide, except I decided to use *91.

When I dial *91, I get a fast busy. Not what I expected.

When I dial *4711 (use codec G711 only) I get a fresh dialtone.

Any comments?

Shale

My Digit map and outbound call route settings:

Phone 1 port digit map:
(992xxxxxxxxxx|9921xxxxxxxxxx|[1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))

(the 992 bit was an experimental thing I did a while back and never removed)

phone 1 OutboundCallRoute:
{911:sp3},{933:sp3},{(Mvg1):vg1},{([1-9]x?*(Mpli)):pp},{(<#:>):ph2},{(<**82:>(Mbt2)):bt2},{(<**81:>(Mbt)):bt},{(<**8:>(Mbt)):bt},{**0:aa},{***:aa2},{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Msp3)):sp3},{(<**4:>(Msp4)):sp4},{(<**9:>(Mpp)):pp},{(Mpli):pli}

The Line DigitMap is empty.

azrobert

I copied your Star Code into my OBi200 and it worked.
I get silence for a second then Dial tone.

What is your Phone Port's Primary Line DigitMap?
If it contains a rule that matches *91 remove it.

Did you see my previous post before I removed it?
I tried your Star Code on an OBi110 and got a Busy.
I didn't have time to investigate, so I deleted my post.
Apparently, that is not a valid command for an OBi110.

You said:
QuoteThe Line DigitMap is empty.

Is the Line Port your Primary Line and its DigitMap empty?

Shale

#6
"What is your Phone Port's Primary Line DigitMap?"

Physical Interfaces > Phone 1 =SP1 Service
Voice Service > SP1 Service does not have a DigitMap
ITSP Profile A > DigitMap = (1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|011xx.|xx.|(Mipd)|[^*#]@@.)

So I am suspecting you are saying that I should get rid of the |[^*#]@@. part.

"Did you see my previous post before I removed it?" Yes, but after searching out one of the items, I did not remember accurately what the other one was, I think.

"Is the Line Port your Primary Line and its DigitMap empty? "
I think that is the Physical Interfaces > Phone 1 =SP1 Service thing.  (I was using phone 1)
Physical Interfaces > Phone 2 =SP3 Service, and I guess I would modify the ITSP Profile C > DigitMap to be able to the *91 with phone 2 also.

Am I looking at the right places?


azrobert

I thought about this and what I'm suggesting is not valid.
I'm correct that *91 must not match a rule in the Phone Port DigitMap or the Primary Line's Digitmap, but if it does you won't get a BUSY.
You will get an IVR message saying you have a configuration error.
[^*#]@@. will not match *91
[^*#] means the first character can be anything but * or #
I don't see the problem with your configuration.
It looks like your OBi202 just doesn't like your Star Code.
What firmware level is your OBi202?
My OBi200 is at Build 4477.
Try adding *91| to the beginning of your Phone Port DigitMap.
Do you now get the IVR message after dialing *91

Shale

ModelName OBi202
HardwareVersion 1.3
SoftwareVersion 3.0.1 (Build: 4041)
I know this is not the latest software.

Adding "*91| " ---
Phone 1 port digit map:
Before (992xxxxxxxxxx|9921xxxxxxxxxx|[1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))

Did in local interface:
After (also removed the 992 test from before)
(*91|[1-9]x?*(Mpli)|[1-9]S9|[1-9][0-9]S9|911|**0|***|#|##|**70(Mli)|**8(Mbt)|**81(Mbt)|**82(Mbt2)|**1(Msp1)|**2(Msp2)|**3(Msp3)|**4(Msp4)|**9(Mpp)|(Mpli))

After the change, I got SIT tones, and "there is no call route available to complete your call"

azrobert

This proves that your previous configuration didn't have a stray rule somewhere that matches *91.

The only thing I can suggest is upgrading your firmware. If you don't want to upgrade because you want to use the old method of adding GV, I think Build 4350 is the last build to support the GV old method. This is from memory and my memory sucks, so you better confirm that build 4350 supports the GV old method.