New extension phone cannot pickup CAP lines, has to wait until incoming call is placed on Park line 1

[John in Texas]

I've added new extension phones (DT330) to our SV8100 PBX, WebPro 9.50 without problems in the past by copying a working extension profile (15-01, 15-02, 15-07 and 15-20) to the new extension profile. We added an additional card to support more phones. Since then, I can get the new extension profile to work perfectly except they cannot pickup the main line when it rings (CAP 0001), someone else must answer and place the call on a Park line, then the new extension user can pick up the call. All our phones were originally setup to ring when the main line has an incoming call. Also the new extension phone does not ring when a new call comes in the main line (CAP 0001) nor does the call indicator lamp light up for the incoming call. The new extension rings and the lamp lights up when someone dials their extension number internally, they can call others internally and can call out. I thought I found the reason as the new extension is not listed in 22-04, but then I noticed that other extension numbers are not listed there, but they can hear and answer new inbound calls. Ugh. Thank you in advance for any suggestions.

 

[roldix27]

check program 15-06 if the new ext. have a similar map access with your operator

 

[John in Texas]

Thank you roklix27 for the suggestion. Yes, all extensions have the same Night Mode value of '1'. Please let me know if you have any other ideas.

 

[belevedere]

Is 22-02 set DIL to a virtual/CAR key? If so, does the new extension have that VE/CAR key on a button?

 

[John in Texas]

Thank you belevedere for the suggestion. 22-02 are all set to DID. Please let me know if you have any other ideas. What is killing me is this happened over a year ago and I cannot remember what was changed to get it to work for that new extension.

 

[belevedere]

If you are routing by DID, then trace the call. Look at 22-11 for the incoming digits, then see where it is going, ie:extension, ring group, etc. If by extension, does the new phone have that extension appearance? If by ring group, it that phone in the ring group, 22-04?

 

[John in Texas]

That is why you are an instructor belevedere! I'm not quite there in solving my problem, but feel that I am closer due to your previous post. I checked 22-11 and my problem phones (not ringing with the incoming calls) look to be setup correctly. The 22-04 ring group looks okay, but 22-10 DID Translation Table Area Setup may be where the problem is. As I understand it, 22-10 defines the range(s) of the DID translation table area for the extensions I want included. What I'm confused about is how the table is currently filled out.

I don't understand why line 02 begins with the same entries as line 01 and why the second range entered in line 01 is limited to 20 extensions. I would have put 121 to 140 in the second half of line 01. From what is in the table, I can see that all extensions above 140 are not included and of course my new ones are above 140. This is why I think I'm getting to the missing component. I'm thinking of entering 1 to 140 on line 01 where the first set is in place of 1-120, followed by entering 165 to 172 where the 121-130 was entered and then putting '0' in the four fields on line 02. Your thoughts please.

 

[John in Texas]

I tried several combinations on populating 22-10 translation table area with no positive results. Ugh

 

[belevedere]

22-13 determines the DID Table Translation Area, EX: 22-13, mode 1 =1, mode 2=2, mode 3=3 for your DID trunk group. This means that in 22-10, table area 01 is mode 1, 02 = mode 2, 03 = mode 3.
In your screen shot, 01, 1 to 120, and 02, 1 to 120 will not change with day night modes. any numbers in those tables 1-120 route the same way D/N. 121 to 130 route numbers in the day mode, 131 to 140 route number in night mode.
So, in 22-11, table 121, incoming number abcd routes one way, and the same number abcd in table 131 in night mode route a different way, and the only numbers in tables 1 to 120 are those that never follow night mode, such as a personal DID or a FAX machine.
See attached.

 

[John in Texas]

Thank you belevedere for sharing your time and knowledge. What you posted along with the DID Translation sheet helped me to understand more about this area. I noticed that my 12-01-01 is checked and and the automatic night mode switching is not checked, this indicates to me that we only use mode 1 as our receptionist never manually evokes mode 2. Since all my phone sets are within my 120 DID translation tables, I remain perplexed why extensions such as found in DID Translation table entry 58 cannot pickup a CAP line, cannot hear the inbound call ring, and the phone's lamp does not light. Of course I compared the table entries for 58 to ones that do work and the values are the same with the exception of the target number and dial-in name. Please let me know if you have any other suggestions and thank you again.

 

