VCS Control and VCS Expressway design

Unanswered Question
Dec 1st, 2011

I have an implementation where I have 2 VCS Control and 1 VCS Expressway software version X6. The end costumer has a Internet firewall Fortinet woroking in routed mode with NAT. My question is about the placement of the VCS Expressway in the environment. Is it mandatory put the Expressway in front of the firewall with a Internet valid IP address on it? Is it possible put the Expressway behind of the firewall and configure a NAT for it? Make sense having VCS control and VC expressway in the IP subnet without NAT between them?

Thanks in advance.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.6 (11 ratings)
cfiestas Thu, 12/01/2011 - 12:14


You are not can do either.

Cesar Fiestas

e.lopessilva Thu, 12/01/2011 - 12:24


Thank you for your answer. If I decide put the Expressway behind of the firewall with NAT and in the same subnet of the VCS Control woud be a aceptable design since I don't have a NAT between the Expressway and the VCS Control? The Expressway would be useful for the solution?



cfiestas Thu, 12/01/2011 - 14:52


Example   <-------------->    68.x.x.x(public natted to .3)

VCSC                      VCSE

Just make sure you have the dual nic option installed eventhough you will not need the sec interface, and that the natted ip address this case 68.x.x.x is on the respective lan interface most likely where .3 is configured.


Cesar Fiestas

ryan_oconnell Thu, 03/15/2012 - 05:50

If I have the same requirements you are discribing above where my VCSC is in the same subnet as my VCSE   <-------------->    68.x.x.x(public natted to .3)

VCSC                      VCSE

Which  model to a follow in the guide to setup the traversal? None of them  talk about this scenario the closest one would be the 3 port firewall.  Anyway I would like to make it work as you discribed above in this  example.

On my VCSC I have pointed my Traversal peer to be and it shows "ACTIVE"

On my VCSE I have my "IP" configuration setup as follows

LAN 1 IPv4 =

IPv4 Static nat = On

IPv4 Static nat address = 68.X.X.X

Lan2 = Not plugged in

I have it setup  as follows and when I make and outbound call from endpoint to external  client <> the call proceeds, my jabber  client rings and I can answer, and I get "no incoming video"

When  I reverse the process and make a call from Jabber to I get the user can not be found and I see no search  history in my expressway.

I suspect my issues are FW related and DNS SRV releated.

What is the easiest way to test the the DNS SRV records are setup properly?

What is the easiest way to test the FW Static NAT rules are setup properly?


awinter2 Thu, 03/15/2012 - 06:05


with your scenario, you should configure the VCS-C's traversal client zone to speak with the public NAT IP, that is the only way the traversal zone will work properly.

You could optionally starting using LAN2 (making sure that LAN1 and LAN2 are in different subnets) and then configure the traversal client zone on the VCS-C to communicate with the VCS-E LAN interface which is not in static NAT mode.

In this scenario, the SRV records for should point to the DNS name of your public NAT IP 68.x.x.x (SRV records should ideally not point to an IP address, so I recommend creating a DNS A record which points to the NAT IP and then point the SRV records towards this A record.).

The easiest way to verify that static NAT is set up properly would simply be to check that incoming and outgoing calls are working on both H323 and SIP

You could optionally extend the testing to involve calls to external IP addresses, incoming/outgoing interworked calls and so forth.



ryan_oconnell Thu, 03/15/2012 - 19:53


Can you help me understand your comment "you should configure the VCS-C's traversal client zone to speak with the  public NAT IP, that is the only way the traversal zone will work  properly" On my VCS-C I now having it pointing to a peer address of 68.x.x.x but when i do this the Traversal Client is unable to connect to the VCS-E. Is this what you ment?  If I point my traversal zone to the public IP is the firewall suppose to hairpin it back to the VCS-E??

So now my setup now goes as follows

On my VCSC I have pointed my Traversal peer to be 68.x.x.x and it shows "FAILED"

On my VCSE I have my "IP" configuration setup as follows

LAN 1 IPv4 =

IPv4 Static nat = On

IPv4 Static nat address = 68.X.X.X

Lan2 = Not plugged in

When I change the Peer back to at least it goes to "ACTIVE"


awinter2 Fri, 03/16/2012 - 01:34

Hi Ryan,

