TelePresence Bootcamp Module 05.

01

VCS
Overview
2

Modification History
Revision Date Originator Comments
Initial
Release
11/28/2012 Vernon Depee






Table of Contents
Modification History ..................................................................................................................................... 2
1 Overview ........................................................................................................................................... 4
2 VCS Basics .......................................................................................................................................... 4
2.1 What is a VCS? .......................................................................................................................... 4
2.2 Control/Expressway .................................................................................................................. 4
3 Configuring a VCS .............................................................................................................................. 4
3.1 Dial Plan .................................................................................................................................... 4
3.1.1 Matching Methods ............................................................................................................ 5
3.1.2 Search Rules ...................................................................................................................... 5
3.1.3 Transforms ........................................................................................................................ 6
4 VCS Troubleshooting ......................................................................................................................... 6
4.1 VCS Troubleshooting tools ........................................................................................................ 6
4.1.1 Netlog ................................................................................................................................ 6
4.1.2 Tcpdump ........................................................................................................................... 6
4.1.3 Search History ................................................................................................................... 7
4.1.4 System Snapshots ........................................................................................................... 10
4.2 Calls not connecting ................................................................................................................ 10
4.3 VCS calls dropping ................................................................................................................... 11
4.4 VCS Registration Failing .......................................................................................................... 11
4.5 VCS not booting ...................................................................................................................... 11
5 Provisioning ..................................................................................................................................... 11
6 VCS Applications ............................................................................................................................. 17
3

6.1 Presence .................................................................................................................................. 17
6.1.1 Presence Server............................................................................................................... 17
6.1.2 Presence User Agent ....................................................................................................... 17
6.2 Conference Factory ................................................................................................................. 18
6.3 FindMe .................................................................................................................................... 18
7 Clustering ........................................................................................................................................ 18
7.1 Pre X6.1 ................................................................................................................................... 18
7.2 Post X6.1 ................................................................................................................................. 18
8 Zones ............................................................................................................................................... 19
8.1 Default Zone ............................................................................................................................ 19
8.2 DNS Zone ................................................................................................................................. 19
8.3 Neighbor Zone ......................................................................................................................... 19
8.4 Traversal Zone ......................................................................................................................... 19


4

1 Overview
The VCS is the core of the video network infrastructure. The VCS does a lot. When I say that the VCS
does a lot, I mean the VCS really does a lot. As of the writing of this document, the VCS has a 495 page
administrator guide. This doc is meant to help new users understand what the VCS is and what it does,
but the VCS administrator guide should still be considered required reading in order to fully understand
as much as possible about the VCS.
The VCS administrator guide can be downloaded from the Cisco website:
https://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administ
rator_Guide_X7-2.pdf
2 VCS Basics
2.1 What is a VCS?
The VCS operates as a gatekeeper and registrar. This means that SIP/H323 devices can register to the
VCS. When these devices intend to place calls, they send the call requests to the VCS which then in turn
attempts to establish the call using the call policy configured on the VCS.
All signaling messages going out of an endpoint and coming into the endpoint will come from that
endpoints VCS. Media may go through the VCS, but it will only do so under some circumstances The
call must be crossing a traversal link, the call must be interworked, or the call (if on an expressway) must
be between two endpoints that the VCS has detected cannot establish media in a point-to-point nature,
such as them both being behind two separate NAT/PAT connections.
2.2 Control/Expressway
The VCS comes in two flavors the control and expressway. The two VCSs have very little in the way of
differences aside from how they are meant to be deployed.
The VCS control communicates with the expressway via a traversal zone. The traversal server is on the
VCS-Expressway and the traversal client is on the VCS-control. The VCS-control is meant to be installed
inside of a firewall (and likely inside a NAT), while the expressway is meant to be installed on a different
side of the firewall (either a DMZ or the public internet). The traversal client on the VCS-control is
configured with the IP address of the traversal server for the VCS-expressway. The only configuration for
this zone on the VCS-expressway is the authentication account. This means that the link can be
established if the VCS-expressway cannot communicate directly with the VCS-control due to a NAT. The
control establishes the connection and the expressway is able to respond to the VCS-expressway via the
NAT/PAT entries.
3 Configuring a VCS
3.1 Dial Plan
The Dial Plan is how the VCS determines what calls should be connected. The dial plan can control the
following:
Should a call be allowed?
5

