Portas utilizadas pela central Mitel

Port Range	Direction	Purpose & Details
TCP 22 (SSH)	Server « Internet	AMC communications. Allow inbound and outbound packets on TCP port 22 between the 6010 and the Internet to enable server registration, software and license key downloads, alerts and reporting.
TCP 443 (HTTPS)	Server « Internet	Remote Server Management. Allow inbound and outbound packets on TCP port 443 between the 6010 and the Internet to allow remote management of the server, if required. HTTPS access to the manager on the external interface must be also be explicitly enabled from the server manager interface.
TCP 443 (HTTPS)	Server « LAN	Local Server Management. Allow inbound and outbound packets on TCP port 443 between the 6010 and the LAN to allow for management of the server. HTTPS access to the manager on the external interface must be also be explicitly enabled from the server manager interface. The firewall should be configured to limit HTTPS access to desired management hosts.
TCP 6800, 6801 and 6802	Server « Internet Server « LAN Server « ICP(s)	MiNet Call Control. Allow incoming and outgoing packets for TCP ports 6801 and 6802 between the server and the Internet. Allow incoming and outgoing packets for TCP ports 6800, 6801 and 6802 between the server and the LAN and the server and the ICP(s). The LAN rule can be omitted if there are no teleworker sets on the LAN, but ensure that the ICP(s) can communicate with the server’s public address.
UDP 69	Server « Internet Server « LAN	Firmware Downloads. Allow incoming TFTP requests from the Internet and from the LAN to the server on UDP port 69. Allow outbound replies to these requests, from the server to both the Internet and the LAN. Phones will be unable to boot if this is misconfigured. LAN rules can be omitted if there are no in-office Teleworker sets. Note: a source UDP port of 69 is used for all replies from the 6010 TFTP server.
UDP 20,000 to 23,000 (RTP)	Server « Internet Server « LAN	Voice Communications. Allow incoming and outgoing RTP on UDP ports 20000 – 23000 between the server and the Internet. Misconfiguration here is a common cause of one-way audio problems.
UDP 1024 to 65,535 (RTP)	Server ® LAN	Voice Communications. Allow outgoing RTP on UDP ports greater than, or equal to, 1024 from the server to the phone network (LAN). Failure to do so often results in a loss of audio from the remote phone to the local phone network (LAN).
UDP 1024 to 65,535 (RTP)	LAN ® Server	Voice Communications. Allow outgoing RTP on UDP ports greater than, or equal to, 1024 from the phone network (LAN) to the publicly routable IP address of the server. Failure to do so usually results in the loss of audio from the local phone network (LAN) to the remote phone.
TCP 3300 (VFA)	Server « Internet Server « LAN	Optional VoiceFirst Communications. Allow bidirectional traffic on TCP port 3300 if you have a VoiceFirst Solution installed.
TCP 8001 (MiTAI)	Server « Internet Server « LAN	Optional MiTAI Communications. Allow bidirectional traffic on TCP port 8001 if you are using the Your Assistant Softphone v3.1 or higher with the Teleworker Solution.
TCP 3999 (5230 set)	Server « Internet Server « LAN	Optional 5230 IP Appliance Communications.Allow bidirectional traffic on TCP port 3999 if you are using Mitel 5230 IP Appliances as Teleworker sets. This enables communications from the on-board PDA.

Voip mudo (Resolvido)

Hoje, enfim conseguimos resolver um problema que há uma semana estava nos deixando de cabelo em pé.

O problema era o seguinte:

De um lado núcleo da rede com ip 10.x.x.x (gateway,switch, central voip tudo no geral). Do outro lado uma outra filial próxima ao núcleo, interligada por fibra, firewall na borda com nat e rede local 172.x.x.x.

Quando um telefone ip na 172.x.x.x se registrava na central que fica na rede 10.x.x.x, ele não ouvia a outra ponta.

Por exemplo o telefone 4455 registrado na rede 172.x.x.x, ligava para o telefone 4456 que estava registrado na rede 10.x.x.x, o telefone 4455 não ouvia, já o 4456 ouvia normalmente.

Estávamos a mais de uma semana quebrando a cabeça com regras de nat, liberação de porta udp no firewall e nada.

Porque o seguinte o protocolo sip utiliza a 5060 udp para sinalização, para se registrar na central.

Já o áudio, protocolo rtp utiliza porta aleatória que podem ir da 8000 até 32000 udp também, e acreditávamos que era o firewall que estava bloqueando, sendo que dá rede 10 não pingávamos a rede 172 e vice-versa funcionava.

Após várias reuniões, partimos pra uma ação conjunta onde entramos na central na rede 10 e demos um tracert para rede 172 e vimos que o tracert morria em um dos gateways, bastou entrar nesse gateway e verificar as rotas, tava lá escondidinha, uma rota que apontava para rede 172 estava com a máscara errada, bastou alterar, pronto todo mundo se falando.

Por isso, é importante o trabalho em equipe de todos em um problema, seja a equipe de redes, infra ou aplicações, todos devem estar focado no problema.