yes, if your VCS-E is only using one LAN interface, and this LAN interface has static NAT enabled on it, all traversal clients (as well as endpoints registering to this VCS-E) will have to address this VCS-E through it's static NAT address, in this case 68.x.x.x.

This means that your firewall has to hairpin traffic from the VCS-C to the VCS-E, as you have noted. This is also referred to as NAT reflection.

Please consult Appendix 4 of "" for more details and an explanation of why it must be configured this way.



ryan_oconnell Fri, 03/16/2012 - 06:29


Would you happen to know a url or guide that shows how to configure "nat reflection" on an ASA running 8.4. When I search for this term all I get is links to this post. Does it go by some other name in ASA features?

awinter2 Fri, 03/16/2012 - 07:22


I believe the relevant ASA command in this case would be 'same-security-traffic permit intra-interface'.

More information about that command here:

I would however strongly suggest that you consider utilizing both LAN interfaces of the VCS-E instead of just one, so that the VCS-C can communicate with the non-NATed LAN interface of the VCS-E, since hairpinning would force the video traffic through your firewall multiple times, as well as introduce asymmetric routing.



ryan_oconnell Fri, 03/16/2012 - 12:15

Ok so if we decide to do it this way how should my interfaces look whould it be like this?

To do as you suggested my new setup will look like this>  (Lan1 = Lan2=> (fwIn<->FWOut)= 68.x.x.x(public natted to 20.2)

VCSC                                      VCSE

LAN 1 IPv4 =

IPv4 Static nat = Off

Lan 2 IPv4 =

Static Nat On

IPv4 Static nat address = 68.X.X.X


So if I set it up exactly like above, I gather that I woul Peer with and access the device from Should my Gateway for VCSE be set to or should it be set to the GW of the 10.10.10.x network?

Do I need to do any static routes on the VCSE box ?

Message was edited by: Ryan O'Connell, added picture easier to see

awinter2 Fri, 03/16/2012 - 13:51


with that scenario, you would set the default GW to

Whether or not you need to add static routes depends on if there is a router on the 10.10.10.x subnet which will be used to route traffic to subnets located behind this router (For example for reaching TMS, NTP, DNS and so forth), if that router is not performing NAT. If the router is performing NAT, static routes are usually not needed.

This is described in further detail in the appendix I mentioned earlier, and there is also an example scenario in there which you should be able to use as a guideline, with some adjustments.

- Andreas

yohanes1187 Sun, 11/09/2014 - 22:49

Hi Ryan / Andreas,

Have you got your solution about your issue? Currently I have the same issue with Expressway C & E while preparing demo for customer. The demo topology is similar with Ryan. Exp C & Exp E are in the same subnet, and Exp E is NAT-ed to public IP address.

When I pointed Exp C to Exp E peer with local IP, it shows ACTIVE. But when I pointed the peer to public IP, it shows FAILED.

I have also read about NAT Reflection in firewall to make this work. But in the customer site, unfortunately we cannot directly see the firewall configuration / device type to check whether it is support that feature or not.

From Exp C, we can ping both Exp E private IP Address and NAT-ed IP Address. My question is, how could I know if customer's 3rd party firewall support NAT Reflection feature or not besides ping result?


Thank you.


Yohanes Hartono


awinter2 Fri, 12/02/2011 - 00:48


that is not entirely correct. The article you linked to states that the "outside IP address" of the VCS-E needs to be a publicly routable IP address, which is correct. In this case, "outside IP address" means the public static NAT IP address for the VCS-E on the firewall/router outside the VCS-E (For a scenario where the VCS-E is located in a DMZ behind a static NAT).

In order for the VCS-E to be located behind a static NAT, the VCS-E must have the Dual Network Interfaces option key, which unlocks both the second LAN interface of the VCS-E as well as unlocking the static NAT functionality which is built into the VCS-E.



Marwan ALshawi Fri, 12/02/2011 - 01:02

Hi Anreas,

This article looks like stating or implying no static nat but either a DMZ with public ip not nated DMZ

Or the other option you mentioned with two interfaces where one ip can be places in a not anted DMZ and the other interface in private DMZ

Personally I had issue with one interface with static nat one to one with ASA till got it changed to non nated DMZ things fixed

Which is I believe stated clearly in the above article ! Let me know if I missunderstood anythingnhere ?


Martin Koch Sun, 12/04/2011 - 15:50

Like Andreas stated, its possible to have the VCS-E behind a static 1:1 nat, but then you need the

dual interface option. Even if you only use one interface, as this also enables the NAT ip address configuration.

If there is NAT in between the VCS-C and VCS-E or not does not matter.

Both would work fine out of the box with the traversal zone.

If the VCS-E (towards the public, for example on a private ip) is behind 1:1 NAT or two interfaces

(one internal one public) are required, the dual interface option is needed.

You find some more information in the VCS admin guide.


Marwan ALshawi Mon, 12/05/2011 - 00:13

Thanks Andreas and Martin

But the two interfaces option with one to be placed in the public is not accepted by most of the customers due to the security risk

If the two interfaces option chosen then one interface can be placed in a not NATed DMZ,  public IPs only which will make sure there is no firewall bypass from security point of view

awinter2 Mon, 12/05/2011 - 00:21


with the dual network interfaces option key installed on your VCS-E, you will have quite a lot of flexibility in terms of how you deploy the VCS-E:

- Using 1 network interface in a DMZ with a publicly routable IP address

- Using 1 network interface in a DMZ with a private IP address with Static NAT enabled

- Using 2 network interfaces in one or more DMZ's with a publicly routable IP address assigned to the externally-facing interface

- Using 2 network inerfaces in one or more DMZ's with private IP addresses assigned to both interfaces with Static NAT enabled

In any scenario where both NIC's are used, it is recommended that these interfaces have IP addresses in different subnets. It is also recommended that any firewalls which carry traffic to and from this VCS-E is not performing any sort of SIP and H323 application inspection/fixup as this might interfere with the built-in firewall traversal functionality (H.460 and Assent) of the VCS-E.

Hope this helps,


e.lopessilva Mon, 12/05/2011 - 06:57


Could you tell me what would be the options with a license for just one LAN interface actived?



awinter2 Tue, 12/06/2011 - 00:41

Hi Everaldo,

assuming that with "license for just one LAN interface", you mean not having the dual network interfaces option key, the only supported option is to assign LAN 1 with a publicly routable IP address not behind any sort of NAT (If connectivity with public networks/Internet is required, that is).

Marwan ALshawi Tue, 12/06/2011 - 04:52

Agree with Andreas and if you refer to my first post you will see same recommendation !

Ricardo Sicheran Fri, 01/13/2012 - 08:48

So say I have a dsl in bridge mode.  Then I will have to connect my VCS Starter Pack's only NIC to it and assign public ip to it.

So my internal endpoints will have to register through the public internet to get to this VCS-E?

Can you elaborate on how a call to finds their VCS?  For SIP is it just the two domain records _sip_ , _sips that need to resolve to your VCS outside address?

Do you have any solutions in a scenario where SIP traffic through a firewall needs to go to a CUBE setup for SIP trunk provider while video traffic needs to go to the VCS with option key enabled for NAT?

awinter2 Fri, 01/20/2012 - 02:28


yes your endpoints would then have to register with the public IP address of your Expressway.

The VCS will, as you state, use DNS SRV records for locating remote gatekeepers/SIP proxies, you can find more details about which records are used in the VCS Admin guide.

I'm not too familiar with CUBE and which DNS SRV records usually point to the CUBE, and I guess if the VCS and CUBE "share" similar SRV records that could pose a problem.

For the VCS, it is most common to receive SIP calls over TCP or TLS, e.g _sip._tcp and _sips._tcp.

Hope this helps,


vipersl65 Sat, 12/10/2011 - 00:30

Dont forget in your Control Traversal zone to point the peer to the public IP of the Expressway

maciej_wilk@sev... Fri, 12/23/2011 - 02:04


What about the following scenario?


If the VCS Expressway is in DMZ 2 with a private IP address will I need the Dual Network Interface Option?

From this topic I understand that yes but why can't it work without the option?

What configuration is necessary on Expressway for it to work?

And which IP do I point the VCS Control to? Private IP 192.168.x.x or NATed 212.212.x.x?

Unfotunately there is not much information in documentation for such deployments.

Thanks for help


awinter2 Fri, 12/23/2011 - 02:29


the reason why the VCS-E will need the dual network interfaces option key while deployed in DMZ is because you will need the static NAT feature of the VCS-E for this deployment to work.

In H323 and SIP, call signaling and media addresses are embedded into the signalling payloads of the H323 and SIP messages, and when the VCS-E is located behind a NAT, these payloads need to be altered to contain the public NAT IP of the VCS-E to ensure that external parties are able to reach the VCS-E when attempting to set up signaling and media exchange.

For instance, if you were to place a call from an endpoint registered to the VCS Control towards an endpoint at a remote location (For example, the call would be proxied via the VCS-E. Without using the static NAT feature of the VCS-E, the VCS-E would tell the remote endpoint to send media to the 192.168.x.x address which the VCS-E is assigned with (References to the 192.168.x.x address would be made inside H323/SIP messages). This would obviously not work, but with the static NAT feature of the VCS-E, the VCS-E would replace those embedded IP address references withthe public address 212.212.x.x, which means that the remote endpoint would send relevant traffic to this address instead, and connectivity should work properly (Assuming you have also configured the static NAT properly on the edge firewall/router.

Also, as vipers points out, using the above diagram as an example, where you are using only the LAN1 interface of the VCS-E, you would have to enable static NAT on this interface and configure the traversal client zone on the VCS-C with 212.212.x.x as the peer address in order for this to work.

Hope this helps,


maciej_wilk@sev... Fri, 12/23/2011 - 02:39

Hi Andreas,

Thanks for your quick and thorough explanation!

This is very helpful.

But I am wondering about one more thing - aren't the modern firewalls capable of changing the IP addresses in the payloads of SIP/H323 messages?


awinter2 Fri, 12/23/2011 - 03:02

Hi Maciek,

although many firewalls have SIP and H323 ALG capabilities which might work well for voice applications, my experience is that application-aware firewalls are usually not able to perform the required modifications for H323 and SIP traffic involving complex video with functions such as encryption, H.239 and similar. Many firewalls support older versions of H323 for example, and will therefore have problems when trying to inspect and modify H323 and SIP traffic generated by modern endpoints.

Also, the same firewalls would not be able to inspect/modify the contents of TLS-based SIP traffic since this is encrypted (And therefore should be the signalling type which you would want to use).

Because of the above reasons, the dual network interface option key is required in order to be eligble for support for VCS-E deployments in a NAT/DMZ environment.



maciej_wilk@sev... Fri, 12/23/2011 - 06:07

Hi Andreas,

Thanks for the comment.

One last question - why can't you point the VCS Control to the private IP address of Expressway?

It is NATted anyway.

Kind regards


awinter2 Fri, 12/30/2011 - 01:59


you shouldn't point the VCS Control towards the actual (private) IP address of the VCS-E interface which has static NAT enabled on it since all SIP and H323 traffic sent out this interface on the VCS-E will have relevant SIP and H323 payloads rewritten to make it appear as this interface actually has the static NAT address, thus causing a mismatch between the client and server end of the traversal zone which will induce problems when attempting to set up calls across this zone.



maciej_wilk@sev... Mon, 01/02/2012 - 03:03

Hi Andreas,

Since I don't have the Dual Network Interface license yet, I have configured the VCS Control to point to the private IP address of Expressway 192.168.x.x.

And suprisingly calls to external aliases work.

However they do not work to external IP addresses (the Indirect / Direct calls to unknown ip addresses settings are correct).

Any ideas why calls to aliases work and to IP addresses don't?

Kind Regards


awinter2 Mon, 01/02/2012 - 03:13


the reason for the 'Dual network interfaces' option being a requirement in scenarios with the VCS-E being located in behind a NAT/in a private DMZ is exactly this, that some call scenarios (in fact, most scenarios) will not work properly unless the VCS-E rewrites certain parts of H323 and SIP payloads.

When this is not done, you will see calls failing to connect properly or one-way media, depending on the call scenario and direction of the call.

I can't tell you straight up why your purticular scenario does not work, but in any case it does not really matter since the only supported deployment for a VCS-E behind NAT and/or in a private DMZ warrants the use of the Dual NIC option.

Best regards


maciej_wilk@sev... Mon, 01/02/2012 - 03:59


You mean in order to be able to open a TAC case and receive support you need to have this option, right?

Kind regards


Martin Koch Mon, 01/02/2012 - 06:47

Hi Andreas!

Regarding NAT and pointing to the external ip.

I did not had a customer case with the VCS but I had seen various NAT and DMZ installations

where it was not possible to connect from the inside to the external NAT address.

So your suggested method on pointing to the external IP might not work.

I had seen it on a cisco nat as well, as well as I had seen there some DNS workaround

which automatically translated the NAT IP to the internal instead of the external one

for internal lookups, but this would also just point to the internal ip, ...

Sure, the easiest workaround would be to use the second interface just for the internal

traversal zone and the "NATed" interface for the external communication.

(though I guess that I assume it right that both ips shall not be in the same l3 network)

But I would still like the idea that the VCS-C and -E would be able to handle a traversal zone poitning to the internal ip of the "NATed" interface.


t.svatek Mon, 01/23/2012 - 11:16

Hi Martin,

I fully agree with you: Routing the external IP from an internal Subnet to the DMZ would be very tricky. There should be the possibility to set the external NAT IP based on source IPs instead of setting it to a dedicated NIC. Some customers do have several static 1:1 NATs from/to foreign networks and I believe the only way to solve this today is to set up a dedicated VCS-E per foreign network.

Additionally I´m wondering, if there is no "simple solution" for the most common scenario:

3 Network segments: Internal (private IPs), DMZ (private IPs), Internet (public IPs with Portforwarding/1:1-NAT to DMZ).

Because the restriction, that you´re not allowed to set both VCS-E NIC into the same subnet (in our Case DMZ) and the fact, that the NAT IP would also be used to the VCS-C on internal LAN, I do not see a working solution for that very common case.

Any ideas from Cisco on that?



awinter2 Wed, 01/25/2012 - 00:58


from what I understand, the scenario which you are describing resembles a 3-port firewall. If this is the case, why are you not able to allow the VCS-C to communicate with the public NAT address of the VCS-E? This should be possible with the use of NAT reflection.

It would be helpful if you could describe in more detail why this scenario poses a challenge in your environment.



t.svatek Wed, 01/25/2012 - 08:44

Hi Andreas,

let´s say I´ve got the following common scenario:

Usually, direct traffic beetween Firewall1 and Firewall2 is not allowed, like Martin mentioned before.


  • How can I handle traffic between VCS-C and VCS-E without routing via Firewall Internet?
  • How can I handle several Static NATs from Outside to one VCS-E?



awinter2 Wed, 01/25/2012 - 14:12


for this design, it would make sense to connect LAN1 of the VCS-E to the DMZ firewall subnet and LAN2 of the VCS-E to the Internet firewall subnet, with static NAT enabled for the LAN2 interface of the VCS-E. LAN1 and LAN2 need to be in separate, non-overlapping subnets. With this deployment, the VCS-E would not route any network packets, and the only data which would be proxied between LAN1 and LAN2 would be the payload data of RTP media packets and H323/SIP signaling.

This way, the VCS-C will be set up with a traversal client zone towards the LAN1 address of the VCS-E, while external endpoints can register to the public NAT address of the VCS-E.

Why would you need multiple public static NAT addresses for the VCS-E? As long as the public NAT address is publicly routable and accessible for devices connecting via the Internet, you shouldn't need to assign multiple static NAT addresses for the VCS-E (The VCS-E is in any case limited to a single public NAT address).



t.svatek Wed, 01/25/2012 - 23:24

Hi Andreas,

most of our customers are not allowed to install any device directly to the Internet Subnet, as of their security policies. That´s why they set up a DMZ. Additionally, VCS-E would be open for management access via public internet in this scenario. I like Martin´s idea of beeing able to exclude the NAT IP in the traversal zone to VCS-C.

The foreign networks are connected to a separated Firewall Subnet and are not connected to the public internet. This often happens at customers, who own private interconnection networks to other partners. For example financial Institutions or public departments. Either they are using overlapping private IP addresses or public IPs, but without connecting them to the public internet. For those scenarios we have to use Static NATs to give access to Servers within the DMZ. That´s why i´m asking for the need to set up multiple NAT Adresses on VCS-E.

Also helpful would be the possibility to be able to use LAN3 and LAN4 Interfaces on VCS-E and beeing able to set them into the same subnet.



awinter2 Wed, 01/25/2012 - 23:39


I'm not saying that you should install the VCS-E in the Internet subnet, with my suggestion, both VCS-E interfaces will remain in the private addressing space, outside the DMZ firewall and inside the Internet firewall. Unless the VCS-E can somehow communicate with the Internet firewall, how would it in any case be reachable from the Internet side?

VCS-E would not necessarily be open for management from public networks, you should easily be able to block access to management/low ports from public networks in the Internet-facing firewall, so that shouldn't be an issue.

The VCS-E currently only supports having one static NAT address, so in your scenario, you would have to find a way to let these foreign networks reach the VCS-E via its current static NAT address.

- Andreas

t.svatek Thu, 01/26/2012 - 00:02

Hi Martin,

sorry for misunderstanding you. Outside DMZ Firewall and Inside Internet Firewall is unfortunately the same subnet.

Not sure, if I understand you right, but the VCS-E would be reachable via the static NAT from the internet.

To summarize this, my wishlist for future releases would be:

  • being able to exclude the NAT IP from Traversal Zone and/or set both LAN1 and LAN2 into the same Subnet.
  • being able to use LAN3 and LAN4



awinter2 Thu, 01/26/2012 - 00:20


it may be that in your case, outside DMZ firewall and inside Internet firewall is the same subnet, which would then not be a viable solution for the VCS-E, but in general, if these firewalls had their outside and inside interfaces, respectively, in different subnets, or if they have multiple interfaces or are VLAN capable, then the concept is that the VCS-E would connect to each of these subnets with each of its interfaces.

That being said, it is not always the case that a dual-NIC VCS-E can be dropped into any existing deployment and be expected to work "out-of-the-box", considerations will always have to be made and in some cases, the network will have to be modified or re-designed somewhat to allow the VCS-E to function properly in a static NAT environment (as is the case with many other network devices as well).

Regarding your comment on the VCS management (HTTPS, SSH) being reachable from the Internet via the static NAT, if you are in control of the Internet-facing firewall, you would be able to create firewall rules preventing traffic from Internet to TCP ports 22, 80 and 443 of the VCS-E, and this is the recommended way to do things in any case.

What would you like to use LAN3 and LAN4 for? Link aggregation for resiliency and increased bandwidth, or other applications?



t.svatek Thu, 01/26/2012 - 01:22

Hi Andreas,

yes, I try to get a second DMZ Subnet whenever possible. What Martin mentioned before ist, that many customers do have a very simple firewall solution (for example one 3port Firewall) and in these cases, pointing the VCS-C to the public IP of VCS-E often isn´t possible. I can confirm that and that´s why I´m asking to consider a feature enhancement for future releases.

Regarding Static Multiple Static NATs: Other devices like email servers are working fine also with multiple Static NATs from different external IPs to the same private IP in the DMZ. For example in my drawing if VCS-E would be a email Server, it would work with both Static NATs from external to the same DMZ IP. That´s why customers expect that this would also work with VCS-E, but it doesn´t because of IPs included in SIP protocoll and the fact, that VCS-E can handle "only" one NAT IP per LAN Interface. (Regardless I´m glad that it works at all).

If I would be able to use LAN3 and LAN4 I would be able to handle 2 additional networks with NAT. But usually, there is only one additional network to be NATed to the VCS-E.

many thanks for your advice


ruben.montes Wed, 01/25/2012 - 14:56


I have one question regarding the manipulation of the SIP header done by the VCS-E when there's local NAT done by the firewall. In the opposite flow, from home Movi for example to VCS-E, what happens when home router does NAT? In this situation the IP address in the SIP header (Movi private address) is different than the IP address in the L3 header (PATed public address). This is real scenario as well as home Movi with direct public IP.

My topology is a little bit different but I'm ahving some troubles:

VCS Starter Package with Dual interface but only LAN1 connected to inside --> L3 switch --> Firewall --> Internet

In this topology, there are some external calls that fail, from the troubleshooting, only the calls that come NATed by a home router are working properly. When the Movi client has a public IP, it is not working.

Any idea?


Martin Koch Wed, 01/25/2012 - 16:38

Could you define "failed"?

* Provisioning failure

* Registraion failure?

* Does the remote site ring on a call?

* what happens if answer is clicked

* does video / and or audio not work

* does the problem occur in both directions?

* ...

* Did you check that the Firewall has proper firewall openings to all used ports, inbound and outbound?

(expecially / in / out)

* did you enter the external IP address in the NAT config of the VCS?

* is there an additional firewall in between the internet and the endpoint on the public ip?

* do you use turn / ice?

* which movi / vcs versions do you use? (to test bugs I would alsways use the latest, here X7.0.3 and Jabber 4.3)

If movi is on a public ip and a firewall blocking ports (which shall be open) you might see issues.


This Discussion