Should a call to a certain number be changed into a different number?
Where should we route call attempts?
The VCS handles its dial plan in the following order: CPL, Transforms, and then Search rules.
3.1.1 Matching Methods
Transforms and search rules can be used to change the destination address. When changing the
destination address, you first need to match the destination address. The VCS allows 4 ways to match
the destination address: an exact match, a prefix, a suffix, and Regular Expressions.
Note: The VCS comes with a tool that can be used to test matching methods. It can be reached at
Maintenance > Tools > Check Pattern.
3.1.1.1 Exact Match
Exact matches only match an exact string. Once this exact string has been matched, you can add a
prefix, suffix, or completely change the destination alias.
For example, if the exact pattern to match is 555 and the alias is 555 this would be considered a match
and we could change it to 556 with a replace, 9555 with a prefix, or 55510 with a suffix. In search rules,
we also have the option to leave it as is.
If the pattern to match is 555 and the alias is 556, then it would not be considered a match and would
not be changed.
3.1.1.2 Prefix
Prefixes match only the beginning of the string. Once a prefix has been matched, you can add a prefix,
suffix, strip the prefix, or replace the prefix.
For example, if the prefix to match is 555 and the alias is 555438 this would be considered a match and
we could change it to 9555438 by adding a prefix, 55543810 by adding a suffix, 438 by stripping the
prefix, or 867438 by replacing the prefix. In search rules, we also have the option to leave it as is.
3.1.1.3 Suffix
Suffixes match only the ending of the string. Once a suffix has been matched, you can add a prefix,
suffix, strip the suffix, or replace the suffix.
For example, if the suffix to match is 438 and the alias is 555438, this would be considered a match and
we could change it to 9555438 by adding a prefix, 55543810 by adding a suffix, 555 by stripping the
suffix, or 555898 by replacing the suffix. In search rules, we also have the option to leave it as is.
3.1.1.4 Regex
Regular expressions allow us to be very creative when matching strings.
3.1.2 Search Rules
On a VCS, search rules are used to direct calls to a certain source as well as modify the destination.
6

Search rules can be set to pass calls to an alias or an IP address to a certain zone. When passing calls
whose destinations are an IP address, the VCS cannot match certain IP addresses. It will only match all ip
addresses and only if the VCS is set for indirect routing mode.
Search rules to an alias can be set to match all aliases or to match specific aliases defined by a prefix,
suffix, an exact match on the destination string, or a regular expression.
After making a match, we can either leave the destination as it is or transform the destination before
passing the call to a zone. If we pass the call to the local zone, then we are attempting to connect to a
party registered to the VCS. We can also connect to a different zone to pass the call to another device.
If we match a search rule, but are unable to complete a call, then we can either continue on to the next
search rule or stop searching and terminate the call as configured in the search rule configuration page.
3.1.3 Transforms
Transforms are available for us if we want to make permanent changes to the destination alias. Unlike
search rules, transforms are a permanent change to the destination alias. These can be matched in the
same ways as the search rules by exact pattern matches, suffixes, prefixes, and regular expressions.
Transforms are usually used to make sure that before we pass a destination to a search rule that it
matches the format that the search rule expects. This could be something as simple as stripping a prefix
or making sure that the alias has a domain and is in URI format.
4 VCS Troubleshooting
4.1 VCS Troubleshooting tools
4.1.1 Netlog
The netlog is the most useful troubleshooting tool for the VCS. The netlog shows all signaling messages
in and out of a VCS as well as why the VCS is routing these messages to certain parties. To collect a
netlog in X7 and later, go to maintenance > Diagnostics > Diagnostic logging and set the related log
levels to debug. Press start new log then begin your test. Once the test has been completed, click stop
logging and download the log.
To collect a netlog in versions of VCS prior to X7, ssh in as admin, make sure you are capturing the
output of the session and type netlog 2. Once you are done collecting the logs, type netlog 0.
4.1.2 Tcpdump
TCPdumps can be run from the VCS in order to troubleshoot signaling or media issues. Instructions for
the tcpdump command can be found in the Linux guide. Please be sure to make sure that any endpoints
that you want to log with a tcpdump are set to be non-encrypted on both signaling and media. If you
have a tcpdump of an unencrypted call (both media and signaling), you can run it through Zoltes to turn
the packets back into a video stream. CALO Zoltes Login with your CEC
7

4.1.3 Search History
The VCS search history shows all search attempts that are run through the VCS. When the VCS receives a
request to establish a call, there will be an entry in the search history. If there is no entry in the search
history, then the call never reached the VCS. The search history can be reached by going to status >
search history on the VCS web interface. If you click on view under actions for a specific call it will detail
everything that this call has gone through, including cpls, findme, transforms, and search rules as well
as the response from the zones it is searching in.
Here is an example search:
Search (62)
o State: Completed
o Found: True
o Type: SIP (INVITE)
o CallRouted: True
o CallSerial Number: a9167580-1489-11e2-a1ce-005056a11a90
o Tag: a9167634-1489-11e2-8250-005056a11a90
o StartTime: 2012-10-12 12:27:05
o Duration: 0.09
o Source (1)
Authenticated: True
Aliases (1)
Alias (1)
Type: Url
Origin: Unknown
Value: test.c60@vdepee.local
Zone (1)
Name: LocalZone
Type: Local
Path (1)
Hop (1)
Address: 14.80.96.130:5061
o Destination (1)
Alias (1)
Type: Url
Origin: Unknown
Value: sip:86702@vdepee.local
o SubSearch (1)
Type: Transforms
Action: Not Transformed
ResultAlias (1)
Type: Url
Origin: Unknown
Value: 86702@vdepee.local
SubSearch (1)
Type: Admin Policy
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: 86702@vdepee.local
8

