TANDBERG Compliance Appliance Deployment Manual

Compliance Appliance™

Deployment Guide

Copyright © TANDBERG 2009. All rights reserved. This Deployment Guide may not be copied, photocopied, translated, reproduced, or converted into any electronic or machine-readable form in whole or in part without prior written approval of TANDBERG Limited.

TANDBERG Limited reserves the right to revise this documentation and to make changes in content from time to time without obligation on the part of TANDBERG Limited to provide notification of such revision or change. TANDBERG Limited provides this documentation without warranty, term, or condition of any kind, either implied or expressed, including, but not limited to, the implied warranties, terms or conditions of merchantability, satisfactory quality, and fitness for a particular purpose. TANDBERG Limited may make improvements or changes to the product(s) and/or the program(s) described in this documentation at any time.

All other product and company names herein may be trademarks of their respective owners.

D 1440501

EUROPEAN HEADQUARTERS Philip Pedersens vei 20, 1366 Lysaker, Norway Telephone: +47 67 125 125 Fax: +47 67 125 234 Video: +47 67 126 126 Email: tandberg@tandberg.com

U.S. HEADQUARTERS 1212 Avenue of the Americas 24th Floor, New York, NY 10036 Telephone: +1 212 692 6500 Fax: +1 212 692 6501 Video: +1 212 692 6535 Email: tandberg@tandberg.com

Table of contents

1 About this guide .................................................................................................... 1

1.1 Who is it for? ................................................................................................. 1

1.2 When to use it ............................................................................................... 1

1.3 More information? ......................................................................................... 1

1.4 Terminology .................................................................................................. 1

2 How the TCA enables compliance ........................................................................ 3

2.1 Scalable ........................................................................................................ 3

2.2 Flexible .......................................................................................................... 3

2.3 Seamless and always on .............................................................................. 3

2.4 Configuring TCA ............................................................................................ 3

2.5 Licenses ........................................................................................................ 4

3 Defining the compliance policy .............................................................................. 5

3.1 What is a compliance policy? ........................................................................ 5

3.2 What to ask the Compliance & Risk team ..................................................... 5

3.3 Who: which endpoints to record .................................................................... 6

3.4 How many TCAs: what resolution to record .................................................. 7

4 Storage .................................................................................................................. 8

4.1 What we mean by ‘storage’ ........................................................................... 8

4.2 What gets stored where? .............................................................................. 8

4.3 How much storage do you need? ................................................................. 9

4.4 Recording indicators: when to play them .................................................... 11

5 Optimizing TCA performance .............................................................................. 13

5.1 Efficient media streaming ............................................................................ 13

5.2 Efficient transcoding .................................................................................... 13

5.3 Taking local regulations into account .......................................................... 13

6 Implementing the compliance policy ................................................................... 15

6.1 The VCS Policy File .................................................................................... 15

6.2 Using patterns to identify compliant endpoints ............................................ 15

6.3 Neighboring a TCA using zones.................................................................. 16

6.4 Turning off recording ................................................................................... 18

6.5 Preventing users avoiding recording ........................................................... 18

7 Security ............................................................................................................... 19

7.1 Redundancy ................................................................................................ 19

7.2 What is secure and what isn’t ..................................................................... 19

8 Creating the policy file ........................................................................................ 20

8.1 Specifying which endpoints to record ......................................................... 20

8.2 How the policy file directs these calls to the TCA ....................................... 20

8.3 Commented policy file (all calls recorded) .................................................. 22

8.4 Route selected calls to TCA ....................................................................... 24

9 Deployment scenarios ........................................................................................ 27

9.1 Scenario 1 – basic deployment .................................................................. 27

9.2 Scenario 2 – deployment across a WAN .................................................... 28

9.3 Scenario 3 – deployment to cater to regional variations in regulations....... 29

9.4 Scenario 4 – non-participating VCS ........................................................... 30

9.5 Scenario 5 – external organization ............................................................. 31

9.6 Scenario 6 – VCS cluster ........................................................................... 32

10 Sample TCA calculator ....................................................................................... 33

11 Call Flow within TCA ........................................................................................... 34

1 About this guide

1.1 Who is it for?

This guide is for TANDBERG personnel who need to install and configure a TANDBERG Compliance Appliance™ (TCA) to enable an organization to record video conferences. It explains the process you need to go through to gather information and make decisions about how best to configure TCA.

This guide assumes that you are an experienced in video conferencing and have a working knowledge of:



video conferencing and related IT concepts



the TANDBERG video conferencing solution, specifically the Video Communication Server (VCS)



how to configure VCS systems by editing policy files.

1.2 When to use it

Use this guide in combination with the Compliance Appliance Getting Started Guide and the Compliance Appliance Release Notes when you are installing a TCA.

This guide will help you to work out how best to configure the TCA to meet an organization’s compliance needs. Every organization will have its own reasons for recording video conferences and will be operating in different (and potentially multiple) regulatory environments.

By following the steps in this guide you will be able to form a complete picture of exactly what degree of video conference compliance an organization needs and how best to configure TCA to deliver this.

1.3 More information?

If you have a question that this guide doesn’t answer, contact the TANDBERG Assistance Centre (TAC).

1.4 Terminology

Table 1: Terminology

Term Definition

call The passing of media streams between two or more endpoints.

policy file A .xml file on the VCS that contains the instructions telling TCA what to record.

E164 number A number used to identify an endpoint, such as ‘61455’. See also ‘URI’.

endpoint A point on a video conferencing network that generates a media stream.

external storage The external disk storage in the data centre to which the TCA transcodes

recordings. Not part of the TCA.

internal storage The internal hard disks in the TCA that provide over 1 terabyte of temporary

storage for recordings waiting to be transcoded.

kb/s Kilobits per second

LAN Local area network

mb/s Megabits per second

media stream The video and audio passing from one endpoint to another. A call consists of a

