Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - MrNitch

Pages: [1] 2 3
1
MiVoice Office 250/Mitel 5000 / Re: 5000HX 5.1 Email Gateway to O365
« on: April 27, 2021, 09:15:33 AM »
Thank you!

2
MiVoice Office 250/Mitel 5000 / 5000HX 5.1 Email Gateway to O365
« on: April 23, 2021, 09:45:14 AM »
Does anyone know if version 5.1 is able to send to O365 servers directly? As of the 14th of this month all 4 that I manage have stopped forwarding and I am thinking Microsoft deprecated some TLS or some other security protocols that the PBX is using to send the voicemails via SMTP. A sample of our email log is below.


Apr 19 12:30:10 Mitel5000 exim[28426]: 1lYXXW-0008Pk-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.46.36] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 12:30:10 Mitel5000 exim[28426]: 1lYXXW-0008Pk-00 failure while setting up TLS session
Apr 19 12:30:10 Mitel5000 exim[28426]: 1lYXXW-0008Pk-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.73.138] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 12:30:10 Mitel5000 exim[28426]: 1lYXXW-0008Pk-00 failure while setting up TLS session
Apr 19 12:30:10 Mitel5000 exim[28426]: 1lYXXW-0008Pk-00 == facome@centuryac.com T=remote_smtp defer (-38): failure while setting up TLS session
Apr 19 13:00:10 Mitel5000 exim[3594]: 1lYXXW-0008Pk-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.73.10] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 13:00:10 Mitel5000 exim[3594]: 1lYXXW-0008Pk-00 failure while setting up TLS session
Apr 19 13:00:10 Mitel5000 exim[3594]: 1lYXXW-0008Pk-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.74.10] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 13:00:10 Mitel5000 exim[3594]: 1lYXXW-0008Pk-00 failure while setting up TLS session
Apr 19 13:00:10 Mitel5000 exim[3594]: 1lYXXW-0008Pk-00 == facome@centuryac.com T=remote_smtp defer (-38): failure while setting up TLS session
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.44.36] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 failure while setting up TLS session
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.74.10] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 failure while setting up TLS session
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 == email@mydomain.com T=remote_smtp defer (-38): failure while setting up TLS session
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 ** email@mydomain.com: retry timeout exceeded
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 Process failed (69) when writing error message to visualmail@mydomain.com
Apr 19 13:30:10 Mitel5000 exim[11229]: 1lYXXW-0008Pk-00 Completed
Apr 19 14:29:28 Mitel5000 exim[24679]: 1lYZaI-0006Q3-00 <= visualmail@mydomain.com U=root P=local S=226218 T="[0:21] Message for MB 11262 from a caller at (333) 333-9302"
Apr 19 14:29:29 Mitel5000 exim[24774]: 1lYZaI-0006Q3-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.73.138] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 14:29:29 Mitel5000 exim[24774]: 1lYZaI-0006Q3-00 failure while setting up TLS session
Apr 19 14:29:29 Mitel5000 exim[24774]: 1lYZaI-0006Q3-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.46.36] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 14:29:29 Mitel5000 exim[24774]: 1lYZaI-0006Q3-00 failure while setting up TLS session
Apr 19 14:29:29 Mitel5000 exim[24774]: 1lYZaI-0006Q3-00 == email@mydomain.com T=remote_smtp defer (-38): failure while setting up TLS session
Apr 19 14:30:10 Mitel5000 exim[26475]: 1lYZaI-0006Q3-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.73.138] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 14:30:10 Mitel5000 exim[26475]: 1lYZaI-0006Q3-00 failure while setting up TLS session
Apr 19 14:30:11 Mitel5000 exim[26475]: 1lYZaI-0006Q3-00 TLS error on connection to mydomain.mail.protection.outlook.com [104.47.73.10] (SSL_connect): error:00000000:lib(0):func(0):reason(0)
Apr 19 14:30:11 Mitel5000 exim[26475]: 1lYZaI-0006Q3-00 failure while setting up TLS session
Apr 19 14:30:11 Mitel5000 exim[26475]: 1lYZaI-0006Q3-00 == email@mydomain.com T=remote_smtp defer (-38): failure while setting up TLS session


Thank you
Kenny

3
MiVoice Office 250/Mitel 5000 / Re: Keeping a spare 5000 on the shelf
« on: January 16, 2020, 05:59:58 PM »
I have spare boxes setup at my core locations but the licensing does not follow so in the DR instance your PBX will restart every 4 hours I believe is the timer. For DR we have considered that acceptable while I get the hardware replaced or the license moved to the new box. Some of my locations have the PBX on and live just at a different IP and not connected to anything, this will save me a plane ticket and or very long and frustrating conversation with someone while talking them through flipping cards and cables.


Thank you

4
MiVoice Office 250/Mitel 5000 / Re: Huntgroup priority
« on: June 29, 2018, 08:59:53 AM »
Yes that does make sense, and is how we have it setup and is how it is working. I did not realize that it would not push infront of a call that was already ringing on a device though. I will explain it to the user.

Thank you!

5
MiVoice Office 250/Mitel 5000 / Huntgroup priority
« on: June 28, 2018, 05:40:56 PM »
Good afternoon everyone.

I have Huntgroups A, B, C and Z and recall huntgroups for each of A-C

Each huntgroup has an extension list of a group of separate phones.
Each Recall huntgroup has an extension list consisting of the same group of phones plus the group of phones in huntgroup/extension list Z

I have set the Huntgroup Z to have a priority of 50 while the rest have a 0 priority.

When Huntgroup A has a call and it rolls over to the Recall huntgroup that includes the Z phones, while that call is ringing on it, and someone calls directly to the Z Huntgroup it stuck behind the Huntgroup A recall.

I would like all calls directly to the Z huntgroup to push to the front of the Z phones queue. Is there a different way I should be attempting this.



Thank you
Kenny

6
I just caught that we had packet inspection hitting this data. This has now been disabled. I am still working on catching the error and what call it is associated with.

7
Will do thank you!

8
Hey Guys I am getting a report of an entire huntgroup of phones doing a burst ring, similar to the online notification the phone will do but none stop until they reforward an endpoint that is currently forwarding all calls to them. During this time the logs have some events I am not familiar with as well. They are below time stamped at 9:06 and 15:12. I thought this was a network issue and am still pursuing that route but wanted to see if anyone had seen these messages before.