SubSearch (1)
Type: FindMe
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: 86702@vdepee.local
SubSearch (1)
Type: Search Rules
SearchRule (1)
Name: LocalZoneMatch
Zone (1)
Name: LocalZone
Type: Local
Protocol: SIP
Found: False
Reason: Not Found
Gatekeeper (1)
Address: 14.80.99.95:0
Alias (1)
Type: Url
Origin: Unknown
Value: 86702@vdepee.local
Zone (2)
Name: LocalZone
Type: Local
Protocol: H323
Found: False
Reason: Not Found
Gatekeeper (1)
Address: 14.80.99.95:0
Alias (1)
Type: Url
Origin: Unknown
Value: 86702@vdepee.local
SearchRule (2)
Name: to traversal
Zone (1)
Name: trav
Type: TraversalClient
Protocol: SIP
Found: True
Gatekeeper (1)
Address: 14.80.99.96:7001
9

Alias (1)
Type: Url
Origin: Unknown
Value: 86701@14.80.97.130
In this search, we can see a few important details about this call. First, at the very top, we can see that
the search has completed and that it is no longer searching.
Secondly, we can see that the destination was found.
Third, we can see that the call came into the VCS as a SIP call.
The CallSerial Number and Tag are very useful when cross referencing this information with netlogs
taken from the VCS as they will easily allow you to find where a certain call starts.
The source field tells us about the calling party. The authenticated flag is very important because if
authenticated is false, then we do not know for sure that the alias is the real alias which would prevent
us from being able to use CPLs to route calls based on origin.
Note: We can only filter based on source with CPLs if the source is authenticated. If the source is not
authenticated, the source shows as a blank string .
After the source, we have the initial destination information. The initial destination is how the call was
initially presented to the VCS before any transformations or search rules may have edited the
destination.
After the initial destination, we hit the transforms. Transforms permanently change the destination alias
for the remainder of the search. If a transform takes place, the search history will indicate so here.
Following the Transforms are the Admin Policy Actions. The admin policy actions are the CPLs in effect
on this VCS. A result of Proxy means allow the call to continue. The search history page does not give
much detail on the effects of a CPL, so if you are debugging a CPL, please look into collecting and
analyzing a netlog.
After the CPLs come the search rules. There will be one entry for each search rule that will show the
following:

1.) Name of the search rule
2.) The zone searched
3.) The type of zone searched
4.) The protocol (SIP/H323)
5.) Whether or not the destination was found
10

6.) Reason the destination was not found if not found
7.) The IP address and port of the server the search was performed on (port 0 for local)
8.) The exact alias that was searched for
One of the most important things to pull from this is what destination was searched for by the search
rule. This needs to match specifically what the other side is expecting to see or else the call will not
connect. For instance, if I have a search rule to check another VCS for the alias bob@vdepee.local, but
the remote side is expecting bob@outside.vdepee.local, I would need to make a change to my search
rule to make sure that I am requesting the specific alias that the other side is expecting.
Another important thing to note here is that if found is false, the reason given for the failure is usually
the reason returned by the remote side, except for certain exceptions such as communication timeouts.
This means that if I search for 12345@ipaddress and I pass this to a call manager, if I receive a Not
Found back, that means that the call manager is saying that it cannot find this alias and that I am either
not passing the alias in the correct format or that the call manager is not configured to allow this call to
complete. This is very useful in isolating on which side the problem exists.
4.1.4 System Snapshots
The VCS system snapshot is a collection of logs and diagnostic information from the VCS. Taking a
system snapshot can be a time consuming and processor intensive process, so please be sure not to do
this during a time of high load for the customer.
4.1.4.1 BU Snapshot analyzer
With a system snapshot, we can run it through the BUs incident report tool to determine if the
customer is hitting any crashes that match documented stack trace signatures. In order to do this,
upload the snapshot to the Incident Report Tool: https://10.50.152.110/
4.1.4.2 Manually analyzing the snapshot
The harddisk logs (logs found on the VCS in /mnt/harddisk/log) are available in the VCS system snapshot
under /mnt/harddisk/snapshot/plugins/harddisklogs/log.
The harddisklogs folder contains the sensors.log which should be one of the first steps in
troubleshooting VCS issues that appear to be related to processor or memory utilization.
4.2 Calls not connecting
If calls on a VCS are not connecting, the first thing that we need to do is define how far the call process
makes it before the calls fail. I always start by asking Does the other side ring? If the callees line
doesnt start to ring, then you know that the call request never makes it to the callee. This is most likely
due to an improperly set up dial plan or a network issue.
If the callees line starts to ring, then you know that the search rules are properly set up. You will need
to look deeper at the signaling to determine why the call is being dropped. A good rule of thumb here is
to find out who is sending the bye and backtrack from there. Determine who is ending the call request
(sending the bye) then look at the logs there to determine why the bye is being sent. Please note
11