[belevedere]

Sure sounds like a CAP key issue. Do the buttons have any? (*08 + 1-999). You can press FNC + line key to see what is there.

 

[John in Texas]

belevedere: We use NEC DT330 (DESI less 8-button with LCD) phones. When I check the programming at the phone for CAP 0001 I see in the phone's top display: 'LINE KEY 01' and 'CAP KEY 0055'

In WebPro 9.5, 15-07 Function Keys, the function key 01 shows '*08 - CAP Key' under Function and '55' under Additional Data for my extension and yes my phone allows me to hear and answer incoming calls on CAP 0001. I noticed that the Additional Data value for each user for their CAP Key increments +1 from the extension that precedes them. For example, the extension for the user that follows my extension has an Additional Data value of '56' for their Function Key 01 and '*8 - CAP Key' for the Function value. I noticed that the users that cannot hear or answer incoming calls on CAP 0001, their Additional Data value is not incremented over the preceding extension as it is the same as the copied value of the users extension profile I copied from when setting up the new extensions. I'm not sure how this value is used in the system. Is this meaningful?

Is there something else I need to check?

 

[belevedere]

Extensions with different CAP keys have their own appearance, so if they place a call on hold they will be the only ones to be able to retrieve it. With shared CAP keys a call placed on hold can be retrieved by anyone with the same CAP key appearance. There are only 2 required commands for CAP keys, 15-07 and 20-02-23 which should be set to 0, or not checked.

 

[John in Texas]

Thank you again belevedere for helping. Please confirm that I am correctly understanding your last post. Two or more extensions can share calls placed on hold only when their Function Keys appearance are the same. For example, they each have 'CAP 0001' or 'Park 1' keys. These values are defined in 15-07 under the Function value. The order sequence does not have to be the same. For example the first Function key for one extension might be used for CAP and another its for Park. The 15-07 Additional Data values do not appear to be meaningful since two extensions that each have 'CAP 0001' can pick up the call even though the 'Additional Data' values differ for these two extensions in 15-07. This last point causes my curiosity to wonder what or how the Additional Data field is used, but then that is not my biggest problem right now.

In my version of Webpro 9.5, the 20-02-23 field is titled 'UX5000 Phone Operation Mode. The options for this field do not appear to be involved with CAP keys and even if I am wrong, this value is for all users so it cannot be the root of why a few of my extensions cannot pick up incoming calls off CAP 0001 or hear the incoming call ring. Is there possibly a typo in your post of the item you meant to list?

 

[belevedere]

No typo, the system was designed to use UX-5000 phones on an upgrade, so this program allows for that.
20-02-23 field is titled 'UX5000 Phone Operation Mode, set this only if you have UX-5000 phones in your system from an upgrade.
At this point I would need to see your database, or you might consider bringing in a certified NEC tech to look at it. You seem to be doing things correctly, so there is something else going on or being missed.
In PCPro you have a tools tab/reports/non-default value and verify options to compare databases to each other, or to a default database. Very useful tools in situations like this.

 

[John in Texas]

Thank you again belevedere! I loaded PCPro 10.0 today and generated some reports as you suggested. Unfortunately, I did not have a default or old database to compare to as these had not been shared by our outside tech. I just have .gz files that I make when making minor changes via WebPro. I can now see the value of having an old or default database for comparison with the powerful tools in PCPro. Today, I did save a copy of the current database for future comparisons. My feeling is it would be too much to ask you to look at the current database and I don't want to be unfair. Tomorrow afternoon I will put in a ticket with our local NEC certified tech to resolve what the issue is. I can then do another capture of his updated database and will likely be able thru the compare tool, be able to see what was changed to get the problem resolved. Thanks for everything, you are awesome!

 

[John in Texas]

My outside tech led me to the missing puzzle piece. In 15-09-47 and -48 Virtual Extension Ring Assignment, all Modes needed to be checked for the new phone extension profiles. I didn't think this was needed since 12-01-01 and -02 Night Mode Switching was set to manual, but I was wrong and learned from this.

Thank you to all that suggested solutions and those that read with the intent to try and help. They too furthered my knowledge.