The document provides an overview of the key components in a Sametime audio and video architecture: Proxy Registrar, Conference Manager, Video Manager, Video MCU, SIP Edge Proxy, TURN server, and client behavior. It discusses the installation order, configuration of elements like the Video Manager, and considerations for deploying audio and video capabilities for internal and external users.

1. New Way To Learn
Deploying Sametime
Audio and Video
Gabriella Davis
Technical Director
The Turtle Partnership
gabriella@turtlepartnership.com

2. Who Am I?
Admin of all things and especially quite
complicated things where the fun is
Working with security , healthchecks,
single sign on, design and deployment of
Domino, ST, Connec>ons and things that
they talk to
Stubborn and relentless problem solver
Lives in London about half of the >me
gabriella@turtlepartnership.com
twiDer: gabturtle
Awarded the first IBM Life>me
Achievement Award for Collabora>on
Solu>ons

3. Audio Video Components

4. 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?

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

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

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

8. 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
session
tim sip session
sue sip
session
creates sip sessions
Community Server
all calls are
initiated from here

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

10. PR+CF
Gab
Alan
Tim
Sue
PR+CF
create registrations
request a SIP session
passes SIP session request
gab sip
session
alan sip
session
tim sip session
sue sip
session
creates sip sessions
Community Server
all calls are
initiated from here

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

12. Video Manager
Video Manager
Gab
Alan
Tim
Sue
Proxy Registrar
create 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

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

14. Gab
Alan
Tim
Sue
Proxy Registrar
1. 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

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

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

17. External Routing
Tim
Sue
Gab
Alan
InternalDMZExternal
Community Server
all calls are
initiated from here
Proxy Registrar
Conference Manager
creates 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

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

19. Client Behaviour

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

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

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

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

24. Deploying

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

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

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

28. 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 Yes
Conference
Manager
Yes
PR+CF
Community Server Yes
Video Manager Yes
Video MCU Yes
SIP Edge Proxy Yes Yes Yes
TURN Yes Yes

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

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

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

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

33. Do not configure territory
Restrict the bit
rate if required

35. VMCU Settings

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

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

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

39. Troubleshooting

40. 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”

41. 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 :-)

42. 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”

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

44. TURN Server Logs
❖ Configured in logging.properties in the TURN application
directory
❖ Log files TURNServerx.log.x etc

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

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

47. Questions?