stream from each endpoint to each other endpoint.

resolution The size of a media stream in pixels:

QCIF – 176x144 CIF – 352x288 4CIF – 704x576 VGA – 640x480 DVD – 720x576 XGA – 1024x768 SXGA – 1280x1024 HD – 1280x720

SAN Storage-attached network

NAS Network-attached storage

TCA TANDBERG Compliance Appliance™

transcode The process by which TCA decrypts (if necessary) then converts recordings to

lower resolutions (if required) and copies a MPEG4 formatted file to external storage.

URI Universal Resource Indicator – in this case a string identifying an endpoint, e.g.

j.smith@tandberg.com. See also ‘E164’.

VCS TANDBERG Video Communication Server

WAN Wide area network

2 How the TCA enables compliance

The TANDBERG Compliance Appliance™ (TCA) is a device that enables an organization to demonstrate regulatory compliance in the medium of video conferences. It does this by recording video conference calls between nominated endpoints on the video conferencing network.

TANDBERG have designed the TCA to be scalable, flexible, seamless and always on. These attributes make the TCA transparent to the users of the video conferencing network. Deployed correctly, the TCA provides a complete archive of all recorded conferences that can be stored in a range of resolutions.

2.1 Scalable

Whether you have just a few endpoints you need to record, or thousands, you can deploy TCAs to meet the demand. One TCA can record up to 100 video streams at 1 megabit/second simultaneously, which correlates to 50 endpoints in point to point calls.

This guide explains how to define the recording demands of an organization and work out how many TCAs it will need to meet that demand.

2.2 Flexible

The TCA stores recordings in real-time on its own temporary storage, then transcodes (converts and copies) the recordings to external storage. You can configure the TCA to convert high-resolution recordings to lower resolutions to minimize storage needs. You can also make a copy of the audio component of a recording and store it separately if local regulatory requirements allow this.

This guide explains how to work out an organization’s external storage requirements and optimize the TCA to use that storage most efficiently.

2.3 Seamless and always on

The TCA gives you the option to play a recording indicator at the start of a conference to let the participants know that they are being recorded. Apart from that, its operation is completely invisible to the participants – it has no discernible effect on call quality and can’t be turned off, so it provides compliance without requiring any compromises.

This guide explains how to deploy the TCA so it does not affect call quality and functions invisibly in the background to make an organization compliant.

2.4 Configuring TCA

You control how the TCA operates using a combination of the TCA Administration Application and a policy file that you upload to the Video Communication Server. This document includes some examples of policy files, but see the TCA Getting Started Guide for details of how to set up the basic TCA configuration using the Administration Application.

2.5 Licenses

When it records a call, TCA interposes itself in the media stream between the two endpoints. From the perspective of licenses, this means that two licenses are activated when a call is being recorded: one for the call to the TCA and one from the TCA to the other endpoint.

Release 1 of TCA supports 100 licenses, which means that it can record up to 50 point-to-point calls simultaneously. You need as many VCS non-traversal licenses as the number of TCA licenses. Your customer will need to discuss license arrangements with a TANDBERG sales representative.

3 Defining the compliance policy

3.1 What is a compliance policy?

To deploy the TCA in an organization you first need to understand its compliance team’s policy. This is just a set of rules that define which conferences the team wants to record, how long they want to keep the recordings and in what resolution. For example, an organization might need to record all video conferences between the endpoints only in its boardrooms and store them for seven years in highdefinition, or keep the video for six months but the audio for seven years.

Understanding the compliance policy will enable you to work out how many TCAs are needed to record the video conferences and how much storage the organization needs to keep the recordings. Once you know the organization’s requirements you can consider any geographical or system aspects that may affect how you implement the TCAs.

Depending on the requirements and the existing network configuration, you may be able to slot a TCA in quite simply. On the other hand, you may need to deploy numerous TCAs and make significant changes to the network, to endpoint addresses and various other aspects. Each customer will have different requirements that you need to cater to, so this section explains how to work this out.

At the back of this guide there is a Sample TCA calculator spreadsheet that you can use to help you gather the details you need and form an estimate. You can download this spreadsheet from ???URL???. We also include a Configuration Checklist so that you can record the significant details of each site.

3.2 What to ask the Compliance & Risk team

In this step you need to talk to your customer’s Compliance & Risk team and help them to define their policy. Aspects to define include:



which calls they want to record



whether or not they have to tell people that they are being recorded and does this vary by location



where they want to store the calls and in what format



whether they want to record just internal or external calls, or both



how long they want to retain the records.

Once you have the scope of the compliance requirement you can talk to the multimedia, telephony, database and network administration teams to get some idea of what it will cost to do this. At the end of this process you should be able to give the Compliance & Risk team some options and the likely cost of each.

3.3 Who: which endpoints to record

The first thing to do is define the number of endpoints that need to be recorded and where they are, both geographically and in terms of their position on the network. You may want to create a matrix that lists:



each endpoint address



the country it’s in (if relevant)



the gatekeeper it’s attached to



its likely bandwidth.

3.3.1 Example: General Mortgage Bank

For the sake of example, let’s look at a hypothetical customer, the General Mortgage Bank (GMB). The bank’s compliance team wants to be able to record video conferences for several different groups in a number of countries that have different compliance regulations.

They want to record:



their board meetings, which take place every month via video conference from the boardrooms in London, Tokyo and New York



their trader conversations, which are generally short calls made from 20 desks on two trading floors in London equipped with videophones



calls from the management in the New York office



at their CEO’s discretion, his calls to business partners and clients.

This gives a total of 48 endpoints:



3 in the boardrooms in London, New York and Tokyo, used once a month for an entire day



40 desks on the London trading floors, used ten hours a day for numerous short calls



4 in the New York office which are on permanently



1 in the CEO’s office, used once or twice a day for calls of up to an hour.

The matrix for GMB might look something like this:

Table 2: Sample endpoint matrix

Endpoint URI Country VCS Bandwidth (mb/s)

ceo@gmb.uk UK VCS1-UK 4

UK.boardroom@gmb.uk UK VCS1-UK 4

US.boardroom@gmb.usa USA VCS1-US 4

JP.boardroom@gmb.jp Japan VCS1-JP 4

UKtrader@gmb.uk UK VCS2-UK 0.384

“ (times 39) “ “ 0.384

UStrader@gmb.usa USA VCS2-US 0.384

“ (times 3) 0.384

3 Defining the compliance policy

3.4 How many TCAs: what resolution to record

Once you know the number of endpoints, you need to know the total bandwidth of all the endpoints the customer wants to record at the same time. This determines how many TCAs you need to be able to record the peak volume without overstepping the maximum volumes the TCA can receive and transcode.

The TCA can record up to 100 streams (i.e. 50 point-to-point calls) at 1 megabit/second so if the peak volume is likely to exceed that then you need another TCA. Note that limit is regardless of bandwidth, so even if each stream was 384 kb/s, the TCA would still only record 100.

Bandwidth is a function of the resolution of a call, so an organization that has 30 high-definition calls producing 4 mb/s has much higher bandwidth requirements than one running 10 calls from videophones at 384 kb/s.

The TANDBERG Management System (TMS) provides a range of reports that can help you to work out the average and peak bandwidths of the organization.

3.4.1 Example: General Mortgage Bank

GMB’s board meets on the 15th of each month via video conference from the boardrooms in London, New York and Tokyo. On these days the three boardroom endpoints generate six high-definition streams of 4 mb/s, or 24 mb/s in total, for about ten hours.

While the board is meeting, the traders in London are still using their videophones, generating about 17 mb/s (384 kilobits*44) giving a peak load on these days of about 41 mb/s for ten hours. This is well within the 100 mb/s capacity of a single TCA to store and transcode, but the bank decides it might be good idea to install a second one anyway to provide redundancy.

4 Storage

4.1 What we mean by ‘storage’

The TCA has over a terabyte of internal disk space which it uses to store the recordings temporarily until it transcodes them to external storage. When we say storage we mean the disk space provided by a network-attached storage device (NAS) or storage-attached network (SAN) to which the TCA is attached over a LAN or WAN link. The TCA transcodes to this external storage for long-term archiving of the recordings.

Important

: it is the organization’s responsibility to provide enough external storage capacity to cope with the output of the TCA. The amount of output is determined by the compliance policy. You can work out how much storage the TCA will need, but the organization must decide how long it wants to keep the recordings and in what resolution and ensure that this storage space is available. The TCA does not permanently store anything, once a recording has been transcoded it is deleted from the TCA.

4.2 What gets stored where?

Recordings are stored on whatever external storage device the TCA is attached to. When you finish installing and configuring a TCA you should give the customer a handover document that lists the details of the TCA’s configuration, showing which endpoints it is recording, where it is transcoding to and the transcoding bit rate. The Configuration Checklist at the back of this document is a good starting point.

4.2.1 External calls

VCSs cannot send Location Request Queries outside their network, so a VCS can’t ask a TCA in another organization to record a call. Where two organizations are using TCA, the location of the recording depends on each organization’s recording policy. If both TCAs are set to record calls going out and coming in from outside the organizations, both TCAs will create a copy of the call. If the TCA of the organization receiving the call is not configured to record all incoming calls, only the TCA of the organization that initiates the call will record it.

4.2.2 Viewing recordings

You can view transcoded recordings with any MPEG4 player. You can only view recordings after the TCA has transcoded them to external storage; there is no facility for viewing recordings in the TCA’s temporary storage.

4.2.3 Example: General Mortgage Bank

GMB has two TCAs, one in London, the second in Tokyo. The Tokyo TCA is configured to record only calls from the New York office and the boardrooms, so it provides ‘redundancy’ and steps in if the London one fails. Of course, this means that if the London TCA fails, all local London calls will be routed through Tokyo until it comes back online, but at least recording will continue.

4 Storage

The recordings from these TCAs are also stored in different external storage locations. Viewing the recordings of the boardroom and New York endpoints requires access to the storage in Tokyo, while viewing all the other recordings requires access to the London storage.

4.3 How much storage do you need?

The decisive factors affecting storage requirements are:



the number of calls you are recording



the resolution in which you choose to store the video



how long you need to store it.

This will equate to a dollar figure per megabyte, per year.

The TCA records calls exactly as they are transmitted, but it provides unencrypted video (and audio) to the external storage. This process is called ‘transcoding’ and the TCA does it continuously as it is recording, then deletes the recording from its internal storage. This clears the disk storage in the TCA to make room for new recordings.

4.3.1 Choosing a transcoding bit rate

In the transcoding process, the TCA can convert any higher definition file to a lower definition file that requires less storage space. By choosing the transcoding resolution you can control how much disk space you need and how quickly the TCA transcodes each call.

For example, if you choose to store high-definition files as they are, you will need a lot more storage than if you decide to transcode them into a smaller file format such as CIF. The transcoding process will also take longer, as there is more information to transcode.

You set the transcoding resolution in the Administration Application when you configure TCA. Bear in mind that the bit rate you choose needs to match the resolution – choosing a high resolution and a low bit rate will causes issues such as lost frames and slow transcoding.

Transcoding resolution is a global setting for each TCA. If an organization wants to store recordings from different endpoints at different resolutions it will need a separate TCA for those endpoints.

4.3.2 Consider the content

Another aspect to consider when choosing this setting is the content in the recordings. If you choose a very small transcoding resolution to save storage space, you may not be able to see everything in the recording clearly. This is especially important if you expect users to include content such as PowerPoint presentations – at low resolutions these can become too small to read.

4.3.3 What TCA generates

When it transcodes a recording, TCA generates an .mp4 file containing the video and audio, plus a .xml ‘sidecar’ file that contains information about the .mp4 file. It writes these files to a directory on the nominated external storage device according to these rules:



