New Way To Learn

Deploying Sametime Audio and Video

Gabriella DavisTechnical DirectorThe Turtle Partnershipgabriella@turtlepartnership.com

Who Am I?

Adminofallthingsandespeciallyquitecomplicatedthingswherethefunis

Workingwithsecurity,healthchecks,singlesignon,designanddeploymentofDomino,ST,Connec>onsandthingsthattheytalkto

Stubbornandrelentlessproblemsolver

LivesinLondonabouthalfofthe>megabriella@turtlepartnership.comtwiDer:gabturtle

AwardedthefirstIBMLife>meAchievementAwardforCollabora>onSolu>ons

Audio Video Components

SIP Proxy Registrar❖ Is responsible for maintaining the registry for each client and

any conferences

❖ If the client can’t find the Proxy Registrar to register then their voice and video preferences won’t be available

❖ When registering, the client also transmits their ip:port combination. This is different than their SDP*

❖ When initiating any call the client sends their SDP* which contains information about their location, hardware and request *what’s a SDP Gab?

Session Description Protocol❖ A message format for multimedia communications

❖ A SDP contains information from the client such as

❖ session information. who I am and where to locate me

❖ media information. what type of media do I want to communicate with on this session

❖ The Proxy Registrar receives a SDP from a client wanting to initiate a session

❖ It is aware of the status of the person that client wants to talk to and will forward the request to them

❖ The invitee responds with their own SDP and a negotiation ensues

❖ Once established the traffic is routed outside of the Proxy Registrar

Proxy Registrar

Gab

Proxy Registrar

gab registers details for SIP availablity so the PR knows who is

available and where they are

gab sends a SDP when negotiating an audio or

video call PR sends a SIP message to Alan notifying him of an

awaiting call

Alan

alan responds to the PR with his own SDP

post negotiation of SDPs Gab and Alan initiate a peer

to peer session

Conference Manager❖ Establishes the SIP session for each client and monitors the audio and video state

❖ This applies to all calls including multiway and point to point

❖ The Conference Manager is instructed by the Community server to create the SIP session

❖ The Proxy Registrar forwards the SIP messages

❖ The Proxy Registrar server receives the client requests for a SIP session and forwards those to the Conference Manager

❖ With multiway calls all video traffic is sent via the VMCU

❖ The Conference Manager does not route audio and video traffic

❖ *sometimes referred to as the Conference Focus

Conference Manager

Gab

Alan

Tim

Sue

Proxy Registrar

create registrations

request a SIP session

Conference Manager

passes SIP session request

gab sip session

alan sip sessiontim sip session sue sip

session

creates sip sessions

Community Server

all calls are initiated from here

Combined PR+CF

❖ One deployment scenario is a combined server that contains both Proxy Registrar and Conference Manager functionality

❖ The single server installs with both applications

❖ Deploying as a combined server doesn’t affect the behaviour of each of the applications

❖ It does however prevent you from clustering

PR+CF

Gab

Alan

Tim

Sue

PR+CF

create registrations

request a SIP session

passes SIP session request

gab sip session

alan sip sessiontim sip session sue sip

session

creates sip sessionsCommunity Server

all calls are initiated from here

Video Manager❖ Manages how traffic will be distributed across the VMCUs

❖ Is aware of defined media rules and will enforce scaling on audio and video traffic

❖ Uses routing rules to determine which VMCU the traffic should route through

❖ Cannot be clustered

❖ Creates Conference/Meeting rooms according to a template

❖ Requires a dedicated Linux server

❖ With a Video Manager offline the Conference Manager will see it as unavailable and only peer to peer calls will be available

Video Manager

Video Manager

Gab

Alan

Tim

Sue

Proxy Registrarcreate registrations

request a SIP session

passes SIP session request

Conference Manager

gab sip session

alan sip session

tim sip session

sue sip session

request access to VMCU

6. uses routing rules to assign VMCU

Community Server

all calls are initiated from here

creates sip sessions

Video MCU❖ Routes all audio and video traffic for any conference involving

more than two people

❖ Requires a dedicated Linux server

❖ Cannot be clustered but multiple instances can have a load balancer to route traffic

❖ It that scenario, regardless of routing rules, everyone is routed to the VMCU of the call owner

❖ The VMCU ensures the correct audio and video stream is delivered to each client according to the client request and the Video Manager rules

Gab

Alan

Tim

Sue

Proxy Registrar1. create registrations

2. request a SIP session

Conference Manager

3.passes SIP session request

4. creates sip sessions

5. request access to VMCU

6. uses routing rules to assign VMCU

Video MCU

Video Manager

7. verifies audio and video rules for each session

8. bidirectionally routes audio and video

Video MCU

SIP Edge Proxy❖ Takes the Proxy Registrar role in architecture that requires

external or multi network access

❖ The SIP Edge Proxy is placed in the DMZ to accept requests from clients for SIP registration and forward those to the internal Proxy Registrar

❖ The public DNS name for the SIP Edge Proxy must match that of the internal Proxy Registrar

❖ Often we deploy split horizon DNS to handle that configuration

TURN Server❖ For clients that have a NAT address that prevent peer to

peer communication

❖ Clients that are on another network than the Media Server elements and present as a different IP than their source one will need access to a TURN server

❖ TURN acts as a relay for audio and video traffic both inbound and outbound

❖ If the TURN is in the DMZ then traffic between it and the VMCU must be open

External Routing

Tim

Sue

Gab

Alan

InternalDMZExternal

Community Server

all calls are initiated from here

Proxy Registrar

Conference Managercreates sip sessions

request access to VMCU

Video MCU

Video Manager

uses routing rules to assign VMCU

SIP Edge Proxy

TURN

create registrations

create registrations& SIP traffic

Community MUX

all calls are initiated from here

verifies audio and video rules for each session

audio / video traffic

Tim

Sue

Gab

Alan

InternalDMZExternal

stcomm.nwtl.com

all calls are initiated from here

stpr.nwtl.com

stcm.nwtl.com

creates sip sessions

request access to VMCU

stmcu.nwtl.com

stvmgr.nwtl.com

uses routing rules to assign VMCU

stpr.nwtl.com

stturn.nwtl.com

create registrations

create registrations& SIP traffic

stcomm.nwtl.com

all calls are initiated from here

verifies audio and video rules for each session

audio / video traffic

Publicly resolvable DNS entries

Internally resolvable DNS

entries

Fully Qualified Host Names

Client Behaviour

Standalone Client❖ The Community server tells the standalone client where the

Proxy Registrar is

❖ The client can only register with the PR if they have active hardware

❖ If not the options are greyed out

❖ Since the Community server will always advertise the name for the PR - that name must resolve externally as well

❖ Set the TURN DNS entry to 0.0.0.0 internally if clients have direct access to the VMCU ensures they do connect directly

Rich Client

❖ The details of the SIP Proxy Registrar are supplied to the client by the Community Server

❖ The Conference Manager talks to the Meeting Server to initiate a session for the meeting and for everyone in it

❖ Watching or listening to a session still requires a SIP session be established

❖ Audio and Video streams are sent via the Conference Manager integrated with the Meeting server

❖ Using the Meeting client is a good way of initially testing your architecture is working

❖ Single sign on tokens must exist between your Meeting server and Community server

❖ To create and store a token to pass between servers set the client preferences to remember the clients password

Web Meetings

❖ In a browser based meeting the audio / video WebPlayer plugins must be installed

❖ The plugins create the registration from the browser with the SIP Proxy Registrar

❖ Traffic is routed through the Meeting Server and via the web plugins

Mobile

❖ On a mobile client audio video activity behaves as if you are in a web meeting

❖ The Sametime proxy server provides the service to route traffic

❖ The Sametime applications register via the Sametime proxy server and route audio and video traffic the same way

❖ The Sametime proxy server and meeting server handle the routing with the VMCU

Deploying

Building AV - Internal❖ Plan your architecture carefully

❖ There is a specific install order and a specific order in which deployment plans must be created

❖ Some elements can be clustered, some cannot

❖ The ones that cannot can be separate installs behind a load balancer

❖ if you might want to cluster the SIP Proxy Registrar in the future do not install a combined PR+CF

Install Order❖ Many of the elements have dependencies on each other

❖ You can’t created a deployment plan for a Video Manager for instance until one exists for a SIP Proxy Registrar

❖ This applies to primary nodes. Secondary nodes can always be added later

❖ The Conference Manager must be installed after the Video Manager

❖ If installing a combined PR+CF you therefore must create the deployment for, and install, the Video Manager first

Creating Deployment Plans❖ If you are installing separate SIP Proxy Registrar and Conference Manager

1. SIP Proxy/Registrar

2. Video Manager

3. Conference Manager

4. Video MCU

❖ If you are installing a combined PR+CF

1. Video Manager

2. Combined SIP Proxy/Registrar and Conference Manager ("PR+CF" option)

3. Video MCU

You must install the servers in the same sequence that you created the deployment plans.

Clustering❖ Not all elements can be clustered

❖ Those that can are able to have secondary nodes added at any time to aid capacity

❖ If an element can’t be clustered it can still exist in multiple instances fronted by a load balancer

Can Be Clustered Multiple Instance with LB

Multiple Individual Instance

SIP Proxy Registrar YesConference Manager

Yes

PR+CF

Community Server Yes

Video Manager Yes

Video MCU Yes

SIP Edge Proxy Yes Yes Yes

TURN Yes Yes

Building AV For External Users❖ Consider the bandwidth requirements and the location of

your users

❖ since audio and video generate the most traffic and those come via the VMCU, geographically located VMCUs may be helpful

❖ Plan for site rules via the Video Manager to set routing and compression

❖ Introduce a bandwidth manager for more granular control over network traffic

External Access ❖ The architecture for internal vs external Sametime

communications is essentially Internal ++

❖ The design of your internal architecture is the same regardless of whether you want to grant external access

❖ Consider that users may work both internally and externally and their configuration with the FQHNs to find servers will not change

❖ Using internal only domains for server identities can be problematic especially if you want to configure SSO or shared certificates

Video Manager Configuration❖ Configuration for the Video Manager is read by the Websphere server

from a soliddb database on the linux file system

❖ The soliddb instance must be started before the WebSphere server or the configuration will to be read

❖ To verify the soliddb database server is listening on the Video Manager

❖ netstat -tulvn |grep “2315”

❖ When using multiple Video Managers you will want to replicate the configuration held in the soliddb

❖ There are scripts supplied that enable you to do that

Video Manager Settings❖ Configuring the site topology allows you to set up routing rules

for clients

❖ The Video Manager installs with a default territory - this cannot be changed or added to

❖ Configuring the VMCU allows you to set up rules for codecs and traffic

Do not configure territory

Restrict the bit rate if required

VMCU Settings

DMZ Elements❖ External users must be able to

❖ Connect to a Community Server

❖ you can add a MUX in the DMZ

❖ or use a HTTP proxy for web clients

❖ Register with the SIP Proxy Registrar

❖ You can add a SIP Edge Proxy in the DMZ

❖ Send and receive audio and video traffic

❖ a TURN server will provide relaying of that traffic and NAT traversal

Firewall Rules❖ From outside the firewall the client must be able to reach

❖ The SIP Proxy Registrar or SIP Edge Proxy usually on ports 5060 / 5061

❖ The SIP Edge Proxy must then be able to route that traffic to the internal SIP Proxy Registrar

❖ The Community Server or Community MUX on port 1533

❖ A HTTP Proxy that can forward access to internal Sametime Proxy or Meeting servers

❖ UDP or TCP port 3478 on the TURN server

❖ The TURN must be able to route UDP traffic for ports 49152 - 65535 to the VMCU

HTTP Connect❖ HTTP Connect functionality is new with Sametime 9.0.1

❖ It allows for audio and video communication over port 443 when in web meetings

❖ It is used by the WebPlayer browser plugins

❖ It is not possible to tunnel audio and video traffic from the Sametime standalone or embedded client

❖ To enable HTTP Connect you must manually change the ports used by the SIP_ProxyRegHost on the SIP Proxy Registrar and the TURN server http://ibm.co/1ZfZdrT

Troubleshooting

TCP vs UDP❖ UDP is an alternate protocol to TCP

❖ It’s a fire and forget traffic with no mechanism for confirmation of delivery

❖ For that reason it’s more efficient but less reliable

❖ Used a lot in high volume data transmissions like audio and video where dropped packets are manageable

❖ UDP is an option for VMCU and TURN communications that you should used where possible

“I would tell you a joke about UDP but you probably wouldn’t get it”

No Audio / Video Options❖ If the client cannot register

with the SIP Proxy Registrar successfully the Voice and Video page will be blank

❖ A blank page in your preferences usually means something has gone wrong with access to your AV architecture

❖ Or you just don’t have a camera or mic enabled :-)

Verifying the Video Manager

❖ The Video Manager installs as a standalone WebSphere server outside of the SSC cell

❖ To review the Video Manager’s WebSphere settings go to http://<videomanagerhostname>:9060/ibm/console

❖ To review the status of the Video Manager , what sessions it’s managing and if it can talk to the VMCU go to its management interface

❖ http://<videomanagerhostname>:8443/dma7000

❖ This is the polycom admin interface that you should rarely need to use unless investigating a problem

❖ The default username and password is “admin” : “admin”

Verifying The VMCU

❖ service soft_mcu status

❖ 0 = service is running

❖ 3 = service is not running

❖ 4 = service is unavailable

❖ 5 = service has startup issues

TURN Server Logs❖ Configured in logging.properties in the TURN application

directory

❖ Log files TURNServerx.log.x etc

SSL Certificates❖ When using SSL throughout your deployment you should

ensure to get a certificate from a known CA

❖ The Video Manager and SSC Cell must exchange certificates so that the servers in the SSC cell are able to talk to the Video Manager and vice versa

❖ Certificates that can’t recognise each other or that continually prompt the user in the client to accept them can cause enormous invisible problems

I like to buy a wildcard for my entire domain and use that for all servers

What Breaks What?❖ Audio and Video need a working Community server

❖ The VMCU can’t operate without the Video Manager

❖ The Conference Manager can’t initiate n-way sessions if the Video Manager isn’t available

❖ No SIP traffic can be sent to the clients and clients cannot register for SIP communications if the SIP Proxy Registrar isn’t accessible

❖ The Video Manager reads its configuration from the soliddb database when it loads so soliddb must be running first

❖ The TURN server isn’t a background service and if it stops running audio and video traffic can’t be sent to clients not on the server network

Questions?