Remote Phone w/ PS-1 - No Audio

[Hovus]

Hello all,

Happy Monday...(not so happy considering it's President's Day and here we are working!  ),

I have a customer that's having no audio on remote phones on any type of call (internal, incoming, outgoing). They have a base unit HX on 5.1 SP4 with a PEC and PS-1. We have public IP on both spots in the DB for getting remote phones to work, ports forwarded to the base unit. Phones are up, but no audio. Only thing I can think of is ports need to be forwarded to PS-1 instead of base unit, but I'm not 100% on PS-1s and I can't seem to find any documentation regarding PS-1s and remote phones and whether anything would be different from normal HX installations.

Any insight to this would be appreciated...THANKS!

[Hovus]

Found this in Appendix B of the Installation Manual:

5. Configure the IP phone (that is on the Internet) to communicate with the system’s (public)
NAT address. You can do this through the IP phone setup sequence or through the IP
phone Web page. The address to use is the public address associated with the Base
Server’s main IP address – regardless of whether the system is equipped with an optional
PEC-1.

Confirms that everything is set up properly...now I'm at more of a loss as to why there'd be no audio...

[Hovus]

And further down in Appendix B:

Base Server with a PEC-1 and a PS-1
The firewall should have three statically mapped public IP addresses for the 5000 CP–one each
for the Processing Server, the Processor Module, and the Processor Expansion Card. Set the:
• “System NAT IP Address” in System\IP Settings in DB Programming to the statically mapped
public IP address of the Processing Server.
• “NAT IP Address” in System\Devices and Feature Codes\IP Connections\<node>\P6000
to the statically mapped public IP address of the Processor Module.
• “NAT IP Address” in System\Devices and Feature Codes\IP Connections\<node>\P6001
to the statically mapped public IP address of the Expansion Card.

What does the remote IP Phone use in the above scenario? What's the point of having 3 separate public IP addresses???

[chrismitel]

Hi Hovus,

I have never run a phone in teleworker mode with a PS1 but I would have thought you point the phone to the PS1's public IP address but I might be wrong.

With regards to the reasoning for the IP addresses please see below taken from a doc I got from Mitel which explains it briefly...

The PM and the PEC will have a Private and a Public Static IP address
When the phone boots up it will be programmed to look for the External IP (Public) IP address of the 5000 Processor Module (PM).
This will be forwarded to the statically mapped Internal IP address of the 5000 Processor Module (PM) and so the contact is made.
The Processor Module will reply to the Phone using the Route it came in on and supply the details for boot up.

When a Call comes in it will know to send it down that route as there will be a relationship now between the PM and the Phone.
On call setup - if there is a resource problem, or compression is required, then it may include information in the packet for the phone to use the PEC for the speech call, however data will always communicate with the PM.

The external address for the PM and the PEC are programmed in the P6xxx numbers in System/IP Connections/P6xxx/NAT IP Address of DB programming.

[dwayneg]

Easy thing to miss: every phone that points to the NAT address needs to have the field NAT ADDRESS TYPE set to NAT (SYSTEM/DEVICES AND FEATURE CODES?PHONES/XXXX/IPSETTINGS).  Very common cause of no audio or half audio.

[Hovus]

That goes without saying Dwayne 

[Hovus]

I'm having the customer's IT staff confirm the ports are being forwarded to the base HX's IP just to be 100% sure. I'll update once I find out.

[Tech Electronics]

Hovas,

Not that I think this is your problem, but don't forget that you can not use Peer-2-Peer Audio on those phones either.

I personally think that they don't have all the ports necessary for UDP set up properly and since the phone came up the TCP connections are working fine and you would have noticed if they couldn't get to the TFTP Server on boot up so that part is ok as well. Since all audio is UDP that is where you need to be looking and most the time even though the ports are opened up they forget to remove them from packet filtering and the packets get dropped.

If you are using a 53xx phone you can port mirror the data port on it easy enough and then set up Wireshark on it and then port mirror a port on your switch to look at the port the phone system is on and watch your data traffic when you place a call.

Thanks,

TE

[mem5449]

I agree with dwayneg. Forgetting to set the phone to NAT (in station programming) is THE number one cause of one way audio. It's so easy to miss since NATIVE is default.  I forget this at times myself when taking demo phones on and off site.

Oh, ever wonder why the UI developers buried some of this commonly accessed stuff so far down/deep in the "tree"? Sure makes for a LOT of clicking and difficult to give a newbie Admin training. Sometimes I miss the Axxess v4.4 'forms' method of programming

[keefers]

Hi Hovus,
Did you ever find a fix for this issue?  I am experiencing the exact same problems for my remote phones.  The client had an Inter-tel 5000 version 2.4.  We migrated everything over to a new Mitel HX5000 version 6.10.   Everything is working great except the remote phones.  I have gone through all that I have found on the forums and with support.  Let me know if you ended up getting this resolved.
Thanks
Keith