Just got a mail from Cisco regarding a bug in the Linux kernel making some processes on the VCS go haywire and create a heavy CPU load on the box.
The fix is currently to boot the VCS.
The supposed bug is discussed here: http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today
UPDATE: Cisco supportforum post
There seems to be a bug eith the openSSL running on VCS X6.0. It has some problems with .pfxes created by the MS Certificates snapin. Should be fixed before X6.3.
In the mean time, we’ll have to use openSSL elsewhere to create certs for the VCSes and Codian MCUs.
My exellent colleague Marjus has done some testing with VCS and Lync integration!
Read his post here.
Here are the service records needed to use the Tandberg VCS:
_h323ls._udp.company.com srv 1 0 1719 vcs-e.company.com.
_h323cs._tcp.company.com srv 1 0 1720 vcs-e.company.com.
_sip._udp.company.com srv 0 0 5060 vcs-e.company.com.
_sip._tcp.company.com srv 0 0 5060 vcs-e.company.com.
_sip._tls.company.com srv 0 0 5061 vcs-e.company.com.
_sips._tls.company.com srv 0 0 5061 vcs-e.company.com.
_sips._tcp.company.com srv 0 0 5061 vcs-e.company.com.
There should also be an a-record pointing to the vcs express. (in this example, vcs-e.company.com)
Also, should anyone ever need it, here are the ports that an endpoint needs opened outbound if it is registering directly to a VCS express:
TCP/2776 (Q931/H245 for external traversal endpoints)
UDP/2776 (RTP Media from external traversal endpoints)
UDP/2777 (RTCP Media control traffic from external traversal endpoints)
UDP/1719 (H323 RAS signaling from gatekeepers/VCSes and traversal endpoints)
TCP/1720 (Q931/H.225 call connect signaling)
UDP/5060 (SIP signaling)
TCP/5060 (SIP signaling)
TLS/5061 (Encrypted SIP signaling)
Todays topic is Bandwith and call control
There will also be a test today.
To be able to call out on the internet on the VCS, you need to add the DNS Zone. It should only be added on the Express, not on the control. It will not be there by default. On the Gatekeeper/BorderController this is not necessary.
If you are neighboring gatekeepers, you need to use a pattern type to reach the endpoints on another gatekeeper. It will work fine without, but if you plan to use bandwith control the call will not be in the correct link if you don’t use a pattern. This is possibly a bug, and will probably be fixed in version X3.
SIP <-> H.323 interworking will also work when contacting an endpoint on the outside, but it will consume 1 ekstra traversal license because of the interworking, so it will use 2 traversal licenses.
And I passed the TCEP as well 🙂
Todays topic is Call Control Components – GK, VCS-C, VCS-E
When you factory reset these units, all option keys will disappear.
When a CCC is in routed mode, RAS. Q931 and H.245 info will go through the device, as opposed to non-routed mode, where only RAS will pass through the device. In SIP, all calls are in routed mode, but with H.232 this is optional. The VCS is always in routed mode though.
The VCS has a SIPH.232 interworking feature. Note that using this interworking feature will count as 1 traversal call.
For the sake of redundancy, there is a possibility to set up alternate Gatekeepers. When using this, the endpoint will recieve a list of alternate gatekeepers. If the gatekeeper the endpoint is registered to goes down, the endpoint will connect to the next endpoint on the list. Be sure to set the H.323 TTL down to something shorter than 1800 seconds if the environment demands faster recovery from an outage. Note that a gatekeeper can only be alternate to another gatekeeper, and a bordercontroller can only be alternate to another bordercontroller, a gatekeeper can not be alternate to another bordercontroller and the other way around. This also applies to VCScontrol/express.