Professional Documents
Culture Documents
05.01 - VCS - Overview
05.01 - VCS - Overview
01
VCS
Overview
Modification History
Revision
Initial
Release
Date
11/28/2012
Originator
Vernon Depee
Comments
Table of Contents
Modification History ..................................................................................................................................... 2
1
Overview ........................................................................................................................................... 4
VCS Basics.......................................................................................................................................... 4
2.1
2.2
Control/Expressway .................................................................................................................. 4
3.1.1
3.1.2
3.1.3
Transforms ........................................................................................................................ 6
4.1.1
Netlog ................................................................................................................................ 6
4.1.2
Tcpdump ........................................................................................................................... 6
4.1.3
4.1.4
4.2
4.3
4.4
4.5
Provisioning ..................................................................................................................................... 11
6.1
Presence .................................................................................................................................. 17
6.1.1
Presence Server............................................................................................................... 17
6.1.2
6.2
6.3
FindMe .................................................................................................................................... 18
Clustering ........................................................................................................................................ 18
7.1
7.2
Zones ............................................................................................................................................... 19
8.1
Default Zone............................................................................................................................ 19
8.2
8.3
Neighbor Zone......................................................................................................................... 19
8.4
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
VCS Basics
Configuring a VCS
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
4.1
VCS Troubleshooting
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
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
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)
Zone (2)
Type: Url
Origin: Unknown
Value: 86702@vdepee.local
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
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.)
2.)
3.)
4.)
5.)
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
10
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.
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.
11
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-42938531461107073406";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-42938531461107073406";connectivity=0
Accept: application/pidf+xml
Content-Length: 0
12
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;egresszone=DefaultZone;branch=z9hG4bK90564126ddb0bd823b5be71ce5250e7b69482.4ea968681398c3a327a5bb9c2cac084e;proxy-call-id=c9f1fcaa121f-11e2-a03e-005056a11a90;rport
Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb761fbb25a2cf4b9aa2ff833bf50ff69.1;received=14.80.95.52;rport=52725;ingresszone=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-42938531461107073406";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
13
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;ingresszone=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-42938531461107073406";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;ingresszone=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-42938531461107073406";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
14
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-42938531461107073406";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;egresszone=DefaultZone;branch=z9hG4bKef6940ea3dab77c3f3a9a445bb7649f469483.54645a23c314f6b1e018a71353270469;proxy-call-id=c9f36e14-121f11e2-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-42938531461107073406";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;egresszone=DefaultZone;branch=z9hG4bKef6940ea3dab77c3f3a9a445bb7649f469483.54645a23c314f6b1e018a71353270469;proxy-call-id=c9f36e14-121f11e2-a8e0-005056a11a90;received=14.80.99.95;rport=5061
15
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
16
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.
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.
17
Clustering
18
Zones
19