03-11-2013 02:36 AM - edited 03-16-2019 04:11 PM
Hello,
I'm facing a problem in which I need to register an IP Phone against a CUCM 7.1 lab environment over a WAN link. I have forwarded TFTP udp port, SCCP tcp port and RTP range ports and IP phone tftp server pointing to public IP.
I have confirmed that tftp redirection is working properly and IP Phone get de SEP...cnf.xml and stays on registering status. I also realized that the xml got shows CUCM private IP and, initially couldn't be routed through port 2000. So, I got de xml file, installed a tftp server locally and modified xml pointing to the public address of CUCM lab location. I have detected nat entries on port 2000 from remote source but still remains registering.
Then, is it possible to register an IP Phone over a WAN link without stablishing a VPN, only forwarding ports? If so, can someone help me to know what I am missing?
I will appreciate your help.
Regards
Solved! Go to Solution.
03-11-2013 03:52 AM
Hi
I think it's unlikely you will get this to work well, without some degree of application inspection on your device performing NAT / port forwarding.
The issue as you have seen is that many of the higher level protocols in play here embed the IP addresses in higher level packets. SCCP and RTP both do this, so you'll see in packet decodes that the private IP address will still be present even though you're modifying it at the network layer.
Even if you manage the get to the phone to register, it is unlikely you'll ever get any audio. The SCCP call setup packets will contain the private address of CUCM. This means that any audio that is set up from the phone will be attempted to this private address rather than the public one.
It is possible that your port forwarding device *may* be able to perform these application layer inspections for you - although this will very much depend on what this device is.
Hope this helps.
Barry Hesk
Intrinsic Network Solutions.
03-11-2013 03:52 AM
Hi
I think it's unlikely you will get this to work well, without some degree of application inspection on your device performing NAT / port forwarding.
The issue as you have seen is that many of the higher level protocols in play here embed the IP addresses in higher level packets. SCCP and RTP both do this, so you'll see in packet decodes that the private IP address will still be present even though you're modifying it at the network layer.
Even if you manage the get to the phone to register, it is unlikely you'll ever get any audio. The SCCP call setup packets will contain the private address of CUCM. This means that any audio that is set up from the phone will be attempted to this private address rather than the public one.
It is possible that your port forwarding device *may* be able to perform these application layer inspections for you - although this will very much depend on what this device is.
Hope this helps.
Barry Hesk
Intrinsic Network Solutions.
03-11-2013 03:57 AM
HI
Using Cisco ASA phone prxy feature will resolve all your doubts. It is easy to implement and Certified by Cisco.
https://supportforums.cisco.com/docs/DOC-5704
Regards
Ronak Patel
Rate all helpful post by clicking stars below the answer.
03-12-2013 01:10 AM
Thank you both,
I won't spend more time in this and try to config a VPN if possible.
Regards
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide