[VoiceOps] Mitel 3300 - NAT - Media Issue

Scott Berkman scott at sberkman.net
Tue Apr 3 20:23:26 EDT 2012


If you aren't doing any Far-end NAT traversal (meaning you/they have an SBC
at the provider side configured to deal with this), you probably DO want to
turn on the SIP ALG in the Cisco 3700 ('ip nat service sip udp port 5060' or
similar).  That's probably your easiest fix.

 

Something has to be responsible for telling the far end system what routable
IP to send the media (RTP) back to.  What you have happening now is the SDP
as it reaches the carrier still has a private IP address, which is obviously
bad.

 

If you enable the SIP ALG in the 3700, it should keep track of the session
and modify the SIP messages to translate the local/private IP(s) to the
public/routable one as needed.

 

The problem is that the SIP ALG in the Cisco router isn't very configurable
and can sometimes be buggy depending on IOS and HW.  If you run into issues,
you may want to look into something with a better ALG such as Edgewater
Edgemarc, similar products, or a small SBC.  Personally, I'd use the
Edgemarc just about 100% of the time in that spot of I had the choice and
means and there was nothing crazy I needed the power and flexibility of an
Acme for.

 

Good luck,

 

-Scott

 

From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org]
On Behalf Of Robert Dawson
Sent: Tuesday, April 03, 2012 9:41 AM
To: voiceops at voiceops.org
Subject: [VoiceOps] Mitel 3300 - NAT - Media Issue

 

Working with someone on SIP trunks for a Mitel 3300. The Mitel is sitting
behind a NAT on a Cisco 3700 (i.e. no fixup/ALG) and inbound media is
failing because the phones private IPs are being targeted directly in the
SDP. Even if I force all media back to the NAT address it still fails
because there is no translation for the phones.

 

Anyone know if there is a way to force the Mitel to proxy the media or have
any insight into getting around this shy of putting a proxy at the customer
site(which is what we should probably do anyway)?

 

Thanks,

Rob

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20120403/c535ec80/attachment.html>


More information about the VoiceOps mailing list