03-03-2014 04:57 AM - edited 03-18-2019 02:41 AM
Hello all,
We are facing a problem to do call between 2 endpoint with the following setup:
VCS control (192.168.10.5) (Nated to 10.1.10.5)
Video Endpoint 1 (10.1.1.5 - register to VCS 10.1.10.5)
Video Endpoint 2 (10.1.2.5 - register to VCS 10.1.10.5)
Direct Call between Endpoint 1 and Endpoint 2 works fine.
Once Endpoint are registred to VCS control (using public ip address 10.1.10.5). The call using Endpoints H323 id or SIP URI is not possible.
As far as I understand, the problem may come from the fact that during the call setup Endpoint1 will try to contcat endpoint 2 via VCS. endpoint 1 will send request to VCS (leg 1) with source address (SA) 10.1.10.5 - destination address (DA) 10.1.10.5. then VCS will send leg 2 of the call setup to endpoint 2 with source address (SA) 192.168.10.5 - destination address (DA) 10.1.2.5. As NAT is only for DA, the the VCS ip address is not getting NATed. The endpoint 2 will then try to send back call setup packets to VCS using 192.168.10.5 as DA. then it will fail as VCS private ip address is not known.
Can someone advise if he alreadymake such setup (using NATed ip address of the VCS control)? and if my understanding is correct? Thanks.
Regards,
Ahmed
Solved! Go to Solution.
03-04-2014 05:47 AM
The call setups are not working because the negotiation of the media is within the SIP SDP, and the IP's within the SDP are not modified with the NAT. All in all, its not a supported design for this reason. I've seen some instances with it works (sometimes) using ALG, and keeping all calls unencrypted, but that solution is hit or miss.
03-05-2014 01:38 AM
Hello Ahmed!
Like Zachary said, an ALG approach is more PITA and people get frustrated if conferencing fail, ...
And if it fails you will have a harder time to get support.
I do not know the scale of your deployment / network and the kind of call flows.
Until you have a full network integration with transparent ip networking in between
video endpoints in all networks I would recomend that you still regiter them to the VCS-E.
Besides that you could use an additional VCS-E in your network where the remote networks
can register to or even have a VCS-C in the remote network registering to the additional or
your existing VCS-E with a traversal zone.
Please remember to rate helpful responses and identify helpful or correct answers.
Please remember to rate helpful responses and identify
03-03-2014 12:25 PM
NATing to the VCS Control is not supported. NATing to a VCS Expressway is, when the Dual NIC option key is applied.
03-03-2014 03:45 PM
You might get a NATed VCS-C working though a ALG or some other NAT helper,
but thats not a Cisco supported deployment.
Like Zachary said, NAT of the VCS-IP is only supported on a VCS-E with the
Dual Interface option.
The VCS-C is the internal VCS which has to have a bunch of ports to be open and no NAT to be involved.
The VCS-E is the VCS which handels NAT upfront the client and can also be itself Nated if the
porper keys is added.
There is nothing stopping you do deploy a VCS-E in in the inside if Firewall/NAT traversal is needed on the inside.
Can I ask why you want to have a deloyment using a VCS-C with nat?
Please remember to rate helpful responses and identify helpful or correct answers.
Please remember to rate helpful responses and identify
03-04-2014 05:41 AM
Thanks Zachary and Martin for your reply.
The current setup is that we have both VCS-C and VCS-E. internal (Private) endpoints and vpn users with Jabber video register to the VCS-C and external (Internet) Endpoint and Jabber register to the VCS-E.
Now, few external (internet) endpoints are migrated to MPLS network. So we don't want to register them anymore to the VCS-E but to the VCS-C but the Private and MPLS networks are still different networks. Thus we try to NAT VCS-C ip address and register MPLS Endpoints to the VCS-C natted ip address. The registration works, so MPLS endpoints can register to the VCS-C using its Natted ip address but not the call setup via the VCS-C.
Martin,
I know that the NATed solution is not supported by Cisco but you think this might work if NAT is correctly implemented. I have the feeling that the call setup is not working because endpoints when receiving the call setup request from the VCS-C. The source ip address is the VCS-C private ip address (Not the Nated one). So endpoints don't know how to route back to this private ip address od the VCS-C during call setup. Please advise.
Best regards,
Ahmed
03-04-2014 05:47 AM
The call setups are not working because the negotiation of the media is within the SIP SDP, and the IP's within the SDP are not modified with the NAT. All in all, its not a supported design for this reason. I've seen some instances with it works (sometimes) using ALG, and keeping all calls unencrypted, but that solution is hit or miss.
03-05-2014 01:38 AM
Hello Ahmed!
Like Zachary said, an ALG approach is more PITA and people get frustrated if conferencing fail, ...
And if it fails you will have a harder time to get support.
I do not know the scale of your deployment / network and the kind of call flows.
Until you have a full network integration with transparent ip networking in between
video endpoints in all networks I would recomend that you still regiter them to the VCS-E.
Besides that you could use an additional VCS-E in your network where the remote networks
can register to or even have a VCS-C in the remote network registering to the additional or
your existing VCS-E with a traversal zone.
Please remember to rate helpful responses and identify helpful or correct answers.
Please remember to rate helpful responses and identify
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: