Show Posts
1
Mitel MiVoice Business/MCD/3300 / Teleworker problem with calling in-office IP desk phones
« on: April 11, 2024, 10:39:30 AM »
I am having troubles with teleworker phones making calls to other Mitel phones in the office. When a teleworker calls an in-office phone there is “dead air” and no audio can be heard by either person. We have been advised to open udp ports 50000 – 50511 from the MBG server in our DMZ to the entire internal voice lan where our MiVoice, MiCollab, 3300 controllers, and all IP deskphones reside. We have never had these ports opened before and this seems excessive, is it necessary? Please see below for details. Any advice you can offer is greatly appreciated.
Server Configuration
1. MiVoice VM Server, MiCollab VM Server, and physical 3300 controllers all located on inside voice network
2. MBG VM Server located in the DMZ
Firewall Configuration
1. Ports have been opened as recommended by Mitel’s documentation
2. Firewall logs do not show any blocked traffic between MBG and MiVoice, MiCollab, and 3300 controllers
3. Have tried opening all ports between MBG and MiVoice/MiCollab/3300 controllers for testing (nothing changed)
4. Ports are opened between the MBG server and other internal servers (MiVoice, MiCollab, 3300 controllers)
5. Ports are *not* opened directly from the MBG server to in-office desk phones (5330e & 6930)
Phone Models
1. A mix of 5330e and 6930 IP phones
What has changed
1. Version upgrades for MiVoice, MiCollab, MBG, and 3300 controllers in late January 2024
2. MiVoice version: 10.1 (Active software load: 10.1.0.29 (21.1.0.30))
3. 3300 Controllers version: 10.1 (Active software load: 10.1.0.29 (21.1.0.30))
4. MiCollab version: 9.7.1.110-01
5. MBG version: 11.5.2.31
What is happening
1. Both 5330e & 6930 teleworker phones can call a 5330e phone that is in the office
2. Both 5330e & 6930 teleworker phones *cannot* call a 6930 phone that is in the office
3. Both 5330e & 6930 in-office phones can call both 5330e & 6930 phones that are teleworkers
a. Recently, I have began to see dead air when an in-office phone calls a teleworker
b. This is rare but it has happened a few times
4. MBG event logs show “one-way audio” with “comment:loss of rx stream, from:IS, duration:5963” as description
a. This event does not always appear when a teleworker calls an in-office phone and gets “dead air”
Observations
1. Seeing the MBG server try to connect with the IP of the internal Mitel phone directly – is this normal behavior?
a. When a teleworker calls in in-office phone, firewall logs show that the MBG server tries to connect directly with the in-office phone on udp ports 50000 – 50511
b. If these ports are allowed, the calls succeed
c. I have never had these ports opened and this has never been an issue until after this version upgrade
2. Calls from a teleworker to an in-office 5330e succeed, even though the firewall logs a failed attempt at a direction connection to the IP of the desk phone
3. Calls from a teleworker to an in-office 6930 fail and the firewall logs a failed attempt at a direction connection to the IP of the desk phone
4. Calls from the MiCollab app on an iPhone to an in-office desk phone always seem to work fine
5. This problem doesn’t appear to affect teleworkers that use the PC softphone but I do not know this for sure
6. Unknown if the problem exists with a teleworker calling an in-office softphone
7. These problems were first noticed about 3 – 4 weeks after the late January version upgrades and seem to be progressively getting worse
Server Configuration
1. MiVoice VM Server, MiCollab VM Server, and physical 3300 controllers all located on inside voice network
2. MBG VM Server located in the DMZ
Firewall Configuration
1. Ports have been opened as recommended by Mitel’s documentation
2. Firewall logs do not show any blocked traffic between MBG and MiVoice, MiCollab, and 3300 controllers
3. Have tried opening all ports between MBG and MiVoice/MiCollab/3300 controllers for testing (nothing changed)
4. Ports are opened between the MBG server and other internal servers (MiVoice, MiCollab, 3300 controllers)
5. Ports are *not* opened directly from the MBG server to in-office desk phones (5330e & 6930)
Phone Models
1. A mix of 5330e and 6930 IP phones
What has changed
1. Version upgrades for MiVoice, MiCollab, MBG, and 3300 controllers in late January 2024
2. MiVoice version: 10.1 (Active software load: 10.1.0.29 (21.1.0.30))
3. 3300 Controllers version: 10.1 (Active software load: 10.1.0.29 (21.1.0.30))
4. MiCollab version: 9.7.1.110-01
5. MBG version: 11.5.2.31
What is happening
1. Both 5330e & 6930 teleworker phones can call a 5330e phone that is in the office
2. Both 5330e & 6930 teleworker phones *cannot* call a 6930 phone that is in the office
3. Both 5330e & 6930 in-office phones can call both 5330e & 6930 phones that are teleworkers
a. Recently, I have began to see dead air when an in-office phone calls a teleworker
b. This is rare but it has happened a few times
4. MBG event logs show “one-way audio” with “comment:loss of rx stream, from:IS, duration:5963” as description
a. This event does not always appear when a teleworker calls an in-office phone and gets “dead air”
Observations
1. Seeing the MBG server try to connect with the IP of the internal Mitel phone directly – is this normal behavior?
a. When a teleworker calls in in-office phone, firewall logs show that the MBG server tries to connect directly with the in-office phone on udp ports 50000 – 50511
b. If these ports are allowed, the calls succeed
c. I have never had these ports opened and this has never been an issue until after this version upgrade
2. Calls from a teleworker to an in-office 5330e succeed, even though the firewall logs a failed attempt at a direction connection to the IP of the desk phone
3. Calls from a teleworker to an in-office 6930 fail and the firewall logs a failed attempt at a direction connection to the IP of the desk phone
4. Calls from the MiCollab app on an iPhone to an in-office desk phone always seem to work fine
5. This problem doesn’t appear to affect teleworkers that use the PC softphone but I do not know this for sure
6. Unknown if the problem exists with a teleworker calling an in-office softphone
7. These problems were first noticed about 3 – 4 weeks after the late January version upgrades and seem to be progressively getting worse