directory tree is year/month/day



file name is origin URI_destination URI_TCA ID number_unique call ID.mp4



the ‘Date modified’ date of the .mp4 file is the time at which the call was initiated.

This screenshot shows an example of the directory structure and file format:

If you are also storing a separate copy of the audio only, TCA transcodes it into a .m4a file.

Whoever is responsible for managing the recordings will need to conduct periodic checks of the stored files to ensure that the recordings are transcoding correctly.

If a recording is more than two hours long, TCA breaks it up into a series of recordings each of two hours or less.



If the endpoint is participating in a conference hosted on an MCU then the recording name will be of the form origin URI_MCU URI_TCA ID number_unique call ID.mp4, if the endpoint dialed into the MCU and MCU URI_destination URI_TCA ID number_unique call ID.mp4 if the MCU dialed the endpoint.

If you are using a TANDBERG Codian MCU and ‘Use conference name as caller ID’ is set on the MCU then the outputted recording will be in the format of ConfName_endpointName. This is for H.323 only and does not work with SIP calls. SIP will always be MCU URI_destination URI.

4.3.4 Handling recording and transcoding errors

TCA automatically tears down a call if recording stops for any reason. When the TCA becomes available again the call can resume. In this situation, the TCA transcodes the incomplete part of the call with the designation ‘partial’ in the filename so you can identify that it is an incomplete call.

If a transcode is not completed for any reason (e.g. the connection to storage fails), you will see an incomplete .mp4 file in the directory but no matching sidecar file. When TCA transcodes the recording again and produces a complete .mp4 file, it will also create the sidecar file.

4 Storage

TCA does not delete incomplete transcodes or any other files from storage; this is the responsibility of the storage administrator.

4.3.5 If external storage is unavailable

If the TCA is unable to transcode for any reason (e.g. storage becomes full, link to the storage becomes unavailable) the TCA will keep recording until its internal storage is full. When its internal storage is full it will not record any more calls. Once the link is re-established it will start transcoding the recordings. When there is space on its internal storage again it will start recording new calls.

4.3.6 Separating audio and video

A video recording includes an audio component, but some countries allow organizations to store video and audio separately for different lengths of time. For example, if an organization is required by law to keep audio files for seven years, but video for only six months it can set its storage rules to delete the video six months after it was transcoded to external storage. This can significantly reduce long-term storage needs.

To cater to this, TCA can make a separate copy of just the audio component (in .m4a format) and store it separately. Ask the Compliance & Risk team if any regulations like this apply to their operations.

4.3.7 Example: General Mortgage Bank

GMB generates on average about one gigabyte per day of video data and is required by law to store these video files for seven years. This represents a significant expense, so it’s in the bank’s interests to reduce the storage volume required as far as possible.

After discussing it with the regulators, their Compliance & Risk team concludes that storing the video of the dealers in CIF resolution is adequate for disclosure purposes, but that the boardroom conferences need to be in VGA or better. They install two TCAs, one for the boardrooms that transcodes to VGA, and one for the dealer groups, which transcodes to CIF at 192 kb/s, reducing the overall daily transcoding volume significantly.

4.4 Recording indicators: when to play them

In some countries the law requires that organizations tell people that a call is being recorded. In the USA for example, this rule varies from state to state, but generally takes one of three forms:



‘no party’ – no requirement to inform either caller that they are being recorded



‘one party’ – an organization must tell its employees that they may be recorded (though this can be done through their employment contract rather than on an ad hoc basis)



‘two party’ – organizations must tell both parties in the call that they are being recorded.

TCA comes with a standard audio announcement and image that you can configure to play and display at the start of a call. How and when an organisation chooses to do this depends on the local rules and the type of call. Ina future release organizations can also choose to replace the standard image and sound file with its own versions.

4.4.1 Setting recording indicators

Using the TCA Administration Application you set whether or not to display them to the endpoints involved in a call.

The Recording Indicator is a global setting per TCA, so if an organization wants some endpoints to display the indicators while others don’t, it will need separate TCAs.

4.4.2 Example: General Mortgage Bank

GMB wants to remind its directors that the board meetings are being recorded. The traders on the other hand, are making dozens of short calls a day and don’t want to be constantly held up by the announcement.

Through the TCA Administration Application, they configure one TCA to record the boardroom endpoints and set it to show the recording indicator. They set the other TCA to record the traders’ videophone endpoints and turn the indicator off.

5 Optimizing TCA performance

To avoid call latency or other quality issues you need to consider the network configuration, the location of the endpoints and the physical placement of the TCAs.

5.1 Efficient media streaming

When it records a call, the TCA interposes itself between the endpoints, so it’s important that it be physically as close to the endpoints as possible.

Avoid situations in which the media from endpoints that are close together is being routed over a wide area network to a TCA located far away (e.g. in another country). That sort of configuration may create latency and other issues.

Slower speed links such as wide area network links are the ones you need to use most efficiently. As calls are being made in real-time, the links between endpoints and TCAs need to be efficient enough to support the video stream.

5.2 Efficient transcoding

The link to the external storage can afford to be slower as it only affects transcoding, but efficient transcoding is still important. Transcoding rate is a function of resolution and link speed. The higher the resolution required and the slower the link, the longer it will take to transcode the video.

Wherever possible, connect the TCA to external storage over a low-latency link and transcode to the lowest possible resolution.

If the TCA is copying high-definition files to external storage over a slow wide area network , you may also experience drop-outs, in which case TCA will restart transcoding whatever file was interrupted.

In extreme cases you risk being in ‘transcode deficit’ where the volume of incoming video exceeds the rate of transcoding to the point where the TCA runs out of disk space. TCA can support 100 streams at 1 megabit/second while transcoding to CIF at 192 kb/s at two hundred times that rate, so this situation is unlikely to occur unless you have massive input volumes, but it’s important to be aware of it.

