*67

[hosted]

how do I pass *67 to the carrier? I cant seem to send any star codes.

[Vodia PBX]

In the replacement, when you want to use a star, you have to put a \ in fron of it and use the full form with the sip in it. For example:

 

sip:\*67@\r;user=phone

[hosted]

Pattern - \*67

Replacement- sip:\*67@\r;user=phone

 

I still get 'this feature is not available' I deleted *67 from the feature codes.

[Vodia PBX]

The pattern can never start with *. * is always handled internally by the PBX. You can have a pattern like 9969.

[voipguy]

The pattern can never start with *. * is always handled internally by the PBX. You can have a pattern like 9969.

 

 

Hi pbxnsip,

 

I think this is a design bug?

 

Your own manual on page 130/131 states the pattern can START with a star * symbol and the replacement can also contain a star symbol. See attached screen shot.

 

I put in what your manual states:

 

Pattern \*([0-9]*)@.* replacement sip:*\1@\d;user=phone

 

Then in the "Show Test Area" box I inputted *674166381234 and the output box showed sip:*674166381234@d;user=phone which is what we expect and want.

 

I then made a test call with my SNOM 370 and in my call logs it shows a 3 second call to *674166381234 but the call was never made - instead I hear the PBXNSIP voice stating this feature is not available at this time.

 

I made sure my feature code *67 was removed before doing the tests.

 

The reason we want to send *67 to our own sip proxy is so that we can see the incomming caller id of our customer to bill him (we bill via our sip proxu and not by PBXNSIP logs) and then when we send the call to our terminating provider we change the out going display to Private Number. This way our customers can still use the nationally known *67 call block feature code.

 

I think this is a BIG bug in the design.

[Vodia PBX]

Okay, sorry I wasnt very clear... Of course you can use the symbol * in a pattern. In a simplyfied pattern, it has a special meaning. That means when you use the *, you won't match the * that someone dialled on the phone.

 

But the main point is that the PBX does not pass numbers to the dialplan if they start with a "*". The star at the beginning of the dialled number tell the PBX that this is a special code on the PBX that needs to be processed locally.

[voipguy]

Okay, sorry I wasnt very clear... Of course you can use the symbol * in a pattern. In a simplyfied pattern, it has a special meaning. That means when you use the *, you won't match the * that someone dialled on the phone.

 

But the main point is that the PBX does not pass numbers to the dialplan if they start with a "*". The star at the beginning of the dialled number tell the PBX that this is a special code on the PBX that needs to be processed locally.

 

 

Hi pbxnsip,

 

No, you were clear. We understand that you were trying to tell us you can't pass numbers to the dialplan if they start with a "*".

 

The problem I have is that your own manual states you can pass numbers to the dialplan that start with a "*" symbol.

 

For some reason the screen shot of the image I posted yesterday wont open in your forum.

 

At the bottom of page 130 of your new manual the title is: Sending Star Codes on a Trunk

 

"Sending Star Codes on a Trunk"

"In this case, you need to use extended regular expressions:

 

Pattern:\*([0-9]*)@.* replacement: sip:*\1@\d;user=phone

 

The pattern matches patterns that start with a star symbol followed by any number of digits. The replacement then inserts the star again and puts the dialed number after the star."

 

(Of course that pattern captures all * codes but we would change it so it would only capture the *67 code.)

 

Am I reading that wrong?

 

Even in the dial plans test area when the user enters *674166381234 on the phone/pattern side the replacement shows the correct output *674166381234

 

If I'm reading the manual correct then this is a bug.

 

Also, do you not think this is a design bug? Meaning why would PBXNSIP force us to not be allowed to capture * codes on a users phone, especially with a PBXNSIP hosted edition.

 

I know PBXNSIP uses * codes for special things like speed dials from *00 to *60 and then *61 to *99 for feature codes. But the system should be smart enough to check if the user entered *67 and *67 is not used in the feature list because I removed it then proceed to the dial plan part of the program.

[Vodia PBX]

Looks like we need fix the manual

[voipguy]

Looks like we need fix the manual

 

 

lol....I don't think the manual needs to be fixed, I think the issue of how PBXNSIP handles * feature codes needs to be fixed.

 

 

