cisco vcs - overview

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: [email protected]

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:[email protected]

o SubSearch (1)

Type: Transforms Action: Not Transformed ResultAlias (1)

Type: Url Origin: Unknown Value: [email protected]

SubSearch (1) Type: Admin Policy Action: Proxy ResultAlias (1)


8

SubSearch (1) Type: FindMe Action: Proxy ResultAlias (1)


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: [email protected]

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


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


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 [email protected], but

the remote side is expecting [email protected], 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:[email protected] 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: [email protected]

CSeq: 201 SUBSCRIBE

Contact:

From: ;tag=d7347f81f3dbf78f

To:

Max-Forwards: 70

Route:

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


CSeq: 201 SUBSCRIBE


To: ;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:


Via: SIP/2.0/TLS 14.80.95.52:52725;branch=z9hG4bKb761fbb25a2cf4b9aa2ff833bf50ff69.1;received=14.80.95.52;rport=52725


CSeq: 202 SUBSCRIBE

Contact:


To:

Max-Forwards: 70

Route:


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"




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:[email protected], [email protected]"

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:


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


CSeq: 202 SUBSCRIBE

Contact:


To:

Max-Forwards: 69

Record-Route:

Record-Route:


Expires: 300




P-Asserted-Identity:

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:[email protected], [email protected]"

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


zone=DefaultZone


CSeq: 202 SUBSCRIBE

Contact: "VCS Provisioning Service"


To: ;tag=de1e470eff0baeb2

Record-Route:

Record-Route:

Expires: 300



Content-Length: 0


Detail="Sending Response Code=200, Method=SUBSCRIBE, To=sip:[email protected], [email protected]"


SIPMSG:

|SIP/2.0 200 OK


zone=DefaultZone


CSeq: 202 SUBSCRIBE



To: ;tag=de1e470eff0baeb2

Record-Route:

Record-Route:

Expires: 300



Content-Length: 0

|

Oct 9 14:44:11 adc-vcsc provisioning: Level="INFO" Detail="Provisioned user" User-URI="[email protected]" AOR="[email protected]"

SIP-Proxy="14.80.99.95" UTCTime="2012-10-09 14:44:11,597"


Detail="Receive Request Method=NOTIFY, Request-URI=sip:[email protected]:52725;transport=tls, [email protected]"


SIPMSG:

|NOTIFY sip:[email protected]:52725;transport=tls SIP/2.0

Via: SIP/2.0/UDP 127.0.0.1:22410;received=127.0.0.1


CSeq: 8 NOTIFY


From: ;tag=de1e470eff0baeb2

To: ;tag=d7347f81f3dbf78f

Max-Forwards: 70

15

Route:

Route:




Subscription-State: active

Content-Type: text/xml

Content-Length: 433

[email protected]@[email protected]|


Detail="Sending Request Method=NOTIFY, Request-URI=sip:[email protected]:52725;transport=tls, [email protected]"


SIPMSG:

|NOTIFY sip:[email protected]: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


CSeq: 8 NOTIFY




Max-Forwards: 69

Record-Route:

Record-Route:




Subscription-State: active

X-TAATag: c9f36eaa-121f-11e2-94d1-005056a11a90

Content-Type: text/xml

Content-Length: 433



Detail="Receive Response Code=200, Method=NOTIFY, To=sip:[email protected], [email protected]"


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



CSeq: 8 NOTIFY



Server: TANDBERG/773 (MCX 4.4.3.14479)

Content-Length: 0


Detail="Sending Response Code=200, Method=NOTIFY, To=sip:[email protected], [email protected]"


SIPMSG:

|SIP/2.0 200 OK



CSeq: 8 NOTIFY



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.



Detail="Receive Request Method=REGISTER, To=sip:[email protected], [email protected]"


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


CSeq: 9001 REGISTER

Contact: ;+sip.instance=""

From: ;tag=d5f49424b1f687d8

To:

Max-Forwards: 70

Route:

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY


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.

cisco vcs - overview

Documents