5.3 Taking local regulations into account

Another factor affecting the number of TCAs is variations between local compliance regulations. For instance, some countries require recordings involving their citizens to be stored in that country only, so this can also affect where you physically put the TCA, or which external storage you transcode to.

5.3.1 Example: General Mortgage Bank

GMB has a number of factors to consider when deciding where to put their TCAs:



their main data centre and long-term storage facility is in London



most of their calls are made in London between two office buildings there



their compliance policy requires boardroom conferences to be recorded in at least VGA resolution



local Japanese regulations stipulate that calls involving Japanese citizens must be stored in Japan



the dealers don’t want the recording indicator to play every time they make a quick call, but the bank needs it displayed on all the CEO and board recordings.

To cater to all of these requirements, GMB install one TCA in London and a second one in Tokyo. They configure the London TCA to record all the dealer and CEO calls as it is physically closest to these endpoints and the calls don’t require a recording indicator. This ensures that all the local video conferences remain on the UK LAN rather then being routed over a WAN via Tokyo and back again.

They configure the Tokyo TCA to record the boardroom calls as these involve endpoints in Tokyo, New York and London, require a recording indicator and have to be stored in Japan. The Tokyo TCA is also configured to act as a redundant TCA for the whole network if the London one fails for any reason.

Finally, they configure the London TCA to transcode at CIF resolution over the LAN link to the local data centre. The Tokyo TCA is configured to transcode at VGA over the LAN to external storage in the Tokyo office. This deployment meets their compliance policy requirements and provides the most efficient transcoding process for both TCAs.

6 Implementing the compliance policy

6.1 The VCS Policy File

As we said before, when TCA records a conference, it interposes itself between the endpoints. To make this possible, the network needs to be able to identify which endpoints need to be recorded so it can direct them to the TCA.

TCA relies on a policy file that sits on its neighbored VCS to tell it which endpoints to record. By editing this file you define which endpoints you want TCA to record.

Important

: it is essential that you make a backup of the original VCS Policy file before editing it to include instructions for the TCA. If you need to turn TCA off for any reason you will need to revert to the previous version of the VCS Policy file.

6.2 Using patterns to identify compliant endpoints

To define which endpoints to record, you could just make a list of the relevant URIs or E164 numbers, but that is a rather inflexible method requiring constant updating and prone to error. The preferred method is to define ‘patterns’ that TCA recognizes.

Some examples might be to record:



all E164 numbers beginning with particular digits



the subnet IP addresses that identify zones (e.g. 103.72.0.0) where ‘103.72’ is the identifier



all URIs containing a particular string (e.g. j.smith@uk.gmb.com) where ‘@uk.gmb.com’ is the string to match.

You define the patterns of the endpoints you want to record in the VCS Policy file. See Creating the policy file on page 20 for more information about editing and using policy files.

6.2.1 Considering the implications

Creating patterns that meet an organization’s compliance requirements can be a complex business and may require renaming of endpoints. If you have to do that, you may also find that you need to change business cards, address books and so on, so the implications need to be considered carefully when defining the compliance policy.

You may want to start with a list of the specific endpoints that need to be recorded, then implement a more sophisticated system using patterns over time. Many organisations only do updates to systems every six months, so you may need to coincide with the IT department’s schedule if you plan to do things like change endpoint addresses.

There will be a number of ways to handle this depending on each organization’s compliance policy and its network configuration. You will need to discuss this with the IT and video conferencing teams so you can reconcile the needs of the compliance policy with the practical implications and likely costs.

6.2.2 Example: General Mortgage Bank

GMB has 48 endpoints it needs to record, so they need a way to identify these to the TCAs.

The bank has a fairly high turnover of dealer staff, so making a list of their URIs is not practical. Instead, they opt to rename the trader endpoints with an identifier, so

j.smith@uk.gmb.com becomes

j.smith.trader@uk.gmb.com. They then edit the policy file to recognise all URIs containing ‘.trader’ as

needing to be recorded.

The identifiers for the CEO and boardroom endpoints are unlikely to change, so their E164 numbers or URIs can simply be added to the policy file. The four endpoints in the New York office are distinctive because they have their own URI extension of ‘@usa.gmb.com so GMB can edit the policy file to recognise all URIs containing ‘@usa.gmb.com’ as needing to be recorded.

6.3 Neighboring a TCA using zones

6.3.1 About neighboring

Video Communication Servers (VCS) use ‘zones’ to define groups of endpoints that are accessed via other gatekeepers. The gatekeepers are known to the VCS as ‘friends’ or ‘neighbors’. TCAs have to be neighbored to VCSs in much the same way as gatekeepers. Once you have neighbored the TCA to a VCS, you can upload a policy file to the VCS that tells it how to use the TCA.

This diagram shows a typical simple deployment with two TCAs:

In this deployment:



EP1 and EP2 are registered with VCS1



TCA1 and TCA2 are neighbored with VCS1



Zone A is defined with two peers, TCA1 and TCA2



TCA1 and TCA2 are transcoding to NAS1



VCS1 chooses either TCA1 or TCA2 to record calls between EP1 and EP2



if TCA1 is unavailable, VCS1 chooses TCA2.

An alternative to this would be to put the TCAs in separate zones so you can assign calls to each TCA according to priorities in your VCS policy file.

6 Implementing the compliance policy

6.3.2 How the VCS and TCA work together

TCA works in much the same way as a VCS in ‘traversal mode’ in which the actual media stream is routed through the VCS. Each endpoint is registered to a specific VCS which identifies the endpoint by its IP address and URI. To enable TCA to record a call, the VCS has to pass the IP addresses of the endpoints to it.

The process followed by the VCS when attempting to locate a destination endpoint is described below.

1 The user enters into their endpoint the alias or address of the destination endpoint.

2 The destination address is sent from the caller’s endpoint to its local VCS (i.e. the VCS to which it

is registered).

3 The VCS applies any pre-search transforms to the alias.

4 The VCS applies any Call Policy to the (transformed) alias. If this results in a new alias, the process

starts again, with the new alias checked against the pre-search transforms. In the case of a TCA Call Policy the policy can match either the initiating or receiving endpoint alias to see if either is required to be recorded. If either of them does, the VCS appends the prefix ‘CAREC (compliance appliance recording) to the alias (e.g. ‘j.smith@gmb.com

’ becomes ‘CAREC.j.smith@gmb.com’).

5 The VCS applies any User Policy (if FindMe is enabled) to the alias. If the alias is a FindMe name

that resolves to one or more new aliases, the process will start again; all the resulting aliases will be checked against pre-search transforms and Call Policy.

6 The VCS then searches, in order of priority, all its zone matches, including those configured on the

Local Zone (which includes any cluster peers). At each priority, zones are searched first in the native protocol and then, if the VCS interworking configuration allows, the alternative protocol. If the alias matches an ENUM zone, this may return a URI. If so, the process starts again; the URI is checked against any pre-search transforms, Call Policy and User Policy. In the case of a TCA Call Policy all aliases prefixed with CAREC are responded as “found” by the TCA.

7 If the alias is found within the Local Zone or by one of the external zones, the VCS will attempt to

place the call to that zone.

8 If the alias is not found, the VCS will respond with a message to say that the call has failed.

9 Once the call is placed by the VCS to the TCA, the TCA then strips off the CAREC prefix and then

sends the original alias to the VCS, it then gains the true destination address from the VCS or it’s neighbored zones and completes the call.

Note that the above is somewhat simplified, see section 11 Call Flow within TCA for a detailed description of how the call flow works within the TCA and the Call processing section of the VCS Administrator Guide for more information as to how the VCS processes calls.

6.3.3 Using zones to manage TCAs

Depending on how your endpoints and VCSs are configured, you can use zones to direct calls to particular TCAs. For example, if a call comes from London, which is defined as ‘Zone UK’, you can rout all the calls in that zone to a TCA in London.

You can also use zones to set priorities that determine the order in which TCAs are chosen to record a call from a particular endpoint. For example, if you have three TCAs in zones A, B and C, and an endpoint in ‘Zone A’. If the endpoint makes a call that needs to be recorded, you can tell the VCS to prefer the TCA in Zone A, but if it is not available, to try the TCA in Zone B then Zone C.

You define these zone priority instructions in the zone definition screen of the VCS Administration Application. The VCS sends the call to the zone that responds first, so if you want to ensure that a VCS sends calls to the physically closest TCA you need to set the zone priorities so it queries the closest one first. Also be aware that the VCS uses zones to control and optimize bandwidth, so you need to consider that if you change the zone priorities.

See section 9 Deployment scenarios for some examples of how to use zones.

6.4 Turning off recording

There may be circumstances in which you need to turn off recording. For example, the TCA is designed to tear down any call if recording stops at any point during the call, so if you’re experiencing network issues that cause the TCA to drop out periodically, you may need to disable it temporarily so you can continue to use the video conferencing network while the problem is fixed.

To turn a TCA off you need to turn off the policy file on the VCS to which the TCA is neighbored. To do this, make a backup of the policy file that contains the control instructions for TCA, then replace the file with the original policy file that doesn’t contain the TCA instructions. This will prevent any calls being routed to the TCA.

6.5 Preventing users avoiding recording

In a network where endpoint configurations are not locked down, users may be able to change their endpoint URI. This presents a risk that users can make calls that are not recorded. If recording is compulsory, ensure that the network is locked down.

7 Security

7.1 Redundancy

If you only have one TCA and it becomes unavailable for whatever reason, then any calls made until it becomes available again will fail. As with any network technology, it is a good idea to have a second ‘redundant’ TCA in case the main one fails.

Whether you have the second TCA sitting unused or run both of them in parallel to share the load is up to you. The issues of optimal TCA placement will apply to each TCA you add to the network, so it’s important to define clearly what role each TCA will play and the load requirements it will need to meet.

Of course, you can have multiple TCAs in a single zone, or multiple zones each with one or more TCAs. The best configuration depends on the compliance policy and the design of the network. When installing the TCAs it’s also worth considering the points of failure in the network (such as whether you are connecting multiple TCAs through the same router or both TCA power connections to the same power supply).

7.2 What is secure and what isn’t

The TCA records whatever is being streamed from the endpoints. If the media stream is encrypted, the TCA stores the encrypted stream plus the encryption key. When it transcodes the encrypted media, the TCA de-crypts it using the key, so all transcoded video is transmitted and stored ‘in the clear’.

TCA transcodes all recordings (whether the original was encrypted or not) onto external storage ‘in the clear’. If an organization needs a secure link between the TCA and external storage, you’ll need to ask the network administrator to provide it.

Once the transcoded file is on the external storage, the security of the recording and access to it are the responsibility of the storage administrator.

8 Creating the policy file

The policy file provides the rules that determine how each VCS identifies calls from compliant endpoints that need to be recorded and chooses a TCA to record calls.

This section contains three examples of policy files for a number of different TCA deployments:



the Commented policy file (all calls recorded) contains comments that explain what each section of the file is doing and is an example of a file that sends every call the VCS receives to the TCA for recording



the Route selected calls to TCA file is an example of a file that sends calls made from a specific set of defined endpoints.

The easiest way to configure a policy file is to make a copy of an existing VCS policy file and modify it using an XML editor.

Important

: before editing the VCS policy file, make a backup of the original. If you

subsequently need to switch the TCA off, you can upload the original file back to the VCS.

8.1 Specifying which endpoints to record

As we discussed in section 6.2 Using patterns to identify compliant endpoints, you can use the policy file to define the specific subsets of endpoints that you want to record.