however, that the user agent sending the bye is not necessarily the guilty party. There could be timeout
issues or a compatibility mismatch due to misconfiguration elsewhere that is causing the bye to be sent.
4.3 VCS calls dropping
When calls are being dropped from a VCS, the important thing to figure out initially is what the pattern
for failure is. Do calls only fail to/from certain sites? Do calls fail at certain times? For SIP calls, do they
end after 15 or 30 minutes? If so, this is usually related to a session refresh issue. Do calls fail after an
hour? If so, that is usually related to a session timer on a firewall not seeing any keepalive traffic.
Netlogs and tcpdumps are very useful for debugging call drop issues.
4.4 VCS Registration Failing
If registrations are failing to a VCS, we need to determine if it is a configuration issue or a network issue.
For this, I usually start out by looking at the VCS event log. If we see registration accepted or registration
denied messages, it could help pinpoint what the issue is. If there is nothing in the event logs, move on
to the netlog. If there is nothing in the netlog, check a tcpdump to see if the packets are even ever
reaching the VCS.
Keep in mind that registration requests on the VCS are sent to subzones. If a subzone is set to check
credentials, a username/password will be required to complete the registration.
There are other things such as allow/deny lists that can prevent registrations. Also, be sure to check the
SIP/H323 global settings to make sure that registrations are allowed.
4.5 VCS not booting
After the Linux operating system has loaded, the VCS starts to run all of the scripts in /etc/init.d to boot
the VCS applications. The main VCS application is /etc/init.d/S75tandberg. This script will fail to run if
the VCS has detected any hardware failure. If the file /tmp/hwfail exists, the VCS application will refuse
to load. If this happens, read the contents of the /tmp/hwfail file with the command:
cat /tmp/hwfail
The contents of the file will tell you what failure was detected and why the VCS is refusing to load.
5 Provisioning
Provisioning is based on the concept of what I call dumb endpoints because endpoints dont have
much, if any local configuration when using provisioning. The endpoints just reach out to the VCS,
sending a subscribe message, and the VCS responds with the configuration for the endpoint, in XML
format. Provisioning on a VCS is very useful for some customers, as hardware can be recycled for
multiple users with unique logins. For example, a librarian working at a desk in the library can log into
movi with her credentials during her shift, but when her shift ends, the next librarian can log in with her
own credentials. The two different credentials are two different accounts with two different URIs
meaning that someone wanting to call the first party wouldnt accidentally call the second.
There are currently two provisioning methods available TMSAgent and TMSPE. TMSPE is the
recommended solution as TMSAgent has proven to be quite unstable.
12

The first stage of provisioning is that the client sends a subscribe message:
SIPMSG:
|SUBSCRIBE sip:vdepee@vdepee.local SIP/2.0
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb3384aba1125928ac27aea2721925c73.1;received=14. 80.95.52;rport=52725
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 201 SUBSCRIBE
Contact: <sip:vdepee@14.80.95.52:52725;transport=tls>
From: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
To: <sip:provisioning@vdepee.local>
Max-Forwards: 70
Route: <sip:14.80.99.95;lr>
User-Agent: TANDBERG/773 (MCX 4.4.3.14479) - Windows
Expires: 300
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
Accept: application/pidf+xml
Content-Length: 0

After the subscribe message, if authentication is enabled, we will see a 407 challenge come back from
the server to the client. This 407 will be followed by another subscribe with a Proxy-Authentication field:
SIPMSG:
|SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb3384aba1125928ac27aea2721925c73.1;received=14.80.95.52;rport=52725
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 201 SUBSCRIBE
From: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
To: <sip:provisioning@vdepee.local>;tag=570b2e5de605dd17
Server: TANDBERG/4103 (X7.1)
Proxy-Authenticate: Digest realm="adcvcscusoraclecom.vdepee.local",
nonce="ce5c34a80be6e6baf70a8bfdd95aa5fe9582c0f3f205096b774cd5a48378", opaque="AQAAAIER/Mid+EWJt/MNvh4p3PUBWGDf", stale=FALSE,
algorithm=MD5, qop="auth"
Content-Length: 0
SIPMSG:
|SUBSCRIBE sip:vdepee@vdepee.local SIP/2.0
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb761fbb25a2cf4b9aa2ff833bf50ff69.1;received=14.80.95.52;rport=52725
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 202 SUBSCRIBE
Contact: <sip:vdepee@14.80.95.52:52725;transport=tls>
From: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
To: <sip:provisioning@vdepee.local>
Max-Forwards: 70
Route: <sip:14.80.99.95;lr>
User-Agent: TANDBERG/773 (MCX 4.4.3.14479) - Windows
Expires: 300
Proxy-Authorization: Digest nonce="ce5c34a80be6e6baf70a8bfdd95aa5fe9582c0f3f205096b774cd5a48378",
realm="adcvcscusoraclecom.vdepee.local", qop=auth, opaque="AQAAAIER/Mid+EWJt/MNvh4p3PUBWGDf", username="vdepee",
uri="sip:vdepee.local", response="5a4576b3b2fad997c7665ad3eeae21a5", algorithm=MD5, nc=00000001,
cnonce="37380fe69ea6969bb49d615d1d63db4a"
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
Accept: application/pidf+xml
Content-Length: 0
13


