Processing star codes in a dial plan

[RichardDCG]

How can I set the PBX (V68.0.8) to process star codes?  i.e. I want to dial *21 as a call forward with the carrier to put a forward on my line.  I have tried \*21 as a pattern and no luck - I get a Vodia message, also set 345 as a pattern and  sip:*\21@\r;user=phone as replacement with no luck - it seems to go a bit further in that I get a carrier message, but the Vodia logs show I have called 345XXXXXXXX.

[Vodia Support EU]

I would recommend that you set this filter as a prefix in the SIP Trunk under "Routing/Redirection". I see you have also chosen a prefix here 345XXXXXXX. Before that, I would create an extension to which I would forward these calls and then deal with them as desired.

[Vodia PBX]

We have recently a flag "Process star codes" that will pass star codes to the dial plan. There you can use the regular rules to match star codes. However that means that all star codes are matches. If you don't want that, you could just use a special prefix like 88821 to have the same effect.

[RichardDCG]

9 hours ago, Vodia PBX said:

We have recently a flag "Process star codes" that will pass star codes to the dial plan. There you can use the regular rules to match star codes. However that means that all star codes are matches. If you don't want that, you could just use a special prefix like 88821 to have the same effect.

"use a special prefix like 88821 to have the same effect."    - that's what I thought I did. 

I want to be able to redirect inbound calls at the exchange using a star code not at the PBX.

 

This does not seem to work:

When passing a star (*) to the carrier, a backslash is required before the star (e.g., \*67); otherwise, the system will treat the star and the numbers that follow as a star code. In the sample shown above, a backslash has been placed before the Block Caller-ID (*67 ) star code, so when the trunk is used, the system will replace the \*67 with a *67 , causing the caller-ID to be blocked. (The d in the latter part of the string tells the system to replace it with the domain. If an r had been used, the system would replace it with the registrar.)

Important: When using star code patterns in dial plans, you must remove the code from the standard star codes and/or any customized codes. If you’d rather not use star codes in the pattern field but still want to have the dial plan activate a star code, you can use a workaround. You can create a “stand-in” star code that will be used to correlate with the desired star code. In the example shown below, users will need to enter 99 before entering the actual phone number. The system will replace it with the *67 star code. This method allows you to retain the *67 star code as part of the default list of star codes; however, users will need to be informed ahead of time so they that will know to enter 99 before entering the phone number.

[Vodia PBX]

Oh I think I forgot something important. When there is no local match for a valid PBX star code, it would forward that to the dial plan anyway. So there would be no need to suppress the star codes in the dial plan.

If the simple pattern match does not work, just use a ERE pattern, e.g. (\*[0-9]+)@.* which should so the job as well.

[RichardDCG]

I just get "this feature is not available at this time"...

[Vodia PBX]

Maybe you can attache the log file here (log level 9 for trunk), then we should see how the PBX processes this. 

[Vodia PBX]

We discussed this internally again. The solution to have a simple flag to enable or disable star code processing in the dial plan does not solve the problem well. We'll add a setting where you can just list the star codes that the system should run through the dial plan. This should address the problem in a much better way. You can try this out in the 68.0.11.beta build (Debian64/CentOS64). 

[RichardDCG]

Should the system send the * code to the trunk?  I have listed *21 in Star codes that are handled in dial plan  But, it seems to be stripping the *, do I need to set anything else?

[Vodia PBX]

Hmm it should not strip that. I would turn logging on to level 9 (TRUNK) and see what it processes. The problem might be that the "simple" patterns have problems with matching star codes and you might have to revert to extended regular expressions?

[RichardDCG]

I can see the following?

[5] 15:16:30.673

TRUN:

Dialplan "Lab_Test": Match *21@lab.xxxxx.com.au to sip:21@sip.yyyyy.com.au;user=phone on trunk 612xxxxyyyy

 

matching a *21 to 21?  What can I try to process the star code out the trunk?  lab.xxxxx.com.au is our test PBX, sip.yyyyy.com.au is our registration server.  PBX V 68.0.14

[RichardDCG]

had to set \*21 as the pattern and *21\@\r;user=phone as the replacement.  Seems to work.

[Vodia PBX]

8 hours ago, RichardDCG said:

had to set \*21 as the pattern and *21\@\r;user=phone as the replacement.  Seems to work.

You could try (\*[0-9]+)@.* as the pattern. Then the replacement could be just *.

[RichardDCG]

thanks, that would be better.