To use patterns, the endpoints in question must contain an common identifying element (e.g. the word ‘trader’ in

joe.smith.trader@tandberg.com) that makes them distinct from the rest. You then specify the

pattern or patterns you want to record in the address regular expression section of the policy file.

You can specify whether either the origin endpoint or the destination endpoint is the one that needs to be recorded using the address switch field. In the example below the file is specifying that all URIs of destination endpoints (as opposed to origin) containing the expression ‘trader’ must be recorded:

<address-switch field="destination"> <address regex="CAREC[.](.*)"> </address> <address regex=".*trader@tandberg.com">

To stipulate multiple patterns, separate them with a pipe symbol (|). Note that if you specify an E164 number it takes precedence over an H.323 address.

See the VCS User Guide for more information about control files.

8.2 How the policy file directs these calls to the TCA

In section 6.3.2 How the VCS and TCA work together, we talked about how the VCS changes the URI of the endpoint to send it to the TCA by adding the prefix ‘carec’ and the suffix ‘caxxx’.

8 Creating the policy file

The following section of the policy file is the part that does this:

<address-switch field="destination" subfield="alias-type"> <address regex="URI|url-ID"> <taa:location clear="yes" regex="(.*)@([A-Z,a-z,0-9,.,-]+)([:;]*)(.*)" replace="CAREC.\1@\2.CAXXX\3\4">

For example, if the URI

joe.smith.trader@tandberg.com was passed to the policy file, the taa:location

regular expression would change it to

carec.joe.smith.trader@tandberg.com.caxxx. The TCA would

then automatically recognize this URI as needing to be recorded.

8.3 Commented policy file (all calls recorded)

We start by rejecting all calls that are using IP addresses. VCS X3 currently has a bug where upon it cannot transform IP addresses

We look at the originating address of the endpoint

If the originator is the TCA itself we ignore it

</address> <not-present>

If there is no originating address, we look at the destination address

<address-switch field="destination"> <address regex="CAREC[.](.*)">

Firstly we check that this call is not already being routed to the TCA

Next we transform the destination address to ensure that the call is routed to the TCA. This will ensure that all calls are routed

<address-switch field="destination" subfield="alias-type"> <address regex="URI|url-ID"> <taa:location clear="yes" regex="(.*)@([A-Z,a-z,0-9,.,-]+)([:;]*)(.*)" replace="CAREC.\1@\2.CAXXX\3\4">

Take a well formed SIP address and surround the address with “CAREC” and “CAXXX”. The regular expression pointed to by “regex” splits the SIP address, taking into account addresses such as joe.smith@tandberg.com:5060;transport=tcp. Note that the domain can only contain alphanumerics, dots and dashes. It maybe that some domains have other valid characters that may be missed by this expression.

8 Creating the policy file

This section is for H.323 addresses.

<taa:location clear="yes" regex="(.*)" replace="CAREC\1"> <proxy/> </taa:location> </otherwise> </address-switch> </otherwise> </address-switch> </not-present> <otherwise>

If there was an originating address, we do the same as above.

<address-switch field="destination"> <address regex="CAREC[.](.*)"> <proxy/> </address> <otherwise> <!-- All other calls need to be routed via the CA by <address-switch field="destination" subfield="alias-type"> <address regex="URI|url-ID"> <taa:location clear="yes" regex="(.*)@([A-Z,a-z,0-9,.,-]+)([:;]*)(.*)" replace="CAREC.\1@\2.CAXXX\3\4"> <proxy/> </taa:location> </address> <otherwise> <taa:location clear="yes" regex="(.*)" replace="CAREC\1"> <proxy/> </taa:location> </otherwise> </address-switch> </otherwise> </address-switch> </otherwise> </address-switch> </otherwise> </address-switch> </taa:routed> </cpl>

8.4 Route selected calls to TCA

This version of the file specifies two endpoints to be recorded: joe.smith.office@tandberg.com and david.andrews.office@tandberg.com.

<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:taa="http://www.tandberg.net/cpl-extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd"> <taa:routed> <address-switch field="destination" subfield="alias-type"> <address regex="TRANSPORTID"> <reject status="reject" reason="IP address dialing not allowed in CA mode"/> </address> <otherwise> <address-switch field="origin"> <address contains="CA_RECORDED">  <proxy/> </address> <not-present>  <address-switch field="destination"> <address regex="CAREC[.](.*)">  <proxy/> </address> <address regex="joe.smith.office@tandberg.com|david.andrews.office@tandberg.com">  <address-switch field="destination" subfield="alias-type"> <address regex="URI|url-ID">  <taa:location clear="yes" regex="(.*)@([A-Z,a-z,0-9,.,-]+)([:;]*)(.*)" replace="CAREC.\1@\2.CAXXX\3\4"> <proxy/> </taa:location> </address> <otherwise>  <taa:location clear="yes" regex="(.*)" replace="CAREC.\1"> <proxy/> </taa:location> </otherwise>

8 Creating the policy file

</address-switch> </address> <otherwise>  <proxy/> </otherwise> </address-switch> </not-present> <otherwise>  <address-switch field="destination"> <address regex="CAREC[.](.*)">  <proxy/> </address> <address regex="joe.smith.office@tandberg.com|david.andrews.office@tandberg.com">  <address-switch field="destination" subfield="alias-type"> <address regex="URI|url-ID">  <taa:location clear="yes" regex="(.*)@([A-Z,a-z,0-9,.,-]+)([:;]*)(.*)" replace="CAREC.\1@\2.CAXXX\3\4"> <proxy/> </taa:location> </address> <otherwise>  <taa:location clear="yes" regex="(.*)" replace="CAREC.\1"> <proxy/> </taa:location> </otherwise>  </address-switch> </address> <otherwise>  <address-switch field="origin"> <address regex="joe.smtih.office@tandberg.com|david.andrews.office@tandberg.com">  <address-switch field="origin" subfield="alias-type"> <address regex="URI|url-ID">