If the authentication is successful, we will then see the VCS accept the credential:
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,587" Module="network.ldap" Level="INFO": Detail="Searching local database for SIP
credential: vdepee"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,588" Module="network.http" Level="DEBUG": Message="Request" Method="POST"
URL="http://127.0.0.1:9998/credential/name/vdepee" Ref="0x7fc1d960bf80"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,589" Module="network.http" Level="DEBUG": Message="Response" Src-ip="127.0.0.1"
Src-port="9998" Dst-ip="127.0.0.1" Dst-port="47874" Response="200 OK" ResponseTime="0.001758" Ref="0x7fc1d960bf80"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,589" Module="network.ldap" Level="INFO": Detail="H.235 credential found in local
database for name: vdepee"

After the authentication process has been completed, the VCS will relay the provisioning request to
itself on the ports specified in xconfig sip routes for provisioning. If the user is found in the provisioning
database, we will then see the XML configuration for the user be relayed from the provisioning server to
the VCS application, then back out to the client:
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,592" Module="network.sip" Level="INFO": Dst-ip="127.0.0.1" Dst-port="22410"
Detail="Sending Request Method=SUBSCRIBE, Request-URI=sip:vdepee@vdepee.local, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,592" Module="network.sip" Level="DEBUG": Dst-ip="127.0.0.1" Dst-port="22410"
SIPMSG:
|SUBSCRIBE sip:vdepee@vdepee.local SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;egress-
zone=DefaultZone;branch=z9hG4bK90564126ddb0bd823b5be71ce5250e7b69482.4ea968681398c3a327a5bb9c2cac084e;proxy-call-id=c9f1fcaa-
121f-11e2-a03e-005056a11a90;rport
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb761fbb25a2cf4b9aa2ff833bf50ff69.1;received=14.80.95.52;rport=52725;ingress-
zone=DefaultZone
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 202 SUBSCRIBE
Contact: <sip:vdepee@14.80.95.52:52725;transport=tls>
From: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
To: <sip:provisioning@vdepee.local>
Max-Forwards: 69
Record-Route: <sip:127.0.0.1:5060;transport=udp;lr>
Record-Route: <sip:14.80.99.95:5061;transport=tls;lr>
User-Agent: TANDBERG/773 (MCX 4.4.3.14479) - Windows
Expires: 300
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
Accept: application/pidf+xml
P-Asserted-Identity: <sip:vdepee@vdepee.local>
X-TAATag: c9f1fd4a-121f-11e2-b16b-005056a11a90
Content-Length: 0



Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,593" Module="network.sip" Level="INFO": Src-ip="127.0.0.1" Src-port="22410"
Detail="Receive Response Code=200, Method=SUBSCRIBE, To=sip:provisioning@vdepee.local, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,593" Module="network.sip" Level="DEBUG": Src-ip="127.0.0.1" Src-port="22410"
SIPMSG:
|SIP/2.0 200 OK
14

Via: SIP/2.0/UDP
127.0.0.1:5060;branch=z9hG4bK90564126ddb0bd823b5be71ce5250e7b69482.4ea968681398c3a327a5bb9c2cac084e;received=127.0.0.1;rport=5060
;egress-zone=DefaultZone;proxy-call-id=c9f1fcaa-121f-11e2-a03e-005056a11a90
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb761fbb25a2cf4b9aa2ff833bf50ff69.1;received=14.80.95.52;rport=52725;ingress-
zone=DefaultZone
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 202 SUBSCRIBE
Contact: "VCS Provisioning Service" <sip:127.0.0.1:22410>
From: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
To: <sip:provisioning@vdepee.local>;tag=de1e470eff0baeb2
Record-Route: <sip:127.0.0.1:5060;transport=udp;lr>
Record-Route: <sip:14.80.99.95:5061;transport=tls;lr>
Expires: 300
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
Content-Length: 0



Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,593" Module="network.sip" Level="INFO": Dst-ip="14.80.95.52" Dst-port="52725"
Detail="Sending Response Code=200, Method=SUBSCRIBE, To=sip:provisioning@vdepee.local, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,593" Module="network.sip" Level="DEBUG": Dst-ip="14.80.95.52" Dst-port="52725"
SIPMSG:
|SIP/2.0 200 OK
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb761fbb25a2cf4b9aa2ff833bf50ff69.1;received=14.80.95.52;rport=52725;ingress-
zone=DefaultZone
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 202 SUBSCRIBE
Contact: "VCS Provisioning Service" <sip:127.0.0.1:22410>
From: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
To: <sip:provisioning@vdepee.local>;tag=de1e470eff0baeb2
Record-Route: <sip:127.0.0.1:5060;transport=udp;lr>
Record-Route: <sip:14.80.99.95:5061;transport=tls;lr>
Expires: 300
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
Content-Length: 0

