Pri blocking calls

[incomminc]

I have a client with a MICS running 7.1 and three Pri circuits. They have been having a problem with incoming calls for about a month and a half. I have swapped out the DTI cards, replaced the software and the problem is still there. The carrier did some more testing over the weekend and came back with calls being rejected with error code CV 44 and CV 47.

The three circuits are set up as follows

PRI
4ESS
B8ZS
ESF

All three are in pool PRI A. The carrier is sending four digits. The incoming calls are coming in on a preferred hunt sequence. Meaning that they send the calls to the least used channel over the three circuits. I asked hem to set the incoming to a true terminal hunt but they are unable to do it in a 4ESS switch.

The majority of the calls are answered by a Cinphony II ACD and are directed straight to the groups. The Cinphony is a standalone unit with 16 channels. At any given time there are 5 to 7 ports in use by the ACD.

Calls appear to ring in ok until there are about 30 to 35 calls in the ACD que. After that the calls are rejected. Does anyone know if the MICS is a full non-blocking switch or is there a limit to the number of calls it can handle at once? When the call rejection starts it not only rejects calls to the ACD, but also rejects calls to individual phones. And during that time it seems that one in about 10 calls goes through.

Also does anyone know what the error code CV44 and CV 47 mean?

Any light you can shed on this will be much appreciated.



Dan Schollian

http://www.incomminc.com

 

[DigitelD]

Are CV44 and CV47 Cause Codes? If so here is what I have:
Cause No. 44 - requested circuit/channel not available [Q.850]
This cause is returned when the circuit or channel indicated by the requesting entity
cannot be provided by the other side of the interface.
Cause No. 47 - resource unavailable, unspecified [Q.850]
This cause is used to report a resource unavailable event only when no other cause in the
resource unavailable class applies.

 

[incomminc]

Yes they are cause codes, and if I interpret it correctly the carrier is trying to send the call to a channel that is in use. The carrier has said that the issue is that the switch is rejecting the call even though during time of low call volume the calls connect fine. That’s why I am wondering if the switch is only capable of handling 30 to 35 simultaneous calls. I also can't rule out the carrier is having issues once the call volume reaches 30 to 35 calls. I think I would have a better chance winning the lottery and retiring on my own private island before the carrier admits it is their issue.

Dan Schollian

http://www.incomminc.com

 

[Phonehed]

I think I'd scroll through all 69? PRI channels and make sure they are still provisioned but I wouldn't be surprised if it's something on the carriers side.

As I recall, all Norstars are non-blocking systems so if there's an idle channel available, even under the heaviest of traffic loads, anyone with access should be able to grab a line and call out or in on it.

All users should also be able to access an intercom channel simultaneously and tie up every phone in the system on internal calls too.

If you have 69 PRI channels but only 16 channels into the ACD group, I can see how that might result in a lot of ring no answers under peak load but not disconnects.

I assume those 69 channels are also shared with many other users outside of the ACD group?

Phonehed in Dallas

 

[dnsincomminc]

All of the PR channels are provisioned and yes they are used for in and out dialing. From what I can gather the average outbound use is about 8 10 ten calls at any given time. I looked in the link status for all three and during the heaviest times they are at about 80% capacity. Also when the calls are not completing, there are any where from 10 to 30 available channels. I just got more information from the carrier and they are saying that all of the issues are occurring on the second circuit. I am going to replace the card in the morning and have them test it again. They also said that the calls are being rejected because the switch is set to DTMF/Wink and it should be set to Q931. When I asked them what Q931 meant, they could not explain it. They said it is not DTMF/Wink. I then asked why it only happened during high inbound call volume and they said it is because of the Norstar. As you can see I am getting a lot of help from the carrier.

Dan Schollian

http://www.incomminc.com

 

[DigitelD]

Here is an explanation of Q931:

Q.931 (also called Q931) is a signaling protocol for Integrated Services Digital Network (ISDN) communications that is used in voice over IP (VoIP). The Q.931 protocol is involved in the setup and termination of connections.
Q.931 is used to transmit and receive call signaling messages according to the H.225 protocol for digital telephone services. The messages in Q.931 include setup (a signal indicating the establishment of a connection), call-proceeding (a signal indicating that the call is being processed by the destination terminal), ring-alert (a signal that tells the calling party that the destination set is ringing), connect (a signal sent back to the source indicating that the intended destination phone set has received the call), and release/complete (a signal sent by either the source or the destination indicating that the call is to be terminated).

 

[dnsincomminc]

Thanks for the info, but do you know why they would say that the call is being rejected because the switch is set to DTMF/Wink? And is there a setting in hardware to set the signaling to Q.931 on the Norstar?

Dan Schollian

http://www.incomminc.com