<taa:location clear="yes" regex="(.*)@([A-Z,a-z,0-9,.,-]+)([:;]*)(.*)" replace="CAREC.\1@\2.CAXXX\3\4"> <proxy/> </taa:location> </address> <otherwise>  <taa:location clear="yes" regex="(.*)" replace="CAREC.\1"> <proxy/> </taa:location> </otherwise> </address-switch>  </address> <otherwise>  <proxy/> </otherwise> </address-switch> </otherwise> </address-switch> </otherwise> </address-switch> </otherwise> </address-switch> </taa:routed> </cpl>

9 Deployment scenarios

9.1 Scenario 1 – basic deployment

9.2 Scenario 2 – deployment across a WAN

9 Deployment scenarios

9.3 Scenario 3 – deployment to cater to regional variations in regulations

9.4 Scenario 4 – non-participating VCS

9 Deployment scenarios

9.5 Scenario 5 – external organization

9.6 Scenario 6 – VCS cluster

10 Sample TCA calculator

You can download this spreadsheet from www.tandbergnpd.com

# SIP endpoints 20000 # H.323 endpoints 300 # HD/Telepresence 4 Call Speed (Kbs) 384 Call Speed 768 Call Speed 2048 Average Duration of call (hours) 1 Average Duration of call 1 Average Duration of call 1 Resolution CIF Resolution 4CIF Resolution HD Resolution, framerate and codec not used in calculations at

present Framerate 25 Framerate 25 Framerate 30 Video Codec h.264 Video Codec h.263 Video Codec h.264 Future Growth (per year) 10% Future Growth 0% Future Growth 10% # Calls per day 2031 Total number of calls (see TMS CDR reports to gain accurate stats) Peak concurrent calls 203 At peak times (exchange open/close?) how many calls (Can get from TMS CDR reports) % multipoint 10.00% Of these calls, how many are multipoint, hosted on a MCU Avg# Endpoints in multipoint 4 Store multiview only no CA has a config option to only store the multipoint view being sent from the MCU, rather than each endpoint stream Hours Growth MB per CA % SIP calls per day 70% 1421.7

1563.87

191929.5

% H.323 calls per day 20% 406.2

406.2

109674

% HD calls per day 10% 203.1

223.41

146232

2031

2193.48

447835.5

74639.25

4825.66 Retention Period (months) 6 Archived Quality (Kbs) 768 Format will always be MPEG4, resolution and framerate will be dropped to meet this bandwidth. We'll keep audio quality high. Hours of business 8 Gives us an idea of when the box will be idle so that it can transcode with full power # of VCS 2 Not used in any calculations just yet, but peak concurrent call number must match licensed calls on VCSes # of CAs 6 # Peak streams through each CA 74.43

Each point to point call counts for 2 media streams

Peak bandwidth through each CA (Mbs) 45.59 Bandwidth is the maximum possible, endpoint codecs should be reducing the total bandwidth of the call speed over the life of a call # Hours recorded per day in total 4468.2

Each endpoint stream in a point to point plus only the multipoint stream if that option is selected. Otherwise a stream for each (avg#) endpoint in multipoint

Internal disk per day on each CA (GB) 164.21 10 bits in a byte, 1000MB in a GB used in this calculation External storage per day in total (GB) 1206.41 Total internal disk divided by the quality reduction ratio Transcoding Deficit In Day for each CA 791

Assumes TCA will only transcode when it is not taking calls, so 24 hours - 8hours for a business day = 16 hours to transcode on all CPU resources

Transcoding Deficit in 7 day Week 8565 This assumes that the weekend is available for transcoding, negative is bad. Transcodes per CA if 1 hour conferences 96

8 cores x the realtime transcode rate. May be much higher if video codec is h.264 as transcoding burden will be less

Transcode rate x realtime 12

We may be able to calculate this more precisely when taking the codec, framerate and resolution settings into account. This value is output to CIF on a low-end server. Higher resolutions = slower transcode (XGA = 2x)

External storage required:

week (GB) 6,032.07 5 days in a week month (GB) 26,541.11

22 days in a month

Retained (GB) 159,246.65

16459.2

Cost of storage (GB) $20.00 Total cost for retained video $3,184,932.96 Retained next year (GB) 171,986.38

11 Call Flow within TCA

Configuration Checklist

Organization details

Organization name

Compliance Manager

Phone

Location Email

Video Administrator

Phone

Location Email

Storage Administrator

Phone

Location Email

Network Administrator

Phone

Location Email

Compliance appliance details

Appliance name IP address

Physical location

VCS Neighbour

Recording resolution Transcoding resolution

Transcoding bit rate Recording indicator?  On  Off

Attached storage

Separate audio storage

Endpoint pattern

Appliance name IP address

Physical location

VCS Neighbour

Recording resolution Transcoding resolution

Transcoding bit rate Recording indicator?  On  Off

Attached storage

Separate audio storage

Endpoint pattern

Appliance name IP address

Physical location

VCS Neighbour

Recording resolution Transcoding resolution

Transcoding bit rate Recording indicator?  On  Off

Attached storage

Separate audio storage

Endpoint pattern

Appliance name IP address

Physical location

VCS Neighbour

Recording resolution Transcoding resolution

Transcoding bit rate Recording indicator?  On  Off

Attached storage

Separate audio storage

Endpoint pattern

Appliance name IP address

Physical location

VCS Neighbour

Recording resolution Transcoding resolution

Transcoding bit rate Recording indicator?  On  Off

Attached storage

Separate audio storage

Endpoint pattern

Appliance name IP address

Physical location

VCS Neighbour

Recording resolution Transcoding resolution

Transcoding bit rate Recording indicator?  On  Off

Attached storage

Separate audio storage

Endpoint pattern

TANDBERG Compliance Appliance Deployment Manual

Specifications and Main Features

Frequently Asked Questions

User Manual