|

Oct 9 14:44:11 adc-vcsc provisioning: Level="INFO" Detail="Provisioned user" User-URI="vdepee@vdepee.local" AOR="vdepee.movi@vdepee.local"
SIP-Proxy="14.80.99.95" UTCTime="2012-10-09 14:44:11,597"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,599" Module="network.sip" Level="INFO": Src-ip="127.0.0.1" Src-port="22410"
Detail="Receive Request Method=NOTIFY, Request-URI=sip:vdepee@14.80.95.52:52725;transport=tls, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,599" Module="network.sip" Level="DEBUG": Src-ip="127.0.0.1" Src-port="22410"
SIPMSG:
|NOTIFY sip:vdepee@14.80.95.52:52725;transport=tls SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:22410;received=127.0.0.1
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 8 NOTIFY
Contact: "VCS Provisioning Service" <sip:127.0.0.1:22410>
From: <sip:provisioning@vdepee.local>;tag=de1e470eff0baeb2
To: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
Max-Forwards: 70
15

Route: <sip:127.0.0.1:5060;transport=udp;lr>
Route: <sip:14.80.99.95:5061;transport=tls;lr>
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
P-Asserted-Identity: <sip:provisioning@vdepee.local>
Subscription-State: active
Content-Type: text/xml
Content-Length: 433

<ProvData xmlns="http://www.tandberg.net/Provisioning/2/"><Services item="1"><Sip item="1"><SignOnUri
item="1">vdepee.movi@vdepee.local</SignOnUri><URL item="1">14.80.99.95</URL></Sip><PhoneBook item="1"><URL
item="1">phonebook@vdepee.local</URL></PhoneBook><Presence item="1"><URL
item="1">presence@vdepee.local</URL></Presence></Services><Configuration item="1"><DisplayName
item="1">Vernon</DisplayName></Configuration></ProvData>|

Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,601" Module="network.sip" Level="INFO": Dst-ip="14.80.95.52" Dst-port="52725"
Detail="Sending Request Method=NOTIFY, Request-URI=sip:vdepee@14.80.95.52:52725;transport=tls, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,601" Module="network.sip" Level="DEBUG": Dst-ip="14.80.95.52" Dst-port="52725"
SIPMSG:
|NOTIFY sip:vdepee@14.80.95.52:52725;transport=tls SIP/2.0
Via: SIP/2.0/TLS 14.80.99.95:5061;egress-
zone=DefaultZone;branch=z9hG4bKef6940ea3dab77c3f3a9a445bb7649f469483.54645a23c314f6b1e018a71353270469;proxy-call-id=c9f36e14-121f-
11e2-a8e0-005056a11a90;rport
Via: SIP/2.0/UDP 127.0.0.1:22410;received=127.0.0.1;ingress-zone=DefaultZone
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 8 NOTIFY
Contact: "VCS Provisioning Service" <sip:127.0.0.1:22410>
From: <sip:provisioning@vdepee.local>;tag=de1e470eff0baeb2
To: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
Max-Forwards: 69
Record-Route: <sip:14.80.99.95:5061;transport=tls;lr>
Record-Route: <sip:127.0.0.1:5060;transport=udp;lr>
Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-
1107073406";connectivity=0
P-Asserted-Identity: <sip:provisioning@vdepee.local>
Subscription-State: active
X-TAATag: c9f36eaa-121f-11e2-94d1-005056a11a90
Content-Type: text/xml
Content-Length: 433

<ProvData xmlns="http://www.tandberg.net/Provisioning/2/"><Services item="1"><Sip item="1"><SignOnUri
item="1">vdepee.movi@vdepee.local</SignOnUri><URL item="1">14.80.99.95</URL></Sip><PhoneBook item="1"><URL
item="1">phonebook@vdepee.local</URL></PhoneBook><Presence item="1"><URL
item="1">presence@vdepee.local</URL></Presence></Services><Configuration item="1"><DisplayName
item="1">Vernon</DisplayName></Configuration></ProvData>|

Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,616" Module="network.sip" Level="INFO": Src-ip="14.80.95.52" Src-port="52725"
Detail="Receive Response Code=200, Method=NOTIFY, To=sip:vdepee@vdepee.local, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,616" Module="network.sip" Level="DEBUG": Src-ip="14.80.95.52" Src-port="52725"
SIPMSG:
|SIP/2.0 200 OK
Via: SIP/2.0/TLS 14.80.99.95:5061;egress-
zone=DefaultZone;branch=z9hG4bKef6940ea3dab77c3f3a9a445bb7649f469483.54645a23c314f6b1e018a71353270469;proxy-call-id=c9f36e14-121f-
11e2-a8e0-005056a11a90;received=14.80.99.95;rport=5061
16

