Mitel 3300 suddenly stopped allowing extensions to dial externally or be contacted via external # 1

[jexter13]

Hi Guys,

We've been faced with a strange issue and according to our carrier, the problem lies in house. We are no longer able to make or receive external calls back into our Mitel 3300 system. The controller has a BRI card in it and an ISDN service from the carrier. There was recently some software patching done from the carrier in the region (This is in Kuala Lumpur) which saw an outage occur around the area - this is apparently resolved now.

Unfortunately I am not amazing at this phone system and from what I can see, it doesn't seem to be showing anything in the error logs and after doing a continuous CSS trace on the controller this is the activity I saw on it but I wasn't sure exactly how to interpret it to find the particular fault.

Any help would be greatly appreciated - I do know my way around the system and it has been fairly fault free.


CCS Tracing is enabled for continuous output display

BRI VDsu-3 Mod 1 Port 3 - TUE APR 08 13:50:36 2014
CI 78 1 8011 a659600 5 0 a1ef142 CRM |C:30H|


BRI VDsu-3 Mod 1 Port 3 - TUE APR 08 13:50:36 2014
CO -145 1 f2 8011 0xa659600 7 0 UAPI_DISCON_REQ
(SEND...BRI-Usr - NET3 - EURO) P_Id:0xa659600 C_Id:8011 TotLen:7(Exp + Raw), PrLen:7
Private IE's:
Cause 0,8, 4,80,80,80, 90 Normal Call Clearing


BRI VDsu-3 Mod 1 Port 3 - TUE APR 08 13:50:36 2014
CI 34 1 f2 8011 0xa659600 7 0 UAPI_DISCON_CONF
(RECD...BRI-Usr - NET3 - EURO) P_Id:0xa659600 C_Id:8011 TotLen:0(Exp + Raw), PrLen:0
Private IE's:


BRI VDsu-3 Mod 1 Port 3 - TUE APR 08 13:50:36 2014
CO -53 1 8011 a659600 7 0 a1ed1f8 CRM |C:30H|

13:50:36 RO26 DPN 2 CRM/CIM ;30;
13:50:36 RI26 DPN 2 CRM/CIM ;30;
13:53:20 RI23 DPN 1A ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#
13:53:20 RI23 DPN 1D SSRM_I *50*000061429057232#62038055
13:53:20 RO23 DPN 2 CRM/CIM ;0;
13:53:21 RI23 DPN 2 CRM/CIM ;0;
13:53:52 RI24 DPN 1A ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#
13:53:52 RI24 DPN 1D SSRM_I *50*000061429057232#62038055
13:53:52 RO24 DPN 2 CRM/CIM ;0;
13:53:53 RI24 DPN 2 CRM/CIM ;0;