So your response indicates I am reading the manual correctly and this should work, even the PBXNSIP "Show test area" box in the dial plan screen which allows you to test your dial plan strings also works for the Pattern:\*([0-9]*)@.* replacement: sip:*\1@\d;user=phone but you think the manual needs to be fixed?

 

Can you at least forward this bug, issue, feature request or whatever you want to call it to your coding department?

[Vodia PBX]

The question if a star code matches or not is non-trivial. If the PBX would allow exceptions, it would make it very difficult and random to find out why a star code was not forwarded to a trunk. Because of that, the PBX treats eerything starting with * as a star code. There is a very simple workaround if you want to pass a * to the carrier, just use another prefix instead of * (e.g. 99).

[pbx support]

lol....I don't think the manual needs to be fixed, I think the issue of how PBXNSIP handles * feature codes needs to be fixed.

 

 

So your response indicates I am reading the manual correctly and this should work, even the PBXNSIP "Show test area" box in the dial plan screen which allows you to test your dial plan strings also works for the Pattern:\*([0-9]*)@.* replacement: sip:*\1@\d;user=phone but you think the manual needs to be fixed?

 

Can you at least forward this bug, issue, feature request or whatever you want to call it to your coding department?

 

Well what you see in the "show test area" is what is being passed to the dial plan & what would be the result.

 

But in this case, if you dial *67xxxxxxxxxxxx from the phone, PBX consumes *67 (as mentioned in the couple of posts earlier - special treatment for numbers starting with *)

Maybe we have to pass it onto dial plan if the code is not configured/matched. We will investigate.

[voipguy]

The question if a star code matches or not is non-trivial. If the PBX would allow exceptions, it would make it very difficult and random to find out why a star code was not forwarded to a trunk. Because of that, the PBX treats eerything starting with * as a star code. There is a very simple workaround if you want to pass a * to the carrier, just use another prefix instead of * (e.g. 99).

 

 

Hi pbxnsip,

 

It's not a simple workaround. You have to think of the bigger picture. We are using the Hosted version of PBXNSIP. We want PSTN customers to switch over to the VoIP world and the PSTN customers are used to dialing *67 to block their number. *67 is nationally known as the call block code. Since PBXNSIP doesn't block the # key from being sent to the dial plan a better temporary workaround is #67

 

For two more reason why it would be better for the Hosted provider to control the *67 code see my next post.

 

I see in the new Admin manual released March 8th that you "fixed" the manual on page 130/131 so it now tells you you can't send the * code.

[voipguy]

Well what you see in the "show test area" is what is being passed to the dial plan & what would be the result.

 

But in this case, if you dial *67xxxxxxxxxxxx from the phone, PBX consumes *67 (as mentioned in the couple of posts earlier - special treatment for numbers starting with *)

Maybe we have to pass it onto dial plan if the code is not configured/matched. We will investigate.

 

 

Hi pbx support,

 

Yes, please look into allowing * codes that are not configured/matched in the domains feature code list to be forwarded to the dial plan.

 

We are using the hosted version and here are two reasons why this would benefit us and others.

 

1. We send all our calls to our sip proxy server that bills each call. Right now if a customer does *67 PBXNSIP blocks the call and our sip proxy doesn't know who to bill because we can't see the caller id. Now if PBXNSIP would just pass the *67 along with the number the customer dialed then our proxy server will see who the incomming call is from and know to block that customers out going name and number when we dial the destination number.

 

2. With the current PSTN world when a customer does *67 it only blocks the name and number for that one call - this is what customers are used to. With PBXNSIP when you do *67 it blocks all calls forever until the customer dials *68 to unblock calls. This confuses customers and causes calls to customer service which wastes our time explaining to the customer that they have to dial *68 after the call to unblock their number. I know you included a domain option to reset all blocked numbers at midnight because of this issue. This problem wouldn't exist if we did *67 on a per call basis like the PSTN world does. If a customer wants his number blocked all the time then we would just give him a dial plan that does *67 for him on every call.

 

It would be great if this feature could make it into ver 4.

 

Thanks

[Vodia PBX]

Regarding billing, RFC3325 explains that there is a difference between hiding the number and telling the provider who to bill. We do support RFC3325, so that should be possible.

 

There is another (IMHO more elegant way) of telling the provider who to bill, I believe it was specified in the scope of IMS. This is called the "ICID", which is essentially a token that the PBX will present when it uses the trunk. This token can be assigned by the provider and it makes 100 % clear who is sending the call. Unfortunately, this method did not make it to most of the providers, it is a shame.

 

