Cisco Cisco TelePresence Video Communication Server Expressway
Cisco Multiway without TelePresence Conductor
Cisco TelePresence Multiway Deployment Guide (Cisco VCS X7.2 and Conductor XC2.0)
Page 16 of 35
VCS with H.323 endpoints initiating a Multiway conference
The Multiway Conference Factory functionality is SIP based. To allow H.323 endpoints to initiate a Multiway
conference:
conference:
1. Go to
VCS configuration > Protocols > Interworking
.
2. Set H.323 <-> SIP interworking mode to Registered only (or On is also acceptable).
SIP endpoints with SIP MCU
No special configuration is required beyond that of setting up the VCS to work with a SIP MCU.
SIP endpoints with H.323 MCU
An H.323 MCU registers with E.164 service prefixes, therefore, for a SIP call to be placed onto an H.323
MCU, the dialed URI must be converted to an E.164 number and the leading digits of that number must
match the service prefix. This is carried out using the local zone match and transform defined in the “
MCU, the dialed URI must be converted to an E.164 number and the leading digits of that number must
match the service prefix. This is carried out using the local zone match and transform defined in the “
” section above.
To enable the VCS to perform the SIP to H.323 interworking:
1. Go to
VCS configuration > Protocols > Interworking
.
2. Set H.323 <-> SIP interworking mode to Registered only (or On is also acceptable).
H.323 endpoints with H.323 MCU
No special configuration is required beyond that of setting up the VCS to work with an H.323 MCU, and
setting up the configuration for “
setting up the configuration for “
”.
H.323 endpoints with SIP MCU
No special configuration is required beyond that of setting up the VCS to work with a SIP MCU, and setting
up the configuration for “
up the configuration for “
”.
VCS configuration: in a cluster
If the VCS is in a cluster, each VCS in the cluster will be configured with the same alias, but, each template
must be unique.
must be unique.
The %% value is not shared between cluster peers, so each peer must generate a unique ad hoc conference
ID (so that if conferences are set up by different VCS peers, they cannot issue the same conference ID).
This is most easily done by adding a VCS ID between the <Conference prefix> and the %%.
ID (so that if conferences are set up by different VCS peers, they cannot issue the same conference ID).
This is most easily done by adding a VCS ID between the <Conference prefix> and the %%.
For example, if the <MCU service prefix> is 555 and <Conference prefix> is 77, then a 3 digit VCS ID could
be used, such as 001 for the first VCS, 002 for the second. Thus VCS 1 would have a template:
55577001%%@example.com, VCS 2 would have a template 55577002%%@example.com.
be used, such as 001 for the first VCS, 002 for the second. Thus VCS 1 would have a template:
55577001%%@example.com, VCS 2 would have a template 55577002%%@example.com.
VCS configuration: in a network of VCSs
If the VCS is in a network with other VCSs, one or more VCSs may have Conference Factory enabled.
Each VCS with Conference Factory enabled, whether it has the same or different alias configured, must
generate a unique ad hoc conference ID. Therefore, just as with clusters, every VCS that has Conference
generate a unique ad hoc conference ID. Therefore, just as with clusters, every VCS that has Conference