We have multiple sites with the Mitel 5000. Lately, we are experiencing multiple issues at various locations. Once the D channel is reset, all is well for a while. This has increased in frequency over the past month. We have PRIs going into our Mitel 5000s and unfortunately, we do have different versions of software on the various 5000s. This is only happening at the sites with Mitel and Verizon. It is intermittent and can happen at several sites that are all serviced by different Verizon central offices. Verizon states they have made no changes in their environment. There have been no changes to the Mitel equipment. All of a sudden we are having an issue with a release message.
The issue stems from a rare disconnect (Its valid but its rare it happens) that comes in to the 5000 from the Verizon CO.
In short, the call rings into the 5000 and during the call setup (seems to be right at the facility_ind message, that gets caller name information) The 5000 gets a disconnect message that the circuit is no longer available. While the 5000 does not respond correctly to this message, 4 seconds later Verizon sends us a message to clear the channel and the 5000 respond back that its ok to do that.
At this time the call is in the voicemail system and setting up routing to a destination to a end user on the 5000 and call processing blocks this message. This now causes a scenario where we have told Verizon that the channel is clear when it really is not. They then proceed to send another call.
Mitel is writing a patch to handle this but I was wondering if anyone else is having this issue where nothing has changed in their environment and have Verizon PRI telco.
Log from one location with notes from Mitel.
Failure somewhere upstream of Telco and they send us a disconnect message
(9298): //RCVD----ISDN 33 01 01 00 00 02 81 07 00 08 04 00 00 00 A2
(9299): // Message ID: DISC_IND
(9310): // Cause: NO_CIRCUIT_AVAILABLE
(9311): // [0281] <= DISC_IND: NO_CIRCUIT_AVAILABLE
The disconnect is then sent to the connected call that is on Channel 1 in voicemail right now
(9317): //STATE---{DISC_IND} Sent to <connected_trs_t>
The message is blocked to VM
(9336): //MSG-----Message Enqueued: {connect_request} from (1:'@0079') to (1:'2550')
(9344): //STATE---Message was BLOCKED: {connect_request}
(9408): //MSG-----Message Enqueued: {connect_ack} from (1:'2550') to (1:'@0079')
(9410): //MSG-----{connect_ack} Received by 'Call' (1:'@0079') from (1:'2550')
(9412): //MSG-----Message Enqueued: {connect_ack} from (1:'@0079') to (1:'90101')
(9427): //MSG-----{connect_ack} Received by 'Trunk Device' (1:'90101') from (1:'@0079')
(9428): //MSG-----{connect_ack} Received by 'Physical Device' (1:'90101') from (1:'@0079')
Telco (verizon) sends us a request to clear the channel
(10837): //RCVD----ISDN 06 01 01 00 00 02 81 07 00 08 04 80 82 00 E6
(10838): // Message ID: CLEAR_IND
(10846): // Coding Standard: CCITT_STANDARD
(10856): //STATE---{CLEAR_IND} Sent to <connected_trs_t>
(10857): //MSG-----Message Enqueued: {CLEAR_RESP} from (1:'90101') to (1:'PP015')
(10858): //MSG-----Message Enqueued: {connect_request} from (1:'90101') to (1:'@0079')
(10860): //STATE---<connected_trs_t> Returned NOKILL
(10861): //STATE---Removing state <connected_trs_t>
(10871): //TIME----10:15:32 6-26
Here we then tell the telco that the call can be cleared (but we still hold the channel up in voicemail)
(10873): //SENT----ISDN 08 01 01 00 00 02 81 07 00 08 04 80 80 80 90
(10874): // Message ID: CLEAR_RESP
(10877): // Call ID: 0281
(10915): //MSG-----{connect_ack} Received by 'Trunk Device' (1:'90101') from (1:'@0079')
(10916): //MSG-----{connect_ack} Received by 'Physical Device' (1:'90101') from (1:'@0079')
A new call is then sent by Telco on Channel 1 and we clear this since we still have the channel held up in voicemail
(11954): //RCVD----ISDN 1B 01 01 00 00 02 84 71 00 04 0A 80 90 80 90 00 00 00 00 00 82 00 (11960): // Message ID: SETUP_IND
(11963): // Call ID: 0284
(11970): // Info Element: CHANNEL_ID_IE
(11971): // Data: 81 80 80 81 00 00 80 03 00 00 01
(11989): // Data: 82 81 33 30 31 37 37 34 35 36 35 32
(11990): // [0284] <= SETUP_IND: [1] 3.1K '3017745652' '3012601256' cname_following
(11992): //MSG-----{SETUP_IND} Received by 'Trunk Device' (1:'90101') from (1:'PP015')
(11993): //MSG-----{SETUP_IND} Received by 'Physical Device' (1:'90101') from (1:'PP015')
(12001): //MP------01:191- 10:15 06-26 *** default_trs_t::ti_setup_ind - We received a setup request for a new call while we were on a call.
(12014): //SENT----ISDN 07 01 01 00 08 02 84 07 00 08 04 80 80 80 90
(12015): // Message ID: CLEAR_REQ
(12018): // Call ID: 0284
The original call on channel 1 is finally released
//(12760): //MSG-----Message Enqueued: {release_request} from (1:'90101') to (1:'@0079')
(12852): //TIME----10:15:39 6-26
//(12854): //MSG-----{release_request} Received by 'Call' (1:'@0079') from (1:'90101')
(201449): //MP------01:609- 10:52 06-26 *** <=============================================
Verizon resets D channel on PRI and issue's clear
(201450): //MP------01:610- 10:52 06-26 *** Message ID: MANAGEMENT_IND DSL ID: 01
(201455): //MP------01:615- 10:52 06-26 *** Info Elem: HOST_MANAGEMENT_IE IE Length: 01
The issue stems from a rare disconnect (Its valid but its rare it happens) that comes in to the 5000 from the Verizon CO.
In short, the call rings into the 5000 and during the call setup (seems to be right at the facility_ind message, that gets caller name information) The 5000 gets a disconnect message that the circuit is no longer available. While the 5000 does not respond correctly to this message, 4 seconds later Verizon sends us a message to clear the channel and the 5000 respond back that its ok to do that.
At this time the call is in the voicemail system and setting up routing to a destination to a end user on the 5000 and call processing blocks this message. This now causes a scenario where we have told Verizon that the channel is clear when it really is not. They then proceed to send another call.
Mitel is writing a patch to handle this but I was wondering if anyone else is having this issue where nothing has changed in their environment and have Verizon PRI telco.
Log from one location with notes from Mitel.
Failure somewhere upstream of Telco and they send us a disconnect message
(9298): //RCVD----ISDN 33 01 01 00 00 02 81 07 00 08 04 00 00 00 A2
(9299): // Message ID: DISC_IND
(9310): // Cause: NO_CIRCUIT_AVAILABLE
(9311): // [0281] <= DISC_IND: NO_CIRCUIT_AVAILABLE
The disconnect is then sent to the connected call that is on Channel 1 in voicemail right now
(9317): //STATE---{DISC_IND} Sent to <connected_trs_t>
The message is blocked to VM
(9336): //MSG-----Message Enqueued: {connect_request} from (1:'@0079') to (1:'2550')
(9344): //STATE---Message was BLOCKED: {connect_request}
(9408): //MSG-----Message Enqueued: {connect_ack} from (1:'2550') to (1:'@0079')
(9410): //MSG-----{connect_ack} Received by 'Call' (1:'@0079') from (1:'2550')
(9412): //MSG-----Message Enqueued: {connect_ack} from (1:'@0079') to (1:'90101')
(9427): //MSG-----{connect_ack} Received by 'Trunk Device' (1:'90101') from (1:'@0079')
(9428): //MSG-----{connect_ack} Received by 'Physical Device' (1:'90101') from (1:'@0079')
Telco (verizon) sends us a request to clear the channel
(10837): //RCVD----ISDN 06 01 01 00 00 02 81 07 00 08 04 80 82 00 E6
(10838): // Message ID: CLEAR_IND
(10846): // Coding Standard: CCITT_STANDARD
(10856): //STATE---{CLEAR_IND} Sent to <connected_trs_t>
(10857): //MSG-----Message Enqueued: {CLEAR_RESP} from (1:'90101') to (1:'PP015')
(10858): //MSG-----Message Enqueued: {connect_request} from (1:'90101') to (1:'@0079')
(10860): //STATE---<connected_trs_t> Returned NOKILL
(10861): //STATE---Removing state <connected_trs_t>
(10871): //TIME----10:15:32 6-26
Here we then tell the telco that the call can be cleared (but we still hold the channel up in voicemail)
(10873): //SENT----ISDN 08 01 01 00 00 02 81 07 00 08 04 80 80 80 90
(10874): // Message ID: CLEAR_RESP
(10877): // Call ID: 0281
(10915): //MSG-----{connect_ack} Received by 'Trunk Device' (1:'90101') from (1:'@0079')
(10916): //MSG-----{connect_ack} Received by 'Physical Device' (1:'90101') from (1:'@0079')
A new call is then sent by Telco on Channel 1 and we clear this since we still have the channel held up in voicemail
(11954): //RCVD----ISDN 1B 01 01 00 00 02 84 71 00 04 0A 80 90 80 90 00 00 00 00 00 82 00 (11960): // Message ID: SETUP_IND
(11963): // Call ID: 0284
(11970): // Info Element: CHANNEL_ID_IE
(11971): // Data: 81 80 80 81 00 00 80 03 00 00 01
(11989): // Data: 82 81 33 30 31 37 37 34 35 36 35 32
(11990): // [0284] <= SETUP_IND: [1] 3.1K '3017745652' '3012601256' cname_following
(11992): //MSG-----{SETUP_IND} Received by 'Trunk Device' (1:'90101') from (1:'PP015')
(11993): //MSG-----{SETUP_IND} Received by 'Physical Device' (1:'90101') from (1:'PP015')
(12001): //MP------01:191- 10:15 06-26 *** default_trs_t::ti_setup_ind - We received a setup request for a new call while we were on a call.
(12014): //SENT----ISDN 07 01 01 00 08 02 84 07 00 08 04 80 80 80 90
(12015): // Message ID: CLEAR_REQ
(12018): // Call ID: 0284
The original call on channel 1 is finally released
//(12760): //MSG-----Message Enqueued: {release_request} from (1:'90101') to (1:'@0079')
(12852): //TIME----10:15:39 6-26
//(12854): //MSG-----{release_request} Received by 'Call' (1:'@0079') from (1:'90101')
(201449): //MP------01:609- 10:52 06-26 *** <=============================================
Verizon resets D channel on PRI and issue's clear
(201450): //MP------01:610- 10:52 06-26 *** Message ID: MANAGEMENT_IND DSL ID: 01
(201455): //MP------01:615- 10:52 06-26 *** Info Elem: HOST_MANAGEMENT_IE IE Length: 01