Passing *69 upstream to the provider might have the side-effect that it blocks the caller-ID for all users from the PBX that are sharing the trunk. In other words, you neighbor might accidentially turn it on just after you turned it off and you are making a phone call now.

[voipguy]

Passing *69 upstream to the provider might have the side-effect that it blocks the caller-ID for all users from the PBX that are sharing the trunk. In other words, you neighbor might accidentially turn it on just after you turned it off and you are making a phone call now.

 

Hi pbxnsip,

 

Passing *67 along with the telephone number has no effect on my neighbor, other office users or anyone else on the PBX. It's a one time per call block per user. It has nothing to do with the trunk or turning one thing on or turning one thing off.

 

Here's an example:

 

If I want to call my friend Jeff at 1-416-638-1234 but I don't want him to see my caller id name and number show up on his phone then I have to block my number, to do this I would pickup my SNOM 370 phone and dial one complete string *6714166381234 PBXNSIP would then send that complete dial string to the dial plan and then the dial plan sends that complete string to the trunk and then to my own SIP proxy server, my sip proxy server sees the prefix as *67 so before it dials my friend Jeff it will change my outgoing name and number to Private Name Private Number and then it will dial 1-416-638-1234 and on Jeff's call display phone it will show Private Name Private Number.

 

Now that's if PBXNSIP would allow me to pass the *67 to the dial plan but right now it doesn't allow that. We don't want PBXNSIP to do the call blocking, we want our own sip proxy to do it - why? - so when a call comes from PBXNSIP into our sip proxy we can see the caller id and then we know who to bill for that call, if PBXNSIP blocks the call then it comes into our sip proxy as anonymous and we won't know who to bill for that call.

[Vodia PBX]

Yes, you are right! Maybe this is another way of blocking the caller-ID? I remember from FXO that this was done in a similar way. Maybe we should embrace this and make it a way of indicating anonymous calls. Are there other feature codes that should be passed on call-by-call basis?

[voipguy]

Yes, you are right! Maybe this is another way of blocking the caller-ID? I remember from FXO that this was done in a similar way. Maybe we should embrace this and make it a way of indicating anonymous calls. Are there other feature codes that should be passed on call-by-call basis?

 

Hi pbxnsip,

 

That would be great if you guys could pass the *67......very important for companies using your Hosted version.

 

I personally don't require any other * codes to be passed on to the dial plan but maybe don't limit it to just *67. Maybe make your code work so if it gets a * code see if it matches a * code in the domains feature code list and if no match then send the * code to the dial plan.

 

Of course this only applies to * codes from *61 up to *99 as I think you currently reserve *00 to *60 for speed dial numbers. We don't want to mess with the speed dials.

 

Thanks

[pbx support]

Hi pbxnsip,

 

That would be great if you guys could pass the *67......very important for companies using your Hosted version.

 

I personally don't require any other * codes to be passed on to the dial plan but maybe don't limit it to just *67. Maybe make your code work so if it gets a * code see if it matches a * code in the domains feature code list and if no match then send the * code to the dial plan.

 

Of course this only applies to * codes from *61 up to *99 as I think you currently reserve *00 to *60 for speed dial numbers. We don't want to mess with the speed dials.

 

Thanks

 

There is fix ready for this issue. If you are using centos - http://pbxnsip.com/protect/pbxctrl-centos5-4.0.1.3438

[voipguy]

There is fix ready for this issue. If you are using centos - http://pbxnsip.com/protect/pbxctrl-centos5-4.0.1.3438

 

 

Hi pbx support,

 

This is great!!!

 

I tested it and it works PERFECTLY!!!!

 

Thanks.....this solves our call block billing problem and gives us more options/control over how PBXNSIP operates.

 

Thanks

[hosted]

wow that was super fast!

[voipguy]

The passing of *67 to the dial plan is now broken in version 4.0.1.3442.

 

I'll start a new thread.

[voipguy]

The passing of *67 to the dial plan is now broken in version 4.0.1.3442.

 

I'll start a new thread.

 

 

I got it working - what I did was switch the dial plan to text mode - copied it all...then deleted that dial plan - created a new dial plan with same text - now it works.