With Arne B. Østensen
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn about the Cisco TelePresence Video Communication Server and the new features in X7 Software Release with Expert Arne B. Østensen. Arne B. Østensen is the team lead of the Cisco TelePresence Solution Group in Cisco's Technical Assistance Center in Lysker, Norway. Before joining Cisco, he worked at Tandberg as a product specialist for telePresence infrastructures. He has over four years of experience working and supporting telePresence products.
Remember to use the rating system to let Arne know if you have received an adequate response.
Arne might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the sub-community discussion forum shortly after the event. This event lasts through October 28, 2011. Visit this forum often to view responses to your questions and the questions of other community members.
First i would like to say thank you for this opportunity, it is great when you can ask the industry experts directly. I have few questions and would appreciate your help.
1.0 Will the Cisco Video Communications Server (VCS) be discontinued going forward and Cisco CUCM take over as Voice/Video call processing server? I hear rumors this been the plan going forward?
2.0 I have increasing requests from customers asking to use their existing voice gateway (Cisco ISR 28XX, 29XX, or 39XX) registered to CUCM as ISDN video gateways. Is this possible to achieve? Is there any Cisco documentation for this?
3.0 If yes on question 2, what is the best way to integrate the Cisco ISR with VCS? Are there any licensing or specific feature requirements on the Cisco ISR routers?
4.0 If not what is the best way to achieve ISDN availability for devices/endpoints registered to VCS.
5.0 Can you briefly explain the main new features in X7 Software?
6.0 I know this topic only mansions VCS, if you don’t mind i was attempting to register the Cisco C20/C40 (TC 4.2.1) end points to CUCM 8.6, but with out any luck. Is there any Cisco documentation on how to register the Endpoints to CUCM?
Hi, thanks for taking the time to answer questions! I have a couple...
We have a large VCS/TMS/Telepresence Server 8710 deployment + CUCM (CUCM is voice only at the moment). Now that endpoints can register to CUCM, what are the pros and cons between using VCS and CUCM?
Can you explain VCS clustering in version 7? I am experienced in CUCM clustering but am not familiar with clustering in VCS.
The C-series TC5 software now supports CUCM 8.6. The VCS is still the gatekeeper that supports the C-series the best will all its features like FindMe, Multiway, Interworking etc., but if you don’t have a VCS you can now buy these endpoints and register them to your Cisco Unified Call Manager solution instead. So if you register the C-series to CUCM, you will lose some features, but also gain some new features in CUCM. If I had both solutions (VCS and CUCM), I would register the C-series on the VCS.
A Cluster of VCSs contains a master peer with one or more slave peers. A fully loaded cluster contain six VCSs whereas four is active and two is for redundancy. If you configure anything on the master peer, the slave peers will be replicated with the same configurations. Clusters are used for large video networks, which require redundancy and fail over. E.g. for registration failover functions you can use SIP Outbound, DNS SRV records, DNS round-robin or Alternate gatekeepers (H.323).
Clustering works pretty much the same as in previous VCS versions, but in X7 we have added the shared call licenses function. This means the peers doesn’t have to have the same amount of call licenses installed. If one of the peers goes down, the cluster database will have information about these licenses and the call licenses can then be used on another peer in the cluster (for two weeks). A VCS Cluster is using IPSec (Internet Protocol Security) to enable secure communications between each cluster peer.
To find more information about the VCS clusters, please take a look at our admin and cluster deployment guide;
1) There are no plans to discontinue the Video Communication Server, in fact VCS development plans are escalating as the long term vision for VCS is to be the Cisco NAT traversal mechanism and the interface to 3rd party products. E.g. you will have noted the new development of a B2BUA for OCS/Lync in VCS X7.0. Also there are a number of people today that do not have CUCM, and they are very happy with the Call Control capabilities today. We intend to continue to support them with further releases. Likewise there are people with CUCM and not VCS; they may choose to register endpoints to CUCM to get video connectivity. However, for the best experience; a system using CUCM for voice and VCS for video is still recommended.
2) Yes it is supported, but these gateways only support voice calls. You need the Cisco Telepresence ISDN gateway if you want to do video calling over ISDN.
3) To configure the ISR, create a SIP neighbor zone towards the ISR gateway from the VCS, and you should be good to go.
4) We recommend to use the Cisco Telepresence ISDN Gateway
5) The X7 software is a huge update for the Video Communication Server. This to make integrations easier, simpler scalability and greater flexibility. So in one word the new features in X7 equals to “Superb”. In a lot of words, please see the X7 software release notes, or my presentation deck.
6) TC4.2.1 is not supporting CUCM. The TC5.0 software will add support on the C-series for native registrations on CUCM version 8.6. When the TC5.0 software are released (now in beta), we will also release documentation for the configurations needed.
Thanks a lot for your responce, very helpfull.
Just to clarify in regard to the Cisco ISR routers as ISDN video gateway, I have a customer with a 2921 gatekeeper using it as ISDN gateway for Video, the ISR router is also configuried for H320 (ISDN Channel bonding). Polycom and C20 End points are registered to it. video works inbound/outbound. So my question is will it be posible to register the polycom and C20 to VCSc and still use the H320 gateway for Video?
We currently use a ISR our self in our production environment but only for audio calls. I have no experience with video on this ISR, yet.
I will do some tests here and get back to you if this is supported through the VCS or not. My guess is that it will work, but I'm not 100% sure.
In the mean time, could you send me the following information:
- "show diag" from the ISR
- What BRI/PRI cards does the ISR have?
- What hardware do you use?
Please send me this information through this forum in a private message.
This was a very useful presentation, and it's great to see all the practical improvements and the direction the VCS is headed. I was hoping you could address the options for authenticating against multiple AD domains (in separate forests).
a) Based on the NTLM challenge process, it seems that the VCS will only authenticate Movi users with accounts in the domain to which the VCS belongs to. Is this correct?
b) If so, could the VCS utilize a trust relationship with a separate AD domain to authenticate users on the other domain? For example: The VCS has joined the Cisco AD and is authenticating Cisco Movi users. Then if a two way trust relationship is created with the external Tandberg AD domain, will Tandberg AD user accounts be able to be authenticated by the VCS?
Thanks Arne - great answer!
I now have another question as I've just been asked to address a new requirement...
What's the best way to get VCS Expressway to be able to dial public facing SIP/H323 endpoints that it doesn't have a peer relationship with? e.g. dial by SIP URI or IP address over the public internet from an internal endpoint with VCS expressway proxying the signalling + RTP?
I know that internal endpoints can dial each other by IP address etc, but it's my understanding that this traffic is direct between endpoints with no need for a proxy such as Expressway.
The Expressway use the DNS zone to dial non-registered/non-neighbored systems. If you dial something@domain, the VCS Expressway will first try to find the Video SRV-record of the domain; E.g. for SIP unencrypted the SRV-record equals “_sip._tcp.domain”. This SRV-record will then point to a A-record/IP-address where the system can be found for that domain (Endpoint or gatekeeper).
The VCS supports firewall traversal (Assent and/or H.460.18/19) to overcome problems with firewalls (in and out). When you dial from an internal system, there is normally one or more firewalls blocking the signaling and/or media. That’s why we need a VCS Control and Expressway to implement firewall traversal for the call (signaling and media). You could of course open the required ports, but this would be a huge job and a lot of maintenance for the network engineers. Also business security could be compromised if you open the required ports for all endpoints.
If you are dialing from an internal endpoint to another internal endpoint, the VCS will normally only take the signaling (if endpoints are registered to VCS), and the media will go directly between the endpoints. If the VCS has to do something with the media or signaling (interwork SIP <> H.323 / IPv4 <> IPv6 / traversal / gateway interop / etc.) all signaling and media will flow through the VCS(s), and it will consume a traversal call license.
So to sum up; It doesn’t matter if you are calling H.323/IP or SIP. The endpoints/clients will pretty much act in the same way. If you are calling public to internal (or vice versa), you probably need to have great skills on the firewall(s), or simply use our traversal firewall solution to make successful calls.
Thank you for your detailed response for Nick question about signalling and media traffic for VCS Control.
1). Please clarify how the flows media and signalling when operating VCS-Expressway and two remote endpoints on the different sites that are registered on this VCSE. Is there a difference in H323/SIP? Do I understand correctly that the all traffic (signaling and media) will pass through proxy VCS-E if remote endpoints have their own private address?
2). The сustomer has a lot of equipment ex-Tandberg (MXP, C-series, EX, VCS, VCS-E, Movi ...). What protocol (H323 or SIP) you recommend to use as the primary and why?
Will the new device, such as MX100 or MX400 support H323?
1) There’s a big difference for SIP compared to H.323 registrations on the technical level, but in theory they have pretty much similar logic.
If the VCSE cannot reach the system directly, and the signaling needs to be traversed over a firewall etc. to be able to connect to the system (e.g. a NATed system). VCSE will suggest Assent or H.460 registration for the endpoint (H.460 is only for H.323). If the endpoint support this, this will be its first choice. If one of the systems in a call is behind a firewall, the VCSE needs to take the media as well to make sure all the media is being routed correctly. This will consume a traversal license on the VCSE.
However, if two endpoints is assigned on public IPs and no interworking is needed, then the media will go directly between the endpoints, and the signaling will be routed through the VCSE and one non-traversal call license is consumed (if signaling routed is set to “Always”). SIP also supports ICE/TURN, which relay the media to the fastest working (optimized) route.
2) More and more endpoints will have SIP support. SIP is a pretty new protocol for video (has been used for IM and audio for a long time), so it’s not as standardized as H.323 yet. I promise SIP will get there – and even more features will be supported on the SIP compared to H.323 protocol for the future. I would in most cases recommend to use mixed protocols (that’s why we have the interworking on the VCS!). But this relies on your dial plans, interoperability with other parties, license consumption etc..
So I cannot recommend one of these, but if I could choose myself, I would probably prefer SIP over H.323.
3) MX-series supports both SIP and H.323
Thanks for your feedback.
A) A single VCS (or a cluster) can only handle one domain. We have no plans to support more domains on a single VCS/cluster, for now. The VCS will only try to challenge AD with NTLM if the client is sending “DOMAIN\user” as it’s user name. If not, VCS will try the other configured authentication mechanisms.
B) No, unfortunately this won’t work. To utilize more “authentication domains”, I suggest to use one VCS/cluster per AD domain. Of course this will be a more costly solution, but it will also provide more flexibility and it will of course be supported.
Hope this helps.
Hyvää päivää Tom!
There is an advanced settings tab in the b2bua config shoing the used vcs ports.
Also useful on the VCS web interface: Maintanance > Tools > Port Usage > *
More in the deployment guide:
I tried it out earlier (without the guide) and it workd fine!
Hilsen fra Norge,
Please remember to rate helpful responses and identify