Option11 + Octel 250: Calls not going to voice mail box 1

[elypu]

Hello,

I was wondering if anyone might have any idea why this is happening:
- The incoming calls are answered by receptionist and forwarded to an extension.
- If there is no answer at that extension, the call bounces back to reception instead of going to voice mail box.
- Voice mail server is Octel.
- It does not happen all the time, but it seems quite frequent to be annoying.

- I looked at the Hunt settings and they seem to be OK.

Thank you.

 

[djstandridge]

There should be a black box between the pbx and vm. that is a bridge between the 2 they are actually the cards from m2008's with data ports. If the bridge is bad then calls will never hit the voice mail. One thing you can do is to unplug a port from the PBX side and place a 2008 on it and then call the DN to see it if rings. If it does then more than likely it's the bridge. Hope this helps

 

[pcat200]

I believe the O250 had cards in the server that emulated the digital cards, doing away with the DMID device. These ports on these cards are connected to digital ports on the PBX via a 25 pair. Verify the programming on the PBX is correct with respect to these ports and the group they are in. Also, in the O250, if I remember right, Menu 13 allows you to look at and test the ports in the O250. It may be all the ports get busy and the calls are going back to the operator. It has been a long time since I worked on a O250. It may be you have some faulty ports either on the PBX or in the 250.

 

[DocVic]

I had some time in Salt lake once. I opened up a bad DMID. I found 3 M2008 sets in it. I laughed so hard...

DocVic
Dedicated to Nortel Products till the end.
Need help? Call Me Now!

 

[KE407122]

Meridian 1 --HUNT only hunts on encountering a set Busy, A no-answer condition requires the FDN XXXX assignment. (XXXX is the Pilot number into the Octel)
Sounds like the transfers are being recalled by timer.

Yes, DMID's haven't been used for quite a while. FLTN integration did away with the DMID - 2616 sets. I only have one site with it. The rest were all FLTN integration.
Watch out, the FLTN- could use ACD integration as well.
OCTEL(Configuration Note 5401)
Both HUNT and FDN have to be in the set programming to get to the OCTEL.



KE407122

 

[elypu]

Hi guys,

Thank you very much for your time in replying to my post.
I am not sure if I would be able to identify the "black box".
I will try first to look at programming of the sets.
They use M3903 and m3904 sets, and the reception has a console Nortel MERIDIAN M2250 ATTENDANT CONSOLE.

My impression is that, when there is a large volume of calls, all the channels are becoming busy and that is when the problem occurs. If that is the case, what is a possible solution?

Thank you gain for your time.

 

[pcat200]

I would use the ACD integration mentioned by KE407122. It would hold callers in q until a channel becomes available, maybe give them a RAN to please hold. I would still check the channels of the FLTN card to make sure they are all ok.

 

[Reusser]

Print the DN of your voice mail

IF ACD using the FLT card -it should show all the agents assigned.

Stat card the agents are assigned to - will see if ports are logged in or not.

Octel always has one or more ports not logged in and used for message waiting lamps. rest should be logged in.

 

[KZ9Y]

Something to think about...

All of the dig. TN's that the Octel uses are in a linier hunt chain. I think a bad TN can hose the hunt chain.

>****

 

[elypu]

Hello,

Thank you all for your replies.
I believe I understand a little better now, and this also with the help from your answers, why the problem started.

In the mean time a technician was sent to check our Octel system and everything appears to be fine on the voice server side. The log files from Octel did not record any error and the ports tested OK.
Apparently, if I am using the right terms, the integration between the Option 11 PBX and the voice server Octel is implemented using 16 TN programmed as M 2616 sets.

The technician that came on site said that his company looks only after the voice server and that if we have problems with the PBX, we should contact the other company.
But he did try some tests in the PBX. He looked at the TN in LD 20. Also, he did a simple test that I understood only after he left and I read more info on the Internet. The technician dialed the extensions of the 2616 sets, one by one. Before he left he told me just that the Octel server is OK, but he said that there are two extensions in the PBX that are not going to Octel.

So, long story short, I repeated his test and I determined that two DNs in the hunt queue were not working.
At this point, I am not sure if those are bad ports.
I just modified the TN before the two defective ones to hunt to the DN immediately after the two bad ones. I believe that in this way I bypassed the two bad ones in the hunting queue. In the queue containing the 16 sets 2616, the two bad ones were in positions 4 and 5, and I guess the hunting chain was very short because of this. So, now at lease we use 14 out of the total of 16 ports to Octel. Today there was no reports about the problem.

The next step that I would like to try is to determine if the ports can be repaired (I am thinking to out the TNs and then reprogram them) or to reprogram those extensions to other good TNs.
I am not sure if I am right in what I am thinking.

Thank you all for your messages that helped me to understand a little more about how this works.

 

[KZ9Y]

Exactly what I said two posts up...sorry about my spelling

************************************************

M3904DBA (Programmer) 2 Apr 10 15:13
Something to think about...

All of the dig. TN's that the Octel uses are in a linier hunt chain. I think a bad TN can hose the hunt chain.
>****

************************************************


Print the defective TN's. (for insurance)

Move the defective TN's to new TN's. (LD 11 move command)

Swing jumpers to the new TN's

Out the defective TN's





>****