7940 phone registration over WAN pub IP

[mshamkumar]

Hi friends,

               We have 2branches one in Ind and other in US and at US end we have 2800 cisco router and we installed CCM X.X,configured all basic things what all to have and NATed CCM IP to Public IP address.coming to india side we have four 7940G phones and DSL Internet connection.Question is? can we register these phone to US CCM by giving Public IP address as server IP by adding manually in Phones.help me is this possible or not....thanks in advance....

[Jonathan Schulenberg · Accepted solution]

Here's the thoughts that come to mind. My short answer is 'no' but others may disagree. My recommondation would be to install an independant CME router at the remote site in India.

1. UCM is not intended to be publically facing at all. You should be using IPsec tunnels and possibly GRE to connect the sites without performing NAT between the UCM servers, IP phones, or gateway. You could investigate using ASA Phone Proxy instead but I'm not a fan of it.
   
2. NAT does not work with RTP (short answer).
3. You may run into difficulties with signaling timeouts due to the RTT delay from US to IN and back.
4. India has laws related to Closed User Groups which place restrictions on how you make off-net calls. You should consult appropriate councel to ensure compliance with local laws before proceeding.

[paolo bevilacqua · Accepted solution]

Do not insist on having phones and CM with public addresses. That is unconvenient and unsecure.

Instead configure a VPN between sites and you will be fine.

[mshamkumar]

Thanks a lot for ur best replies.....

[kechengpc]

I am planning to deploy ASA phone proxy with Cisco ISR G2,  some ip phone registration to CME over WAN. What's 'unconvenient and unsecure' referred to?

[Jonathan Schulenberg]

p.bevilacqua's response was addressing the concept of UCM servers being given public (or NATed) IP addresses, not ASA Phone Proxy.

I am not a fan of Phone Proxy because it is a cumbersome, temporary, and inflexible solution to remote IP phones. That is purely my opinion however and others may see more value in it.

[kechengpc]

Thanks. If no ASA phone proxy, what's the solotion for remote ip phone with site-to-site VPN?

[Jonathan Schulenberg]

Here is what I say to my customers when I have this conversation. Again, this is my opinion, take it for what it is, it comes with no warranty.

Your currently shipping options, from most to least preferred are:

• Use an ASA5505 or ISR881 at the remote location and use DMVPN (ISR only) or EasyVPN to connect it to your head end. Cisco brands this the Cisco Virtual Office (CVO) solution. It used to be the Enterprise Teleworker Solution. It's highly tested, deployed, and documented. The downside is it increases your deployment cost.
  
• Use a soft phone such as IP Communicator with AnyConnect or legacy IPsec VPN client. Low cost and easy to deploy; however, PC interruptions (e.g. Windows being Windows) can affect voice quality. No QoS either.
• ASA Phone Proxy. It eliminates the dependency of a computer and avoids the additional cost of a router or ASA at the remote end. It does not provide QoS. You are essentially configuring your ASA to impersonate UCM to the phone and your phone to UCM.
  
  • You need several public IP addresses and expose your TFTP service to the outside world. This means you need to use TFTP file encryption to prevent reconnaissance attacks. I would say that TFTP file encryption is best practice regardless but that's another discussion.
    
  • It acts like a UCM cluster that you have enabled mixed mode authentication and encryption on. This means you have separate certificate management of your phone proxy phones which can't renew their certificate someday when it expires since CAPF requires TCP 2000 (SCCP).
  • The same phone cannot "roam" between inside and outside of the firewall because it has different security modes or certificates configured.
  • If your UCM cluster is already in mixed mode then you have double the certificates to manage because the ASA must deal with re-encrypting and authenticating traffic for the inside traffic leg.
  • It is licensed per-ASA chassis. If you have a fail-over pair, you must buy the licenses twice. If you have a DR site, you have to buy them again for that ASA chassis as well.
  • If you configure the phone's CallManager Group to include more than one UCM node, it will consume two Phone Proxy licenses. This is because the phone keeps open TCP sessions to the primary and secondary UCM servers and each connection consumes a Phone Proxy license.

UCM 8.0(1) is expected to include another (better!) option for certain [current] phone models; however, you need to discuss that with your Cisco Account Manager. Details on UC 8.0 are in varying states of public vs. NDA and I'm not sure where this one is.

[kechengpc]

For centrically administration considerations , the deployment steps is CIPC with VPN client, ASA Phone Proxy and last step is site-to-site VPN.  ASA Phone Proxy has better voice quality than  soft phone?  With  site-to-site VPN , can centrically operate on  head end without any local administration at the remote location(no professionals )?

[Jonathan Schulenberg]

To answer your questions:

1. IP Communicator and a comparable 7900 series phone are capable of the same voice codecs. There is no theoretical difference in voice quality between the two. The advantage to a 7900 series phone from a technical standpoint is only the independent CPU. If a process on Windows locks up the CPU, it can affect the voice call since IP Communicator is just another (high priority) application on the same PC.
2. It is possible to centrally provision and maintain IPsec-based solutions if you follow the CVO solution. The Enterprise Class Teleworker Design Guide provides additional detail about this, including the management components required at the head end.
   

[kechengpc]

Thanks Jonathan. 7940 ,7941, or 7942 has own DSP to process voice codec, your referring to CPU? With CIPC on netbook(intel atom 240 1.6Ghz,1GB RAM), any experience about voice performance?

[Jonathan Schulenberg]

I was referring to CPU in a general context. A physical phone has it's own processing abilities that are independant of the PC. The fact that a phone uses a DSP in addition to a CPU is not really relavent to this conversation.

I cannot speak to how well, or not, IP Communicator will work on your individual hardware. Test it and find out.

IP Communicator Data Sheet

[kechengpc]

Thanks again. Throught the CVO solution,  need routers(871,881 or 891/892) on the remote location, another router(for example, ISR G2 2901) on the head end. Any software need? Have a configuration example ?

[Jonathan Schulenberg]

All of those questions are addressed in the SRND I referenced above. I would suggest you read and consider the information in it before proceeding.