Recent Posts

Pages: 1 ... 4 5 [6] 7 8 ... 10
51
The 3300 only sets up and tears down the calls, all audio streams from device-device, or perhaps device-teleworker server in your case
52
Hi ZuluAlpha!

There is a firewall involved. The MBG server resides in the DMZ zone of the firewall, the other Mitel servers and in-office desk phones reside on the inside, corporate lan zone of the firewall. I have opened all ports for testing from MBG to internal servers and vice versa. The only way it seems that teleworker calls succeed is if I allow MBG (DMZ zone) to talk directly to the in-office desk phones (inside zone).

This was not the case prior to the upgrade in January, is this normal behavior that MBG needs to talk directly to the desk phones in the office when I call is initiated from a teleworker?
53
On the inside if your TW and MBG are trusted it shouldn't be an issue. Is there an external firewall involved? It sounds like it's blocking SIP to the 6900's.
54
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
55
Sorry for the delay, apparently I don't have notifications for replies turned on.
Currently running MiVB 9.3.0.24. I'll try upgrading to 10.1.0.29 later this week after hours and see if that makes a difference. Appreciate the suggestion, lundah!
56
Mitel Software Applications / IGNITE WEB V9
« Last post by rbarock on April 03, 2024, 04:16:58 AM »
Hi,

We are using Web Ignite for users (v9) and have come across an interesting problem
There are several customers on the same MIVB, but separated into tenants. If a user from organization A searches for a contact person in Ignite, he will also see the contacts of customer B. Can that be solved?

Have a good day everyone.
57
SIP On Mitel / Re: DTMF not correctly sent from SIP extension
« Last post by acejavelin on April 02, 2024, 04:24:17 PM »
Make sure your DTMF payload type (96 or 101 usually) is set the same in the SIP Peer Profile as it is in the device.
58
SIP On Mitel / DTMF not correctly sent from SIP extension
« Last post by mem94043 on April 01, 2024, 12:59:19 PM »
I have a SIP door phone set up on a MiVo250. Users can call from any Mitel IP phone extension to the door phone (SIP ext) and when it answers they  dial the 'relay' code (built-in to door phone) and it triggers just fine. However, if the door phone initiates a call to another Mitel IP extension and it answers, the door phone does not recognize any touch tones entered by the user on the IP phone.  So, I essentially have one-way DTMF working.  Any thoughts on what is causing this??  Thx!
59
SIP On Mitel / Re: 6867i 6.2 Firmware Interesting Issue
« Last post by crazyscout on March 27, 2024, 10:11:13 AM »
Found part of the issue, the Outbound proxy server being a URL was causing the phone some issues. Based off of the PCAP I did where I saw no registration attempts this leads me to believe it is a DNS issue as it cant resolve our URL to an IP thus has nowhere to send a registration attempt to. The odd part is our provisioning server is configured as a URL as well so DNS must be working if it grabs configurations just fine.

Rolling back to pre 6.X firmware also resolves the issue and the phones register just fine. Anyone know if there were any kind of DNS changes in the 6.X firmware?
60
Mitel Software Applications / Re: Micollab IDS Managed Client user information
« Last post by lundah on March 26, 2024, 05:52:46 PM »
Look in your Detained User Updates, there should be an Update record for the user that you just need to check the checkbox for and then click "Save".
Pages: 1 ... 4 5 [6] 7 8 ... 10