Scenario: Currently I have a Cisco MCU5310 sitting on internal network using only Port A with internal IP address settings but I could not call in from external network. There is no NAT settings option like normal Cisco C40/C60.
q1. if I would like to make a mix of VC sessions with internal and external parties, do I need to use Port A for internal network connection and Port B for external network connection?
q2. Or rather I can use only Port A for both external and internal VC session just like a normal Cisco C40/C60 but would need the IT firewall team to do the NAT routing of the traffic from external to internal vice versa for the MCU to work connecting both internal and external VC parties?
q3. What would be the firewall ports that are required to be opened and the settings needed to set in the Cisco MCU5310 in this case?
I advise you to move this post to Telepresence community to get TP experts respond. This community is for Cisco WebEx Meetings Server and Cisco Unified MeetingPlace products and is not observed by Telepresence experts.
I hope this helps.
You will need the 2nd port licensed in this case. http://www.cisco.com/c/en/us/td/docs/telepresence/infrastructure/articles/mcu_ip_vcr_configure_video_firewall_27.html
Do you have a VCSC/VCSE? Thats the ideal way to go about with this configuration.
For this setup, we do not have VCSC/VCSE.
Can other parties from external network call in to MCU5310 with only one port configured on internal network?
If the IT tech support configured the required ports routing on the firewall, will it help to resolve the external parties call in issue or 2nd port is a must to be enabled?
It's possible for external and internal endpoints to call into the MCU at the same time with only one IP assigned to the MCU, but it depends if you have your network routing setup to allow both internal and external traffic to reach that one IP. We did this with our MCU some years ago, we used a single IP on the MCU and was open on the firewall to allow incoming external endpoints to connect directly into conferences, while at the same time internal endpoints were doing the same. You can either open up the IP of the MCU completely or just the required ports needed on your firewall.
Ideal, if you don't have a VCS, you'd use the second port (video firewall) on the MCU, and of course the preferred method is the use of a VCS. In either case, it just depends on what you have and how you're capable of deploying it within your environment, such as having the video firewall option key on the MCU or using a VCS.
Thanks for your feedback.
At first I thought it is a must to enable 2nd port in order to make it work for external parties.
Looks like there is some configuration issue with the IT support side on the firewall ports routing although they mentioned they have opened the ports required for us.
I will double check with them on this.
It's not a must, just prefered to make the MCU and the network its deployed on more secure than just using a single IP for both internal and external communication, since the video firewall port (port B), allows you to connect the MCU to both the internal and external network at the same time by keeping the data going through the two ports separate.
I have placed the MCU5310 back at customer side after tested working in our office using Port A network port only and we are able to do two-way calls without issue. When this unit is placed back at customer side which IT has mentioned he has opened up all the ports but we are still encountering issue.
When initiate call from MCU to external endpoints, the call can be connected but the endpoints are not able to see/hear anything from the Cisco MCU Welcome Page.
When I tried to dial in from external endpoints to MCU WAN IP Address, the call cannot get through but I have used command prompt window "telnet WAN IP Address 1720" and it looks that it has open up the port but somehow the endpoints keep ringing after around 15-20 seconds, the call ended itself.
Anyone could advise how we can work further from here or if the firewall could have problem in packet identification which causes the data packets lost?