Via: SIP/2.0/UDP 127.0.0.1:22410;received=127.0.0.1;ingress-zone=DefaultZone
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 8 NOTIFY
From: <sip:provisioning@vdepee.local>;tag=de1e470eff0baeb2
To: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
Server: TANDBERG/773 (MCX 4.4.3.14479)
Content-Length: 0



Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,616" Module="network.sip" Level="INFO": Dst-ip="127.0.0.1" Dst-port="22410"
Detail="Sending Response Code=200, Method=NOTIFY, To=sip:vdepee@vdepee.local, Call-ID=798024a03db31470@127.0.0.1"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,616" Module="network.sip" Level="DEBUG": Dst-ip="127.0.0.1" Dst-port="22410"
SIPMSG:
|SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1:22410;received=127.0.0.1;ingress-zone=DefaultZone
Call-ID: 798024a03db31470@127.0.0.1
CSeq: 8 NOTIFY
From: <sip:provisioning@vdepee.local>;tag=de1e470eff0baeb2
To: <sip:vdepee@vdepee.local>;tag=d7347f81f3dbf78f
Server: TANDBERG/773 (MCX 4.4.3.14479)
Content-Length: 0

The client then looks through the provisioning data and pulls out the URI. The client will then register
with the IP address listed in the URL field with the URI that was passed to it in the provisioning data.

<ProvData xmlns="http://www.tandberg.net/Provisioning/2/"><Services item="1"><Sip item="1"><SignOnUri
item="1">vdepee.movi@vdepee.local</SignOnUri><URL item="1">14.80.99.95</URL></Sip><PhoneBook item="1"><URL
item="1">phonebook@vdepee.local</URL></PhoneBook><Presence item="1"><URL
item="1">presence@vdepee.local</URL></Presence></Services><Configuration item="1"><DisplayName
item="1">Vernon</DisplayName></Configuration></ProvData>|

Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,874" Module="network.sip" Level="INFO": Src-ip="14.80.95.52" Src-port="52726"
Detail="Receive Request Method=REGISTER, To=sip:vdepee.movi@vdepee.local, Call-ID=d3578f95668ee497@14.80.95.52"
Oct 9 14:44:11 adc-vcsc tvcs: UTCTime="2012-10-09 14:44:11,874" Module="network.sip" Level="DEBUG": Src-ip="14.80.95.52" Src-port="52726"
SIPMSG:
|REGISTER sip:vdepee.local SIP/2.0
Via: SIP/2.0/TLS 14.80.95.52:52726;branch=z9hG4bKa48eb14f47cbe2ef4da5d5e851549ebf.1;received=14.80.95.52;rport=52726
Call-ID: d3578f95668ee497@14.80.95.52
CSeq: 9001 REGISTER
Contact: <sip:vdepee.movi@14.80.95.52:52726;transport=tls>;+sip.instance="<urn:uuid:ec4f499a-bff8-5866-97df-9b73c9dc1807>"
From: <sip:vdepee.movi@vdepee.local>;tag=d5f49424b1f687d8
To: <sip:vdepee.movi@vdepee.local>
Max-Forwards: 70
Route: <sip:14.80.99.95:5061;lr>
Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY
User-Agent: TANDBERG/773 (MCX 4.4.3.14479) - Windows
Expires: 3600
Proxy-Authorization: Digest nonce="ce5c34a80be6e6baf70a8bfdd95aa5fe9582c0f3f205096b774cd5a48378",
realm="adcvcscusoraclecom.vdepee.local", qop=auth, opaque="AQAAAIER/Mid+EWJt/MNvh4p3PUBWGDf", username="vdepee",
uri="sip:vdepee.local", response="f346f05b1356d0b2118374591dbdb984", algorithm=MD5, nc=00000002,
cnonce="e124f9b6cb7131f10b1a23077598e5d8"
Supported: replaces,100rel,timer,gruu
Content-Length: 0
17


Once registered, the client will use the other provisioning data as needed. In the example above, the
client has received the phonebook and presence URIs as well as its display name.

6 VCS Applications
The VCS has a number of applications that help it stand out as more than just a sip proxy. The VCS is
capable of handling presence for endpoints that are capable of understanding presence, a B2BUA to
increase functionality when integrating with Lync/OCS, OCS relay to publish presence onto an OCS
environment, conference factory to allow ad-hoc call escalation to MCUs, and FindMe to allow single
number reach.
6.1 Presence
Weve all seen presence in use in many applications, the VCS is no different. With the presence server
on the VCS, users can set their presence statuses. Examples of supported presence statuses include
Available, Away, Busy, and Offline.
6.1.1 Presence Server
The presence Server is the brains behind presence. On the VCS, if the presence server is enabled, the
VCS will route all presence requests for anything at any one of the sip domains for the vcs or any of the
vcss ip address to the presence server. Once this has occurred, the Presence Server will respond to the
presence request and the VCS will not pass the presence request to any other devices. This means that it
is very important to make sure that only one cluster of VCSs per sip domain has the presence server
enabled. Lets look at an example:
We have a VCS cluster in America and a VCS cluster in EMEA. The VCSs all use the sip domain of
cisco.com. Lets say that both VCS clusters have the sip server enabled. When a user in AMER looks up
the presence of a user in EMEA, the VCS cluster in AMER intercepts the presence request and returns that
it does not have presence data for the EMEA user. For this reason, the user appears as offline.
Now lets look at that same example, but assume that only AMER has an active presence server. When
the AMER user looks up the EMEA users presence status, the AMER cluster is aware of the EMEA users
status because the AMER cluster is the only one running a presence server, so the EMEA users presences
are handled by the AMER cluster. In this example, everyone can see everyone elses presence properly.
If the VCS receives a presence request that is for a different domain, the presence request follows the
call policy on the VCS and will be routed based on CPLs, transforms, and search rules.
6.1.2 Presence User Agent
The presence user agent allows the VCS to publish presence for registered endpoints that are not
presence capable. This should be enabled on all VCSs that you would like to receive presence from
endpoints registered to.
18