So 29200 is a huntgroup of 10 or so phones and receives all of it calls via a 8620 IP Phone that is set to forward all calls to 29200. At 9:06 all of the endpoints in 29200 [they are all 8620's as well] started doing a burst ring and when picking up the handsets there was no call to answer.

The slip errors you see are on a PRI card that is not in production and is not handling any live calls currently just prepped for testing a new circuit.

-10:778- > -10:559- 08:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:560- 09:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:561- 09:06 08-22 *** void call_t::set_device_info(const cp_id_t&, call_device_info_t*, const cp_id_t&) Null Call Control ID
-10:778- > -10:562- 09:06 08-22 *** Message not processed in state_machine_t:
-10:778- > -10:563- >      To Extension:  '29200'
-10:778- > -10:564- >    From Extension:  '@01*F'
-10:778- > -10:565- >          Category:  0x01
-10:778- > -10:566- >              Type:  0x0106
-10:778- > -10:567- >              Name:  {campon_t}
-10:778- > -10:568- 10:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:569- 10:10 08-22 M2002 INF HW CP [1.14.0]: Off-Line From Digital Keyset Port
-10:778- > -10:570- 10:10 08-22 M2002 INF HW CP [1.14.1]: Off-Line From Digital Keyset Device
-10:778- > -10:571- 10:13 08-22 M2002 INF HW CP [1.14.0]: On-Line From Digital Keyset Port
-10:778- > -10:572- 10:13 08-22 M2006 INF HW CP [1.14.0]: Power-Up From Digital Keyset Port [E4,00,01]
-10:778- > -10:573- 10:13 08-22 M2002 INF HW CP [1.14.1]: On-Line From Digital Keyset Device
-10:778- > -10:574- 11:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:575- 13:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:576- 13:43 08-22 M2037 INF HW CP Closed IP LINK To node 12 - Reason(701): Socket timed out
-10:778- > -10:577- 13:45 08-22 M2036 INF HW CP Established IP LINK To node 12
-10:778- > -10:578- 14:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:579- 14:26 08-22 A010 ALARM  '12001' - 200CTR1 Is Off Hook
-10:778- > -10:580- 14:27 08-22 A000 ALARM  Alarm Automatically Cleared
-10:778- > -10:581- 15:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:582- 15:04 08-22 A010 ALARM  '12052' - 205CTR2 Is Off Hook
-10:778- > -10:583- 15:12 08-22 *** void call_t::set_device_info(const cp_id_t&, call_device_info_t*, const cp_id_t&) Null Call Control ID
-10:778- > -10:584- 15:12 08-22 *** Message not processed in state_machine_t:
-10:778- > -10:585- >      To Extension:  '29255'
-10:778- > -10:586- >    From Extension:  '@0136'
-10:778- > -10:587- >          Category:  0x01
-10:778- > -10:588- >              Type:  0x0106
-10:778- > -10:589- >              Name:  {campon_t}
-10:778- > -10:590- 15:13 08-22 A000 ALARM  Alarm Automatically Cleared
-10:778- > -10:591- 16:01 08-22 M5086 WRN HW CP Hourly Threshold For Controlled Slips Errors Exceeded on T1/PRI Port [3.1.0]
-10:778- > -10:592- 16:12 08-22 A010 ALARM  '12507' - 250CTR7 Is Off Hook
-10:778- > -10:593- 16:14 08-22 A000 ALARM  Alarm Automatically Cleared


Thank you
Kenny

9
MiVoice Office 250/Mitel 5000 / Re: Weird Ring
« on: January 30, 2017, 09:24:10 AM »
I haven't had an issue since AT&T repaired the internet issue, I will upload the repaired database tonight.

Thank you

10
MiVoice Office 250/Mitel 5000 / Re: Weird Ring
« on: January 30, 2017, 09:23:22 AM »
So I regularly do this from time to time when I issues but I didn't think to for this. I have reoccurring errors as well that I tend to see every time and below are them. I never read them to the end, they say DevID which looks similar to the devices in the errors. I blow them off since they say SIP and we are not SIP. I also found that the internet side of the T1 that the PRI handoff was coming in on was very dirty intermittently, I feel perhaps that may have been corrupting the call data some how, does that sound far fetched?


[PageZoneDevices]/[device_id] contains a reference to a device of the wrong type [DevID:52, Type:572]   Deleted record
[SIPMBDevices]/[sip_device_id] contains a reference to a device of the wrong type [DevID:1167, Type:201]   Deleted record
[SIPMBDevices]/[sip_device_id] contains a reference to a device of the wrong type [DevID:1175, Type:201]   Deleted record

Thank you
Kenny

11
MiVoice Office 250/Mitel 5000 / Re: Weird Ring
« on: January 27, 2017, 05:55:33 PM »


Do you see all of the calls this way or only the ones that show up as unanswerable with an IC ring pattern?



The only time we have seen them is when the calls is unanswerable.


They are coming in over those trunks as you said which are provided via PRI and handed to huntgroups which include those extensions listed [plus others, all of which get the same ring and are unable to answer]
Normally when the call is handed off and answerable it just states Device type IP-EP like the expanded call w/ details on the right.

Thank you
Kenny

12
MiVoice Office 250/Mitel 5000 / Weird Ring
« on: January 27, 2017, 09:59:24 AM »
Anyone familiar with a Device type DEV XXXX [random numbers] for incoming calls? The users are saying the call was not answerable when lifting the handset and had the IC ring pattern.

Thank you
Kenny

13
MiVoice Office 250/Mitel 5000 / Re: Paging Zone Limit
« on: January 26, 2017, 09:23:12 AM »
Thanks Hovus! I agree that is a risky change, since I have another 5000HX version and database config very similar in size and setup that is very stable for the past 5 years with the change I am going to take the risk and take note of the change.

Thank you

14
MiVoice Office 250/Mitel 5000 / Paging Zone Limit
« on: January 25, 2017, 11:33:03 AM »
Hello again everyone, I have a 5000 HX running 5.1 and somehow it has over 10 paging zones and appears to have no limit I can continue to add zones without getting the 0-9 warning and they work fully and are pageable. I have another 5000 HX that I would actually like to replicate this on. Has anyone happened to come across the way to 'break' this to add more paging zones after the 10th one has been added?


Thank you
Kenny

15
MiVoice Office 250/Mitel 5000 / Re: ACD Hunt Group Setup
« on: June 28, 2016, 05:02:03 PM »
You were spot on, Hunt Group Members extension list did exactly what I was attempting to do, to incorporate both groups of devices into one huntgroup.

Thank you
Kenny

Pages: [1] 2 3