Redial yields busy because of access code how to allow?

[lloydr1l]

Okay, I have a headache from reading/searching for this, and I've actually tried what I thought would solve this via the instructions located below for incoming CID:

http://www.3cx.com/blog/docs/cid-formatting/

I followed scenario 2 for adding our access code to an incoming call for easy redial, substituting our number instead of "0". Saved the configuration and uploaded to the gateway, but without successful results.

This issue is a one digit access code to access the lines. Both the physical phone, and 3CXPhone show the CID in history, but trying to dial will not work because there is no access code.

How do I setup for redial of numbers in history without the access code?

Thank you for any help in this matter.

 

[leejor]

Two choices...you have to either have the access digit prepended to the number displayed.

http://www.3cx.com/blog/docs/cid-formatting/

Or ...changed/add, to your outbound rules, to accommodate the numbers as dialled.

 

[lloydr1l]

Two choices...you have to either have the access digit prepended to the number displayed.

http://www.3cx.com/blog/docs/cid-formatting/

Or ...changed/add, to your outbound rules, to accommodate the numbers as dialled.

Thank your for the reply leejor. The first choice as I mentioned in my post, did not work. The second choice I considered, but was unsure how to implement. The only way I could figure, was to eliminate the access code, but that's not what we want to do. Is that what you are suggesting by choosing option 2?

 

[leejor]

I'm not certain as to why reformatting the CID didn't work for you. You didn't mention which version of 3Cx you are using , that might make a difference. There may be something you had missed and that option may be worth re-visiting.

Option 2, doesn't mean eliminate the access digit, but simply add additional outbound rules that will handle calls (redials) without the prefix. In some cases that might be easier said than done, but, if the majority of your calls are to be routed out one or, even two trunk groups, then it might not be all that complicated.

It all depends on your reason for having the access digit in the first place. Some people use one to allow callers to select various routes.

 

[lloydr1l]

Version 14 SP3. Missing something is certainly a thought I've had, but can't see where I could have. I followed the guide, which in the second example is exactly what I wanted. The only difference being a different digit for access. The format being +(1)(...)(.*) and 7\2\3

I applied, OK'd, and generated a new config file to upload to the GW. The last part was not addressed in the instructions, but seemed what needed to be done.

As for creating an outbound rule for this, I'm not sure how to do this. It seems creating another rule not requiring an access code for redials would make the other rule obsolete?

 

[leejor]

I haven't done CID re-formatting myself, so any "intricacies", or something you are missing would have to be addressed by someone else that has worked with it.

I would not think that a new configuration file (for the gateway) would be needed because you are simply attempting to re-format the CID within 3CX, nothing would change in the gateway.

As far as the outbound rules... multiple rules, handling slightly different format of number can co-exist. The current rules will still work. You have to keep in mind that outbound rules are "read" from top to bottom and that 3CX receives the whole dialled number with which to make a match in the rules. In this manner, you can "weed out" certain numbers, and send them one route, with a rule that is above the "general" catch-all rule for all the other number. The first match 3CX comes to, will be used.
So, you can have a rule 97175551212, 11 digits long, remove 1 digit along with 7175551212, 10 digits long, remove 0 digits and send both calls to the same destination.

Usually the use of a prefix digit is decided upon because the previous PBX required it, and they want to keep all dialling the same, or to allow people to manually choose an alternate route. 97145551212 goes one way, but 87145551212, goes another. When you are re-dialling a number, you will loose that ability it will follow the route(s), in the outbound rule.

 

[lloydr1l]

For the CID re-formatting issue, the article refers to dealing with the Gateway node, and when finished, with changes applied, 3CX generates the page where a new config file can be saved. This led me to think it had to be uploaded to the Gateway. Again, I'm not sure if it's necessary or not, but you are dealing with the Gateway settings. So I don't know.

I'll have to look over your second part a little closer later, but on initial read it still sounds like it would make the access code obsolete. Using your example of the 7175551212 number, if both are in place then the access code would never be needed since the other rule is there to allow it. But again, I'll have to read and think it through a little more.

Thank you for taking the time to help me.

 

[lneblett]

My understanding of the function is that the ability to reformat the CID is done at each incoming line/trunk regardless of SIP or PSTN and is performed as 3CX receives the call and passes it to the receiving extension.

This is not something that is uploaded to a gateway in the config file, but rather that the system "sees" the incoming CID, if one is present, and then reformats it according to the instructions provided. It will need to be enabled on each port/trunk for however many ports there are as each could be unique to one another.

