Post on 22-Jan-2018
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?