ITP over NAT-One Way Audio

[brainee48]

I am trying to get a NAT working with my 8622 phone, using a MiVoice 250. I have added NAT IP's at the standard places I've seen in other guides, but I'm still only receiving one-way audio. I can hear people when I call them, but they can't hear me.

I have a Fortigate 300c, and have put in both NAT rules and the right ports in. I'm just not sure what I'm missing. I've even reviewed the IP information in DB Programming (including setting the phone to NAT) but no luck. Any help you can provide would be appreciated thanks.

[Tech Electronics]

brainee48,

Well, that isn't enough information to go on; vague at best.

What all equipment do you have for your MiVO-250? If you just have the base system without anything else you only need 1 public IP Address assigned to the system, but if you have an Expansion Processor, which is a card that clips on to the processor, then you will need public IP Addresses.

Where did you assign those Public IP Addresses at in the System?

What version of software is your system running?

What ports did you open up in the system?

A one-way audio issues is a routing issue; typically. The two most common issues known are a misconfiguration in your Firewall or the lack of Public IPs Associated with your system.

Thanks,

TE

[brainee48]

TE,

Here's a rundown:

Base Unit: P6000 NAT IP Set
PS-1: P6001 NAT IP Set
No PEC
System NAT IP Set to same IP as P6001

All IP's set using the Mitel Admin Tool

Fortigate Rules:

From Public to VOIP subnet:

Any -->BASE Server External IP and PS1 External IP-->Base Server Internal IP-->Mitel Base Ports
Any -->BASE Server External IP--> Mitel Base Audio Ports
Any -->PS-1 Server External IP--> Mitel PS-1 Audio Ports

From Voip to Public:
Range_Mitel --> All -->All Ports --> NAT Enabled --> PS-1 Server External IP--> Public

Mitel Base Ports:

TCP: 5566,5570,5567
UDP: 5567,5566,20001,69

Mitel Base Audio:
UDP: 6004-6261

Mitel PS-1 Audio:
UDP: 6604-7039

Using 8622 and 8662 Phones. Phones are at firmware 2.2.04.

Mitel Software Version: 6.2 SP2 Release 79

Let me know if you need any more info.

[Tech Electronics]

brainee48,

You were almost right. Here is table I created awhile back and never posted. I should post this at the top of the board for everyone to easily access. I isn't completed for everything yet, but it is for what you need and a little more.

Type	Port	Purpose
UDP	69, 20001	TFTP for Phone Firmware
UDP	2427	Enable only if using MGCP trunks outside the firewall.
UDP	5004-5007	RTP for Inter-Tel 86xx Phones Audio
UDP	5060	SIP. This would go to the PS-1 if it exists, otherwise it goes to the Base Controller.
UDP	5567	ITP (Inter-Tel Protocol) Call Control for all Inter-Tel IP Phones. 86xx
UDP	6004-7038 6005-7039	RTP & RTCP for Audio to Base Controller. Even numbers are RTP and Odd numbers are RTCP.
UDP	6604-7039	RTP & RTCP for Audio to PEC(Processor Expansion Card)if installed. This requires a second public IP Address.
UDP	50098-50508	RTP for 52xx/53xx Phones Audio
TCP	3998-3999	SAC Protocol (Application and Button Programming on 53xx phones).
TCP	5566	ITP (Inter-Tel Protocol) Call Control for all Inter-Tel IP Phones. 86xx
TCP	5570	Private Networking over IP will not work through a firewall with NAT enabled.
TCP	6800-6802	MiNet Protocol Call Control for Mitel IP Phones. 53xx and 96xx.

Common Things Missed:

• Setting the Phone from Native to NAT - This will force the outgoing packets to show the Pubic IP Address of the Base Controller; do not allow anything to change this.
  
• PEC (Processor Expansion Card) Installed - This is where audio will come from if it is installed and this will require a second public IP Addressed assigned to it.
  
• PS-1 Installed - This is where all SIP Traffic will need to go to if it is installed. MiNet or ITP phones will still go to the Base Controller. This is also where the VM is and where you point to for DB Programming.
  

Thanks,

TE

[brainee48]

Hi TE,

Thanks for the info. It has brought me closer, so I appreciate it. I did have a couple of questions:

1) Since I do have a listing in the Admin tool for a P6001, would that be considered a PEC? If that's the case, then I've assigned a 2nd IP to that interface. I've also assigned the Audio Ports you mentioned to that NAT rule in my firewall (since you mentioned that all audio goes through that device.

2) On the ports you mentioned here:

UDP   6004-7038 RTP & RTCP for Audio to Base Controller.
6005-7039  Even numbers are RTP and Odd numbers are RTCP.

UDP   6604-7039   RTP & RTCP for Audio to PEC(Processor Expansion Card)if installed.
This requires a second public IP Address.

I've added these into my firewall rules, but when you mentioned if the PEC handles all audio, does that mean all the audio ports need to be assigned to that IP interface, or still split between the Base and the PEC?

I feel like I'm really close, but I'm still getting one-way audio.

[Tech Electronics]

brainee48,

Hmm, alright let's see if I can clarify this a little more for you.

Answer to Question 1:
If you see a X over the Icon for P6001 then you don't have one; see picture.
If you don't have a X then you will need to put a Public IP Address in there and point it to the LAN IP Address Associated with the PEC; look in IP Settings.

Answer to Question 2:
To clarify what has to happen you need to be aware of a couple of things.

1. If there isn't a PEC then you would need to make sure that port 6004-7039 goes to the Base Controller to ensure you have RTP/RTCP ports available.
2. If there is a PEC then you could split the audio port to match the following, but it doesn't hurt to just have both of them set to 6004-7039.

• Base: 6004-6261
• PEC: 6604-7039

What you will need to keep in mind is that the audio will always start from the PEC if it is installed until it runs out of ports; then it goes to the Base Controller.

What is the exact scenario step-by-step that you are doing to create the loss of audio issue. For example:

• Telework User (86xx) goes off-hook on their handset and dials Operator (0)
• Operator Answers the phone by picking up the handset and talks
• Teleworker User hears the Operator and talks back
• Operator doesn't hear the Teleworker User
• Operator switches to speakerphone and talks again; waits for audio
• Teleworker Users hears Operator talking and switches to speakerphone; responds to Operator
• Operator still hears nothing and puts call on Hold and picks it back up; asks if User heard MoH<-- This depends on how MoH is setup in the system.
• Teleworker User responds to the Operator with DTMF tones
• Operator still hears nothing and hangs up the call.
• Packet Capture at Firewall should show what ports were used and what the IP Addresses used were

Thanks,

TE

[brainee48]

brainee48,

Hmm, alright let's see if I can clarify this a little more for you.

Answer to Question 1:
If you see a X over the Icon for P6001 then you don't have one; see picture.
If you don't have a X then you will need to put a Public IP Address in there and point it to the LAN IP Address Associated with the PEC; look in IP Settings.

Answer to Question 2:
To clarify what has to happen you need to be aware of a couple of things.

1. If there isn't a PEC then you would need to make sure that port 6004-7039 goes to the Base Controller to ensure you have RTP/RTCP ports available.
2. If there is a PEC then you could split the audio port to match the following, but it doesn't hurt to just have both of them set to 6004-7039.

• Base: 6004-6261
• PEC: 6604-7039

What you will need to keep in mind is that the audio will always start from the PEC if it is installed until it runs out of ports; then it goes to the Base Controller.

What is the exact scenario step-by-step that you are doing to create the loss of audio issue. For example:

• Telework User (86xx) goes off-hook on their handset and dials Operator (0)
• Operator Answers the phone by picking up the handset and talks
• Teleworker User hears the Operator and talks back
• Operator doesn't hear the Teleworker User
• Operator switches to speakerphone and talks again; waits for audio
• Teleworker Users hears Operator talking and switches to speakerphone; responds to Operator
• Operator still hears nothing and puts call on Hold and picks it back up; asks if User heard MoH<-- This depends on how MoH is setup in the system.
• Teleworker User responds to the Operator with DTMF tones
• Operator still hears nothing and hangs up the call.
• Packet Capture at Firewall should show what ports were used and what the IP Addresses used were

Thanks,

TE

After having you send me the picture, I do have a PEC. And I have assigned an External IP to that PEC.

I've placed it so that the ports for both External IP's have the same range, as you suggested.

So I have a phone in my home office I've been testing.

The scenario is:

8622--> Outgoing button--> Dial my Cell Phone #
Cell Phone --> Answer the Call, get echo like sound from the speakerphone, and no audio going out to the cell phone.
8622 --> Pick up handset, place next to audio source, leave my office for another room.

Cannot hear the audio source from the handset. Handset can hear my voice from the Cell phone.

Even when standing at the other side of the room with me just speaking into the 8622 handset (no external audio source), can't hear the 8622 audio from the cell phone.

I've also called others on cell phones and internally and no audio on the handset, but I can hear them.

[Tech Electronics]

brainee48,

From your description you are having a problem with inbound audio from the Teleworker (86xx).

Since the phone knows the IP Address of the System and can Initiate a Call it obviously knows the Public IP of the Base Controller; check.

Although Audio is not able to make it from the Teleworker to the callee this means one of three things is happening.
1. The phone is not set to Native not NAT; This means the phone system will send out its LAN IP Address for the phone to talk back on.
2. The phone is getting the wrong IP Address to talk back to the system. Since you do have a PEC it would need its Public IP Address and that would need to be routed back to the LAN of the PEC not the Base or the PS-1.
3. The IP Address the phone is given to talk back on is blocked or routed incorrectly. Try testing all of the port you have opened up and make sure they are allowing traffic through.

I would setup Wireshark to monitor the port the phone is on and also get a packet capture from the Firewall and phone system if you can. This will tell you which one of these is causing your problem. In essence the Firewall should be able to provide a packet capture from the middle and show you, but it if is the one causing the problem then the information you will be receiving may not be accurate. The most accurate method is to get it from all three sources and at a minimum from the phone system and the phone itself.

If the problem is that the phone system is sending out the wrong information for the phone to talk back on then it is a misconfiguration in the phone system. If the phone system is sending out the right information then it is an issue with the Firewall. The issue with the phone could be that both Microphones on the phone are bad which although not unheard of it is very odd.

To eliminate the phone as the issue you could take it into the office and make sure it works there first then take it back to the remote location if everything is working fine.

Thanks,

TE

[brainee48]

So an Update:

I have it working now. Seems that one of the IP's being used was hooked into a physical VPN device, but wasn't recorded as such in our IP list. Happened to do a packet trace and got some odd results, so I pinged it just for giggles and received a response back. Tracked it down (the VPN is no longer needed) and turned it off, and two way audio commenced. Thanks for your help.