6.2 Conference Factory
Conference Factory is how we configure the VCS to support multiway. For a VCS running conference
factory, any time that a request is made for the alias configured as the conference factory alias, the VCS
will respond with a SIP Refer message matching the next conference alias ID. Every time that a new call
comes in, the next conference alias ID increases by one until it reaches the number range end, at which
point the number will go back to the number range start value.
Once the endpoint receives the refer message, it will dial that new number (which will hopefully connect
to a new conference on an MCU). Once it has connected, it will relay to all of the other endpoints the
alias exactly as it was passed from the VCS.
If the number range is too small, it is possible that you could wind up with new multiway sessions joining
a conference that already existed from a previous multiway session. That could cause some confusion.
6.3 FindMe
FindMe for the VCS is an application that allows single number reach of a user. A user has a FindMe ID,
which when dialed will relay the call to all associated devices in the FindMe users profile as configured.
The details on how to set up FindMe from a user perspective are well documented:
http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/user_guide/FindMe_User_Guide_X
6.pdf
7 Clustering
7.1 Pre X6.1
Clustering prior to version X6.1 in the VCS is not as fun and requires running a script on the VCS as root.
To cluster a VCS, log into the VCS via CLI as root and type the command cluster. After this has been
done, follow the on-screen instructions for establishing the cluster.
7.2 Post X6.1
With version X6.1 of the VCS, a much easier method of establishing clusters was introduced. Merely log
into the master and slaves, navigate to the clustering page under configuration > cluster and enter the
clustering information. Make sure that the same IP address is set to the master on all of the clustered
VCSs and make sure that the pre-shared key is the same on all VCSs. The pre-shared key can be
anything, but it must be the same on all VCSs.
After configuring the cluster, reboot the master VCS. Then wait for it to come up and reboot the slaves.
On the clustering page, there are two statuses. Both statuses must read as succeeded on the master
and all of the slaves. If it does not read as succeeded, then we know that replication has not been
properly established.
The VCS cluster will attempt to replicate once every minute. The replication times are as listed on the
bottom of the cluster configuration page.
19

8 Zones
8.1 Default Zone
All messages that pass through a VCS have a zone of origination. If the messages originated on the VCS,
they are seen as having come from the local zone.
Messages that have not originated from the local VCS come through either the Default zone or another
pre-configured zone. If the message is not detected to have come in from an IP address specified in one
of the neighbor or traversal zones, the message is then considered to have originated from the default
zone.
8.2 DNS Zone
A DNS zone is used for establishing calls to another domain based on the DNS SRV records for that
domain. If a call is passed to a DNS zone, the VCS will do a DNS srv record on the domain for sip and
h323 and attempt to connect the call accordingly.
8.3 Neighbor Zone
A neighbor zone on the VCS serves two purposes. First, the neighbor zone allows you to direct messages
to other SIP/H323 registrars. Secondly, the neighbor zone will be seen as the incoming zone for the
addresses listed, allowing you to create a different authentication policy than what exists on the default
zone. For instance, if my Default zone is set to check credentials, any messages that come in from an
unregistered MCU will be met with a request for authentication. If I added a neighbor zone for the MCU
that was set to treat as authenticated, then the MCU would not have to provide any credentials as the
messages are entering through the neighbor zone (which is set to trust) and not the default zone.
8.4 Traversal Zone
Traversal zones come in two flavors Traversal client and traversal server. The traversal server is
configured on the VCS expressway and the traversal client is configured on the VCS control. It is the job
of the traversal client to establish a connection with the traversal server. Once the session has been
established, the VCS expressway can send sip/h323 messages to the VCS control over the established
tcp sessions. The control constantly reaches out to the expressway to make sure that the sessions do not
time out. During these session refreshes (and initial session establishment), it is normal to see a 401
unauthorized message come from the expressway to the control. When the 401 messages are sent, the
control reaches back out to the expressway providing the credentials that are configured in the traversal
client. If these credentials match those configured on the traversal client, then the session is established
and messages can be passed across the traversal zone.
Note: when calls cross a traversal zone, both media and signaling will cross the traversal zone.