[cisco-voip] NAT for Call Managers

Humayun Sami humayun_sami at hotmail.com
Mon Sep 27 01:24:20 EDT 2010




Thank everyone, I have a question here, lets say that we can get it
to work with using NAT. I wanted to understand the design that how does the IP
to IP (Call Manager to Manager) and phone to phone connectivity works. As in my
knowledge we have separate IP’s for Call Manager. My question is in respect to
the RTP session establishment.

 

I understand it with that we can provide NAT’d addresses to Call
Managers, how will the Phone work here. Even if we have NAT’d the phones subnet
as well. To create RTP session phones will definitely have direct session
established. Can you please make me understand the design working here in
regards to the phone communication and RTP session establishment.

 Regards,
 Humayun Sami






Date: Sun, 26 Sep 2010 11:38:43 -0700
From: nice_chatin at yahoo.com
To: ahmed_elnagar at rayacorp.com; matthnick at gmail.com
CC: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] NAT for Call Managers

Put a Session Border Controller (IPIP Gateway) in between.

--- On Sat, 9/25/10, Nick Matthews <matthnick at gmail.com> wrote:

From: Nick Matthews <matthnick at gmail.com>
Subject: Re: [cisco-voip] NAT for Call Managers
To: "Ahmed Elnagar" <ahmed_elnagar at rayacorp.com>
Cc: cisco-voip at puck.nether.net
Date: Saturday, September 25, 2010, 4:33 AM

You can get it to work, but historically it's one of the more difficult things to do.  Both SIP and H.323 have their various problems with NAT.  With H323, it uses a random port<->random port exchange which firewalls don't like.  Some H.323 endpoints may use non-standard extensions/fields. With SIP, it routinely includes IP
 addresses in fields that should and should not be NAT'd, and often firewalls don't respect the right ones (or at all).  


For instance, the newer phone loads use SCCP v17 which caused some firewalls to stop recognizing the SCCP format.  So, tread carefully is the answer.  

I think RTP is generally handled pretty well, but it's usually the signaling protocols that get ignored.  Make sure you know what they are and try to configure the firewall to be aware of them.


-nick

On Fri, Sep 24, 2010 at 4:24 PM, Ahmed Elnagar <ahmed_elnagar at rayacorp.com> wrote:















NAT have a lot of problems one of them that I faced myself that
the phones show as register on CUCM but actually they are not…try to avoid it
as much as you can…however if it is mandatory choose the device that is making
NAT for VOIP traffic VOIP aware in order to rewrite the NATted packet in the
correct way that is suitable for RTP.

 





 Best
Regards;

  Ahmed Elnagar

  Senior Network PS
Engineer

  Mob: +2019-0016211

  CCIE#24697 (Voice)

 






 





From:
cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On
Behalf Of john_burk at oxy.com

Sent: Friday, September 24, 2010 4:57 PM

To: humayun_sami at hotmail.com; cisco-voip at puck.nether.net

Subject: Re: [cisco-voip] NAT for Call Managers





 



NAT can cause havoc with the RTP stream, but with the right
firewall and design/config it can be made to work. I use VPN if at all possible
to avoid these issues.



John Burk, Consultant 

Sent from my Blackberry



 









From: cisco-voip-bounces at puck.nether.net
<cisco-voip-bounces at puck.nether.net> 

To: cisco-voip at puck.nether.net <cisco-voip at puck.nether.net> 

Sent: Fri Sep 24 08:02:38 2010

Subject: [cisco-voip] NAT for Call Managers 



Is it recommended to use NAT on VoIP. I have
two separate cluster one for cisco call manager and other for Avaya. We are
integrating both the setups(h323). Is it okay to use NAT. Can someone provide
me a document which helps in this reference.





For what reason people do not recommend it in the network, or is it the same
that you do not register your call managers with the domain server. Look
forward to hear.







Regards,

Humayun Sami.



 Disclaimer: NOTICE The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Raya will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any malicious code or virus being passed on. Views expressed in this communication are not necessarily those of Raya.If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. 





_______________________________________________

cisco-voip mailing list

cisco-voip at puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-voip





-----Inline Attachment Follows-----

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



      
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100927/55cd54f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1801 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100927/55cd54f5/attachment.jpg>


More information about the cisco-voip mailing list