What I am not clear about, is if this is an access code to select an outbound route or a PIN code by which an extension is forced to input before being granted access to an outside line.

If using to gain access to a trunk/line, then the outbound rule would need to see have the access code stipulated in the "calls to numbers starting with prefix "X"", where X is the code. Then it would also need to have a strip of one to remove the access code so it is not passed to the trunk.

Consideration needs to given to where in the rule listing this one falls as the rules are processed in the order presented and if the format of the call is met by any other rule, the first rule it encounters that meets the criteria will be used to effect the dial.

 

[leejor]

it still sounds like it would make the access code obsolete. Using your example of the 7175551212 number, if both are in place then the access code would never be needed since the other rule is there to allow it. But again, I'll have to read and think it through a little more.

In essence, yes, it would make the access code unnecessary, if you tell people to dial that way. Most, out of habit will probably continue to use the access digit.

As I said, it all depends why you chose to have an access digit in the first place. If you have a second route that requires an "8", or a "7" access digit, then callers would still have to use that if they wanted to force calls over that route.

Use of an access digit and help simplify outbound rules but in many cases it is a "holdover" from analogue (and early digital) PBXs that, in many cases, cut you thought to outside trunk dial-tone as soon as you dialled 9. It's just easier to go with what people are used to rather than having them re-learn how to dial outside calls

 

[lloydr1l]

What I am not clear about, is if this is an access code to select an outbound route or a PIN code by which an extension is forced to input before being granted access to an outside line.

If using to gain access to a trunk/line, then the outbound rule would need to see have the access code stipulated in the "calls to numbers starting with prefix "X"", where X is the code. Then it would also need to have a strip of one to remove the access code so it is not passed to the trunk.

Consideration needs to given to where in the rule listing this one falls as the rules are processed in the order presented and if the format of the call is met by any other rule, the first rule it encounters that meets the criteria will be used to effect the dial.

It is for the user of the system to enter for example "9 or 0" to access an outside line. This is what I've always come across in business, whereas there has always been a digit or code to enter in order to access an outside line. I was under the impression this also cut down on fraud, so I have continued to always have the user enter an access code, which everyone seems to be used to doing.

The outbound rules you reference are setup, with a one digit entry needed to access the lines, and it is stripped. It works fine, except when redial is utilized, because the incoming call does not show up in history with the needed digit for access, making it useless to redial. This is where the CID formatting solution I thought would work, but for some reason the digit is still not being inserted.

 

[lloydr1l]

As I said, it all depends why you chose to have an access digit in the first place. If you have a second route that requires an "8", or a "7" access digit, then callers would still have to use that if they wanted to force calls over that route.

Use of an access digit and help simplify outbound rules but in many cases it is a "holdover" from analogue (and early digital) PBXs that, in many cases, cut you thought to outside trunk dial-tone as soon as you dialled 9. It's just easier to go with what people are used to rather than having them re-learn how to dial outside calls

It is the "holdover" scenario you are describing. Every business I worked for, and even those I frequent for whatever reason, still have this type of usage, and it is what I have stuck with. Users are familiar with entering a 9/0 access code in order to get an outside line, but this is getting in the way of redialing a number in the call history, which does not contain the access code.

 

[NickD_3CX]

As lneblett pointed, indeed this setting affects the call as it is coming into the system and is Trunk-specific.

Anyway, most of the times, the issue is the actual pattern you out in the Incoming CID Reformatting settings, that it does not match exactly what is coming in.

What I would suggest is run Wireshark on the Server, make an incoming call and find the INVITE coming from the Trunk/Gateway and see exactly how the number is formatted in the From : User Part, or copy-paste it here so we can have a look (blank out any sensitive information, but leave enough for us to work with).

This way you could see of the pattern you have matches what indeed is arriving to the server.

 

[lloydr1l]

For anyone else coming across this, I did go through the steps to capture and send information into support. Even though I was following the steps taken in scenario #2 of the article listed above, thinking it was exactly like what I wanted, the reason it was not working for me had something to do with 10 digits minus the "+" listed in the article.

This was the one section I did not, and still do not fully understand about the article dealing with +. So even though it looked like my example, somehow it differed.

The solution in my case-
Source CID Pattern: (.*)
New Source CID Pattern: 9\1

9 being the access code to reach a line. Hope that helps someone. Thanks to all.

 

[lneblett]

The plus sign (+) is part of the e164 numbering format which is more commonly used by VoIP providers given their ability to route calls globally.

https://en.wikipedia.org/wiki/E.164