cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
886
Views
0
Helpful
5
Replies

VCS (NAT) Call setup failed

nuinoahmed
Level 1
Level 1

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

2 Accepted Solutions

Accepted Solutions

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.

View solution in original post

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

View solution in original post

5 Replies 5

Zac Colton
Cisco Employee
Cisco Employee

NATing to the VCS Control is not supported. NATing to a VCS Expressway is, when the Dual NIC option key is applied.

Martin Koch
VIP Alumni
VIP Alumni

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

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

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.

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

Getting Started

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: