8/18/2019 05.01 - VCS - Overview

1/19

 

TelePresence Bootcamp Module 05.01

VCS

Overview

8/18/2019 05.01 - VCS - Overview

2/19

2

Modification History

Revision Date Originator Comments

InitialRelease

11/28/2012 Vernon Depee

Table of ContentsModification 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

8/18/2019 05.01 - VCS - Overview

3/19

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

8/18/2019 05.01 - VCS - Overview

4/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

endpoint’s 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 VCS’s 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?

https://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdfhttps://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdfhttps://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdfhttps://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdfhttps://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/admin_guide/Cisco_VCS_Administrator_Guide_X7-2.pdf

8/18/2019 05.01 - VCS - Overview

5/19

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 MethodsTransforms 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.

8/18/2019 05.01 - VCS - Overview

6/19

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 thesame 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

TCPdump’s can be run from the VCS in order to troubleshoot signaling or media issues. Instructions forthe 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

http://rtp-calo-zoltes.cisco.com/zma/http://rtp-calo-zoltes.cisco.com/zma/http://rtp-calo-zoltes.cisco.com/zma/http://rtp-calo-zoltes.cisco.com/zma/

8/18/2019 05.01 - VCS - Overview

7/19

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 cpl’s, 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-005056a11a90o  Tag: a9167634-1489-11e2-8250-005056a11a90

o 

StartTime: 2012-10-12 12:27:05o  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/18/2019 05.01 - VCS - Overview

8/19

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

8/18/2019 05.01 - VCS - Overview

9/19

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 CPL’s to route calls based on origin. 

Note: We can only filter based on source with CPL’s 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 CPL’s 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

8/18/2019 05.01 - VCS - Overview

10/19

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 notconnect. 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 BU’s 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 callee’s line

doesn’t 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 callee’s 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

mailto:bob@vdepee.localmailto:bob@vdepee.localmailto:bob@vdepee.localmailto:bob@outside.vdepee.localmailto:bob@outside.vdepee.localmailto:bob@outside.vdepee.localhttps://10.50.152.110/https://10.50.152.110/https://10.50.152.110/mailto:bob@outside.vdepee.localmailto:bob@vdepee.local

8/18/2019 05.01 - VCS - Overview

11/19

8/18/2019 05.01 - VCS - Overview

12/19

8/18/2019 05.01 - VCS - Overview

13/19

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 SIPcredential: 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 localdatabase 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.0Via: SIP/2.0/UDP 127.0.0.1:5060;egress-

zone=DefaultZone;branch=z9hG4bK90564126ddb0bd823b5be71ce5250e7b69482.4ea968681398c3a327a5bb9c2cac084e;proxy-call-id=c9f1fcaa-121f-11e2-a03e-005056a11a90;rportVia: 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.1CSeq: 202 SUBSCRIBEContact:

From: ;tag=d7347f81f3dbf78f

To: Max-Forwards: 69

Record-Route: Record-Route:

User-Agent: TANDBERG/773 (MCX 4.4.3.14479) - WindowsExpires: 300Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.4.3.14479;clientid="S-1-5-21-427673460-4293853146-

1107073406";connectivity=0Accept: application/pidf+xmlP-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: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

8/18/2019 05.01 - VCS - Overview

14/19

14

Via: SIP/2.0/UDP127.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=DefaultZoneCall-ID: 798024a03db31470@127.0.0.1

CSeq: 202 SUBSCRIBEContact: "VCS Provisioning Service" From: ;tag=d7347f81f3dbf78f

To: ;tag=de1e470eff0baeb2

Record-Route: Record-Route:

Expires: 300Event: 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=DefaultZoneCall-ID: 798024a03db31470@127.0.0.1CSeq: 202 SUBSCRIBEContact: "VCS Provisioning Service"

From: ;tag=d7347f81f3dbf78fTo: ;tag=de1e470eff0baeb2Record-Route:

Record-Route: 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=0Content-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.1Call-ID: 798024a03db31470@127.0.0.1

CSeq: 8 NOTIFY

Contact: "VCS Provisioning Service" From: ;tag=de1e470eff0baeb2

To: ;tag=d7347f81f3dbf78fMax-Forwards: 70

8/18/2019 05.01 - VCS - Overview

15/19

15

Route: Route: 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=0P-Asserted-Identity: Subscription-State: active

Content-Type: text/xmlContent-Length: 433

vdepee.movi@vdepee.local14.80.99.95phonebook@vdepee.localpresence@vdepee.localVernon|

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.0Via: SIP/2.0/TLS 14.80.99.95:5061;egress-zone=DefaultZone;branch=z9hG4bKef6940ea3dab77c3f3a9a445bb7649f469483.54645a23c314f6b1e018a71353270469;proxy-call-id=c9f36e14-121f-

11e2-a8e0-005056a11a90;rportVia: 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 NOTIFYContact: "VCS Provisioning Service" From: ;tag=de1e470eff0baeb2To: ;tag=d7347f81f3dbf78f

Max-Forwards: 69Record-Route: Record-Route:

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:

Subscription-State: activeX-TAATag: c9f36eaa-121f-11e2-94d1-005056a11a90

Content-Type: text/xmlContent-Length: 433

vdepee.movi@vdepee.local14.80.99.95phonebook@vdepee.localpresence@vdepee.localVernon|

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 OKVia: 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

8/18/2019 05.01 - VCS - Overview

16/19

8/18/2019 05.01 - VCS - Overview

17/19

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 URI’s 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 MCU’s, and FindMe to allow single

number reach.

6.1 Presence

We’ve 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

vcs’s 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 VCS’s per sip domain has the presence server

enabled. Let’s look at an example: 

We have a VCS cluster in America and a VCS cluster in EMEA. The VCS’s all use the sip domain of

cisco.com. Let’s 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 let’s look at that same example, but assume that only AMER has an active presence server. When

the AMER user looks up the EMEA user’s presence status, the AMER cluster is aware of the EMEA user’s

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 else’s 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 CPL’s, 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 VCS’s that you would like to receive presence from

endpoints registered to.

8/18/2019 05.01 - VCS - Overview

18/19

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 user’s 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

VCS’s and make sure that the pre-shared key is the same on all VCS’s. The pre-shared key can be

anything, but it must be the same on all VCS’s.

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 beenproperly 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.

8/18/2019 05.01 - VCS - Overview

19/19

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 ZoneA 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.