Bug in admin / advanced / contacts - Cant use * to precede a trunk seizure prefix

[fgc92210]

Version 16.0.6.655

We have multiple SIP trunks we use for incoming / outgoing.
Depending on the caller ID we want to display when we dial out, we use a prefix *01, *02, *03 to pick the correct outgoing SIP trunk group.

In the admin interface, under Advanced / Contacts, it is impossible to have a trunk seizure prefix starting with *
If we do so, an error message "Invalid value" will pop up.

On the other hand, if I go to the /webclient then Contacts / and add a Company contact with a trunk seizure prefix starting with * , it will work.
Can you guys fix this in the next release, so * and # can precede a prefix made out of numbers ?

Thank you.

 

[Alphabetic]

Works fine if you put it in Home or Business

 

[fgc92210]

I need to use mobile. It does not work for this field.
It should be consistent with the /webclient interface. If one works, the other should too.

 

[leejor]

The asterisk (*), as a leading character, is normally used as a vertical service code (feature), and not a trunk access code, and each device might handle it differently. Had you considered using 91, 92, 93, 94, etc, as the prefixes, to select the outgoing trunk? Was this a carry-over from a previous system?

 

[fgc92210]

I agree with normally used as a service code, but it is not a protocole to follow.
Any other PBX system let you use whatever you want as a trunk seizure prefix.
The issue here is that it works if you edit a contact from the webclient side, but not in the admin side. It's not consistent, and it should be.

I do not want to use 9x as prefix.
Located in North America, people were used with the previous system to use 9 as a prefix trunk seizure, while in Europe they use 0 (I think)

Some numbers start with 9 as area code in the USA, as 908, 916, etc..
This customer does not want to use 11 digits dialing (in the usa, you can use xxxyyyzzzz or 1xxxyyyzzzz).

Since we are down to 10 digits, it's going to be too confusing if they have to dial
91908xxxyyyzzzz
92916xxxyyyzzzz

I know *01 replace 9 in your case, but customer does not want that, and I understand their point of view. It's their habit from a previous system.

Back to the issue, 3CX is not consistent in the user entry. It should.
No matter what, a trunk seizure prefix should allow * as a start.

 

[leejor]

It's their habit from a previous system.

And many times that is a problem, as all features/functions, used on a previous system cannot be implemented, on the new system. Just as people (in North America) have had to adjust to dialling 10 digits instead of 7 for local calls, and had their area codes changed, people have had to adjust. I understand that there is an inconsistency in how this is working for you, but it sounds as if it is something that 3CX will have to choose to implement, for the few people that choose the same dial pattern as yourself.

 

[fgc92210]

I'm sorry but I do not agree. Regardless of what the issue is, you can't have it working on one side of the system, and not on the other side. Either they accept that we can start a phone number with a * in it, or they dont. And if they don't, then they will need to prevent admins to setup Trunks Prefix Seizure starting with a * in the TRUNKS section of the system.

Frankly, just be open minded. What rules your world might not rule someone's else world. If it was an inconvenience, I'd understand. But it's better at this point to leave people use it if they want to, or not use it if they don't want to. It would be an inconvenience to remove the feature in its whole since I am sure I am not the only one using a * in front of a trunk prefix seizure code..

 

[cobaltit]

Frankly, just be open minded. What rules your world might not rule someone's else world. If it was an inconvenience, I'd understand. But it's better at this point to leave people use it if they want to, or not use it if they don't want to. It would be an inconvenience to remove the feature in its whole since I am sure I am not the only one using a * in front of a trunk prefix seizure code..

I think you might be missing the point. There are several feature requests that have languished for years so unless this is truly considered a bug by 3CX, a fix may be a long time coming. So people are recommending other solutions that you can implement TODAY. And the fact that other systems let you pick whatever trunk prefix is a moot point. It's great if a Mitel system or Avaya system lets you do something, but they are closed systems. 3CX has to make sure that anything implemented works on EVERY supported phone. So if one phone doesn't like having a leading * (as @leejor ) mentioned then then 3CX won't implement it. And yes you very well may be the only person trying to use 3CX in this fashion. I've never had this request and I don't recall seeing any such requests in the forums. But whether you are the only one, or the only one who bothered to to post in the forums, or the only one who decided not to use an alternative means really isn't the point. The point is that you are in the minority for this use case, so unless 3CX considers it a bug, I wouldn't hold my breath.

@JohnS_3CX Can you comment if this is a bug (not having the same experience when entering via the web client vs management console)

 

[fgc92210]

@cobaltit
I agree and understand that point.
But my point is that it is possible to do so in one part of the system, while it is not in another part of the system.

Not sure where you are located, but for the past 20 years I installed about 300 systems in North America and maintained probably double of that. Very frequently for a reason or another we had to use trunk seizure prefix starting with *. Every site had their own reason.

As per the phones, we only use Snom and GrandStream, and both allow trunk seizure prefix starting with *

 

[JohnS_3CX]

@JohnS_3CX Can you comment if this is a bug (not having the same experience when entering via the web client vs management console)

Not a bug, but there was no reason it should really be there since it's allowed elsewhere.

The restriction will be removed in a future release, along with some other improvements in validation