BRI VDsu-3 Mod 1 Port 3 - TUE APR 08 13:55:51 2014
CI 35 3 f2 27 0xa64d0a8 12 12 UAPI_CON_IND
(RECD...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:79(Exp + Raw), PrLen:48
Private IE's:
Bearer Cap. 0,4,a,80,80,80,90,0,0,0,0,0,83,
Channel Id 0,18,4,80,81,80,82, (Channel 2)
Calling Num 0,6c,c,80,81,80,83, digits - 20315246
Called Num 0,70,a,84,81, digits - 62038022
Public IE's:
Bearer Cap. 4,3,80 (SPEECH),90,a3,
Channel Id 18,1,8a,
Calling Num 6c,a,1,83,20315246
Called Num 70,9,c1,62038022


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -15 3 27 a64d0a8 1 0 a1ef8fe FN_ORIGINATE


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CI 20 3 27 a64d0a8 1 0 a1ebbd2 FN_POS_ACK 20 2b 0e 16 0e


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -54 3 27 a64d0a8 2 0 a1eb7f4 ISRM_I |S:10H|*3#*233*`IBc#*58*CI*W6a#*50*0020315246#


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -55 3 27 a64d0a8 2 0 a1ebac4 SSRM_I 62038022


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -150 3 f2 27 0xa64d0a8 2 0 UAPI_EVENT_REQ
(SEND...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:15(Exp + Raw), PrLen:15
Private IE's:
EventType ff,0,1, API_EVENT_TYPE_SETUP_ACK
Inversion ff,10,1,1,
Channel Id 0,18,4,80,81,80,82, (Channel 2)


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CI 79 3 27 a64d0a8 2 0 a1eba6a CRM |C:0H|


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -151 3 f2 27 0xa64d0a8 7 0 UAPI_DISCON_REQ
(SEND...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:7(Exp + Raw), PrLen:7
Private IE's:
Cause 0,8, 4,80,80,80, 81 Unallocated (unassigned) number


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:52 2014
CI 36 3 f2 27 0xa64d0a8 7 0 UAPI_DISCON_CONF
(RECD...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:0(Exp + Raw), PrLen:0
Private IE's:


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:52 2014
CO -56 3 27 a64d0a8 7 0 a1ebf56 CRM |C:0H|

13:55:51 RI28 DPN 29 ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#*50*0020315246#
13:55:51 RI28 DPN 9 SSRM_I 62038022
13:55:51 RO28 DPN 2 CRM/CIM ;0;
13:55:52 RI28 DPN 2 CRM/CIM ;0;
13:57:19 RIX DPN PBX4 9 172 D** B** 23 ISRM_I
;10;*3#*233*`IBc#*58*CI*W6a#*238*dXD#
13:57:19 RIX DPN PBX4 9 172 D** B** 20 SSRM_I
*50*00892286878#*19*L#*58*CO*B#
13:57:19 RIX DPN PBX4 9 172 D** B** 27 SSRM_C
*58*CW*^yDg@@@@Eef;7F;7E;@#*58*CQ*00#577335
13:57:19 ROX DPN PBX4 9 172 D** B** 1D NAM
*1#*50*570335#*100*M.Room*1#
13:57:48 RIX DPN PBX4 9 172 D** B** F CRM/CIM ;30;*166*1 2 3 4#
13:57:51 RIX DPN PBX4 10 173 D** B** 23 ISRM_I
;10;*3#*233*`IBc#*58*CI*W6a#*238*dXD#
13:57:51 RIX DPN PBX4 10 173 D** B** 20 SSRM_I
*50*00892286878#*19*L#*58*CO*B#
13:57:51 RIX DPN PBX4 10 173 D** B** 27 SSRM_C
*58*CW*^yDg@@@@EegB`@#*58*CQ*00#577333
13:57:51 ROX DPN PBX4 10 173 D** B** 1D NAM
*1#*50*570333#*100*A.Port*1#
13:58:07 RO21 DPN 23 ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#*238*dXD#
13:58:07 RO21 DPN 20 SSRM_I *50*00892286878#*19*L#*58*CO*B#
13:58:07 RO21 DPN 21 SSRM_I *58*CW*^yDg@@@@EegB`@#*58*CQ*00#
13:58:07 RO21 DPN 27 SSRM_I *58*CE*C*570333*A.Port#*58*C4*1*01*01#
13:58:07 RO21 DPN 15 SSRM_C *58*C6*001#193118641
13:58:07 RI21 DPN 7 NIM *51*3#
13:58:08 RI21 DPN F NIM *4*4#*240*`X`#
13:58:08 RI21 DPN 13 NAM *4*4#*166*1 2 3 4#
13:58:08 RI21 DPN A CCM *58*CP*G#
13:58:08 ROX DPN PBX4 10 173 D** B** A CCM *58*CP*G#
13:59:18 RI21 DPN F CRM/CIM ;30;*166*1 2 3 4#
13:59:18 ROX DPN PBX4 10 173 D** B** F CRM/CIM ;30;*166*1 2 3 4#
13:59:19 RIX DPN PBX4 10 173 D** B** F CRM/CIM ;30;*166*1 2 3 4#

 

[LoopyLou]

No familiarity with BRI connections on a 3300 but would disconnect the circuit from the 3300 wait 30 seconds and plug it back in.

An apple a day keeps the doctor away. Anyone else and you need to throw it harder.

 

[isrm]

Jexter,

Can I assume this is the call that no longer works?

13:53:20 RI23 DPN 1A ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#
13:53:20 RI23 DPN 1D SSRM_I *50*000061429057232#62038055
13:53:20 RO23 DPN 2 CRM/CIM ;0;

The incoming number being dialled is 62038055 - the trunk attributes (trunk service in older loads) needs to absorb at least 1 digit as the system can only route on 7 digits. The remaining digits need to translate to a valid DN in the system. Typically, admins point the incoming digits to a speedcall and then that number points to a DN in the system.

ISRM

 

[jexter13]

Hi Guys,

Thanks for getting back to me.

ISRM - yes, that call does not work.

We have now had an update from the carrier and they now claim they have upgraded the ISDN services so our controller is now presented with 8 digits from the service but our controller is configured to only receive 4.

Where abouts would I find this if you think this would be a logical reasoning for the system to still not be able to make/receive external calls? I've looked at System Config -> Trunks -> Digital Trunks -> ISDN-BRI -> Trunk Service Assignment

There are two trunks labelled BRI A / BRI B and the Dial in Trunks Incoming Digit Modification - Absord is set to 3 and the Insert is set to 2, but I am reluctant to change this.

If there are any other details I can fish out of the system for you to take a look at, please let me know.

Many thanks in advance.

 

[jexter13]

Email from the phone carrier company (might be of some assistance)

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

Upon checking, we’ve found out that the call in to the ISDN BRI is failing due to mismatch of receiving digit. Previously, the receiving digit at Mitel controller was set to last 4 digit. At present (after upgrading) TM is sending full digit (8-digit) according to standard setup & policy (snapshot below).

Appreciate if you can convey this message to your vendor/support team, so that the equipment can be re-configured to receive all 8 digit numbers (instead of 4) from TM.

Thank you.

Incoming call to Mitel controller:

BRI VDsu-3 Mod 1 Port 3 - TUE APR 08 13:55:51 2014
CI 35 3 f2 27 0xa64d0a8 12 12 UAPI_CON_IND
(RECD...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:79(Exp + Raw), PrLen:48
Private IE's:
Bearer Cap. 0,4,a,80,80,80,90,0,0,0,0,0,83,
Channel Id 0,18,4,80,81,80,82, (Channel 2)
Calling Num 0,6c,c,80,81,80,83, digits - 20315246 #A number
Called Num 0,70,a,84,81, digits - 62038022 #B number
Public IE's:
Bearer Cap. 4,3,80 (SPEECH),90,a3,
Channel Id 18,1,8a,
Calling Num 6c,a,1,83,20315246
Called Num 70,9,c1,62038022


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -15 3 27 a64d0a8 1 0 a1ef8fe FN_ORIGINATE


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CI 20 3 27 a64d0a8 1 0 a1ebbd2 FN_POS_ACK 20 2b 0e 16 0e


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -54 3 27 a64d0a8 2 0 a1eb7f4 ISRM_I |S:10H|*3#*233*`IBc#*58*CI*W6a#*50*0020315246#


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -55 3 27 a64d0a8 2 0 a1ebac4 SSRM_I 62038022


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -150 3 f2 27 0xa64d0a8 2 0 UAPI_EVENT_REQ
(SEND...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:15(Exp + Raw), PrLen:15
Private IE's:
EventType ff,0,1, API_EVENT_TYPE_SETUP_ACK
Inversion ff,10,1,1,
Channel Id 0,18,4,80,81,80,82, (Channel 2)


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CI 79 3 27 a64d0a8 2 0 a1eba6a CRM |C:0H|


BRI VDsu-3 Mod 1 Port 4 - TUE APR 08 13:55:51 2014
CO -151 3 f2 27 0xa64d0a8 7 0 UAPI_DISCON_REQ
(SEND...BRI-Usr - NET3 - EURO) P_Id:0xa64d0a8 C_Id:27 TotLen:7(Exp + Raw), PrLen:7
Private IE's:
Cause 0,8, 4,80,80,80, 81 Unallocated (unassigned) number

 

[sarond]

Incoming should be fixed by your Trunk Attributes.
You now need to absorb the appropriate number of digits, 4 in your case.
If you are being presented 8 then this will absorb 4 so you using 4 digits.

Not sure of outgoing as this should affect it.

 

[sarond]

Just re-read through some of this post.
Don't take my advise yet.

You will need to change Trunk Service Assignment to get incoming calls working if they a presenting a different number of digits to what they were previously.
It sounds like you are inserting a 2 to match you directory numbers, is your extension range 2xxx? Is your extension range 4 digits long?
Do you have a range of DDI's?

 

[jexter13]

I've tried adjusting the trunk service assignment in regards to absorbing digits but it still doesn't seem to work unfortunately. I must not be adjusting the fields correctly in regards to the number of digits being absorbed, although i've tried many different combinations.

The extension range in the office is 3 digits and is 3xx. By DDI's do you mean a number range assigned to us from the carrier? If so, then yes - there is a number range assigned to us.

Everything was all working great up until there was an outage in the area and then an 'upgrade' was amended to the telco's service and now the tech is implicit that our controller is only set to receive 4 digits on the controller as opposed to 8.

Thanks for your help.

 

[Waldosworld]

Can you make outbound calls?
If not, the carrier has done more in their "upgrade" than just change the number of digits being presented to the system otherwise outbound calls would not have been affected.

 

[isrm]

Jexter,

62038022 is the called number and you said the extensions are 3 digits in length. If this is the case then absorbing 5 digits will leave you with 022. Is this a valid DN in the system? Meaning, is 022 a valid extension number? If not then you should have a speedcall that translates to 022 and the actual digits can point to an extension.

ISRM

 

[sarond]

Easiest way to test is not to worry about the absorbing and inserting, delete these and set the non-dial in answer point for day and night1/2 as quick test.
Also make sure you are working on the correct 'Trunk Service Assignment' if you look at the Digital Trunk Assignment it will tell you what Trunk Service they are using.

 

[jexter13]

Hi Guys,

Update to the situation - the carrier has fixed the service in regards to external calls being made and that is now working correctly and seems to be attaching itself to the correct extensions.

Sarond, I tried setting the non-dial answer point for day and night1/2 as an extension and it went through ok. What does this mean needs changing?

Thanks!

 

[jexter13]

Here is the CCS trace after doing this

12:51:09 RI23 DPN F CRM/CIM ;30;*166*1 2 3 4#
12:51:09 RO26 DPN F CRM/CIM ;30;*166*1 2 3 4#
12:51:10 RI26 DPN F CRM/CIM ;30;*166*1 2 3 4#
12:51:22 RI24 DPN 1A ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#
12:51:22 RI24 DPN 1D SSRM_I *50*000061288791610#62038055
12:51:22 RO24 DPN 24 NAM *1#*50*570333#*166*6#*100*A.Port*1#
12:51:37 RO21 DPN 1A ISRM_I ;10;*3#*233*`IBc#*58*CI*W6a#
12:51:37 RO21 DPN 2C SSRM_I *50*000061288791610#*58*CE*C*570333*A.Port#
12:51:37 RO21 DPN 26 SSRM_I *58*C4*1*01*01#*58*CW*o_Pj@@@@@JDzMp#
12:51:37 RO21 DPN 15 SSRM_C *58*C6*001#193118641
12:51:38 RI21 DPN 7 NIM *51*3#
12:51:40 RI24 DPN F CRM/CIM ;30;*166*1 2 3 4#
12:51:40 RO21 DPN F CRM/CIM ;30;*166*1 2 3 4#

 

[sarond]

You will have to find out what you need to absorb/insert.
From a previous post it sounds like there is a 2 being inserted, are there entries in you speed calls that direct to extensions?
If you were absorbing 3 digits before and you were being presented 4 and then you insert a '2' it means that the dialable number on the Mitel would be 2x. Does this sound right? It doesn't to me.

If I wanted to send a call to 3xx and was being presented 8 digits, I would absorb 6 and insert 3.
But as mentioned by ISRM check your speed calls.

By using the non-dial in settings you are ignoring what is being presented and just accepting calls on the link/channel.

 

[jexter13]

Hi Sarond,

Changing it to absorb 6 and insert 3 worked a treat! Thankyou!!!

The fax still is not functioning, but I think that might be a seperate issue.

Thanks everyone for all your help - extremely appreciated.

Thanks again.

Jexter

 

[jexter13]

Hi,

I'm not sure if i should start a new thread with this, but it is still a part of the same issue.

All the inbound and outbound external calls are now fine, but the fax is not working and the carrier says we need to adjust the bearer capability/transmission medium to 3.1Khz (Audio) as it is currently set to SPEECH

Any suggestions where I might find this hidden away in the Mitel system?

Thanks again

Jexter