Architecture of Microsoft Mediaroom

Architecture of Microsoft
Mediaroom
Microsoft Mediaroom Server 1.1 SP3.2

Product Documentation
server11sp32-27feb09-2009-0227-1757
Microsoft Mediaroom was formerly known as Microsoft TV IPTV

Edition. Titles, names, and logos have been updated to reflect the
new product name, but some document content may refer to the
previous product name.
Architecture of Microsoft Mediaroom

server11sp32-27feb09-2009-0227-1757
Page 1
Information in this document, including URL and other Internet Web site references, is subject to change without notice.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places,
and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain
name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may
be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the
furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual
property.
© 2009 Microsoft Corporation. All rights reserved.
Microsoft, Mediaroom, the Mediaroom logo, and/or other Microsoft products referenced herein are trademarks of the
Microsoft group of companies.
All other trademarks are property of their respective owners.

server11sp32-27feb09-2009-0227-1757
Page 2
Documentation Feedback
Microsoft welcomes your feedback on this documentation.
Microsoft Mediaroom Customers and Partners: You can provide feedback to any member
of your Microsoft Customer Account Team. Please use the procedure agreed on with your
account team, such as filing an SR.
Microsoft personnel: If appropriate, create a doc bug and, if needed, a KB Article, as
described in Field_Doc_Bug_Process.doc, which you can obtain by looking in Process and
Governance > Technical Publications Process Docs on the Microsoft Mediaroom (tv2)
intranet site or by sending an email to mrdocbug.

server11sp32-27feb09-2009-0227-1757
Page 3
Contents
Architecture of Microsoft Mediaroom...............................................................10
Using Architecture of Microsoft Mediaroom.......................................................................... 11
Audience........................................................................................................................... 11
Documentation Map ......................................................................................................... 11
High-Level Architecture ......................................................................................................... 13
Live TV Subsystem................................................................................................................. 21
Functional Flow from Capture Through Delivery............................................................ 21
Live TV Subsystem Software Components and Data Flow ............................................. 24
Live TV Acquisition Subsystem ...................................................................................... 25
Encoding.................................................................................................................... 25
Supported Data Streams ............................................................................................ 26
Failover Scenario....................................................................................................... 27
Live TV Acquisition Subsystem Software Components and Data Flow................... 27
Live TV Delivery Subsystem ........................................................................................... 31
Instant Channel Change............................................................................................. 32
ICC with Multicast .................................................................................................... 33
Reliable Live TV over RTP/UDP.............................................................................. 34
Failover Scenario....................................................................................................... 35
Service Replication.................................................................................................... 36
Live TV Delivery Subsystem Software Components and Data Flow ....................... 36
DServer/Client Command and Control ..................................................................... 38
DServer Machine Error Codes .................................................................................. 39
Command and Control Data Exchange ..................................................................... 39
Multiple Identical Live TV Delivery Subsystems ..................................................... 40
Scalability......................................................................................................................... 42
Video on Demand Subsystem ................................................................................................. 44
Functional Flow for Non-Distributed VOD Clusters ....................................................... 44
Functional Flow for Regionally Distributed VOD Clusters ............................................. 47
VOD Subsystem Software Components and Data Flow .................................................. 51
VOD Servers .................................................................................................................... 54
Multicast Asset Distribution............................................................................................. 55
Status Updates and Failover ...................................................................................... 57
VOD Clusters and Load Balancing .................................................................................. 58
Adaptive Asset Allocation......................................................................................... 59
Adaptive File Copy and Distributed Ingest ............................................................... 61

server11sp32-27feb09-2009-0227-1757
Page 4
VOD Assets and Content Aggregation ............................................................................. 62
VOD Trick Streams .......................................................................................................... 62
VOD Acquisition Subsystem............................................................................................ 63
VOD Delivery Subsystem ................................................................................................ 64
Decrypting DRM Keys .............................................................................................. 65
VOD Session Management and Load Balancing....................................................... 66
Life Cycle of a VOD Session..................................................................................... 66
Packet Loss and Retry................................................................................................ 67
Service Failover ......................................................................................................... 67
Large Asset Playback................................................................................................. 68
VOD Asset Security ......................................................................................................... 68
Integrating a Branch with an EQoS Interface ................................................................... 69
Integrating a Branch with an EPOC System..................................................................... 70
Live Anytime Subsystem......................................................................................................... 71
Live2VOD Recording Server ........................................................................................... 72
Capturing and Recording Assets................................................................................ 72
Live2VOD Controller Machine ........................................................................................ 73
Live Anytime Recording Schedules .......................................................................... 73
Live Anytime Asset Deployment............................................................................... 73
Live Anytime Roles.......................................................................................................... 73
L2VDB....................................................................................................................... 74
l2vRecServer.............................................................................................................. 74
l2vControllerWS ........................................................................................................ 74
ossLiveToVOD .......................................................................................................... 74
smtLive2VOD............................................................................................................ 74
timeshiftMapServerWS.............................................................................................. 75
RDP Application Subsystem ................................................................................................... 76
RDP Application Subsystem Software Components and Data Flow................................ 76
Windows Server Terminal Services........................................................................... 79
TServer Windows Service ......................................................................................... 79
Terminal Server Session Starter................................................................................. 79
RDP Application Launcher........................................................................................ 80
TServerProxy COM+ Service.................................................................................... 81
Terminal Server Controller Private Web Service ...................................................... 81
Terminal Server Controller Public Web Service ....................................................... 81
Terminal Server Controller Database ........................................................................ 82
Windows Applications............................................................................................... 82
Connecting to RDP Sessions ............................................................................................ 82

server11sp32-27feb09-2009-0227-1757
Page 5
Tracking Terminal Server Sessions.................................................................................. 83
Securing RDP Sessions .................................................................................................... 84
Managing RDP Sessions on Each Terminal Server ......................................................... 84
Scaling, Load Balancing, and Failover............................................................................. 85
Web Service Router ................................................................................................................ 86
Asset Store Subsystem ............................................................................................................ 88
Listings Subsystem.................................................................................................................. 90
Listings Distribution......................................................................................................... 90
Listings File Format ......................................................................................................... 93
Channel Maps................................................................................................................... 93
Media Discovery Subsystem................................................................................................... 95
Service Information Subsystem .............................................................................................. 98
Service Information Subsystem Software Components and Data Flow........................... 98
Client Startup Services.......................................................................................................... 101
Bootstrap Web Service................................................................................................... 101
Interaction of the Bootstrap Web Service with Other Microsoft Mediaroom
Components............................................................................................................. 101
Sync Discovery Service Windows Service .................................................................... 103
Disaster Recovery Application ................................................................................ 103
UpgradeWS Web Service............................................................................................... 103
ClientUpgradeFiles role ................................................................................................. 104
Subscriber Management Subsystem...................................................................................... 105
Service Offerings............................................................................................................ 105
Default Entitlements....................................................................................................... 105
Subscriber Management Information ............................................................................. 105
Billing Events................................................................................................................. 106
SMS Software Components and Data Flow ................................................................... 106
Service Group Subsystem ..................................................................................................... 109
Scalability and Load Balancing...................................................................................... 109
Microsoft Mediaroom Software Upgrades ..................................................................... 109
Service Group Subsystem Software Components and Data Flow.................................. 109
Service Group Database ................................................................................................. 111
Web Services in Service Groups .................................................................................... 111
Service Group SMS Web Service .................................................................................. 112
Branch Management Subsystem ........................................................................................... 113
Bootstrap and Redirection .............................................................................................. 114
Branch Database Tables ................................................................................................. 114
Web Services in the Branch ........................................................................................... 115

server11sp32-27feb09-2009-0227-1757
Page 6
Notification Subsystem.......................................................................................................... 116
Notification Subsystem Software Components and Data Flow...................................... 116
Message Handlers........................................................................................................... 119
Message Delivery and Heartbeat Protocol...................................................................... 119
Client Startup Communications with the Notification Subsystem ................................. 121
High Priority Notification Subsystem............................................................................. 122
Introduction.............................................................................................................. 123
Architecture ............................................................................................................. 123
Branch Routing Cache ...................................................................................... 123
Multicast to NDS in the Service Group ............................................................ 123
NTP-based Clock Synchronization ................................................................... 123
Redundant Message Handling at the Client ...................................................... 124
DVR Scheduler Subsystem ................................................................................................... 125
DVR Scheduling in a Multiple Set-Top Box Environment ............................................ 126
DVR Scheduler Subsystem Software Components and Data Flow................................ 126
User Store Subsystem............................................................................................................ 128
User Store Subsystem Software Components and Data Flow ........................................ 128
Session Key Authority Subsystem ........................................................................................ 130
Search Subsystem.................................................................................................................. 132
Logging Subsystem ............................................................................................................... 135
Logging Subsystem Software Components and Data Flow............................................ 139
Client Management Subsystem ............................................................................................. 143
Client Management Subsystem Software Components and Data Flow.......................... 143
NTP Server ............................................................................................................................ 148
Maintaining A/V Timing ................................................................................................ 149
Client Authentication and Rights Interpretation ............................................................. 150
Server Authentication ..................................................................................................... 150
NTP Server Categories ................................................................................................... 150
NTP Architecture............................................................................................................ 150
TV Services Management Tool............................................................................................. 151
TV Services Management Tool Pages and Associated Tasks ........................................ 151
Multiple and Simultaneous Interactions with TV Services Management Tool .............. 153
OSS Web Services................................................................................................................. 155
Backend Blackout Management Web Service................................................................ 157
Blackout Management Web Service............................................................................... 157
Branch Management Web Service ................................................................................. 158
Channel Management Web Service................................................................................ 158
Content Distribution Web Service .................................................................................. 159

server11sp32-27feb09-2009-0227-1757
Page 7
Client Configuration Web Service ................................................................................. 159
Diagnostics Notification Web Service ........................................................................... 159
Emergency Alert System Web Service .......................................................................... 161
EPG Web Service........................................................................................................... 161
Fingerprint Web Service ................................................................................................ 161
High-Priority Notification Web Service......................................................................... 161
Live Anytime Web Service ............................................................................................ 162
Live Deployment Web Service ...................................................................................... 162
PPV Management Web Service ..................................................................................... 163
Remote Recording Web Service .................................................................................... 163
Restart Anytime Web Service ........................................................................................ 164
Service Substitution Web Service .................................................................................. 164
UI Notification Web Service .......................................................................................... 164
URL Management Web Service..................................................................................... 165
VOD Backend Management Web Service ..................................................................... 166
VOD Branch Management Web Service........................................................................ 166
BSS Web Services................................................................................................................. 168
Billing Record Management Web Service ..................................................................... 169
Grant Management Web Service.................................................................................... 169
Offer Management Web Service .................................................................................... 170
Package Management Web Service ............................................................................... 170
Principal Management Web Service .............................................................................. 171
Reporting Store Web Service ......................................................................................... 171
Microsoft Mediaroom Client................................................................................................. 173
User Interface Framework.............................................................................................. 174
Data Exchange................................................................................................................ 174
Audio/Video Service Support ........................................................................................ 176
DVR Engine, Storage, and Management........................................................................ 177
RDP Application Support............................................................................................... 177
Bootstrap and Client Authentication .............................................................................. 178
Client Remote Control.................................................................................................... 179
Client Upgrade ............................................................................................................... 180
Multiple Client Households............................................................................................ 181
Client Streams ......................................................................................................... 182
Set-Top Boxes with and Without Hard Disks ......................................................... 183
Stream Management.............................................................................................................. 184
Stream Definitions.......................................................................................................... 185
WAN Streams.......................................................................................................... 186

server11sp32-27feb09-2009-0227-1757
Page 8
Ingress Streams ........................................................................................................ 186
Egress Streams ......................................................................................................... 187
Stream Contention .......................................................................................................... 190

server11sp32-27feb09-2009-0227-1757
Page 9
This document defines the overall logical architecture of Microsoft® Mediaroom. It
emphasizes key software components and their interfaces and illustrates how they support
Microsoft Mediaroom deployments.

server11sp32-27feb09-2009-0227-1757
Page 10
Using Architecture of Microsoft
Mediaroom
Microsoft® Mediaroom delivers high-quality live TV and video on demand (VOD) over
diverse IP network infrastructures. It is a robust platform that also enables service providers
to offer compelling interactive TV services such as Remote Desktop Protocol (RDP)
applications, an Electronic Program Guide (EPG), and a digital video recorder (DVR).
Audience
This document is intended for anyone who needs to understand how Microsoft Mediaroom
software components interact with one another. It is assumed that you are already familiar
with the features of Microsoft Mediaroom and need to understand how those features are
implemented. For information about Microsoft Mediaroom features, see Product Overview
(p. 007).
Documentation Map
The Microsoft Mediaroom software distribution includes technical documents that represent
the state of the Microsoft Mediaroom system at the time of publication. The following table
provides pointers to additional Microsoft Mediaroom information.
For information about See
Microsoft Mediaroom system features Product Overview (p. 007)
Finding information in the Microsoft Using the Documentation (p. 005)

Mediaroom Server Deployment and
Operations documentation set
Encoding video for delivery as VOD assets VOD Encoding Guide (Microsoft
Mediaroom Common Reference
documentation set)
Creating metadata for VOD assets VOD Metadata Guide and Reference (p.
007)

server11sp32-27feb09-2009-0227-1757
Page 11
For information about See
Configuring, monitoring, and maintaining Operations Guide (p. 015)

Microsoft Mediaroom
Customizing the client user interface Client Customization and Localization

Guide (Microsoft Mediaroom Client
documentation set)

server11sp32-27feb09-2009-0227-1757
Page 12
High-Level Architecture
The following diagram illustrates the logical organization of software components in the
Microsoft Mediaroom system.
TV/VOD TV/VOD Live TV Unicast Streams (UDP)

Acquisition Delivery Live TV Multicast Streams (UDP)
Subsystems Subsystems VOD/RTP Streams (HTTP)
Management Tool
Asset Store
TV Services
Subsystem
RDP
Keys
Application RDP Sessions
(HTTP)
Subsystem
Cookies
(HTTP)
Operational Support
OSS Web Services
Listings
Subsystem
Data Share User Store Get and Set

(OSS)
Subsystem Value Pair

Data Events
Microsoft Mediaroom Client

(HTTP)
Subscriber
Management
Subsystem
Bootstrap Boot
Web Service Information
BSS Web Services
Business Support
EPG
Web Services Router

Subsystem
Subsystem DVR Scheduler

Recording Schedule Events (HTTP)
(BSS)
Subsystem
Media Media
Discovery Desc
Subsystem Info
Service
Information
Subsystem Search Search Queries
Web Service (HTTP)
Notification Client Mgmt Software

Session Key Authority Subsystem Subsystem Updates
Subsystem
(Common to all Logging Client Events

subsystems) Subsystem (HTTP)
Service Group Subsystem

server11sp32-27feb09-2009-0227-1757
Page 13
VOD Backend
Management
Web Service
Backend Blackout Live Backend VOD Branch

Mgmt Web Management Management
Service Web Service Web Service OSS Web
Services
Live TV Multicast Streams (UDP) Unicast Streams (UDP)

Acquisition Live TV
Subsystem Delivery
Subsystem

Multicast Streams (UDP)
VOD RTP Streams (HTTP)

VOD VOD
Acquisition Delivery
Subsystem Subsystem
Web Services Router

Subscriber
Managemen
Subsystem
Asset Store
Subsystem
VOD/Live TV Acquisition and Delivery

Subsystems
Operations Support Systems TV Services Management Tool
Diagnostics VOD Backend Live Backend Channel

UI Notification
Notification Management Management Management
Web Services
Web Service Web Service Web Service Web Service
VOD Backend Backend VOD Branch

PPV Management
Management Blackout Mgmt. Management
Web Service
Web Service Web Service Web Service
OSS Web
Services
Media
EPG
Notification Discovery
VOD Live TV Subsystem
Subsystem Subsystem
Acquisition Acquisition
Subsystem Subsystem
Service VOD
Asset Store
Information Delivery
Subsystem
Subsystem Subsystem
Subscriber
Management
Subsystem

server11sp32-27feb09-2009-0227-1757
Page 14
Business Support Systems
Billing Record Grant Package Offer Principal

Management Management Management Management Management
Web Service Web Service Web Service Web Service Web Service
BSS Web Services
Subscriber
Management
Subsystem
In a Microsoft Mediaroom system, live TV, video on demand (VOD), and network (RDP)
application services are first acquired and then delivered to Microsoft Mediaroom set-top
boxes (also referred to as "clients" and "devices" in this document). For example, Microsoft
Mediaroom acquires live TV services, which can arrive in a variety of formats. Microsoft
Mediaroom then processes the streams to provide full-screen and picture-in-picture (PIP)
versions of the services in a uniform manner so that they can be delivered from backend sites
to one or more branches using Real-Time Transport Protocol (RTP).
Some Microsoft Mediaroom subsystems perform the acquisition and delivery functions
directly, while others perform a supporting role so that subscribers can discover and select the
services they want to view. For example, the live TV acquisition subsystem processes
incoming live TV services. Similarly, the VOD acquisition subsystem imports VOD assets. In
addition, the media discovery subsystem provides service descriptions that appear in program
listings.
Microsoft Mediaroom defines a set of application programming interfaces (APIs) through
which its service providers can integrate their business support systems (BSS) and operations
support systems (OSS) with Microsoft Mediaroom.
To coordinate the management of services and service information, custom applications can
use a set of OSS Web services that enable operators to manage the entire system across their
networks. Microsoft Mediaroom includes a Web application called the TV Services
Management tool that uses the OSS Web services and provides a user interface for managing
Microsoft Mediaroom services.
Service providers can integrate business support systems through a set of BSS Web services
that provide APIs for managing subscriber accounts, set-top boxes and other devices, billing
events, service packages, offers, and service entitlements.

server11sp32-27feb09-2009-0227-1757
Page 15
Many subsystems contain a set of components (typically Web services and databases) that
can be distributed across multiple security zones to support each service provider’s security
policies. Microsoft Mediaroom also provides a dedicated Web service router that brokers all
communications between Microsoft Mediaroom clients and the client-facing Web services.
The following table summarizes each Microsoft Mediaroom system software component.
Component Description
Live TV Acquisition Subsystem (p. Acquires live video services and generates full-
025) screen and PIP streams. Encodes streams with the
Windows Media 9 Series Audio and Video codecs
in VC-1 and H.264 formats for full-screen content
and VC-1 format for PIP streams. Encrypts and
encapsulates streams in RTP transport streams for
unicast or multicast delivery to one or more live TV
delivery subsystems.
Note If the incoming service does not require
live capture, only the PIP streams are encoded
with the Windows Media 9 Series Audio and
Video codecs.
Live TV Delivery Subsystem (p. Receives live TV services from the live TV
031) acquisition subsystem. Manages the delivery of
audio/video (A/V) streams to Microsoft Mediaroom
clients over IP unicast. Deployed on machines
known as Distribution Servers (DServers).
Live Anytime Subsystem (p. 071) Records live TV services from the live TV
acquisition subsystem, converts them to video on
demand (VOD) format, and deploys them to the
VOD delivery subsystem.
VOD Acquisition Subsystem (p. Creates video on demand (VOD) assets and
063) generates media and VOD asset metadata files for
deployment to one or more VOD delivery
subsystems.
VOD Delivery Subsystem (p. 064) Deploys VOD assets that are available on a VOD
acquisition subsystem. Includes a set of Media Store
virtual directories that deliver the VOD streams to
set-top boxes on request over HTTP.
RDP Application Subsystem (p. Enables subscribers to run remote Web or Windows

server11sp32-27feb09-2009-0227-1757
Page 16
076) applications through Remote Desktop Protocol

(RDP).
Web Service Router (p. 086) Brokers all Web service communications (SOAP
over HTTP) between Microsoft Mediaroom clients
and client-facing Web services.
Asset Store Subsystem (p. 088) Stores metadata for network (RDP) applications and
VOD assets that subscribers can browse, run, and, if
necessary, purchase.
Listings Subsystem (p. 090) Acquires listings data from third-party listings
services. Delivers listings to the media discovery
subsystem, which delivers the listings to Microsoft
Mediaroom clients.
Media Discovery Subsystem (p. Provides media descriptions that include content
095) metadata and information about how to access the
content. Exposes two identical Web services that
support requests from the server-facing tier and the
Web tier.
Service Information Subsystem (p. Provides a central directory for all Microsoft
098) Mediaroom services. Gives Microsoft Mediaroom
clients the information they need to acquire video
services.
Bootstrap Web Service (p. 101) Authenticates Microsoft Mediaroom clients and
logs them on to the Microsoft Mediaroom system.
Contacts the subscriber management subsystem
(SMS) to determine the subscriber status. Returns a
list of URLs for Web services (TServerController
Web service, upgrade Web service, and so on) from
which the Microsoft Mediaroom clients can acquire
configuration data.
Sync Discovery Service Windows Provides clients with the location of resources that
Service (p. 103) they can contact during regular start-up to retrieve
an upgraded version of the client software, or to
recover from client software failure, should one
occur.

server11sp32-27feb09-2009-0227-1757
Page 17
Subscriber Management Subsystem Provides a central repository for information about

(p. 105) subscriber entitlements. The bootstrap Web service
uses the subscriber management subsystem (SMS)
to determine whether subscribers are legitimate and
are allowed to access the service. SMS also stores
billing events when subscribers make purchases and
exposes a Web service through which service
provider BSS systems can modify billing-related
data.
Service Group Subsystem (p. 109) Stores account-specific data.
Service Group SMS Web Service (p. Enables BSS Web services to access the service
112) group database.
Branch Management Subsystem (p. Provides a central database for subscriber

113) information and a Web service to assign accounts to
the appropriate service groups.
Notification Subsystem (p. 116) Enables Microsoft Mediaroom services to send

messages to set-top boxes. Part of the Microsoft
Mediaroom Extensibility Framework.
Custom applications can also send messages to
Microsoft Mediaroom clients through the UI
notification and diagnostics notification Web
services (ossNotificationsWS).
DVR Scheduler Subsystem (p. 125) Manages digital video recorder (DVR) recording
schedules. Prompts clients to start and end
recordings through the notification subsystem.
User Store Subsystem (p. 128) Provides a generic mechanism for saving and
retrieving persistent name/value pairs.
Session Key Authority Subsystem (p. Generates, signs, and disseminates symmetric AES
130) keys to Microsoft Mediaroom components.
Search Subsystem (p. 132) Manages Microsoft Mediaroom client requests for
descriptions of media that meet various search
criteria, such as title or actor names.
Logging Subsystem (p. 135) Manages the various events generated by the

server11sp32-27feb09-2009-0227-1757
Page 18
Microsoft Mediaroom server software components

and Microsoft Mediaroom clients. Collects service
logs and subscriber activity events, such as channel
changes, and saves logs in a server-side database.
Client Management Subsystem (p. Enables Microsoft Mediaroom service providers to

143) upgrade software on set-top boxes in the field.
TV Services Management Tool (p. Provides a Web-based UI through which Microsoft

151) Mediaroom system operators manage live TV,
VOD, and network (RDP) application services.
OSS Web Services (p. 155) Enables the TV Services Management tool and
other OSS systems to manage the acquisition and
delivery of live TV, VOD, Live to VOD, and
network (RDP) application services. OSS Web
services include:
• The ossBackendBlackout Web service.
• The ossBranchBlackout Web service.
• The BranchMgmtWS Web service.
• The osschannel Web service.
• The diagnostics notification Web service
(ossNotificationsWS).
• The ossepg Web service.
• The OssLiveBackend Web service.
• The ossppv Web service.
• The ossremoterecord Web service.
• The UI notification Web service
(ossNotificationsWS).
• The ossurl Web service.
• The ossLiveToVodWS Web service.
• The ossVodBackendWS Web service.
• The ossVodBranchWS Web service.
BSS Web Services (p. 168) Enables the integration of service provider billing
systems with Microsoft Mediaroom. BSS Web

server11sp32-27feb09-2009-0227-1757
Page 19
services include:
• The BillingRecordManagement Web
service.
• The GrantManagement Web service.
• The PackageManagement Web service.
• The OfferManagement Web service.
• The PrincipalManagement Web service.
• The reportingstore Web service.
Service provider's operations support Provides the service provider’s operations and
systems and business support systems billing services. Typically in place for an existing
subscriber base, these systems integrate with the
Microsoft Mediaroom system through the OSS and
BSS Web services.
Microsoft Mediaroom integrates with the service
provider’s OSS and BSS systems by exposing a set
of Web services.
The Web services enable external OSS and BSS
systems to import and export data (get and set
operations). Traditionally, these OSS and BSS
systems include the service provider operations
support systems and business support systems and
the SMS.
Microsoft Mediaroom Client (p. An embeddable, IP-connected software component

173) that runs on Microsoft Windows CE and can be
installed in a set-top box or in devices such as
televisions, DVD players, DVRs, or game consoles.
Consumes video and data services delivered by
Microsoft Mediaroom server machines. Presents a
user interface (UI) that enables subscribers to
discover and view or interact with those services.

server11sp32-27feb09-2009-0227-1757
Page 20
Live TV Subsystem
The live TV subsystem acquires live (real-time) TV services and Pay Per View (PPV) content
from various input sources, processes the service content, and delivers it to Microsoft®
Mediaroom clients.
The live TV subsystem has a separated backend/branch model, in which each branch requests
and distributes a subset of the services made available by the backend. This method provides
control over the distribution state of a live TV service and enables operators to manage the
provisioning of services. Operators can control the following factors:
• The time that a live TV service comes online.
• The live backend that handles the service.
• The branches that distribute the service to clients.
A service provider creates live TV services using the TV Services Management tool in the
live backend. Operators in any branch can then deploy a published live TV service from any
authorized backend. After a branch deploys a live TV service to one or more Distribution
Server (DServer) machines, all clients in the branch that have the corresponding channel in
their channel lineup and are authorized for the service gain the ability to tune and receive the
video content.
The live TV subsystem consists of two subsystems:
• Live TV acquisition subsystem. Acquires and processes live TV services and
produces Real-Time Protocol (RTP) streams. This subsystem packages the RTP
streams in multicast User Datagram Protocol (UDP) packets and delivers the packets
to the live TV delivery subsystem and Microsoft Mediaroom clients. The live TV
acquisition subsystem encrypts the content by using Digital Rights Management
(DRM) technology, and makes the keys available for downstream branches to
distribute to their clients.
• Live TV delivery subsystem. Is responsible for the unicast delivery of live TV
services to Microsoft Mediaroom clients, providing instant channel change (ICC) and
reliable UDP.
Functional Flow from Capture Through Delivery

The following diagram illustrates the functional flow of a single live TV service from the
point of capture through the delivery to Microsoft Mediaroom clients.

server11sp32-27feb09-2009-0227-1757
Page 21
The numbered steps that follow describe details of the process.
1) Live TV acquisition subsystems capture and process a live TV service.
Backend operators use the TV Services Management tool to create and configure a
live TV service. The configuration process defines the capture and process
parameters, such as the transport stream source, the aspect ratio, and the bit rate, for
the live TV acquisition subsystem.
Live TV acquisition subsystems reside in the live backend. A single deployment can
have one or more live backends. A live backend can be deployed nationally,
regionally, or locally.
For additional information on live backends, see Logical Deployment Architecture
(p. 013) in Installation and Configuration Guide. For additional information on
how to configure and publish a live TV service, see Operations Guide.
2) Live TV acquisition subsystems multicast each live TV service on a port with a
unique multicast address. Although the multicast address for each live TV service
must be unique, ports can be reused.
Multicast packets are received by both the live TV delivery subsystem and Microsoft
Mediaroom clients. Multiple branches and numerous clients can connect to a single
multicast live TV service coming from a live TV acquisition subsystem.
Branch operators use the TV Services Management tool to deploy a live TV service
from the live TV acquisition subsystem. Each branch can deploy a different set of
live TV services. If a branch deploys a live TV service as unicast, ICC with
multicast, or multicast RUDP the live TV delivery subsystem receives the multicast

server11sp32-27feb09-2009-0227-1757
Page 22
stream from the live TV acquisition subsystem. If the service is deployed as a
multicast, the DServer machines ignore the service and the clients connect to it
directly. Additionally, a process within the branch periodically polls the backend to
retrieve the keys needed by clients to view the encrypted content.
When configuring a live TV service for deployment, operators set up bulk delivery
for the RTP streams to be either point-to-point (unicast) from the live TV delivery
subsystem, or one-to-many from a multicast transmission. The distribution method
for each live TV service is configured separately for each branch.
If the live TV service is configured with unicast, clients receive all packets in the
RTP stream as a unicast transmission from the live TV delivery subsystem. In this
case, only the live TV delivery subsystem receives the multicast output from the live
TV acquisition subsystem.
Note Unicast delivery is not typically used for deployment

If the live TV service is configured with ICC with IGMP, clients receive some
unicast packets (on startup and for retries), but receive the bulk of the packets in the
RTP stream directly from the multicast stream sent by the live TV acquisition
subsystem. In this case, both the live TV delivery subsystem and the client could be
receiving the multicast output from the live TV acquisition subsystem. Each full-
screen and PIP stream requires a unique multicast IP address and an assigned port.
If a backend operator changes the parameters of a deployed live TV service, the Live
Backend Update Windows service, which is running at the branch, gets the changed
values and uses them to update the branch. The Live Backend Update Windows
service polls the backend periodically for any service data changes.
3) Live TV delivery subsystems deliver the appropriate video content to clients.
If the live TV service is in the client channel map and the subscriber has access rights
to the live TV service, the client displays the live TV service when the subscriber
tunes to the appropriate channel. If a subscriber does not have the appropriate access
rights, a secondary video service can appear. For a live TV service, this secondary
video service is typically some type of upsell trailer.
When the client tunes to a live TV service, with ICC, the live TV delivery subsystem
bursts the live TV service to the client, enabling it to begin displaying live video very
quickly. For unicast delivery, this connection is kept open. For ICC with multicast,
the client switches to multicast after the initial burst is complete. The DServer
machine and client communicate through command and control protocol. Client
authentication occurs during each command and control packet exchange.

server11sp32-27feb09-2009-0227-1757
Page 23
Note For channels deployed using ICC with multicast, when a program is
recording in the background (not being displayed) on the client's DVR, ICC is not
required, and so the client joins the multicast stream directly and uses the DServer
machine for retries.
4) If the client detects lost packets, it requests that the live TV delivery subsystem
deliver the lost packets from the DServer machine to which it is connected. Each
session is bound to a particular DServer machine. If the client is connected to more
than one streaming service at a time, each session is handled independently, and the
sessions may or may not be sourced from the same DServer machine.
Live TV Subsystem Software Components and

Data Flow
The following diagram shows the live TV subsystem software components and a very simple
data flow. This diagram does not reflect scalability.
See Also
High-Level Architecture (p. 013)

server11sp32-27feb09-2009-0227-1757
Page 24
Live TV Acquisition Subsystem
The live TV acquisition subsystem is an installation of hardware and software modules that
take live MPEG-2 transport streams as TV data feeds and convert them into RTP streams.
Live TV data feeds come from multiple media sources:
• Real-time hardware encoders, such as VC-1, H.264, and MPEG-2 encoders.
• Spooled files on a local hard disk drive, such as media files containing Microsoft
Windows Media® audio and video, with only a single audio stream.
• Pre-encoded digital input streams from sources such as a satellite system.
The live TV acquisition subsystem performs the following operations:
• Captures live TV streams that are delivered to the Acquisition Server machine from
MPEG2TS over multicast UDP. This operation includes capturing a secondary audio
program (SAP) if the service is configured to do so.
• Generates VC-1 picture-in-picture (PIP) streams or acquires PIP directly from
encoders.
PIP streams are a lower resolution, lower bit rate, video-only version of a live TV
service. A PIP is typically used as a preview service for a channel other than the one
the subscriber is currently viewing.
• Encrypts video and audio elementary streams (ES) (full-screen video and audio,
secondary audio, and PIP video).
• Generates keys, rotates the keys that are used for encryption on content boundaries as
dictated by operations support systems (OSS) and DRM, and stores the keys in a
database. Once the live TV service is deployed on the branch, a polling mechanism
keeps the keys up to date at the branch.
• Encapsulates streams into RTP for multicast delivery to the live TV delivery
subsystem and, depending on the configuration, to Microsoft Mediaroom clients
through the service provider’s multicast-enabled network.
• Marks the RTP stream with the appropriate Macrovision analog content protection
control bits. The control bits instruct the Microsoft Mediaroom client to add analog
content protection to the outgoing analog live TV stream.
• Finds and marks RAP points in RTP headers.
Encoding
The live TV acquisition subsystem accepts external streams as MPEG-2 transport, sent over
UDP multicast.

server11sp32-27feb09-2009-0227-1757
Page 25
Pre-encoded, full-screen or PIP services are packed into RTP packets. Local streams are MF-
RTP (for example: Acquisition Server machine-generated PIPs). The DServer machine and
client can handle either type of RTP stream.
The live TV acquisition subsystem can generate a PIP stream for each live TV service, but
does not necessarily generate one for each stream. Having the Acquisition Server machine
generate the PIP locally greatly decreases scalability. In the latter case, the live TV
acquisition subsystem must first decode the stream, scale it down to the defined resolution,
and then encode the PIP stream.
PIPs that are externally generated, such as those created by the real-time encoders, are
managed by the Acquisition Server machine as a separate process from the PIPs generated by
the live TV acquisition subsystem. The streams are encrypted and passed through as usual.
Supported Data Streams

Microsoft Mediaroom supports several types of data streams. The following table lists the
data streams supported by the system.
Supported Data Stream Live-over-IP VOD DVR Playout Live-over-

Type DTT
DVB-Teletext (EN 300 472) Yes Yes Yes Yes
DVB-VBI (EN 301 775) for Yes Yes Yes Yes

Teletext
DVB-VBI (EN 301 775) for Yes No No Yes

VPS
AFD 2 Yes Yes Yes Yes
DVB-Subtitles (EN 300 743) Yes Yes Yes Yes
MHEG-5 No No 1 No 1 Yes
EIA 608 Yes Yes Yes No
EIA 708b Yes Yes Yes No

1
If present, because of Live to VOD for example, must be suppressed.
2
For WSS signaling

server11sp32-27feb09-2009-0227-1757
Page 26
Failover Scenario
When operators detect a failure in a server, they can manually change live TV service
assignments from one Acquisition Server machine to another. This process requires the
operator to have configured a designated backup Acquisition Server machine in the cluster.
When failure is detected, the keys used by the initial Acquisition Server machine are reloaded
by the new Acquisition Server machine, and the live TV service continues after a brief
interruption.
See Also
Live TV Subsystem (p. 021)
Live TV Delivery Subsystem (p. 031)
Live TV Acquisition Subsystem Software Components and

Data Flow
The following diagram shows the software components and data flow of the live TV
acquisition subsystem.

server11sp32-27feb09-2009-0227-1757
Page 27
The following table describes the software components of the live TV acquisition subsystem.

server11sp32-27feb09-2009-0227-1757
Page 28
Acquisition group Coordinates live TV, PPV, and blackout acquisition activities across
controller Web the Acquisition Server machines and delivers the appropriate details
service on live TV services to other Microsoft Mediaroom server
components to enable delivery of streams and keys to Microsoft
Mediaroom clients. A single Live Backend Controller machine can
control multiple Acquisition Server machines. The Web service
configures and coordinates the activities of the Acquisition Server
machines. During startup, the Web service reads the service
configuration information from the LiveBackend database and builds
a table of Acquisition Server machines that are responsible for
acquiring these services. All communications between the controller
and the servers are HTTP connections initiated by the server. The
controller cannot initiate a connection to an Acquisition Server
machine. The controller detects whether a server is properly
configured when the server periodically connects to the controller
and requests instructions. The controller detects server failures by
calculating the time elapsed since a particular server connected to the
controller and requested instructions.

server11sp32-27feb09-2009-0227-1757
Page 29
Acquisition Server Captures, repackages, encrypts, and delivers live TV streams from
machine external sources. In some cases, the live TV stream is decoded and
the video re-encoded at a lower resolution. The Acquisition Server
machine can also repackage or play back pre-encoded streams.
Acquisition Server machines use processes to provide a way to
group similar full-screen and PIP services. A process is a task that
must be performed by a single server, such as reading a network
stream, generating a PIP, and emitting both services. Processes can
manage network input or disk input.
A Microsoft Mediaroom installation can have any number of
Acquisition Server machines with each Acquisition Server process
running on an individual machine. The data that emerges from the
Acquisition Server machine includes:
• Boundary keys (used to encrypt data in audio and video
streams).
• Encrypted full-screen live TV services (A/V, and possibly
data streams such as; subtitles, teletext, and a variety of
other content).
• Encrypted PIP services (video only).
Acquisition Server machines can be clustered together. A cluster is a
unit of network configuration and failover aggregation. A server
belongs to no more than one cluster. An Acquisition Server machine
cannot support a process unless it is assigned to a cluster because the
cluster is what tells the Acquisition Server machine the subnet or
subnets to use for ingress, egress, and so on.
Communication between the Acquisition Server machine and the
Live Backend Controller machine follows a polling model. The
Acquisition Server machine periodically polls the Live Backend
Controller machine for updated live TV service information. If
services are added to or removed from the database, the Acquisition
Server machine makes the appropriate updates to its current services.
If a particular server does not poll for a certain amount of time, an
alert is raised.

server11sp32-27feb09-2009-0227-1757
Page 30
Live backend Contains the list of live TV services defined in the live TV
database subsystem, their associated properties, the cluster configurations, the
list of servers in the backend, and keys associated with the services.
The Live Backend Controller machine uses this information when
configuring the Acquisition Server machines. You can modify the
information by using the TV Services Management tool or external
OSS Web services.
Live TV Delivery Subsystem

The live TV delivery subsystem sits near the edge of the service provider’s network. It
receives one or more RTP streams emitted by the live TV acquisition subsystem, and delivers
the live TV services to clients. The live TV delivery subsystem consists of a
EdgeControllerFromEdgeWS Web service and multiple DServer machines. The
EdgeControllerFromEdgeWS Web service manages a group of DServer machines. DServer
machines distribute live TV services to clients, perform ICC, and handle reliable UDP.
DServer machines can receive and deliver live TV services on the same or different subnets.
Note The use of different subnets is recommended.

Using the TV Services Management tool, operators define one or more ingress, egress, and
retry subnets for the live TV delivery subsystem. For additional information, see Configuring
Live TV Services (p. 114) in Operations Guide.
The live TV delivery subsystem handles only point-to-point (unicast) delivery of RTP
streams to Microsoft Mediaroom clients. Multicast RTP streams do not originate through this
subsystem, although it does use them to support ICC with Multicast.
Live TV is delivered over one of the four following protocols:
• Unicast + ICC (RUDP)
• Muticast + ICC (RUDP)
• Multicast + RUDP
• Multicast only

server11sp32-27feb09-2009-0227-1757
Page 31
Instant Channel Change
ICC is a tuning methodology that significantly reduces the time required for a live TV service
to appear on a Microsoft Mediaroom client after a channel change.
Switching channels in a digital environment is inherently slower than switching channels in
an analog system. The delay is caused primarily by the wait for the start of a Group of
Pictures (GOP), or key frame, before the client displays the live TV service. Another source
of delay is the client's caching of enough frames to prevent buffer underflow.
To minimize this delay, the DServer machine maintains a continuously updated circular
buffer of the entire recent content of the stream. When a client requests a channel change
from the live TV delivery subsystem, the selected DServer machine unicasts cached stream
content, starting with an I-frame, to the Microsoft Mediaroom client at an accelerated rate.
The rate is configurable through the TV Services Management tool at deployment time.
Because the first frame is always an I-frame, the wait for an I-frame is completely eliminated.
The wait for the buffering to be satisfied is also greatly reduced because data is arriving at a
faster than normal data rate, allowing the client to begin playing back cached content before a
pure multicast tune would.
After the live TV delivery subsystem sends enough cache content to “catch up” to live TV, it
begins to send new video content at the nominal bit rate of the stream. The burst duration
varies depending on the content of the stream, its associated GOP distance, and its maximum
system time clock/decode time stamp (STC/DTS) delay. Generally, the shorter those values,
the shorter the ICC burst will be. Typical streams as deployed today have burst durations
between 6 and 15 seconds. The following figure illustrates the ICC process.
Provisioning DServer machine bandwidth depends on expected client activity. If 10,000

clients each change channels once a day at a different time, you do not need to provision
nearly as much bandwidth in the DServer machine as you would if each client changes
channel once a second. The more bandwidth that is reserved for each ICC burst, the less
overlap exists between channel changes, but the more bandwidth must be available to each
household.

server11sp32-27feb09-2009-0227-1757
Page 32
ICC with Multicast
ICC with Multicast is an intermediate tuning methodology that combines elements of pure
multicast tuning and ICC. ICC with Multicast uses the live TV delivery subsystem to enable
the client to display full-motion video with the same response time as the ICC model.
Note Both full-screen and PIP streams can be delivered using ICC and ICC with IGMP.
Like ICC, the live TV delivery subsystem unicasts a burst of video frames to the client at an
accelerated rate. After the client buffers enough data to prevent an underflow condition
(which can be between 1 and 5 seconds of video content, depending on the encoding
parameters), the client returns to receiving an ordinary multicast stream.
During the switch to ICC with IGMP, some packets typically are dropped, based on the data
rate of the stream and speed of the IGMP join process. The DServer machine backfills these
packets before the client needs to access them. The time between the channel tune request and
the multicast switchover point can vary depending on the stream parameters, how far the
initial I-frame was from the actual live stream, and the bandwidth reserved for unicast. The
following figure illustrates the ICC with IGMP process.
There is a trade-off between the length of time the client must remain attached to the DServer
machine at the burst data rate and the amount of network bandwidth used for the initial burst.
Whenever a client connects to a managed stream from the DServer machine, the DServer
machine picks a key frame from some point in the past in its buffer and begins transmitting

server11sp32-27feb09-2009-0227-1757
Page 33
data to the client from that point in the stream (thus enabling ICC). That initial time
difference is called the “delay time.” For the DServer machine to catch the client up to the
“live stream,” the DServer machine must transmit data in bursts at a higher data rate until it
transfers not only all the original delayed data, but also all additional data that came in during
the transfer.
If the nominal bit rate of the stream is 1 and the ratio of extra bandwidth percentage available
for the burst is “E”, the amount of time that the client must remain connected to the burst to
catch up to live (“burst time”), is as follows:
burst time = (delay time)/0.E Example: burst time = (3sec)/0.2 = 15sec
As the delay time increases without modifying the amount of extra bandwidth reserved, the
burst time increases. As the amount of extra bandwidth available for ICC increases, the
amount of burst time required decreases. However, the amount of aggregate output bandwidth
that must be reserved per subscriber on the DServer machine does not rely only on the
amount of extra burst bandwidth provisioned; it also relies on the amount of time that a client
spends in the burst state.
Reliable Live TV over RTP/UDP

The live TV delivery subsystem implements a mechanism for delivering reliable live TV over
RTP/UDP. This technique is used between the live TV acquisition subsystem and live TV
delivery subsystem, as well as between the live TV delivery subsystem and clients. The retry
mechanism between the live TV acquisition subsystem and the live TV delivery subsystem
can be turned off at the branch, turned off on a service-by-service basis at the branch, or
turned off on a service-by-service basis at the backend. All services deployed as ICC or ICC
with multicast have UDP implemented between the delivery system and the client.
When delivering RTP packets over UDP, the RTP packed is embedded directly behind the
UDP header.
Packet headers, RTP headers, and the packetized elementary stream (PES) headers within the
content are not encrypted; only the ES data is encrypted. The following diagram shows the
RTP packets within the UDP packets making up the stream.
If a client drops one or more UDP packets, it reports the session ID and the missing packet
sequence numbers to the live TV delivery subsystem over the command and control protocol.
The live TV delivery subsystem then resends the dropped packet or packets.

server11sp32-27feb09-2009-0227-1757
Page 34
The Microsoft Mediaroom Client (on the Set Top Box) does not report missing packets
immediately, because packets can be reordered during delivery. Periodically, the client makes
an analysis of any holes it currently has in the RTP stream and reports all or a subset of those
holes to the DServer machine to which the client is connected. The DServer machine
examines the report and resends the missing packets.
Note The time period between client-hole analyses is 100 milliseconds. This value is not
currently configurable.
Retries between the DServer machine and client are always delivered over the same network
connection as that of the original unicast. Retry traffic between the Acquisition Server
machine and the DServer machine can be routed over a separate connection.
Prior to Microsoft Mediaroom 1.1 SP3.2, all retries were accomplished over unicast. In the
case of a large failure, such as a backbone network failure between the Acquisition Server and
DServer, the result is a flood of packet requests from both DServers and Clients exceeding the
egress capacity of the Acquisition Server(s).
In Microsoft Mediaroom 1.1 SP3.2 and later, a Multicast option has been added as an
alternative approach to RUDP Unicast for servicing requests for lost packets where lost
packets are re-injected into the multicast stream. The retry packets are sent on the same
multicast stream as the original stream and reach the entire network.
This Multicast RUDP (Inband RUDP) addresses scenarios where failures affect a large
portion of the network. However, in the case of a local packet loss between the DServer and
Acquisition Server the result would be flooding the DServer and Client network with
unnecessary retry packets. The Acquisition Server, acting in the Autoselect Mode,
automatically detects the nature of the failure (local loss or large scale network loss) and
automatically selects the appropriate (Unicast vs. Multicast) mode to employ when
transmitting retry packets.
Failover Scenario
While a Microsoft Mediaroom client is connected to a DServer machine, it periodically sends
a command and control packet to the DServer machine and requests the status of the stream.
If the connection fails or times out, the client detects a problem with the DServer machine.
The client disconnects from the DServer machine, selects another one from its service-to-
DServer map, and tries to connect to the new DServer machine.
If the first reconnect is successful, the subscriber perceives, at worst, only a few seconds of
interrupted live TV services. If the client was in the “multicast” portion of an ICC with IGMP
channel session, the subscriber might not perceive a service interruption. However, each
individual DServer machine rejects connections that it cannot handle within its bandwidth

server11sp32-27feb09-2009-0227-1757
Page 35
allocation, so if all DServer machines on the client’s current map reject the tune and the live
TV service was originally deployed as ICC with IGMP, the client simply joins the service in
“pure multicast” mode. The channel change time for pure multicast is large compared to the
tune time for ICC. If the service is deployed as “ICC,” the client cannot recognize the
multicast address, and therefore cannot join directly.
If a client is tuned to a channel for the purposes of “background digital video recording” (the
stream is recording but not currently displaying), there is no penalty for having a slightly
slower channel tune. To improve system scalability, the client immediately joins the service
in multicast mode. The client also initiates a connection to the DServer-to-service retries so
that later viewing of the content has a complete packet stream.
Service Replication
For scalability and redundancy purposes, live TV service delivery is spread across multiple
servers within a live TV delivery subsystem. A DServer machine is the server machine in the
live TV delivery subsystem that delivers live TV content to clients. When operators define a
live TV service in the Microsoft Mediaroom system, they assign a percentage of DServer
machines to manage the distribution of the service. This percentage is called the replication
constant.
The replication constant is specified on a percentage basis. For example, if there are 100
DServer machines and the replication constant for a given service is set to 80 percent, 80 of
the DServer machines distribute that live TV service.
Live TV Delivery Subsystem Software Components and

Data Flow
The following diagram shows the live TV delivery subsystem software components.

server11sp32-27feb09-2009-0227-1757
Page 36
The following table describes the software components in the live TV delivery subsystem.
DServer controller Manages DServer machines and coordinates the distribution of

Web service RTP streams.
Each EdgeControllerFromEdgeWS Web service can manage
multiple DServer machines.
Live configuration Exposes a Web service interface that enables external resources,
state Web service such as the branch management Web service (ossbranch), to update
the content in the BranchDB database.
BranchDB database Contains the configuration information for each live TV service
deployed in the live TV subsystem. This database also contains the
mapping between live TV services and the DServer machines that
distribute them.
Service-to-DServer Exposes a Web service interface that enables clients to obtain the
map Web service service-to-DServer map. This map tells clients the DServer

server11sp32-27feb09-2009-0227-1757
Page 37
machine that is distributing each live TV service.

A table inside the BranchDB database describes the services that
are assigned to each DServer machine. The
EdgeControllerFromEdgeWS Web service goes through the table
and, for each service, randomly selects two DServer machines from
the list. It collates the entries into the service-to-DServer map and
returns the service-to-DServer map to the client.
If a subscriber group is assigned to only one cluster, both servers
will be in the same cluster. If the subscriber group is assigned to
more than one cluster, then the subscriber group will be assigned to
one server in each cluster.
DServer Unicasts live TV services (RTP streams) to clients. The DServer

machine also handles ICC and manages dropped packet requests.
See Also
Live TV Acquisition Subsystem (p. 025)
DServer/Client Command and Control

All communication between DServer machines and Microsoft Mediaroom clients is through
RTP/UDP. Before a DServer machine responds to a client command and control packet, the
client is authenticated. In addition, all command and control packets are encrypted.
To overcome UDP’s inherent unreliability, Microsoft Mediaroom sends command and
control packets multiple times to ensure that the destination receives at least one copy of the
packet. The number of times a packet is sent is configurable; the default value is two.
Each DServer/client command and control packet starts with a 12-byte RTP header, followed
by a 4-byte DServer command and control header. The following table contains the set of
commands that are sent between the DServer machine and Microsoft Mediaroom clients.
Value Description Sent By
0x01 Join request Client
0x02 Retry request Client

server11sp32-27feb09-2009-0227-1757
Page 38
Value Description Sent By
0x04 Leave Client
0x08 Status (for example, stat or ping) Client
0x81 Join response DServer
0x82 Burst complete DServer
0x84 Known hole in stream DServer
0xFF Error DServer
DServer Machine Error Codes

The following error codes are sent from the DServer machine.
Error Code Description Additional Information
0x0001 Service not yet buffered Service GUID
0x0002 Retry packet requested is not valid Synchronization source

(SSRC) and sequence
number
0x0003 No such service Service GUID
0x0004 No such session Session GUID
0x0005 Bad session Session GUID
0x0006 Unsupported command and control None

version
0x0007 Server full None
0xFFFF Session destroyed by server Session GUID
Command and Control Data Exchange

The following diagram, which shows a “join service” command and control exchange
between a DServer machine and a Microsoft Mediaroom client, illustrates how the UDP

server11sp32-27feb09-2009-0227-1757
Page 39
packets that are sent open a hole for bidirectional communication through any intermediate
firewalls.
Multiple Identical Live TV Delivery Subsystems

In a typical Microsoft Mediaroom system, a single live TV delivery subsystem delivers all
live TV services to all clients in a branch. You can configure the live TV subsystem to enable
separate, identical live TV delivery subsystems to service different physical locations without
the operational overhead of maintaining multiple branches.
The following diagram illustrates such a configuration.

server11sp32-27feb09-2009-0227-1757
Page 40
In this illustration, service groups A and B are in two different cities. The live TV delivery
subsystems are physically located in these cities. The Branch Management machine can be
physically located in either city. The Branch Management machine and the two live TV
delivery subsystems all reside in the same logical branch. When an operator deploys a live
TV service (or performs any service maintenance function), the service is automatically
deployed to both live TV delivery subsystems.
The DServer machine clusters in the live TV delivery subsystems are associated with the
clients in their service groups through a subscriber group. In this example, two subscriber
groups are used, set up so that in subscriber group A clients in service group A connect to
DServer machines in service group A, and in subscriber group B clients in service group B
connect to DServer machines in service group B.
For the multiple live TV delivery subsystem feature to work, you must configure the system
to meet the following requirements:
• The backend database and Web services recognize only one live TV delivery
subsystem.
• Each client belongs to only one subscriber group.
• Every client in a service group belongs to the same subscriber group.
• The DServer machines in the live TV delivery subsystem belong to the same
subscriber group.

server11sp32-27feb09-2009-0227-1757
Page 41
Scalability
Live TV subsystem components can be distributed throughout a service provider’s network to
ensure optimum acquisition and delivery of live TV services. The overall acquisition goal is
to process any unique live TV service only once.
Live TV services should be acquired at the point that best aligns with their distribution range.
For example, if a service provider’s network contains a central office and multiple regional
offices, you configure the live TV acquisition subsystems to acquire national services at the
central office and local services at the regional office that is closest to the clients for those
services. The individual regional offices can deliver all, some, or none of these services to
their respective clients. The live TV delivery subsystems (distribution points) are located in
the regional offices closest to the clients.
The following diagram depicts this example of a central office and multiple regional offices
and the configuration of the live TV acquisition subsystems.
You use the TV Services Management tool to define the live TV services that are acquired by
each live TV acquisition subsystem. Similarly, you use this tool to define the services that are
deployed to each live TV delivery subsystem.
For more information on scalability, see Scalability Guide (p. 005).

server11sp32-27feb09-2009-0227-1757
Page 42
See Also
Live TV Acquisition Subsystem (p. 025)
Live TV Delivery Subsystem (p. 031)

server11sp32-27feb09-2009-0227-1757
Page 43
Video on Demand Subsystem
The video on demand (VOD) subsystem acquires VOD assets and delivers them to
Microsoft® Mediaroom clients. Typically, VOD assets are created and managed by third-
party VOD asset content providers, who make the assets available to service providers.
The Microsoft Mediaroom Video on Demand (VOD) subsystem supports the acquisition,
import, and delivery of VOD assets that can be deployed to one or more VOD Servers. The
VOD subsystem uses a deployment method for distributing VOD assets. This method enables
operators to control the distribution state of VOD assets for each individual branch while
maintaining one or more centralized VOD backends.
Functional Flow for Non-Distributed VOD

Clusters
The following diagram illustrates the high-level steps for VOD encoding, importing, and
deploying VOD assets within a VOD subsystem based on one cluster for each branch. A
branch is a logical construct that defines a specific set of Microsoft Mediaroom server roles
on a specific set of server machines. (A branch is not a physical location.)

server11sp32-27feb09-2009-0227-1757
Page 44
1) Content providers use third-party professional VOD encoding tools to encode VOD
assets. During this process, they define VOD encoding parameters such as aspect
ratio, output resolution, bit rate, quality, and buffer window. For more information
about the compression parameters, see VOD Encoding Guide.
Content providers provide the VOD asset metadata. (Microsoft Mediaroom supports
assets delivered with ADI 1.1 or Microsoft Mediaroom metadata. For more
information about how Microsoft Mediaroom translates ADI metadata, see VOD
Metadata Guide and Reference.) Asset metadata includes the business rules (for
example, sales period and price) and the rights information (for example, rental
window). For details, see VOD Assets and Content Aggregation (p. 062).
2) Content providers deliver VOD assets to service providers through a secure
mechanism such as a virtual private network (VPN) or catcher system to the
vodassets folder at the service provider’s site. For information on creating the
vodassets folder, see Creating a Folder for VOD Imports (p. 341).

server11sp32-27feb09-2009-0227-1757
Page 45
3) After a VOD asset is successfully delivered to the vodassets folder, Vod Import
Preprocessor Windows® service can perform necessary translations to an asset or
group of assets. These necessary translations include the following: translating ADI
metadata to Microsoft Mediaroom metadata; translating .png graphics; and applying
an operator’s rules-based modifications to the VOD asset metadata or verbs (for
example, import and deploy). After Vod Import Preprocessor Windows service
completes its tasks, a VOD backend operator might use the VOD Asset Management
tool to modify certain metadata values. Such modifications could include, for
example, the purchase price or the rental time frame. For more information on the
metadata values that VOD backend operators can modify with the VOD Asset
Management tool, see Modifying VOD Asset Metadata at the Backend (p. 347) in
Operations Guide.
4) VOD backend operators use the VOD Asset Management tool to select VOD assets
for import or auto-import. The VOD Creator Station imports and processes VOD
assets that are stored in the vodassets folder. The VOD Creator Station encrypts
VOD assets with Digital Rights Management (DRM) keys; applies Macrovision or
CGMS-A messaging; generates Real-Time Transfer Protocol (RTP) streams for the
main feature; generates trick streams; and stores the generated VOD asset content in
one of the Staging folders. There can be more than one VOD Creator Station
performing these tasks, and more than one Staging folder. For details, see VOD
Acquisition Subsystem (p. 063).
VOD backend operators can choose to have asset files automatically deleted from the
Staging folder when their license window expires. If they select that choice, they can
also choose to have the asset files automatically deleted from the vodassets folder at
the same time. For more information on these choices, see Settings (for VOD
Management) (p. 094) in TV Services Management Tool Reference.
Note Fast forward and rewind trick streams are not created for the asset's trailer file
(preview). The only supported trick stream for the trailer file is pause.
5) Branch operators choose the assets to deploy to the VOD delivery subsystem, or they
have assets deployed automatically. Auto-deployment can be activated and can
depend on rules defined by the VOD backend operator. Deployment of a VOD asset
triggers an automated process that copies the VOD asset from the VOD backend
Staging folder to the selected VOD clusters in the branch. For details, see VOD
Delivery Subsystem (p. 064).
After VOD asset deployment, branch operators can use the VOD Asset Management
tool to modify the VOD metadata to reflect branch-specific parameters.
6) Subscribers can purchase and play a VOD asset, based on the business rules specified
by each VOD asset's business metadata.

server11sp32-27feb09-2009-0227-1757
Page 46
7) The vodControllerWS Web service ensures that the VOD subsystem can support an
additional VOD session prior to each play. Each play request to the VOD subsystem
is authenticated to ensure that only valid clients are accessing VOD assets. For
additional information on the vodControllerWS Web service, see VOD Delivery
Subsystem (p. 064).
When a client requests a VOD asset, the highest priority VOD cluster assigned to the
subscriber group of which that client is a member is contacted. If that VOD cluster is
offline, the next highest priority VOD cluster assigned to that subscriber group is
contacted, and so on until an online VOD cluster with the requested VOD asset is
found. If all VOD clusters assigned to the subscriber group are offline, an error code
is returned to the client.
8) Each asset event is maintained by Microsoft Mediaroom to support the necessary
audit, billing, and settlement.
9) Branch operators can either use the TV Services Management tool on the Branch
Management machine to choose the assets to delete from each branch, or they can
have assets deleted automatically based on the end of the license window, as
specified in the VOD asset’s business metadata.
10) If the backend operator did not choose to have the VOD asset files automatically
deleted from the Staging folders, they can use the VOD Asset Management tool on
the VOD Management machine to manually delete the assets from the Staging
folders. If the backend operator did choose to have the VOD asset files automatically
deleted from both the Staging and vodassets folders, the VOD asset's files are
automatically removed when its license window expires.
Functional Flow for Regionally Distributed VOD

Clusters
The following diagram illustrates the high-level steps for importing, publishing, and
deploying VOD assets within a VOD subsystem based on multiple clusters for each branch.
For more information about each step, see Functional Flow for Non-Distributed VOD
Clusters (p. 044).

server11sp32-27feb09-2009-0227-1757
Page 47
Servers can be positioned closer to the set-top box to accommodate bandwidth constraints. To
configure this, for each geographical region the operator sets up one cluster and one
subscriber group. The operator uses the TV Services Management tool on the Branch
Management machine or uses operations support systems (OSS) APIs to associate a
subscriber group with a cluster.

server11sp32-27feb09-2009-0227-1757
Page 48
To conserve storage and bandwidth for more popular VOD assets, VOD Servers can be
assigned to different VOD clusters that in turn can be associated with the same subscriber
group. You place the more popular VOD assets on VOD clusters that are located at a site
closer to the subscriber, and the less popular VOD assets on VOD clusters that are at the
branch. When the subscriber chooses to view a VOD asset, the VOD cluster assigned the
highest priority is contacted first. If that VOD cluster does not have the requested VOD asset
or is offline, the VOD cluster assigned the next highest priority is contacted. This
arrangement also provides additional failover capabilities. When the higher priority VOD
cluster is offline, the next highest priority VOD cluster that has the requested VOD asset
provides it to the client. The following diagram shows how a VOD asset is served from a
specific VOD cluster based on the priority assigned to the VOD cluster.
Note A VOD cluster should be associated with only one subscriber group.
The vodMapServerWS Web service is hosted on a client-facing service group machine. When
the vodMapServerWS Web service receives a request from a set-top box, one of the
following cases applies:
• The subscriber is in only one subscriber group, and that subscriber group is
associated with one VOD cluster.
• If the associated VOD cluster has the requested VOD asset, it returns the IP
addresses of two VOD Servers from the VOD cluster.
• If the associated VOD cluster does not have the VOD asset, it returns an error
code.
• The subscriber is in more than one subscriber group, but only one subscriber group is
associated with a VOD cluster.

server11sp32-27feb09-2009-0227-1757
Page 49
• If the associated VOD cluster has the VOD asset, it returns the IP addresses of
two VOD Servers from the VOD cluster.
• If the associated VOD cluster does not have the VOD asset, it returns an error
code to the set-top box.
• The subscriber is in one or more subscriber groups; however, none are associated
with a VOD cluster. An error code is returned to the set-top box.
• The subscriber is in more than one subscriber group, and more than one of those
subscriber groups is associated with a VOD cluster.
• The associated VOD cluster that has the highest priority designation and which
hosts a VOD Server that has the VOD asset provides it to the subscriber’s set-top
box.
• If the highest priority VOD cluster is offline, the next highest priority VOD
cluster is contacted. If that VOD cluster has a VOD Server that has the VOD
asset, it is provided to the subscriber's set-top box.
• If none of the associated VOD clusters has the VOD asset, an error code is
returned to the set-top box.
• The subscriber is in one or more subscriber groups, and one or more of those
subscriber groups is associated with multiple VOD clusters.
• The associated VOD cluster that has the highest priority designation and which
hosts a VOD Server that has the VOD asset provides it to the subscriber’s set-top
box.
• If the highest priority VOD cluster is offline, the next highest priority VOD
cluster is contacted. If that VOD cluster has a VOD Server that has the VOD
asset, it is provided to the subscriber's set-top box.
• If none of the associated VOD clusters has the VOD asset, an error code is
returned to the set-top box.
After a VOD cluster is selected, the load balancing algorithm is applied to select the
appropriate VOD Server and interface within that VOD Server.
Note A Microsoft Mediaroom operator assigns a VOD Server to a specific VOD cluster
through an entry in the serverlayout.xml file. For information on assigning a VOD Server to a
specific VOD cluster, see Creating a New Server Layout File (p. 094) in Installation and
Configuration Guide.

server11sp32-27feb09-2009-0227-1757
Page 50
VOD Subsystem Software Components and Data
Flow
The following diagram shows the software components of the VOD subsystem and the data
that flows between the components. It also shows how the VOD subsystem interacts with
other Microsoft Mediaroom subsystems to deliver VOD assets to Microsoft Mediaroom
clients.
The division of VOD acquisition and delivery subsystems enables each to be installed and
operated by one organization or for the VOD acquisition subsystem to be outsourced to a
separate organization. In either case, the VOD delivery subsystem must have secure access to
the VOD acquisition subsystem to access the assets in the Staging folders.
The following table describes each software component, server, and storage location used in
the VOD subsystem.
vodassets folder Contains the pre-imported VOD assets. The VOD Creator Station
looks for the VOD assets in this folder. The location of this folder is
configurable. VOD assets must be transferred to this folder after they
are acquired from a VOD asset content provider. For information on

server11sp32-27feb09-2009-0227-1757
Page 51
creating this folder, see Creating a Folder for VOD Imports (p.
341) in Operations Guide. For additional information on the asset
store subsystem, see Asset Store Subsystem (p. 088).
BranchDB database Database that stores the states of all assets and VOD Server
machines.
vodCatalogWS Web Provides a client-facing Web service interface through which clients
service obtain VOD metadata.
When a Microsoft Mediaroom client needs to construct a Video on
Demand screen, it contacts the vodCatalogWS Web service to obtain
a list of VOD assets and categories. The vodCatalogWS Web service
contacts the subscriber management subsystem (SMS) to look up the
subscriber to determine which assets the subscriber is entitled to
view. The vodCatalogWS Web service returns the complete URL of
each VOD asset. The vodCatalogWS Web service is not responsible
for tracking VOD locations (service information). The
vodCatalogWS Web service is installed on a Server-Facing Branch
machine.
VOD cluster A logical grouping of VOD Servers that manages how assets are
distributed to the VOD Servers in the cluster. After deployment,
VOD Servers periodically report their current asset load back to the
VOD cluster. Microsoft Mediaroom provides one VOD cluster,
named “default.” You assign one or more VOD Servers in the same
branch to a VOD cluster. You can assign multiple VOD clusters to a
subscriber group, assigning a priority to each VOD cluster to control
which VOD cluster the subscriber group's VOD asset requests will
go to in priority order. For information on creating additional VOD
clusters, see Creating a New Server Layout File (p. 094) in
Installation and Configuration Guide.
VOD Server Serves VOD asset content to the subscriber’s set-top box. A VOD
Server can store VOD assets in RAM or direct access storage (DAS)
memory, depending on how popular the VOD asset is at a given
time. For more information about how the load on a VOD Server is
managed, see the VOD Clusters and Load Balancing (p. 058)
section.
VOD Creator Station Exposes an interface through which the vodCreatorControllerWS

Web service controls the import process. There can be more than one

server11sp32-27feb09-2009-0227-1757
Page 52
VOD Creator Station.

During import, the interface takes VOD assets (content and
metadata) from the vodassets folder and encrypts and generates the
RTP format files for the full-screen and trick streams. These
processed files are then placed in the Staging folder with the
corresponding metadata and DRM key files.
Staging folder Contains imported VOD asset files. During deployment these files
are copied from this folder to the Mediaxx folders on the VOD
Servers at the branch. You can configure additional local Staging
folders, or additional Staging folders on a remote machine. For more
information about configuring Staging folders, see Configuring an
Additional Staging Folder on a Local Disk (p. 313) and
Configuring an Additional Staging Folder on a Remote Machine (p.
315) in Operations Guide.
VOD COM+ server Contacts the vodControllerWS Web service every n seconds with
status (including asset and session information).
IIS Extension Responsible for streaming and client authentication. On any

connection changes, IIS Extension updates the VOD COM+ server
machine.
Ingest adapter Uses a variety of methods of loading a VOD asset into a VOD
Server (http and https). Ingest adapter can get assets from the peer
VOD Server machines in the VOD cluster during deployment and
replication.
vodMapServerWS Provides a client-facing Web service interface for set-top boxes to

Web service receive the URLs of asset locations. The vodMapServerWS role is
installed on a client-facing server that has access to the
ServiceGroupDB database.
vodControllerWS Handles communication between the VOD Server and Server-Facing

Web service Branch machine. The vodControllerWS Web service manages the
transfer of VOD asset content from the BranchDB database to each
Media Store virtual directory (Mediaxx) on VOD Servers in each
cluster according to the operator-defined content list.
vodBranchWS Web Provides an interface for all branch-related operations; for example,
service deployment and replication.

server11sp32-27feb09-2009-0227-1757
Page 53
vodBackendWS Web Provides an interface for all backend-related operations, for example,
service import, pre-processing, and vodBackend database access.
VOD branch Provides a wrapper around the vodBranchWS Web service to enable
management Web VOD asset management by the VOD Management tool. For more
service information, see VOD Branch Management Web Service (p. 166).
(ossVodBranchWS)
VOD backend Provides a wrapper around the vodBackendWS Web service to

management Web enable VOD asset management by the VOD Management tool. For
service more information, see VOD Backend Management Web Service (p.
(ossVodBackendWS) 166).
VOD Servers
The type of VOD Server you use to store VOD assets depends on the performance
expectations and popularity of the stored assets:
• RAM. A RAM-based media server serves assets from RAM; therefore, its disk
performance is slower, but the egress capacity is higher. The vodControllerWS Web
service puts the most popular VOD assets on RAM-based VOD Servers to fully
utilize the faster egress capacity.
• DAS. A DAS-based VOD Server serves assets from the hard disk; therefore, its
egress capacity is lower, but it can accommodate more assets than a RAM-based
VOD Server. The vodControllerWS Web service puts all but the most popular VOD
assets on the DAS-based VOD Servers.
VOD assets on a VOD Sever are stored in the Media folder. Under the media folder are sub-
folders named Mediaxx where xx is a positive integer. The Mediaxx sub-folders are either a
local folder or a mount point to another hard disk. The name for each new Mediaxx sub-folder
is incremented by one for each new folder or mount point that is added to the VOD Server for
storing deployed VOD assets.
VOD asset files for each VOD asset are stored under separate Assetxx sub-folders under a
Mediaxx sub-folder. The name for each new Assetxx sub-folder is incremented by one for
each new VOD asset deployed to the VOD Server.
The following example shows the directory structure under the Media folder on a VOD
Server that has three media folders that store the files for a total of six VOD assets:
Media\

server11sp32-27feb09-2009-0227-1757
Page 54
\Media0
\Asset1
\Asset2
\Media1
\Asset3
\Media2
\Asset4
\Asset5
\Asset6
Multicast Asset Distribution

The multicast asset distribution delivery system delivers VOD assets to the branch without
impacting VOD play-out that may be occurring on the set-top boxes.
Note This delivery system does not scale the bandwidth required on the WAN links as a
function of the number of branches.
The following diagram illustrates multicast asset distribution.

server11sp32-27feb09-2009-0227-1757
Page 55
There are four main components to multicast VOD deployment for multicast asset
distribution:
• ContentDistributionControllerWS.
• ContentDistributionServer.
• ContentDistributionReceiver.
• OSS Content Distribution Web service.
There are also three minor components in the existing Microsoft Mediaroom architecture that
connect multicast asset distribution to the import and deployment process:
• VODCreatorControllerWS Web service.
• vodBackendWS Web service.

server11sp32-27feb09-2009-0227-1757
Page 56
• VOD VServer Windows service.
ContentDistributionServer consists of a Windows service at the central office that interfaces
with ContentDistributionController and the asset distribution engine. The engine includes the
distributor driver responsible for streaming VOD assets over multicast and the user mode
code that interfaces to it.
ContentDistributionReceiver consists of a Windows service at each branch; the Windows
service interacts with ContentDistributionController and the asset distribution receiver engine.
The Receiver driver in the engine is tasked with receiving the multicast stream, and the OSS
Content Distribution Web service stores the received VOD asset files according to the
manifest.
Note This feature is only available if the QFE116790 portion of the SP3.2 CP2 is installed in
your Microsoft Mediaroom 1.1 SP3.2 server environment. For information on post-
installation configuration and the content distribution Web service (OSS), see “Appendix of
Changes for QFE116790 - Multicast Asset Distribution” in QFE187577 Release Notes. For
information on configuring multicast asset distribution, see Configuring Multicast VOD Asset
Distribution (p. 320) in Operations Guide.
Status Updates and Failover

When a new task is assigned to a VOD Content Distribution Server, the server must ping the
Content Distribution Controller every n seconds to inform the controller of its status. If a
server fails to report task status within a predefined “server time-out” (default is 30 minutes),
the controller flags the server as inactive, reschedules the task, and changes the primary
server. After the task is rescheduled, it is assigned to any other idle server, and that server
becomes the primary server.
The Content Distribution Receivers time out on receiving the task from the original server
and use the next address to get the manifest on the stream and receive the VOD asset. If the
failed server is successfully restarted and reports its status, the controller continues to send the
tasks to the new primary server. Every time a new server becomes a primary server, or an
offline primary server comes back within the “server time-out”, the current task starts over
again.
There is no failover mechanism for the receiver, but the system supports receiver redundancy.
A VOD cluster can have multiple active receivers, all receiving the VOD asset files at the
same time. When the VOD Servers check the serverlayout.xml file for machines with local
staging, the VOD Servers cycle through all the receivers in the VOD cluster before checking
the VOD backend for local staging. Local staging, if configured, provides a local directory on
the VOD Server for the receiver to use in writing assets.

server11sp32-27feb09-2009-0227-1757
Page 57
VOD Clusters and Load Balancing
VOD clustering optimizes the equipment required to deliver a diverse offering of VOD assets.
Operators can deploy assets based on their usage patterns. VOD assets that subscribers view
often are placed on high-capacity VOD Servers, whereas assets with lower usage patterns are
served from lower-capacity VOD Servers. The VOD clusters associated with the VOD
Servers can also be distributed in different locations, in a central office or a remote location,
to conserve storage and bandwidth for VOD assets that are viewed more frequently. This load
balancing enables service providers to optimize the overall cost of the equipment required to
manage and deliver VOD assets.
The vodControllerWS Web service is primarily responsible for managing the VOD asset
content on each VOD cluster:
• The operator configures VOD Server machines to be part of a VOD cluster (one
load-balanced IP address assigned per cluster). For more information, see Creating a
New Server Layout File (p. 094) in Installation and Configuration Guide.
• The operator associates subscriber groups to VOD clusters, assigning a priority
number to each association (ranging from 1 to 10, with 1 as the highest priority).
• The operator assigns content titles to each cluster. For more information, see
Deploying Assets to VOD Clusters (p. 385) in Operations Guide.
• The vodControllerWS Web service manages the transfer of VOD asset content from
the vodBackend database to each Media Store virtual directory (the Mediaxx folders)
in each cluster according to the operator-defined content list.
To load balance, when a VOD Server boots up, it initializes itself by calling the
vodControllerWS Web service and registering itself. Thereafter, the VOD Server reports its
status through the VOD COM+ Server to the vodControllerWS Web service every 10
seconds.
If for any reason the VOD Server shuts down (either for normal maintenance or unexpected
failure), the vodControllerWS Web service detects its absence when it does not receive a
status update from the VOD COM+ server monitoring that VOD Server. A maximum of 10
seconds elapses before the server’s absence is detected. When the vodControllerWS Web
service detects that the VOD Server has shut down, it updates the database with this
information. After that point, load balancing and adaptive allocation continue with the
assumption that this VOD Server is not available to serve assets to clients. The VOD Server’s
former clients are redirected through the failover mechanism to another VOD Server that has
the same VOD asset that the client requested.
When the VOD Server reboots, it first initializes itself by calling the vodControllerWS Web
service and re-registering itself with the vodControllerWS Web service so that it is
immediately available to serve assets to clients.

server11sp32-27feb09-2009-0227-1757
Page 58
When a request for a VOD asset is received, the vodMapServerWS Web services uses its
copy of the ServiceGroupDB database to determine which VOD Servers have the VOD asset
and which two of those servers are currently the least loaded. Least loaded is defined as
having the most remaining bandwidth for the combined network interface cards (NICs) on
that VOD Server. The least-loaded NIC is selected from both VOD Servers and is then used
to deliver the VOD asset to the client.
The vodControllerWS Web service knows the current load on each (NIC) on the VOD
Servers, where load is defined as the current bandwidth being used on that NIC. You
configure NICs to use for load-balancing clients in the vserver.xml file by specifying the
maximum percentage of the bandwidth to use on a specific NIC (the default is 80 percent).
For more information about the vserver.xml file, see Modifying the vserver.xml File for a
VOD Server (p. 369) in Operations Guide.
To ensure access, the requested VOD asset can be deployed to more than one VOD cluster.
When a VOD asset is requested by a client in a subscriber group that is associated with more
than one VOD cluster, the VOD cluster that was assigned the highest priority number is
contacted first. If that VOD cluster is offline, the VOD cluster with the next highest priority
number is contacted. If all of the VOD clusters associated with the subscriber group are
offline, an error message is returned to the subscriber's device.
Adaptive Asset Allocation

A VOD asset is deployed first to a configurable number of DAS VOD Servers within the
VOD cluster. (The number of servers in the cluster to which the VOD asset is initially
deployed can be set in vodcontroller.xml, which is typically found in the installDir\config
folder. The default is 2.) The DAS servers are chosen based on which has the most disk space
available, or in a rotating fashion if both servers have the same amount of space available.
You can free disk space by deleting the least popular VOD asset on the server, if that VOD
asset exists on more than the configured minimum number of servers. If fewer than the
minimum number of servers are available with sufficient disk space and no assets can be
deleted to free up disk space, the VOD asset’s deployment will fail.
The initial deployment is targeted to the VOD Server that currently has the most available
storage space, directly from the backend Staging folder over HTTP or HTTPS. If the asset's
initial deployment to a VOD Server fails, deployment to a different VOD Server in the cluster
is not attempted and the asset deployment fails. Adaptive asset allocation only applies once
the initial VOD deployment has succeeded.
If necessary for security reasons, the VOD asset can first be copied to a temporary file system
that the vodControllerWS Web service has access to, where it will then be copied to the
Media Store virtual directory in the cluster. The temporary file system is the master storage

server11sp32-27feb09-2009-0227-1757
Page 59
that is installed with the vodControllerWS Web service. Its usage is configurable, and the
setting is stored in the BranchDB database. (By default, the setting is to not use the temporary
file system, but to copy VOD asset files directly to the targeted VOD Server.)
The subsequent copies are made from the first VOD Server to the second VOD Server in the
cluster (the next server that has the most available storage space) through HTTP, using
Windows NT® LAN Manager (NTLM) authentication.
After that, the VOD asset is replicated to additional servers, as needed, based on demand.
This process is called adaptive allocation. The algorithm for determining whether the VOD
asset should be replicated is as follows:
1) When a request comes in, the load balancing algorithm is used. If the selected
interface on the selected VOD Server is above a configured threshold (TA), then the
process continues with Step 2. The default for TA is 60 percent.
2) Replication of the most popular VOD asset on that VOD Server occurs. If the VOD
asset is more popular than the least popular VOD asset in RAM, the VOD asset is
replicated to a RAM-based VOD Server. If not, the VOD asset is replicated to a
DAS-based VOD Server.
3) During replication, the system is analyzed to determine whether the VOD asset fits in
the remaining storage.
• For a RAM-based VOD Server, it is unlikely that the VOD asset fits in the
remaining storage, so the least-used VOD asset is removed from the server, after
ensuring that remaining servers can handle the current subscriber load for the
removed asset. This may mean additional replication to another RAM- or DAS-
based VOD Server for the removed asset. The system will attempt to find the
RAM-based VOD Server that requires the least amount of VOD asset
movement.
• For a DAS-based VOD Server, the list of available DAS-based VOD Servers is
first sorted by network usage from least used to most used. A configuration
variable determines how full the operator wants the disk system to grow to and
once it hits that amount, any replication attempt to that server will result in first
checking to see if a less popular VOD asset can be deleted. Once a VOD asset's
usage goes down, it is not explicitly removed from a DAS-based VOD Server,
but may be removed to make space for the replication of another VOD asset.
4) If a VOD asset is to be removed from a RAM-based VOD Server, it is first copied
over to a DAS-based VOD Server and is then removed from the RAM-based VOD
Server. If multiple assets are to be removed from the RAM-based VOD Server, as
few assets as possible are removed by reviewing the sizes of the least popular assets.

server11sp32-27feb09-2009-0227-1757
Page 60
5) If any step in the process of VOD asset demotion from RAM-based VOD Server to
DAS-based VOD Server fails, there is no rollover, and the whole job is marked as
failure.
6) The VOD Servers that have the VOD asset (including the server chosen in Step 3)
are evaluated to see whether, if any one of the VOD Servers went down, the
remaining VOD Servers would exceed a configured threshold TB, given the existing
load of connections. (TB is defined as the threshold of network utilization that when
reached the VOD server will begin refusing connections.) If the configured threshold
would be exceeded, the VOD asset is replicated to an additional VOD Server.
7) A race condition is avoided by having a single job queue for VOD asset replication
and deletion on all VOD Servers. This job queue is stored in the Branch database.
For example:
• Asset A1 – 20%, Asset A2 – 35%
• Request for Asset A3 received – uses 5%
• Server’s total egress rate hits 60%
• Trigger replication of Asset A2
Adaptive File Copy and Distributed Ingest

When a VOD asset is delivered to a VOD Server, either for initial deployment or because of
adaptive allocation, the vodControllerWS Web service tells the server the rate at which to
copy the file. For initial deployment, the bit rate is set at 200 MBps. For replication, the
vodControllerWS Web service selects the least-used NIC on the sending system and sets the
bit rate to ensure it does not exceed the configured maximum percentage (the default is 50
percent) of the remaining bandwidth below TA. For example, if TA is 80 percent, the interface
is capable of 1 Gbps, the adaptive copy percentage is 50, and the current usage of the least
used interface is 500 MBps, the rate control would be set to 150 MBps: (1000*.8 – 500)*.5.
Additionally, TC is defined as the maximum ingress capacity on a NIC interface. During
adaptive file copy, the lower of the two values (maximum ingress capacity versus the percent
of an NICs available bandwidth) is chosen as the ingress rate. This limits the impact of disk
writes (W) on disk reads (R) delivery of VOD asset to client, because 1W=3R. Defining TC is
simpler than tracking the disk read/write status in the Windows Performance Monitor.

server11sp32-27feb09-2009-0227-1757
Page 61
VOD Assets and Content Aggregation
VOD asset content providers must deliver VOD assets in a specific format for service
providers to import them into the Microsoft Mediaroom system. Each VOD asset consists of a
set of files that include audio/video (A/V) data and related metadata. Content providers can
use any Windows Media® 9, VC-1, or H.264 encoding tool that supports the Microsoft
Mediaroom VOD compression parameters, such as Windows Media Encoder 9 Series.
The VOD asset files include:
• The audio/video (A/V) content itself in Advanced Streaming Format (ASF) or
MPEG Single Program Transport Stream format (TS).
• A trailer, in ASF or TS format.
• Box or poster art in .jpg format.
• Metadata describing the program (such as the feature title and actors), trailer,
business data (such as price), and rights metadata (such as rental window), in
CableLabs ADI 1.1 or Microsoft Metadata XML format.
VOD content providers can generate VOD metadata files with any XML or text editor.
If a VOD asset does not contain the proper set of files, the Microsoft Mediaroom system
aborts the import process. VOD content providers should deliver VOD assets through secure
mechanisms.
Note Microsoft Mediaroom does not provide inventory or version control systems for
managing VOD assets. Each service provider is responsible for performing those tasks using
other tools.
VOD Trick Streams

Microsoft Mediaroom supports the following methods for the VOD Creator Station to use for
generating trick streams for a VOD asset:
• High performance. This mechanism generates trick streams without decompressing
the original stream. Instead it uses the I-frames from the encoded main stream and
selects only the number necessary to produce the desired speed. It plays the I-frames
at a reduced number of frames per second to keep the trick stream bit rate equal to
the bit rate of the main stream. For this mechanism to work well, the GOP size of
assets that use it should be no more than two seconds.
• High quality. This mechanism sets the quality of the encoded trick streams. The
default setting is 30 percent. Trick streams are created and encoded in a single pass.
Increasing the compression quality setting increases the VOD asset import time.

server11sp32-27feb09-2009-0227-1757
Page 62
You can configure trick streams globally and on a per-asset basis. The per-asset settings
override the global settings. Trick streams can be configured only for a VOD asset’s main
feature files. You cannot create trick streams for an asset’s trailer file.
Note Trick stream speed cannot be set through a VOD asset’s metadata. Trick speed is
defined globally. If trick streams are turned off through the global setting, the system can still
have a global trick speed setting that is used only when a VOD asset’s metadata specifically
sets values for its trick streams.
VOD Acquisition Subsystem

The VOD acquisition subsystem manages the VOD manual import and automated import
processes. A VOD Creator Station takes a VOD asset (content and metadata) from a local
vodassets folder and generates a set of media and metadata files. The VOD Creator Station
generates the processed assets in a specific location, known as the Staging folder. To expand
storage for VOD assets without creating another VOD backend, the operator can configure
additional Staging folders, either on the VOD Creator Station or another remote machine that
does not have Microsoft Mediaroom installed. The Microsoft Mediaroom service provider at
the branch can choose the assets to deploy with the VOD Asset Management tool. (For more
information about configuring additional Staging folders, see Configuring an Additional
Staging Folder on a Local Disk (p. 313) and Configuring an Additional Staging Folder on a
Remote Machine (p. 315) in Operations Guide.)
When a VOD asset arrives, it is automatically detected by the VOD pre-import process. The
VOD pre-import process performs the following tasks:
• If the metadata included with the VOD asset is in ADI format, converts it to
Microsoft Mediaroom metadata format.
• If rules are on and set, applies rules as appropriate.
• Does basic repair such as case conversion and ensuring that fields are not too long.
Once the VOD asset is successfully pre-processed, it becomes available for import. The VOD
Creator Station performs the following tasks:
• Validates assets. Assets can be rejected as part of the import process.
• Generates trick stream files for use when the client fast-forwards or rewinds.
• Generates RTP streams for the main feature and trick streams.
• Encrypts the assets and their associated DRM key files. The key file associated with
each RTP stream is encrypted using the backend certificate public key. The operator
installs the backend certificate on the VOD Creator Station. During the deployment
process, the private key associated with the backend certificate is used for decrypting

server11sp32-27feb09-2009-0227-1757
Page 63
the RTP stream’s key file. For information about the deployment process, see VOD
Delivery Subsystem (p. 064).
• Stores encrypted RTP streams and encrypted DRM keys in the Staging folder for
deployment to various branches. The other metadata information (program, business,
rights metadata) is stored as an XML file associated with the VOD asset.
• Sets the Macrovision state for VOD assets. During VOD asset import, DRM tags
each frame of the RTP stream with the appropriate Macrovision analog content
protection control bits, depending on the level of Macrovision protection for the
VOD asset assigned either for the specific VOD asset or by a global setting.
• Sets the CGMS-A state for VOD assets. During VOD asset import, DRM tags each
frame of the RTP stream with the appropriate CGMS-A content protection control
bits, depending on the level of CGMS-A protection for the VOD asset assigned either
for the specific VOD asset or by a global setting.
• Generates index files (saved as .idx files). Each VOD asset also includes a set of
index files. An index file is a mapping of media times to byte offsets within the file.
For example, if you had previously watched the first 10 minutes of a movie and you
want to fast-forward to the place you left off, the client uses the trick stream index
file to determine where to start streaming the associated trick stream media file. Each
VOD asset has one index file for each generated VOD asset, full-screen, trailer, and
all trick streams.
VOD Delivery Subsystem

The VOD delivery subsystem manages the deployment and delivery processes. It optimizes
the equipment required to deliver a diverse offering of VOD assets through VOD clusters. A
VOD cluster is a set of server machines that is optimized to deliver VOD assets based on their
usage pattern. VOD assets that subscribers view most often are generally placed on VOD
Servers with less storage capacity but higher availability (RAM-based servers), while assets
with lower usage patterns are served from VOD Servers with more storage but less
availability (DAS-based servers). This enables providers to optimize the overall cost of the
equipment required to manage and deliver VOD assets.
A branch can have any number of VOD clusters. Operators use the VOD Asset Management
tool to register each VOD cluster in the system and associate the VOD cluster with a set of
VOD backends. Branch operators manually manage the allocation of VOD assets between
clusters by taking advantage of the VOD asset usage information. Asset usage information
includes data such as how many times a VOD asset was accessed in a particular time period.
When deploying a VOD asset, the branch operator defines the VOD clusters that distribute
the VOD asset and the subscriber groups that receive the VOD asset.

server11sp32-27feb09-2009-0227-1757
Page 64
By default, Microsoft Mediaroom is configured with an Everyone subscriber group. VOD
assets deployed to the Everyone group are available to all subscribers. To deploy a VOD asset
to a specific set of subscribers, the operator must first define the appropriate subscriber
groups. For example, to test a new VOD asset before making it available for widespread
purchase, the operator can create a Test subscriber group and specify it when deploying the
VOD asset.
Deploying a VOD asset causes the VOD asset to be copied from the Staging folder in the
VOD backend to one or more of the VOD Servers in the specified cluster. Typically, it is
copied to at least two VOD Servers for redundancy. The number of servers to which you
initially copy is configurable. The first copy is made from the Staging folder to the VOD
Server that has the most storage space available. Subsequent copies are made from VOD
Server to VOD Server to conserve bandwidth from the backend to the branch. The VOD
delivery subsystem updates the SMS, service information (SI) subsystem, and BranchDB
databases to reflect the new asset distribution.
The VOD delivery subsystem uses an SSL connection to copy the block, index, and metadata
files from the Staging folder in the VOD backend to the VOD Server in the branch.
Decrypting DRM Keys

The VOD deployment process also includes the decryption of the DRM keys for each RTP
stream. Decryption proceeds as follows:
1) The VOD delivery subsystem reads the branch certificates from the certificate store.
The branch certificate is installed during Microsoft Mediaroom installation.
2) The VOD delivery subsystem sends the branch public key from the branch to the
VOD acquisition subsystem over the SSL channel.
3) The VOD acquisition subsystem verifies that the branch’s public key is valid.
4) The VOD acquisition subsystem reads the key file for each RTP stream.
5) The VOD acquisition subsystem decrypts the encrypted keys for the requested VOD
asset using the VOD acquisition subsystem’s private key and re-encrypts it with the
branch public key.
6) The VOD acquisition subsystem returns the encrypted keys to the branch.
7) When the branch receives the encrypted keys, it decrypts them (using the branch
private key) and stores them for use by devices.

server11sp32-27feb09-2009-0227-1757
Page 65
8) When a device establishes a VOD session, the VOD delivery subsystem encrypts the
content keys with the client A/V session key and delivers the encrypted keys to the
client. Clients also receive keys to VOD assets for which they have rights at boot
time.
For information about the DRM encryption process, see VOD Acquisition Subsystem (p.
063).
During the VOD asset deployment process, the VOD asset metadata is stored in the Asset
Store Subsystem (p. 088) subsystem and rights data is stored in the Subscriber
Management Subsystem (p. 105) (SMS) by the VOD Asset Management tool.
VOD Session Management and Load Balancing

Each VOD Server in the cluster reports its status to the vodControllerWS Web service on a
regular basis (the default is every 10 seconds). This status includes the current bandwidth
used on the VOD Server egress interfaces (or one interface, if NIC teaming is in use) and
identifies which assets the VOD Server has available. This information is stored by the
vodControllerWS Web service in the BranchDB database, which is then replicated out to the
ServiceGroupDB databases.
A new VOD session is created for the following actions:
• When the subscriber goes from a stopped state to playing a trick stream (fast-forward
or rewind) or from a stopped state to play the VOD asset.
• When the subscriber tunes to any other channel, including other VOD channels.
A new VOD session is not created when the subscriber goes from the play or pause state to
fast-forward or rewind.
When the client receives a subscriber request for a VOD asset, it contacts the
vodMapServerWS Web service for a URL. The vodMapServerWS Web service determines
the first and second least-loaded VOD Server interfaces from which the asset can be served
and returns those URLs to the client. The client then uses those URLs to play the VOD asset.
If the first URL fails, the client tries the second one.
Life Cycle of a VOD Session

VOD session information is kept on the VOD Server. When the VOD Server reaches its
configured threshold, it will refuse any new connections.
A new VOD session is created when:
• A VOD asset is purchased and played.

server11sp32-27feb09-2009-0227-1757
Page 66
• The subscriber tunes back in to the VOD channel after tuning away.
• The subscriber presses the Play button to resume viewing a VOD asset.
A VOD session ends when:
• A subscriber tunes away from the VOD channel.
• A subscriber presses the Stop button.
• The VOD asset finishes playing.
If a subscriber uses the VOD asset’s trick streams (for example, to fast-forward through
portions of the VOD asset), the current session remains open. If a subscriber pauses on a
VOD asset for a long period of time, the VOD session is not closed.
Packet Loss and Retry

The Media Store virtual directories are the Mediaxx folders on a VOD Server that delivers
VOD assets to Microsoft Mediaroom clients (“xx” is an incremental, unique integer assigned
to the folder for each VOD asset). Media Store virtual directories are deployed on Internet
Information Services (IIS) servers. IIS servers handle packet loss and retry by using TCP for
the stream transport. TCP delivers packets error-free and in order.
Service Failover
The vodControllerWS Web service detects VOD Server failure when the VOD Server stops
reporting its status. It detects failure within two intervals of server status reporting (by default,
the interval between status reports is 10 seconds). The vodControllerWS Web service then
updates the database status with this information so that the URL to that server is no longer
returned to clients.
Within a few seconds of the VOD Server’s failure, clients that are using the server for
playback fail over to the second URL that was sent to them originally. If that secondary URL
also fails, the client returns to the vodMapServerWS Web service to request another set of
URLs.
The TV Services Management tool on the Branch Management machine provides a way to
manage VOD Servers, for example, to take a server offline for maintenance or decommission
it and remove entries about it from the BranchDB database. For more information, see
Managing VOD Servers (p. 420) in Operations Guide.

server11sp32-27feb09-2009-0227-1757
Page 67
Large Asset Playback
The maximum size of a single file served by IIS is 2 GB. If a VOD main stream is larger than
2 GB due to the length of the feature, the stream is broken into multiple files. (Optionally, an
operator can configure the import to break files into smaller segments.) The client opens an
HTTP/TCP session for each file that is required (main streams, trick-play files) and continues
to pull down that file until the client either runs to the end of the file or switches mode (trick-
stream play or back to main stream). At that point, a new HTTP/TCP session is initiated. This
process is transparent to the subscriber.
See Also
OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set)
BSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set)
VOD Asset Security

The Microsoft Mediaroom system ensures the security of VOD assets within the system. It
utilizes multiple security measures to ensure that only those subscribers who have access
rights to a VOD asset can actually access the VOD asset.
The Microsoft Mediaroom system uses the following mechanisms to secure VOD assets:
• DRM protection. The VOD acquisition subsystem encrypts VOD assets during
import with strong encryption (AES). VOD assets remain encrypted all the way
through the Microsoft Mediaroom system after import. Microsoft Mediaroom clients
decrypt VOD assets just prior to decoding the content.
The system encrypts main feature and trailer streams using separate keys. Trick and
trailer streams share keys with their respective main stream.
• Macrovision protection. Macrovision prevents unauthorized copying of VOD assets
to DVD recorders and VCRs. Content protection is transparent when subscribers
view the VOD asset, but prevents or substantially degrades copies made on recording
devices by distorting the VOD assets over the analog interface. The Macrovision and
CGMS-A states for VOD assets are set at import time on a per-asset basis or with a
global setting. During VOD asset import, DRM tags each frame of the RTP stream
with the appropriate Macrovision analog content protection control bits. The control
bits instruct the Microsoft Mediaroom client to add analog content protection to the
outgoing analog video.

server11sp32-27feb09-2009-0227-1757
Page 68
• CGMS-A protection. Macrovision prevents unauthorized copying of VOD assets to
DVD recorders and VCRs. Content protection is transparent when subscribers view
the VOD asset, but prevents copies being made on recording devices that honor
CGMS-A. The CGMS-A state for VOD assets is set at import time on a per-asset
basis or with a global setting. During VOD asset import, DRM tags each frame of the
RTP stream with the appropriate CGMS-A protection control bits. The control bits
instruct the Microsoft Mediaroom client to add analog content protection to the
outgoing analog video.
• HDCP protection. High-Bandwidth Digital Content Protection (HDCP) is a form of
Digital Rights Management developed by Intel Corporation to control digital A/V
content as it travels across Digital Visual Interface (DVI) or High-Definition
Multimedia Interface (HDMI) connections. Some countries require service providers
to broadcast VOD asset content without encryption in the transmission or signal path.
By default, Microsoft Mediaroom delivers VOD assets with HDCP enabled, but
provides a way to disable HDCP through an entry in the VOD asset's metadata file or
through creation of a VOD import rule to add or change the disableHDCP value to
the file during the import process. On the client side the information is extracted
from the service information (SI) subsystem data and then flagged to the HDCP
driver. The driver sets the correct HDCP mode for the VOD asset, based on that flag.
For information about the disableHDCP element in the VOD asset metadata file, see
disableHDCP Child Element (p. 031) in VOD Metadata Guide and Reference. For
information about creating VOD import rules, see Setting the VOD Asset Import
Rules (p. 349) in Operations Guide.
• Client authentication. VOD asset requests follow the same client authentication
process that live TV content does (as do all requests for client access to the Microsoft
Mediaroom system). The system authenticates all client requests made to the VOD
subsystem.
• Secure connection between VOD backend and branch. The system can be
configured to use SSL when copying VOD assets between the VOD backend and a
branch.
• Subscriber access rights. The VOD subsystem provides the same subscriber access
rights capabilities as live TV.
Integrating a Branch with an EQoS Interface

The branch can optionally be integrated with an external quality of service interface (EQI) to
oversee the quality of service (QoS) during a subscriber’s VOD purchase experience, as well
as interaction with the VOD asset itself (for example, playing or using trick speeds). For

server11sp32-27feb09-2009-0227-1757
Page 69
information on implementing and deploying an EQI Web service, see Configuring the
External Quality of Service Interface Web Service (p. 183) in Installation and
Configuration Guide. For more information about integrating the branch with an EQI, see
“External Quality of Service Interface Web Service” in OSS Web Service Reference
(Microsoft Mediaroom OSS/BSS Integration documentation set).
Integrating a Branch with an EPOC System

The EPOC Web service is a Web service that service providers can optionally implement and
deploy to define the business logic for VOD purchases. Microsoft Mediaroom does not
provide a sample implementation of the EPOC Web service. For information on
implementing and deploying the EPOC Web service, see Configuring the External Purchase
Offer Cycle Web Service (p. 179) in Installation and Configuration Guide. For details on
the API that this Web service must implement to support EPOC, see “EPOC Web Service” in
OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set).

server11sp32-27feb09-2009-0227-1757
Page 70
Live Anytime Subsystem
The Live Anytime subsystem enables operators to record selected live programs, convert and
save them as VOD assets, generate offers, and make the programs available to subscribers
through the Video on Demand screen.
Note Originally Live Anytime was released as “Live to VOD.” The feature name has
changed as of the Microsoft® Mediaroom Server 1.1 SP3.2 CP2 (SP3.2 CP2) release. While
the latest release of the Microsoft Mediaroom documentation refers to the current feature
name, many system components, such as services and configuration files, use the prerelease
name.
The following diagram illustrates the overall architecture and components of the Live
Anytime subsystem.

server11sp32-27feb09-2009-0227-1757
Page 71
Live2VOD Recording Server
The Live2VOD Recording Server resides in the branch and receives recording jobs from the
Live2VOD Controller Machine (p. 073). The Live2VOD Recording Server automatically
registers itself with the Live2VOD Controller and reports back to that machine every 10
seconds.
Capturing and Recording Assets

The Live2VOD Recording Servers join the appropriate live TV multicast streams according
to configured schedules. The Live2VOD Recording Servers receive and convert the live TV
streams to VOD format, generate trick streams and VOD asset metadata, and temporarily
store the converted data on a local disk.
If padding time was configured for the recording, the configured amount of time is added to
the beginning and end of the scheduled recording. Fast-forward trick streams are generated
simultaneously as the multicast stream is converted to VOD format. Rewind trick streams are
generated after the program has finished recording. Metadata for the Live Anytime asset is
generated from the Electronic Program Guide (EPG) data that was available when the
recording was completed and stored on disk.
After the program and the trick streams are recorded, a VOD metadata file is generated and
index files (.idx) are created for the asset's full-screen, trailer, and trick stream files. At this
point, the program appears as a typical VOD asset in the configured Staging folder that is
used for all VOD assets. For more information about the files generated for a VOD asset
during import, see VOD Acquisition Subsystem (p. 063).
After the recording, trick stream, and metadata generation are completed and the resulting
files are written to the Staging folder, the Live2VOD Recording Server notifies the
Live2VOD Controller that the Live Anytime asset is ready to be deployed through the VOD
delivery subsystem. If the option to create offers automatically when VOD assets are
deployed is selected on the Settings (for Branch Management) (p. 100) page in the TV
Services Management tool, an offer based on the Live Anytime asset's generated metadata is
created.
Note The Live Anytime subsystem also supports Live2VOD Recording Server redundancy
to ensure that a server is available to record a scheduled live program.

server11sp32-27feb09-2009-0227-1757
Page 72
Live2VOD Controller Machine
The Live2VOD Controller machine resides in the same tier as the Server-Facing Branch
machines. The Live2VOD Controller controls the activities of the Live2VOD Recording
Server (p. 072), which automatically registers itself with the Live2VOD Controller and
reports back every 10 seconds.
The Live2VOD Controller also does the following:
• Creates and manages recording schedules.
• Deploys recorded assets to the VOD delivery subsystem.
• Creates offers for deployed Live Anytime assets.
Live Anytime Recording Schedules

The Live2VOD Controller creates and manages recording schedules (such as EPG changes
and recording event changes) for each Live2VOD Recording Server based on:
• Recording events created by the service provider.
• EPG information.
• Live2VOD Recording Server load (ingress bit rate).
• Minimal deployment setting.
• Padding to be added to the beginning and end of a recording.
Live Anytime Asset Deployment

When the Live2VOD Recording Server completes a recording job and notifies the Live2VOD
Controller of that, the Live2VOD Controller then submits a deployment job for the recorded
asset to the VOD delivery subsystem; the latter acts as a VOD backend for the job.
Live Anytime Roles

Live Anytime includes the following roles:
• L2VDB (p. 074)
l2vRecServer (p. 074)
• l2vControllerWS (p. 074)
• ossLiveToVOD (p. 074)

server11sp32-27feb09-2009-0227-1757
Page 73
• smtLive2VOD (p. 074)
• timeshiftMapServerWS (p. 075)
L2VDB
The L2VDB role is responsible for storing the Live Anytime configuration. Because the load
on this database is small, it typically coexists on the same machine with the BranchDB
database.
l2vRecServer
The l2vRecServer role, which is typically installed on the Live2VOD Recording Server, is
responsible for capturing and recording assets. Because of the intense nature of processing
required for capture and recording operations, the Live2VOD Recording Server is typically a
physically separate, high-performance server.
l2vControllerWS
The l2vControllerWS role is responsible for creating and managing recording schedules and
deploying finished assets to the VOD delivery subsystem. The l2vControllerWS role typically
resides on the Live2VOD Controller machine.
ossLiveToVOD
The ossLiveToVOD role enables service providers to write custom applications to monitor
and configure the Live Anytime subsystem.
smtLive2VOD
The smtLive2VOD role provides the interface between the TV Services Management tool and
the Live Anytime subsystem.

server11sp32-27feb09-2009-0227-1757
Page 74
timeshiftMapServerWS
The timeshiftMapServerWS role is a client-facing role that updates the tuning information for
clients who are enabled to receive Live Anytime services. The role was added to the
sessionKeyAuthority_KeyGenerator.xml file with the release of Microsoft Mediaroom SP3.2
CP2. The TimeShiftMap.xml file sets the interval at which the timeshiftMapServerWS Web
service polls for updates to the tuning information for Live Anytime services. For more
information about the TimeShiftMap.xml file, see TimeShiftMap.xml (p. 258) in
Operations Guide.

server11sp32-27feb09-2009-0227-1757
Page 75
RDP Application Subsystem
The Remote Desktop Protocol (RDP) application subsystem enables Microsoft® Mediaroom
clients to display customized applications that run on remote application servers. The
subsystem uses RDP, the same protocol that is used by Windows® Server 2003 Terminal
Services. The Microsoft Mediaroom client initiates, maintains, and terminates RDP
connections to each application.
Subscribers can start RDP applications (network applications) from menus and from the
program guide. The Terminal Server sends application graphics to the client, which then
renders the application UI. When the subscriber presses remote control keys, the client sends
corresponding events to the Terminal Server.
Microsoft Mediaroom enables rapid development and deployment of RDP applications. This
development environment makes it easier to develop and deploy customized behaviors that
suit set-top box requirements. Customer service and self-provisioning applications are good
candidates for implementation as RDP applications.
RDP Application Subsystem Software

Components and Data Flow
The following diagram shows the functional software components of the RDP application
subsystem.

server11sp32-27feb09-2009-0227-1757
Page 76
The following table gives an overview of RDP application subsystem software functionality.
Subsequent sections provide more detailed descriptions of each component.
Windows Server Terminal Services (p. Reside at the service provider site and serve
079) requests for RDP sessions from Microsoft
Mediaroom clients.
TServer Windows Service (p. 079) Provides status updates to the Terminal
Server controller private Web service and
then executes actions returned by the private
Web service. These actions include creating
users, changing passwords, starting new RDP
sessions, and shutting down existing RDP
sessions.
Terminal Server Session Starter (p. 079) Stand-alone application

(TerminalServerSessionStarter.exe) that
starts a Terminal Server session and then
exits.
RDP Application Launcher (p. 080) Launches and manages the lifetime of RDP
applications. The launcher runs on a
Terminal Server and uses a virtual channel

server11sp32-27feb09-2009-0227-1757
Page 77
message from the Microsoft Mediaroom

client to determine which application to run.
The client then renders the application’s UI.
TServerProxy COM+ Service (p. 076) Enables the TServer Windows service and
the RDP application launcher to
communicate with internal Microsoft
Mediaroom Web services.
Terminal Server Controller Private Web Receives session state information from the
Service (p. 081) TServer Windows service on each Terminal
Server and stores it in the tservercontroller
database.
Terminal Server Controller Public Web Runs on a client-facing machine and

Service (p. 081) performs client authentication on all requests.
Terminal Server Controller Database (p. Stores the status of available RDP sessions
082) on Terminal Servers.
Windows Applications (p. 082) Installed on the Terminal Server and run by
the RDP application launcher. Ideally,
Windows applications are designed for
display on TV screens and for operation
within the constraints of Microsoft
Mediaroom set-top boxes.
Web Applications Web applications can be hosted on the RDP

Application Server, on a separate Microsoft
Mediaroom server, or on an external server
running IIS. The RDP application launcher
hosts an Internet 6.0 browser control and
customizes the browser behavior for the
Microsoft Mediaroom environment (some
customization is available through the TV
Services Management tool). For example, it
blocks dialog boxes. The control simulates
the Windows XP Media Center eHome shell
to support Media Center applications.

server11sp32-27feb09-2009-0227-1757
Page 78
Windows Server Terminal Services
Windows Server Terminal Services reside at the service provider site and serve requests for
RDP sessions from Microsoft Mediaroom clients (set-top boxes). At startup, the Terminal
Server machine sets up a pool of RDP sessions that are left in a disconnected state until
clients connect to them.
The Microsoft Mediaroom client contains an RDP client that connects to one of the available
sessions in the pool of RDP sessions that the Terminal Server set up when it was started. The
Microsoft Mediaroom client logs in to the existing RDP session by specifying the Terminal
Server's connection string, user name, password, domain, port number, and session ID.
TServer Windows Service

The TServer Windows service provides status updates to the Terminal Server controller
private Web service, which then stores the new status in the tservercontroller database. The
Terminal Server controller private Web service returns a list of actions to the TServer
Windows service, which the service then executes. These actions include creating users,
changing passwords, starting new RDP sessions, and shutting down existing RDP sessions.
The TServer Windows service repeats this cycle of status updates and task execution at
regular intervals.
This Windows service runs on each Terminal Server machine hosting Windows Server
Terminal Services. If it fails to provide service within a specified timeout period, the
TServerController Web service ceases to assign new RDP sessions to the corresponding
Terminal Server.
The TServer Windows service obtains configuration parameters from an XML configuration
file (TServer.xml) that it reads when it starts. If you modify TServer.xml, the changes take
effect after you stop and restart TServerService.exe. The control panel for this Windows
service is called IPTV Edition TServer.
Calls from the TServer Windows service to the Terminal Server controller private Web
service are routed through the TServerProxy COM+ service.
Terminal Server Session Starter

The Terminal Server session starter is a stand-alone application
(TerminalServerSessionStarter.exe) that starts a Terminal Server session and then exits. The
session starter is launched by the TServer Windows service when it needs to start a new
session.

server11sp32-27feb09-2009-0227-1757
Page 79
RDP Application Launcher
The RDP application launcher (launcher) runs on a Terminal Server and launches and
manages the lifetime of RDP applications. The Microsoft Mediaroom client starts up the RDP
application launcher through its RDP session with Windows Server Terminal Services.
Windows Server Terminal Services then start an instance of the RDP application launcher for
each RDP session.
During deployment, the RDP application subsystem’s access control lists (ACLs) are set up
so that the Terminal Server can only launch the launcher the client starts through its RDP
session, and not launchers for other Terminal Server applications. The launcher determines
which application to run from a virtual channel message that the Microsoft Mediaroom client
sends. The Microsoft Mediaroom client then renders the application’s UI.
For Web-based applications, the launcher hosts an Internet Explorer 6.0 browser control and
customizes the browser behavior for the Microsoft Mediaroom environment (some
customization is available through the TV Services Management tool). For example, it blocks
dialog boxes. Web applications can be hosted on the RDP Application Server, on a separate
Microsoft Mediaroom server, or on an external server that is running IIS. The control
simulates the Windows XP Media Center eHome shell to support Media Center applications.
By supporting a subset of the Media Center object model, the launcher supports RDP
applications that incorporate VOD asset content. Instead of integrating VOD asset content on
the server side and delivering the entire UI over RDP, the RDP application subsystem
delivers all non-video content over RDP and relies on Microsoft Mediaroom clients to
integrate live video or VOD asset content that it receives over the corresponding transports.
Note Microsoft Mediaroom does not support the Media Center object model for Windows
applications.
The Internet Explorer 6.0 control intercepts playback control API calls so that live TV is not
delivered over RDP. Instead, the playback controls are delivered as client messages over RDP
virtual channels. The Microsoft Mediaroom client uses these messages to acquire the
appropriate media streams and integrates those streams with the UI content delivered over
RDP. The launcher also stores cookies for each user in the user store subsystem.
Note Because subscribers can choose language preferences, Web applications can be
implemented to support multiple languages. The application retrieves the user’s language
setting from the UserLanguages list in the HTTP request header
(HttpContext.Current.Request.UserLanguages[0] in ASP.NET). The language names follow
the RFC 1766 standard in the format languagecode2-country/regioncode2 (for example, en-
US). Similarly, you can implement applications to support multiple display resolutions.
For Windows applications, which run on the Terminal Server, the launcher launches the
application maximized (with window frame and menus removed). The launcher stops the

server11sp32-27feb09-2009-0227-1757
Page 80
application when the application session is done. The service provider must install the
Windows applications on the Terminal Server.
The RDP application launcher sends a notification over RDP virtual channels to alert the
Microsoft Mediaroom client that the application has finished loading. It also sends
notifications of various error conditions.
The RDP application launcher communicates with the Terminal Server controller private
Web service when clients connect and disconnect to authenticate clients and to manage the
number of the sessions in the session pool. Calls from the RDP application launcher to the
Terminal Server controller private Web service are routed through the TServerProxy COM+
service. All other calls from the RDP application launcher to internal Web services are also
routed through the TServerProxy COM+ service and Terminal Server controller private Web
service.
For details on developing RDP applications for Microsoft Mediaroom, see RDP Application
Developer’s Guide in the Microsoft Mediaroom ADK documentation set.
TServerProxy COM+ Service

The TServerProxy COM+ service enables the TServer Windows service and the RDP
application launcher to communicate with internal Web services. All calls from the TServer
Windows service and the RDP application launcher to internal Web services are routed
through the TServerProxy COM+ service and Terminal Server controller private Web
service. To make the system more secure, the TServerProxy COM+ service only exposes
access to the necessary internal Web services. The TServer Windows service and the RDP
application launcher do not have the credentials to call the internal Web services directly.
Terminal Server Controller Private Web Service

The Terminal Server controller private Web service receives session state information from
the TServer Windows service on each Terminal Server and stores it in the tservercontroller
database.
Terminal Server Controller Public Web Service

The TServerController Web service runs on a client-facing machine and performs client
authentication on all requests. It acquires RDP session information from the tservercontroller
database that tells Microsoft Mediaroom clients which Terminal Server to contact and to

server11sp32-27feb09-2009-0227-1757
Page 81
which session they should connect. For details on how clients acquire RDP sessions, see
Connecting to RDP Sessions (p. 082).
Terminal Server Controller Database

The tservercontroller database stores the status of available RDP sessions on Terminal
Servers. The TServerController Web service accesses this database to provide RDP session
details to Microsoft Mediaroom clients that need to run RDP applications. The contents of
this database are managed by the Terminal Server controller private Web service.
Windows Applications
The RDP application launcher can run Windows applications installed on the Terminal
Server. Each Windows application runs in a separate process, but in the same RDP session as
the RDP application launcher that started it.
For the best user experience, Windows applications should be designed for display on TV
screens and for operation within the constraints of Microsoft Mediaroom set-top boxes. For
details on design and implementation guidelines, see Application Developer’s Guide in the
Microsoft Mediaroom OSS/BSS Integration documentation set.
Connecting to RDP Sessions

When a subscriber chooses an RDP application from the program guide or the main menu, the
client contacts the client-facing TServerController Web service to request an RDP session.
The client ID is included in the client’s request for an RDP session as part of the client
authentication ticket.
The TServerController Web service queries the tservercontroller database for available
sessions. If a session is available, it sends the TServer Windows service the following
information:
• Terminal Server connection string (machine name or public IP address if specified)
• Port number
• User name
• Password
• Domain
• Session ID of the session to use

server11sp32-27feb09-2009-0227-1757
Page 82
• Security token for client authentication
If no sessions are available, the TServerController Web service returns an error, and the client
repeats its session request until a timeout limit is reached.
If the TServerController Web service returns a session, the Microsoft Mediaroom client
connects to the given Terminal Server session.
The RDP application subsystem only creates one RDP session for each subscriber.
Subscribers can start multiple applications one at a time, but each is delivered over the same
RDP session.
If Microsoft Mediaroom cannot connect to the Terminal Server session, or does not get
confirmation from the Terminal Server that the application launched successfully within a
timeout limit, the Microsoft Mediaroom client presents the “Application not available” error
message.
System operators can manage RDP application items in the Microsoft Mediaroom client
menu with the UserStoreDo command. For details on customizing the client menu, see Client
Customization and Localization Guide (Microsoft Mediaroom Client documentation set).
Note Microsoft Mediaroom clients present available RDP applications to subscribers if they
receive RDP application service information from the media discovery subsystem. Microsoft
Mediaroom operators create media descriptions for the media discovery subsystem with the
TV Services Management tool.
Tracking Terminal Server Sessions

The TServer Windows service that runs on each Terminal Server periodically calls the
Terminal Server controller private Web service to provide updated status of all sessions
running on that machine. In turn, the Terminal Server controller private Web service saves
current session state information in the tservercontroller database.
A Terminal Server is placed into service when the Terminal Server controller private Web
service receives a first status update (initialization message) from the Terminal Server. If the
Terminal Server controller private Web service does not receive a status update from a
Terminal Server within a timeout limit, it is assumed that the Terminal Server is out of
service and the Terminal Server controller private Web service no longer enables new
sessions for that Terminal Server. If that Terminal Server resumes sending status updates, it is
placed back into service.

server11sp32-27feb09-2009-0227-1757
Page 83
Securing RDP Sessions
Calls to the client-facing TServerController Web service go through the Web service router,
which authenticates all clients. Only valid Microsoft Mediaroom clients can successfully
request RDP sessions from the TServerController Web service. On a successful call, the
device ID is stored in the tservercontroller database and associated with the appropriate RDP
session.
The Terminal Server must be configured to run only the RDP application launcher. This
precaution prevents clients from running unauthorized applications residing on Terminal
Servers.
When a Microsoft Mediaroom client connects to a Terminal Server session, the RDP
application launcher receives the device ID from the Microsoft Mediaroom client. The
launcher calls the Terminal Server controller private Web service to get the device ID that it
stored for the session to ensure that they match. If the device ID does not match, the RDP
application launcher immediately disconnects the session to ensure that only authenticated
Microsoft Mediaroom clients can use the Terminal Server.
The Terminal Server controller private Web service generates new passwords for each user
on each Terminal Server and stores them in the tservercontroller database. Passwords are
reset each time that a new user is created or a new session is started. Passwords are also reset
each time a client connects to a session, so that no other clients can connect to the session
with the same password.
Each time the TServer Windows service on the Terminal Server sends the Terminal Server
controller private Web service a status update, the Web service returns a list of sessions to
shut down and a list of user name/password pairs to reset. The TServer Windows service
shuts down the sessions listed and creates the users (if they do not already exist), changes the
passwords, and starts new RDP sessions (if an RDP session does not already exist for the
user) for the list of user name/password pairs.
Managing RDP Sessions on Each Terminal

Server
The TServer Windows service reads the <Sessions> tag in the TServer.xml configuration file
to obtain start, max, and increment parameters that control the number of sessions used on
each Terminal Server. It then contacts the Terminal Server controller private Web service
with an initialization message that lists all current sessions on the Terminal Server.
The Terminal Server controller private Web service returns a list of user name/password pairs
for sessions that should be started to bring the number of sessions up to the start value. The

server11sp32-27feb09-2009-0227-1757
Page 84
TServer Windows service then changes the password for each user and starts a session for
that user if a session does not already exist.
When a Microsoft Mediaroom client connects to a Terminal Server, new sessions may be
started if necessary. The TServer Windows service ensures that the number of available
sessions is never less than start or the number of sessions in use plus increment, and never
more than the maximum number of sessions (specified by max).
When a client disconnects from a Terminal Server, the session on the Terminal Server is
terminated unless it is still needed. If the number of sessions is more than start and more than
the number of sessions in use plus increment, the session is terminated because there are not
enough sessions available.
To take a Terminal Server out of service (for example, for maintenance), you can stop the
TServer Windows service. Existing sessions in use are not affected, and no more clients are
connected to sessions on that Terminal Server. To minimize disruption of the service, you can
wait for clients to disconnect on their own before doing anything that would terminate the
sessions (such as rebooting the Terminal Server).
Scaling, Load Balancing, and Failover

Access to multiple Terminal Server machines is load balanced by the client-facing
TServerController Web service. It uses session state information from all of the Terminal
Servers to load balance and decide which Terminal Server the requesting client should use.
When a Terminal Server machine goes down or is taken out of service, the TServerController
Web service no longer enables new sessions on that Terminal Server machine, which causes
all subsequent connection requests to fail over to the other Terminal Server machines.
Because the TServerController Web service performs load balancing, Terminal Servers
should not be load balanced by other mechanisms, such as network load balancing (NLB) in
Windows Server.
To improve availability of the TServerController Web service and Terminal Server controller
private Web service, the machines running these Web services can be load-balanced with
NLB or other mechanisms.

server11sp32-27feb09-2009-0227-1757
Page 85
Web Service Router
The Web service router (WSR) brokers all Web service communications (SOAP over HTTP)
between Microsoft® Mediaroom devices and client-facing Microsoft Mediaroom Web
services. The WSR proxies Web service requests from Microsoft Mediaroom clients to
Microsoft Mediaroom Web services in other security zones, where the calls are processed.
When the call completes, the WSR returns the result to the client. For a list of client-facing
Web services, see Server Layout Roles for Each Machine (p. 302) in Installation and
The sole purpose of the WSR is to provide a buffer between Microsoft Mediaroom clients and
the client-facing Web services. With the WSR in place, HTTP ports need to be open only
between the application tier, where the application servers reside, and the interface tier on the
perimeter network, which is also sometimes referred to as the “demilitarized zone” (DMZ).
The WSR maintains a routing table that keeps track of the server machines running each
Microsoft Mediaroom Web service. When a Microsoft Mediaroom client tries to contact a
Web service, the WSR looks in its routing table for a server machine that hosts the requested
Web service. If no entry is found, the WSR returns a “404 Not Found” error. If the Web
service is found in the routing table, the WSR passes the request to that Web service.
Note The WSR routing table is loaded one time when the first request arrives. Any changes
to the configuration that affect the routing table require a restart of the IIS application pool for
the changes to take effect. IIS supports a rolling restart, which drains connections from an
existing worker process and sends a new request to a new worker process, thus ensuring no
down time.
The WSR builds its routing table from the routing information in the roles.xml file,
specifically from the <roleURI> XML element.
The following diagram shows how the WSR fits into a typical deployment.

server11sp32-27feb09-2009-0227-1757
Page 86
The WSR provides the following important benefits to securing Microsoft Mediaroom
deployments:
• Reduced attack surface. By moving all Web service application logic out of the
Web tier, fewer public interfaces are exposed to Microsoft Mediaroom clients.
• Application code is located in a secure zone. Application servers that access
databases can reside in different zones than client-facing servers. The perimeter
network does not require open ports to enable SQL communications.

server11sp32-27feb09-2009-0227-1757
Page 87
Asset Store Subsystem
The Asset Store subsystem is a logical construct that stores metadata for RDP applications
(network applications) and VOD assets that subscribers can browse, play, and, if necessary,
purchase.
The following diagram shows the Asset Store subsystem software components.
The following table describes the Asset Store subsystem software components.
VOD branch Provides a Web service through which the TV Services

management Web Management tool initiates import operations and coordinates
service VOD asset deployment.
(ossVodBranchWS)
vodBranchWS Web Enables the VOD, RDP Application, and Search subsystems to
service retrieve VOD asset metadata over HTTP.
vodCatalogPrivateWS Builds the VOD catalog of assets that display in the Search
Web service screen for subscribers. The catalog of assets is the library of
content that the subscriber has requested. The client displays
these assets together in a listing that is viewable by the

server11sp32-27feb09-2009-0227-1757
Page 88
subscriber.
BranchDB database Database that stores the states of all assets and VOD Server
machines. Maintains information about deployed VOD assets.
See Also
Video on Demand Subsystem (p. 044)
RDP Application Subsystem (p. 076)
Search Subsystem (p. 132)
Subscriber Management Subsystem (p. 105)

server11sp32-27feb09-2009-0227-1757
Page 89
Listings Subsystem
The listings subsystem enables operators to manage listings data (also known as Electronic
Program Guide, or EPG, data) for traditional live TV services. The listings data describes
services, programs, and schedules for these programs. It does not contain information specific
to any subscriber, device type, or provisioning rights. This subsystem is sometimes referred to
as the EPG subsystem.
Listings Distribution
Listings data originates from a listings provider, is imported into the Microsoft® Mediaroom
branch, and is then distributed to Microsoft Mediaroom clients.
The following diagram illustrates how the Microsoft Mediaroom system manages this process
end-to-end.

server11sp32-27feb09-2009-0227-1757
Page 90
The following steps describe how the listings data from a listings provider is imported into
the Microsoft Mediaroom listings subsystem.
1) A listings provider (of the service provider’s choosing) creates a Global Listings
Format (GLF)-compliant listings data file.
2) The listings provider copies the listings data file to a secure location to which the
service provider has access.
3) Branch operators define a method for securely copying the listings file. They copy
the listings data file onto the Server-Facing Branch machine that can be accessed by
the ListingsLibrarianWS Web service. Each branch must have its own copy of the
listings data.
Each branch can have the same or different listings data files. For example, two
branches might contain an English-based listings data file while another branch has a
French-based listings data file.
4) The listings subsystem imports the listings data file into its own storage space.
Import performs a complete update of the listings data file; the system does not
currently support partial updates. Import is always done by the console application
Listings Updater.
There are two ways to import a listings data file:
• Scheduled invocation method. Set up the IPTV Edition Scheduler Windows®
service to invoke Listings Updater to import the listings data file at a specific
time. The file is imported at the same time each day regardless of whether its
content changed. This is the recommended method for importing a listings file.
• Manual import. Invoke the Listings Updater application manually by running it
on the command line. This method is not recommended outside of a lab trial, but
can be used for an extraordinary maintenance importation or other special
situation.
During import, the import process does not disturb the current listings data tables; it
writes all listings information to a secondary set of listings tables. After the import is
complete, the import changes the secondary listings tables to the primary listings
tables. Using this method, clients can still request listings data while an import is in
progress and, if the import should fail, the listings data remains intact. For more
information, see Configuring the EPG Import Process (p. 184) in Installation and
The following diagram provides a close-up look at the interactions between the Listings
LibrarianWS Web service and other Microsoft Mediaroom components.

server11sp32-27feb09-2009-0227-1757
Page 91
1) The Listings Updater application continually queries the ListingsLibrarianWS Web
service to determine whether listings data needs to be updated. When Listings
Updater detects that a new import has been requested or that channel maps have
changed, it reruns the import and listings data generation process.
After the Listings Updater application import and listings data generation process
completes, it updates the version number maintained by the ListingsLibrarianWS
Web service. The ListingsLibrarianWS Web service maintains the version numbers
and flags that indicate which data import processes need to be run.
2) The ListingsLibrarianWS Web service keeps track of certain EPG import process
flags in the ListingsSettings database. This database is located on the Branch
Database machine. The ListingsSettings database is always accessed through the
ListingsLibrarianWS Web service.
3) After the EPG import process has completed, the ListingsLibrarianWS Web service
also builds and maintains a local cache of listings data. This cache is available to
other Mediaroom system components through a virtual directory (Web site) enabled
in IIS.
4) Various Delivery Agent Windows services and other EPG-related Web services
query the ListingsLibrarianWS Web service directly to obtain the latest listings data
version information and the URLs of available data.

server11sp32-27feb09-2009-0227-1757
Page 92
5) If the components detect that a new version of listings data is available, the
components access the updated listings data from the virtual directory. If the
querying component is a Delivery Agent Windows service, the service updates its
own local data caches.
Listings File Format

The listings subsystem uses the Microsoft Global Listings Format (GLF) data model to
represent the listings data. The source listings data must be formatted in an XML GLF listings
representation that uses a specific schema to ensure data integrity. Using XML
representations, the listings subsystem provides format uniformity, schema-based validation,
and a consistent transformation mechanism.
Listings providers who provide metadata in other formats are required to have the data
converted to GLF (either by the listings provider, the Microsoft Mediaroom service operator,
or some other party) before Microsoft Mediaroom can import the data.
The listings data file contains the program and scheduling information for a specific time
period, such as the next 14 days of programming. The file should contain information that is
relevant only to that particular period of time and should not contain any scheduling gaps.
Avoid leaving unused data in the file, because the memory available on clients for listings
data is limited.
The listings data file is typically updated (imported) once a day. Avoid frequent updates
(imports) of the listings data, because each time the data is updated it must be sent to each
client in the network.
Listings data is used primarily by Microsoft Mediaroom clients to:
• Populate the program guide.
• Provide program details on the Program Info page, channel panel, and browse panel.
• Define program categories.
• Search by program title and roles.
• Assign ratings to programs.
• Schedule series recordings.
Channel Maps
Channel maps associate services to virtual television channels. A channel map can contain
any number of virtual channels. Channel maps enable service providers to offer different

server11sp32-27feb09-2009-0227-1757
Page 93
channel lineups while using the same set of services. They also enable the creation of test
channel maps when service providers try out new services.
Microsoft Mediaroom clients use channel maps to determine which service to display when
subscribers press number buttons or the channel up and down buttons on the remote control.
A subscriber can be associated with only a single channel map.
In a channel map, a virtual channel is associated to a service collection. Service collections
define a group of related services such as:
• Full-screen (live TV, VOD, and PPV).
• PIP (live TV, VOD, and PPV).
• VOD trailers.
• RDP applications.
Service collections enable operators to define which services to present to subscribers when
they are authorized to view content and when they are not authorized (upsell condition). For
example, when creating a VOD service collection, operators define both a primary and
secondary set of full-screen and PIP services. The primary services are displayed if the
subscriber is authorized to view the VOD asset. They typically contain the feature-length
video and picture-in-picture (PIP). The secondary services are displayed as an upsell
promotion if the subscriber is not authorized to view the VOD asset. They typically contain
the full-screen and PIP trailers.
Note The listings subsystem does not manage channel maps, rate packages, or any type of
subscriber-specific data preferences.
See Also
Media Discovery Subsystem (p. 095)
DVR Scheduler Subsystem (p. 125)

server11sp32-27feb09-2009-0227-1757
Page 94
Media Discovery Subsystem
The media discovery subsystem provides private server-facing and public client-facing Web
services that process requests for media descriptions. Although the mdws Web service and
MDWSPrivate Web service perform the same function, they serve different requestors
(Microsoft® Mediaroom clients and the SearchWS Web service, respectively), and may reside
in different zones for security purposes.
Media descriptions are data sets that contain enough information from the metadata for a
given piece of content (for example, a VOD asset) in sufficient detail to enable Microsoft
Mediaroom software components to operate on the content (for example, to return
information for a search query performed by the subscriber). Each request specifies a piece of
content by a GUID known as a “media descriptor.” The mdws Web service contacts the
service information subsystem for system information, and then it accesses the Listings
Librarian Web service or BranchDB database to retrieve the matching media description.
The following diagram shows the types of communication that the media discovery
subsystem performs.
The following table describes the media discovery subsystem software components.

server11sp32-27feb09-2009-0227-1757
Page 95
mdws Web service Receives requests for media descriptions from Microsoft
Mediaroom clients. Each request specifies a piece of content (for
example, a VOD asset) by a GUID known as a “media descriptor.”
The mdws Web service provides clients with the information
required to assemble the channel map and Video on Demand
screen, which is used to identify and access Microsoft Mediaroom
services. The mdws Web service contacts the service information
(SI) subsystem to retrieve service information about the content,
and then gets listings metadata for the content from the listings
subsystem. The mdwsWeb service uses the returned service
information and EPG metadata to create a media description for the
requested content and delivers it to the Microsoft Mediaroom
client.
MDWSPrivate Web Receives requests for media descriptions from the SearchWS Web
service service. The MDWSPrivate Web service then handles the requests
in the same manner as the mdws Web service.
vodCatalogWS Web Provides a client-facing Web service interface through which

service clients obtain VOD metadata.
When a Microsoft Mediaroom client needs to construct a Video on
Demand screen, it contacts the vodCatalogWS Web service to
obtain a list of VOD assets and categories. The vodCatalogWS
Web service contacts the subscriber management subsystem (SMS)
to look up the subscriber to determine which assets the subscriber is
entitled to view. The vodCatalogWS Web service returns the
complete URL of each VOD asset. The vodCatalogWS Web
service is not responsible for tracking VOD locations (service
information). The vodcatalogWS Web service is installed on a
Server-Facing Branch machine.
vodCatalogPrivateWS Builds the VOD catalog of assets that display in the Search screen
Web service for subscribers. The catalog of assets is the library of content that
the subscriber has requested. The client displays these assets
together in a listing that is viewable by the subscriber.
See Also
Listings Subsystem (p. 090)

server11sp32-27feb09-2009-0227-1757
Page 96
Search Subsystem (p. 132)
Service Information Subsystem (p. 098)

server11sp32-27feb09-2009-0227-1757
Page 97
Service Information Subsystem
The service information (SI) subsystem is the central directory for all Microsoft® Mediaroom
services. The SI subsystem provides Microsoft Mediaroom clients with the information
needed to acquire video and data services. Services include live video services, VOD assets,
and RDP application services.
Microsoft Mediaroom clients communicate with the SI subsystem to:
• Discover available video and data service collections.
• Associate various mixed modes (live TV, VOD, RDP application, image) with a
single top-level service collection.
• Determine which version of a channel to display (for example, full-screen, PIP, or
upsell) depending on context.
The SI subsystem does not maintain or access subscriber, client, or service rights.
Microsoft Mediaroom clients receive data maps in XML format that enable them to discover
and access live, VOD, and RDP application services. This information may be attached on a
service-by-service basis or to the subsystem description. If the information is attached to a
subsystem, it applies to all services carried by that subsystem.
Service Information Subsystem Software

The following diagram shows the SI subsystem software components and how they interact
with other Microsoft Mediaroom components.

server11sp32-27feb09-2009-0227-1757
Page 98
The following table describes the SI subsystem software components.
Service discovery Provides a set of interfaces that enable other Microsoft Mediaroom
Web service server machines to access details for each service.
BranchDB database Maintains base service information data in an SQL database. Base
service information data includes the following:
• Service map, which contains detailed information about
individual services.
• Service collection map, which bundles services together to
present a consistent display across various display contexts.
• Media description map, which associates a media descriptor
(a GUID that identifies a specific media description) with
listings data and a service collection.
At Microsoft Mediaroom system startup, the client service information handler connects to a
bootstrap Web service where it acquires the appropriate service information data. It

server11sp32-27feb09-2009-0227-1757
Page 99
immediately delivers the configuration data for each subsystem from the data map to the
appropriate subsystem. The subsystems can then begin acquiring any specific data required.
See Also
Video on Demand Subsystem (p. 044)
RDP Application Subsystem (p. 076)
Channel Management Web Service (p. 158)
Web Service Router (p. 086)

server11sp32-27feb09-2009-0227-1757
Page 100
Client Startup Services
Microsoft® Mediaroom provides the following services for clients to use while starting up:
• bootstrap Web service. Used when clients go through their startup sequence.
• Sync Discovery Service Windows® Service. Used by clients during startup or
disaster recovery to provide resource locations.
• upgradeWS Web service. Used by clients that run a Microsoft Mediaroom Client
release prior to 1.6.2 to download upgraded software. Clients that run Microsoft
Mediaroom Client 1.6.2 or later use the upgradeWS Web service to locate the server
that has the upgraded software files, which are stored on a machine that hosts the
clientUpgradeFiles role.
• clientUpgradeFiles role. Creates the location for downloadable upgrade software
packages for clients that run a Microsoft Mediaroom Client release of 1.6.2 or later.
These services are described in the following sections.
Bootstrap Web Service

The bootstrap Web service is the first Web service that Microsoft Mediaroom clients
encounter when they go through the startup sequence. Microsoft Mediaroom clients acquire
the URL of the bootstrap Web service by requesting the bootstrap service record from DNS
or from the OEM configuration section of the client boot ROM.
Interaction of the Bootstrap Web Service with Other

Microsoft Mediaroom Components
The following diagram shows how the bootstrap Web service interacts with other Microsoft
Mediaroom components.

server11sp32-27feb09-2009-0227-1757
Page 101
Note Microsoft Mediaroom clients begin their startup sequence by acquiring IP connectivity
through a supported protocol from a local gateway, such as a DSL router. Currently,
Microsoft Mediaroom client software supports only Dynamic Host Configuration Protocol
(DHCP).
The bootstrap Web service enforces service policies for authenticated clients. For example, it
checks the client for a valid certificate and required minimum software version. If the client
software version is below a minimum number, the bootstrap Web service initiates an upgrade
through the upgradeWS Web service. For more information about the client upgrade process,
see Upgrading Devices (p. 582) in Operations Guide.
The Microsoft Mediaroom bootstrap Web service can make use of an external login server
(ELS) Web service, if the service provider provides one. The bootstrap Web service calls the
ELS Web service whenever a set-top box is powered on or connected to the network. The
ELS Web service provisions the set-top box if necessary, verifies that the set-top box is
entitled to connect to the service provider, and returns information signaling the result of the
authentication. In addition, the ELS Web service can optionally redirect the set-top box to a
“self-provisioning” RDP application that, for example, prompts subscribers to enter credit-
card information, choose subscription packages, and so on.
The bootstrap Web service authenticates the Microsoft Mediaroom client and logs it on to the
Microsoft Mediaroom system. It then contacts the subscriber management subsystem (SMS)
to determine the subscriber’s billing status and returns a list of URLs for Web services
(terminal service monitor, client upgrade, and so on) from which the Microsoft Mediaroom
client can acquire configuration data.

server11sp32-27feb09-2009-0227-1757
Page 102
Sync Discovery Service Windows Service
The Sync Discovery Service Windows service hosted on the Sync and Discovery Server
provides clients with the location of resources that they can contact during regular start-up or
to recover from a failure.
The application that clients use to recover from a failure, known as Disaster Recovery
Application (p. 103) (DRA), helps the client restore configuration information and to
acquire a new copy of the appropriate version of Microsoft Mediaroom client software. The
Sync Discovery Service Windows service sends the client a URL for the appropriate DRA
files for all client releases.
The Sync Discovery Service Windows service implements a simple protocol based on the
trivial file transfer protocol (TFTP) that lets clients specify a GUID so that the Sync
Discovery Service Windows service can determine the most appropriate servers to obtain
bootstrap information or the DRA for each client.
Disaster Recovery Application

The Disaster Recovery Application (DRA) is downloaded and executed by the boot ROM on
the set-top box when the set-top box recovers from a disaster, on initial start-up of a set-top
box when no client software is present on the set-top box, or after a catastrophic set-top box
failure.
The set-top box boot loader establishes communication with the Sync Discovery Service
Windows Service (p. 103) through a URL that is returned by the Sync and Discovery
Server, and the appropriate DRA is downloaded to the set-top box.
When the set-top box is new and first run, there is no software present, and the DRA
partitions and formats the storage device, acquires a bootstrap address, and loads or upgrades
the client application as necessary. In a disaster case where the client software has been on the
set-top box before and there are existing partitions, the DRA will only reformat the
application partition, and will not touch the DVR partition. This means no recordings are lost.
For more information, see Client Disaster Recovery (p. 605) in Operations Guide.
UpgradeWS Web Service

The upgradeWS Web service provides Web services for updating pre-1.6.2 clients, or returns
a URL where 1.6.2 or later clients can obtain the appropriate upgrade package. The URL that
is returned for 1.6.2 or later clients points to a machine that hosts the clientUpgradeFiles role
which has the appropriate files for the client. The URL is created from the following items:

server11sp32-27feb09-2009-0227-1757
Page 103
• Client OEM or make from the client’s certificate.
• Client model sent by the client.
• Client version from the Service Group Database.
The resulting URL is in the following form:
http://<clientUpgradeFiles>/<OEM_ID>/<Model_ID>/Application_<version>.dat
This URL directs the client to a virtual directory on IIS. For more information, see Upgrading
Devices (p. 582) in Operations Guide.
ClientUpgradeFiles role
The clientUpgradeFiles role creates a virtual directory on a Web server where the upgrade
packages for 1.6.2 or later clients are located. Set-top boxes must be able to directly connect
to this Web server, as this connection is not made through the Web service router. Clients
download the appropriate upgrade package after receiving the package’s URL from the
upgradeWS Web service.

server11sp32-27feb09-2009-0227-1757
Page 104
Subscriber Management Subsystem
The subscriber management subsystem (SMS) provides access to a repository of information
about Microsoft® Mediaroom subscriber entitlements within a branch. The SMS stores
service offerings (live TV, VOD, and RDP applications), default entitlements for all branch
subscribers, and subscriber-specific entitlements in the service group database. (For
information about service groups, see Service Group Subsystem (p. 109).)
The SMS includes:
• A Microsoft Windows® service that polls for new keys for live TV services.
• Web services through which other Microsoft Mediaroom components can access the
service group database.
Service Offerings
The SMS uses media descriptors to identify all services, whether they provide a live TV,
VOD, or an RDP application service. media descriptors enable service providers to define
services, service collections, and service packages.
Default Entitlements
Microsoft Mediaroom service providers can grant default entitlements for individual services
(for example, access rights to view a premium channel) and for packages of services (for
example, access rights to a collection of premium channels).
If the SMS receives changes to subscriber rights, it may proactively notify the affected
devices.
Subscriber Management Information

The SMS maintains the following information about each subscriber:
• Microsoft Mediaroom devices that are installed at the subscriber’s residence.
• Services and service packages that each account or device is entitled to consume.
• External billing system ID and credit limit.

server11sp32-27feb09-2009-0227-1757
Page 105
Service providers extend a certain amount of credit for the purchase of billable services to
subscribers. The SMS tracks and manages this limit. If a subscriber exceeds the credit limit,
rights to any purchasable service are denied until the limit is reset. Microsoft TV provides
applications that enable the service provider or the subscriber to reset the credit limit within
limits imposed by the service provider’s business rules.
The SMS does not collect or hold a subscriber’s billing information, such as a credit card
number or payment information, but it does track the subscriber credit limit.
Service provider personnel add the subscriber into the service provider’s business system,
which then communicates the information to the SMS through the OSS and BSS Web
services. The SMS maintains information about the subscriber and the associated devices,
with billing information related to each device.
Billing Events
The SMS keeps track of billable Microsoft Mediaroom transactions for each subscriber and
device, including VOD purchases, Pay Per View (PPV) purchases, and subscriptions to
services and channels. When subscribers purchase services, the SMS creates the billing events
and stores them in the service group database. The billing events can then be accessed
through BSS Web services.
SMS Software Components and Data Flow

The following diagram shows how the SMS software components interact with other
Microsoft Mediaroom subsystems.

server11sp32-27feb09-2009-0227-1757
Page 106
The following table describes the SMS software components.
Billing Web service Enables business support systems (BSS) to access subscriber
billing events in the service group database.
Client rights Web service Manages Microsoft Mediaroom client requests for service
access rights and keys. Checks the service group database and
returns valid content protection keys to the client if service
access rights are granted by default or if the subscriber
purchased the service.
Key management Web Enables the live TV acquisition and VOD acquisition
service subsystems to update keys in the subscriber database.
Principal management Web Enables business support systems (BSS) to manage principals
service (subscribers, devices) in the service group database. BSS
systems access this Web service through the BSS principal
management Web service, which is a proxy that exposes the
same API.
Purchase Web service Manages purchase requests from Microsoft Mediaroom

clients.
Resource management Web Enables BSS systems to manage resources (live services,

server11sp32-27feb09-2009-0227-1757
Page 107
service VOD assets, and RDP applications) in the service group

database.
Rights management Web Enables BSS systems to manage rights in the service group
service database.
Business logic resides in the service provider’s operations support systems (OSS) and
business support systems (BSS) rather than in the SMS. For example, Microsoft Mediaroom
exposes Web services to store live service package information. Through these Web services,
the OSS and BSS can define multiple service tiers (for example, basic, silver, and gold) that
include different sets of live channels. The SMS, however, does not track relationships
between these tiers. For example, the SMS does not indicate if the basic tier is a subset of the
silver or gold tiers.
Microsoft Mediaroom provides a set of Web services (billing record management, grant
management, offer management, package management, and principal management), through
which BSS systems monitor and manage SMS data.
For details on the BSS Web service APIs, see BSS Web Service Reference in the Microsoft
Mediaroom OSS/BSS Integration documentation set.

server11sp32-27feb09-2009-0227-1757
Page 108
Service Group Subsystem
Service groups are a subset of servers in the branch that divide the subscriber management
tasks to distribute the processing load and provide a way to perform software upgrades with
minimal service interruptions. Service groups enable operators to:
• Scale up Microsoft Mediaroom systems to accommodate new subscribers.
• Prevent service interruptions while performing system upgrades and other regular
system maintenance.
Scalability and Load Balancing

Microsoft Mediaroom enables operators to add more subscribers by simply expanding their
server capacity at their data centers. At the same time, Microsoft Mediaroom service groups
enable operators move subscribers among different server pools for load balancing, or to
partition their service groups based on any criteria, such as geographic proximity.
Microsoft Mediaroom Software Upgrades

Service groups support an upgrade methodology that maximizes service “uptime” and
business continuity. To maintain service uptime while performing system upgrades,
Microsoft Mediaroom requires minimal spare hardware system resources. For example,
operators can use one service group as a standby group to be shared by all the active service
groups.
Microsoft Mediaroom data migration can be implemented with a fine granularity. A robust
database migration tool minimizes the impact of data migration on subscriber experience. For
details on database migration, see Installation and Configuration Guide.
Service Group Subsystem Software Components

and Data Flow
The following diagram shows the software components that constitute the service group
subsystem as well as the interaction between the service group subsystem and other parts of
Microsoft Mediaroom.

server11sp32-27feb09-2009-0227-1757
Page 109
Each service group in the service group subsystem is supported by a database of information
about accounts and devices assigned to that service group. The service group subsystem also
provides a data access layer through which server-facing Web services in the service group
access the service group database and a Web service that enables BSS Web services to access
the database.
Each service group is self-contained in terms of handling client requests, presenting offers,
and enabling purchasing and billing. The service group database for each service group
includes read-only copies of services, resources, packages, and group offer data, all of which
are replicated from the branch database.
When multiple service groups are deployed, all servers in each service group operate
completely independently of servers in the other service groups. Because there is no
contention among service groups, operators can scale out the Microsoft Mediaroom system
with service groups by adding new subscribers to a service group and also by adding more
service groups as needed, without running into scalability problems. An operator can deploy
so that subscriber accounts are load-balanced evenly among service groups for scalability and
best performance.
Unless operators specify a service group when adding devices and accounts, Microsoft
Mediaroom adds the new principals to a default service group. Operators specify the default
service group through the TV Services Management tool, or they can use custom applications
that manage service group defaults and data through the OSS Web services. While the branch
management Web service enables OSS systems to set the default service group, all subscriber
details are managed through the BSS Web services.

server11sp32-27feb09-2009-0227-1757
Page 110
See Also
Branch Management Subsystem (p. 113)
Service Group Database

All subscriber group and service group metadata, as well as service and asset store metadata,
is stored in the branch database. However, individual subscriber data for each service group is
consolidated and stored in the corresponding service group database, which also incorporates
subscriber group metadata and non-subscriber metadata for that service group. Subscriber
group and non-subscriber metadata are replicated from the branch database to enhance
scalability, and for read-only access. Because the service groups are independent of each
other, operators can continue to add more subscribers by adding new service groups, to scale
out the overall capacity of their system.
Some service group databases are maintained at the service groups. Others are replicas of
databases managed at the branch. The branch management subsystem uses SQL replication to
ensure that account information is kept current in the appropriate service groups.
The service group database includes tables for the following subsystems:
• Asset Store (replica)
• DVR
• Notification
• Session key authority (replica)
• Service information (replica)
• Live Config and Cluster Assignment (replica)
• SMS: devices and accounts
• SMS: group and key (replica)
Web Services in Service Groups

The service group data access layer is a Windows library that enables server components to
access the service group database through Web services in the service group.
The following server-facing Web services are deployed in each service group:
• dvrRemote
• dvrScheduleUpdateService
• mdWSPrivate

server11sp32-27feb09-2009-0227-1757
Page 111
• notificationController
• sessionKeyAuthorityWS
• servicegroupSMSWS
• SGepgWS
• SGPrivateSessionKeyAuthorityWS
• SGTraceLog
• subscriberActivityLogDataWS
• TServerController
• vodCatalogPrivateWS
• vodSGBranchWS
The following client-facing Web services are deployed in each service group:
• bootstrap
• clientEdgeMapWS
• clientLoggerWS
• dvrV2WS
• mdws
• notificationWS
• SearchWS
• smsPublic
• tsMonitorPublic
• Upgrade
• userstorePublicWS
• vodCatalogWS
• vodMapServerWS
Service Group SMS Web Service

The service group SMS management Web service enables BSS Web services, which are
deployed centrally at the branch, to access the service group database. When BSS Web
services need to access information about a specific account, they contact the branch
management subsystem to find out the service group to which the account is assigned. The
BSS Web services can then determine the endpoint URL of the appropriate service group
SMS management Web service, and access the service group database.

server11sp32-27feb09-2009-0227-1757
Page 112
Branch Management Subsystem
The branch management subsystem provides a central database for subscriber information
and a Web service through which it defines the assignment of accounts to the appropriate
service groups. While data that is unique to each service group is stored in the corresponding
service group database, account data is stored centrally in the BranchDB database, and then
replicated in the appropriate service group database. Instead of relying on Web service
communication, however, Microsoft Mediaroom performs database replication through SQL
stored procedures.
The BranchDB database is managed by the following Microsoft Mediaroom server

components:
• The TV Services Management tool enables operators to define new service groups in
a branch and to manage existing service groups.
• The OSS branch management Web service enables OSS applications to retrieve and
update service group definitions created by the TV Services Management tool.
• BSS Web services enable BSS applications to manage accounts, billing records,
grants, offers, and purchases, the details of which are stored in the BranchDB
database and replicated as required in the appropriate service group databases.

server11sp32-27feb09-2009-0227-1757
Page 113
• The branch service group-facing Web service enables server components in each
service group to retrieve information from the BranchDB database. For example, the
bootstrap Web service accesses the BranchDB database when a client in the same
service group starts. For details on the client bootstrap process, see Bootstrap and
Redirection (p. 114).
Bootstrap and Redirection

When a device bootstraps to the server for the service group that the subscriber’s account was
associated with during the previous bootstrap operations, the device checks the SMS to
determine the current status of the subscriber account the device is assigned to.
If the SMS indicates that the device does not exist in the current service group, the bootstrap
server consults with the branch to decide whether the subscriber’s account is in another
service group.
If the account is in the same service group it was in during the previous bootstrap operation,
the bootstrap server goes through the external login system to register the account.
If the account is in a different service group than during the previous bootstrap operation, the
branch returns HTTP status code 301 with the fully-qualified domain name of the load
balancer for the Web service routers of the appropriate service group. The device then
bootstraps again, this time with the correct service group.
Branch Database Tables

The branch database includes tables for the following:
• Asset store
• Branch management
• Live config state
• Notification (stored procedure)
• Session key authority
• Service information
• SMS (subscription group and key)
• User store (global device values)
• VOD

server11sp32-27feb09-2009-0227-1757
Page 114
Web Services in the Branch
The following server-facing Web services are deployed in the branch:
• BranchMgmtWS
• clientEventLogDataWS
• EdgeControllerFromEdgeWS
• epg Web service
• LiveBackendUpdate
• sessionKeyAuthority_KeyGenerator
• sessionKeyAuthorityWS
• serverEventLogDataWS
• vodBranchWS
• vodControllerWS

server11sp32-27feb09-2009-0227-1757
Page 115
Notification Subsystem
The notification subsystem is a general-purpose mechanism for delivering messages from
other Microsoft® Mediaroom subsystems and services to Microsoft Mediaroom clients.
Messages are typically delivered:
• To inform clients that system information (such as listings) has changed and can be
downloaded from Microsoft Mediaroom subsystems.
• To inform clients of state changes, such as entitlement changes.
• To communicate information to subscribers, in the form of short messages that
appear on the subscriber’s screen.
• To tell a client to upload diagnostic information to the logging subsystem.
Each message can be scheduled for delivery at a specific time with an expiration time
interval. In addition, you can add up to ten buttons to a notification message that allow users
to tune to a specified channel or service. For details on configuring buttons in notification
messages, see the related information in "UI Notification Web Service" in OSS Web Service
Reference in the Microsoft Mediaroom OSS/BSS Integration documentation set.
The notification subsystem delivers the messages over UDP/IP to clients, which then put the
messages in a queue and process them in the order in which they arrive.
The notification subsystem exposes the notificationController Web service, through which
Microsoft Mediaroom subsystems can post messages for delivery. Microsoft Mediaroom
provides Web services (for example, UI notification Web service and diagnostics notification
Web service, and High Priority Notification Web Service) through which operations support
systems (OSS) can post notification messages (packaged as XML data) for clients.
For details on the OSS Web services that provide access to the notification subsystem, see UI
Notification Web Service (p. 164), Diagnostics Notification Web Service (p. 159) and
High Priority Notification Web Service.
Notification Subsystem Software Components

and Data Flow
The following diagram shows how the notification subsystem interacts with other Microsoft
Mediaroom subsystems.

server11sp32-27feb09-2009-0227-1757
Page 116
The following table describes the notification subsystem software components.

server11sp32-27feb09-2009-0227-1757
Page 117
Notification Delivers messages from Microsoft Mediaroom subsystems to

delivery Windows Microsoft Mediaroom clients over UDP. It also retrieves messages
service from the notification controller for delivery and attaches
corresponding client information (client ticket, and IP and NAT
addresses and ports) from the service group database. The
notification delivery Windows service accesses the service group
database through the notification controller Web service.
Depending on how the notification subsystem is configured during
installation, messages are either delivered on a unicast or multicast
address. Multicast notifications (when enabled) are only used for
system messages, like EPG and service information changes. Client-
specific, subscriber-specific, or group–specific messages, like
channel map changes, are always sent by unicast. In general, using
multicast addresses provides better performance.
The notification delivery Windows service also maintains regular
communications with clients over a UDP “heartbeat” protocol. This
enables the service to handle client status changes and keep NAT
ports open if the client resides behind a residential gateway. The
notification delivery Windows service stores the client status changes
in the service group database.
The notification delivery Windows service runs on the same host (the
Client Gateway machine) as the Web service router.
Clients receive the addresses of two hosts running the notification
delivery Windows service from the client notification Web service.
Clients should maintain communications with at least two
notification delivery Windows services.
Notification Server-facing Web service. Enables Microsoft Mediaroom

controller Web subsystems to query the service group database, set up messages to
service deliver to Microsoft Mediaroom clients, or cancel pending messages.
Client notification Provides clients with addresses of machines running the notification
Web service delivery Windows service. Uses a random algorithm for selecting
two notification delivery Windows services for any given Microsoft
Mediaroom client that logs on to the system.
Clients get the addresses of machines running the client notification
Web service from the bootstrap Web service.

server11sp32-27feb09-2009-0227-1757
Page 118
Note Because client state is maintained in a database, the client-facing services can scale to
match the number of clients. Any client can communicate with any notification delivery
Windows service or with any client notification Web service.
Message Handlers
The Microsoft Mediaroom client is equipped with message handlers for messages that
Microsoft Mediaroom services may generate. Microsoft Mediaroom clients support several
types of messages, including:
• Rights change messages, which ensure that the client has the appropriate access
rights for services to which it is entitled.
• Service information change messages, which ensure that the client has current media
descriptions. These messages originate in the EPG and SI subsystems and are
typically sent as multicast notifications at repeat intervals.
• Text messages, which the client presents to television viewers through a simple UI.
These messages can be generated by custom applications that interface with the UI
notification Web service.
• Diagnostics request messages, which cause the client to upload diagnostic
information.
If the client has handlers for a message it receives, it processes the message. New or existing
services can post new types of messages to the client, but the client processes only those
messages it is equipped to handle.
Messages can be delivered to individual clients, or they can be broadcast to all clients
simultaneously.
Message Delivery and Heartbeat Protocol

Microsoft Mediaroom delivers notifications to clients over UDP/IP, using a unique heartbeat
protocol designed to reduce message delivery latency and to improve NAT gateway traversal.
When the notification subsystem receives a message to deliver from another Microsoft
Mediaroom subsystem or from a custom application, the message details are stored in the
service group database. Under normal conditions, the notification delivery Windows service
polls the notification controller Web service for message delivery jobs every ten seconds.
This interval may be shorter if the notification subsystem has no notifications to deliver. The
only time this interval is longer than 10 seconds is when the number of messages in the
delivery queue exceeds the maximum of 4000. If the maximum number of messages is

server11sp32-27feb09-2009-0227-1757
Page 119
reached, the system sends messages to clients from the buffer. The notification subsystem
requests 1000 messages at a time from the controller. The controller sends all of its messages,
up to 1000 per request.
The notification delivery Windows service sends the message to the appropriate clients. After
receiving messages, clients respond over UDP/IP to acknowledge and identify the message
received.
To ensure that clients handle only authentic messages, communication between clients and
servers is encrypted. When sending a message, the client or server includes a timestamp on
the message itself. This timestamp is signed by the sender to guarantee authenticity. When the
message is received, the recipient compares the difference between the transmission and
reception timestamps with the Maximum Delivery Threshold Time parameter.
Multicast messages (for example, system messages) are not encrypted, but they are signed so
their origin in the Microsoft Mediaroom system can be verified. Although these messages
cannot be impersonated or modified, they can be intercepted and read, so they include no
personally identifiable or secret information.
Microsoft Mediaroom clients maintain periodic communication with the notification
subsystem to keep NAT firewall ports open. They also indicate if they can still communicate
over UDP/IP by describing their current operational state (for example, power-on, stand-by,
or unavailable).
Under normal conditions, clients send the notification delivery Windows service ping
messages every 30 seconds (not a configurable interval). If Microsoft Mediaroom is
configured with two machines running the notification delivery Windows service, the clients
send pings every 15 seconds to alternating machines, so that each machine receives a ping
every 30 seconds.
Clients use the pings to track the availability of the notification delivery Windows service. If
a client fails to get an acknowledgment from a machine within eight message-ping intervals,
the client considers the notification delivery Windows service dead and contacts the client
notification Web service to get the address of another notification delivery Windows service
to contact.
If a client is removed from the service group database (which is extremely unlikely due to the
pinging), it receives an acknowledgment from the notification delivery Windows service. If
this happens, or if the client’s list of services is empty, the client contacts the client
notification Web service to start from the beginning.
The notification delivery Windows service listens on UDP port 0xabba (43962). If a client
resides behind a NAT residential gateway, it transmits messages over a dynamically received
port. The client includes its NAT IP address and UDP port when it sends heartbeat UDP
packets. The notification delivery Windows service stores this information in the service
group database through the notification controller Web service.

server11sp32-27feb09-2009-0227-1757
Page 120
The following diagram illustrates how notification subsystem components interact when
clients communicate over UDP/IP.
The UDP/IP-based heartbeat protocol supports messages containing no more than 1000 bytes.
The notification delivery Windows service encrypts messages with the corresponding client’s
certificate, which it obtains from the bootstrap Web service. If the message itself is less than
1000 bytes, the ping message includes the encrypted message.
Client Startup Communications with the

Notification Subsystem
On startup, clients contact the client notification Web service to register with the notification
subsystem and get a list of hosts running the notification delivery Windows service. The list
of notification delivery Windows service machines identifies one host as primary and another
as secondary. The designation of “primary” and “secondary” is for notation only; there is no
functional difference between the hosts.
After receiving the host list, the client sets up the multicast receive socket if multicast is
enabled. It then initiates the UDP/IP heartbeat protocol. Initially, the client uses a 5-second
ping interval to establish communications with the notification delivery Windows service
hosts. After receiving acknowledgment messages, the client switches to a 30-second interval.
The following diagram illustrates the communications that occur within the notification
subsystem when a client starts up.

server11sp32-27feb09-2009-0227-1757
Page 121
High Priority Notification Subsystem
The following diagram describes the relationship of the components of the High Priority
Notifications system.

server11sp32-27feb09-2009-0227-1757
Page 122
Introduction
The Microsoft Mediaroom High Priority Notification Web Service provides timely delivery
of messages to Microsoft Mediaroom clients in a timely manner within a specified latency
constraint. Notifications may be targeted to all clients in a single account with a single API
call.
Notifications are delivered in a timely and best effort manner. Timeliness and reliability of
message delivery is dependant upon individual server response time and delays induced by
the message's network path and the reliability of the underlying network and infrastructure.
Architecture
The following sections describe the architecture of the high-priority notification subsystem.
Branch Routing Cache

For SP3.2, the push model was added to the Notification Subsystem in addition to the pull
model. The OSS layer now routes messages directly to the NDS servers. As a means to
increase the speed of processing of branch-to-service and account-to-device mappings, and
because only the NDS is aware of the devices for which it is responsible, a cache is created
that contains account information, device IDs for each account, and service group information
for all the accounts in the branch.
Multicast to NDS in the Service Group

All NDSs in the same service group listen to the same multicast IP address. Messages are sent
to the multicast IP address of the NDS of the service group to which the destination clients
belong.
Each message appearing on an NDS server's multicast IP address is parsed for its destination
device ID. If the destination device belongs to a particular server, the server sends a unicast
message to the intended destination device. If the destination device does not belong to the
server, it simply ignores the message.
NTP-based Clock Synchronization

Because notification messages need to be delivered to the destination device within the
specified latency constraint, all the servers and the devices are synchronized to the NTP
clock. Notification messages are discarded when they exceed the specified latency constraint.

server11sp32-27feb09-2009-0227-1757
Page 123
As a result, all the machines shown in the diagram under the High Priority Notification
Subsystem (p. 122) section must be able to access the NTP servers.
Redundant Message Handling at the Client

Mediaroom clients maintain persistent connections with multiple NDS servers and may
receive multiple copies of the same message sent by more than one server. Each message has
a unique message ID (GUID); the client ignores all but the first message with a specified
GUID.

server11sp32-27feb09-2009-0227-1757
Page 124
DVR Scheduler Subsystem
The DVR scheduler subsystem schedules and manages digital video recordings for all
Microsoft® Mediaroom clients. This subsystem can manage two types of recording schedules:
• One-time recording. A recording that is scheduled to happen one time only. For
example, recording a specific movie at a specific time.
• Recurring recording. A recording that is scheduled to happen multiple times. For
example, recording the next six episodes of a specific program, or recording a
program every Tuesday.
When subscribers create or modify a recording schedule, the Microsoft Mediaroom client
sends the recording information to the DVR scheduler subsystem. The DVR scheduler
subsystem checks for conflicts with other recording schedule requests for the client. Any hard
padding added to the schedule by the operator or subscriber is included as part of the check
for scheduling conflicts, while soft padding added by the operator is discarded if it causes a
conflict. If no conflicts are found, the DVR scheduler subsystem stores the schedule in the
DVR database. If the IPTV Edition DVR Scheduler Updater Windows® service detects a
recording conflict, the conflicting schedule information is sent back to the Microsoft
Mediaroom client, which then prompts the subscriber to resolve the conflict.
The DVR scheduler subsystem also provides a remote recording Web service, dvrV2, which
can be used to schedule recordings remotely. For example, a service provider might write a
Web page that enables subscribers to log in remotely and schedule programs to record. The
Web page would communicate with the DVR scheduler subsystem’s Web service,
remoteDVR, which would arrange for the appropriate set-top box to make the recording.
Each client maintains its own schedule of programs to record, and starts and stops recordings
based on that schedule. Clients periodically communicate with the DVR scheduler subsystem
to verify that their schedules are up-to-date. The DVR scheduler subsystem can also notify a
client that it needs to refresh its schedule (for example, when a recording is scheduled
remotely through the Web service).
The client stores recorded programs in 64 MB file “chunks.” A single recording consists of
multiple chunks. The client also creates an index file for each recorded program to facilitate
trick modes and program positioning. Metadata that is related to the program is also stored on
the hard disk drive.
Note Recording schedules are tied to services, not channel numbers. If a channel map is
reconfigured or if a subscriber reorders the program guide, a scheduled recording still records
the correct program. For example, a recording that is targeted at a program on the ESPN
service still correctly records an ESPN program even after a channel number change.

server11sp32-27feb09-2009-0227-1757
Page 125
DVR Scheduling in a Multiple Set-Top Box
Environment
Each home is allocated a certain number of data “streams.” The number of streams allocated
for a home is determined by the Microsoft Mediaroom service provider. The number of
possible streams is determined by the amount of bandwidth available to the home. The
amount of available bandwidth is different for each geographic area and service provider. The
number of streams determines the number of live broadcasts and PPV offerings that the
household can watch or record simultaneously. (A set-top box tuned to a recorded show does
not use a stream.)
If a household has n streams, the subscriber can record or watch a total of n shows at once.
When a subscriber tries to schedule a show, the DVR scheduler subsystem determines
whether the household has a stream available at that time. If all streams in the household are
already scheduled for recordings, the DVR scheduler subsystem provides full information
about the conflicts to the set-top box. The client then prompts the subscriber to resolve the
conflict by either canceling one of the already-scheduled recordings or aborting the attempt to
schedule a new recording.
For more information, see Multiple Client Households (p. 181).
DVR Scheduler Subsystem Software

The following diagram shows how the DVR scheduler subsystem interacts with other
Microsoft Mediaroom software components.

server11sp32-27feb09-2009-0227-1757
Page 126
The following table describes the DVR scheduler subsystem software components.
DVR Provides activities used to resolve DVR scheduling conflicts. The role
Schedule associated with this Windows service is dvrScheduleUpdaterService, a
Updater Server-Facing Service Group role that can be installed on multiple
Windows machines.
service
dvrV2 Web Provides the client-facing Web services for digital video recording. The
service role associated with this Web service is dvrV2WS, a Client-Facing
Service Group role.
In a multiple set-top box household, each set-top box communicates with the DVR scheduler
subsystem independently, and this subsystem ensures that the set-top box with a hard disk
drive receives all scheduling requests. For more information about multiple set-top box
households, see Multiple Client Households (p. 181).

server11sp32-27feb09-2009-0227-1757
Page 127
User Store Subsystem
The user store subsystem enables Microsoft® Mediaroom components to save and retrieve
persistent information as name/value pairs.
The information types that Microsoft Mediaroom clients store in the user store subsystem
include:
• Last channel tuned.
• Last VOD purchase.
• Last VOD tuned.
• Parental control PIN and block level.
• Subscriber channel map.
The following are examples of system-wide client configuration data stored in the user store
subsystem:
• Notification polling interval.
• Number of guide days to load.
• Subscriber UI menus.
• VOD-only client setting that determines whether the UI enables or disables live TV
and DVR pages.
The user store subsystem can also be used to maintain shared state information between
Microsoft Mediaroom clients and servers.
User Store Subsystem Software Components

and Data Flow
The following diagram shows the software components of the user store subsystem and how
they interact with other Microsoft Mediaroom components. For simplicity, the diagram does
not show secondary components that do not directly relate to the user store subsystem.

server11sp32-27feb09-2009-0227-1757
Page 128
The following table describes the user store subsystem software components.
User store public Web service interface through which client applications can set or
Web service get name/value pairs. The Microsoft Mediaroom client accesses
(userstorePublicWS) this Web service to save state information. The user store public
Web service ensures that only the client application that saves data
can retrieve it.
User store library DLL through which server-facing custom applications can set or
get name/value pairs.
See Also

server11sp32-27feb09-2009-0227-1757
Page 129
Session Key Authority Subsystem
The session key authority subsystem generates symmetric session key authority (SKA)
session keys, and then disseminates them to authorized servers in the Microsoft® Mediaroom
branch. The following illustration shows the structure of the session key authority subsystem.
The following table describes the session key authority subsystem components.
SKA Key Generator Windows Periodically generates symmetric server session keys
service for the various queues defined in the session key
authority database tables.
Session key authority database Contains key queues that store protected (encrypted and
tables (in the BranchDB or signed) session keys and queue definitions.
ServiceGroupDB databases)
sessionKeyAuthorityWS Web Web service through which authorized branch servers

service obtain information about available key queues and
obtain session keys from the queues. The servers verify
the authenticity of the keys before using them.
SKA Loader A library associated with each authorized branch server

that enables the branch serve to communicate with the

server11sp32-27feb09-2009-0227-1757
Page 130
sessionKeyAuthorityWS Web service. The SKA

Loader maintains a local cache of the session keys that
the server obtains from the key queues.
All SKA session keys are protected by headend certificates and asymmetric cryptography.
Note The sessionKeyAuthorityWS Web service does not have access to the certificates that
protect the keys it retrieves from the session key authority database tables, so the service can
run in either an application or database security tier.

server11sp32-27feb09-2009-0227-1757
Page 131
Search Subsystem
The search subsystem supports the Microsoft® Mediaroom client search feature that enables
subscribers to easily locate specific live TV, PPV, and VOD content. It returns sorted sets of
media descriptions when subscribers initiate a search from the Microsoft Mediaroom
subscriber interface.
Subscribers can find programs to watch by using the remote control to enter the title of the
program or the name of a person, such as an actor or director. Subscribers enter the search
criteria using one of the following methods:
• Pressing the remote control's number keys repeatedly to display the desired character
on their screen, similar to the way text is entered on a cellular phone (also known as
“triple tap”).
• Using the arrow keys and OK button to select characters in the on-screen keyboard.
Subscribers do not have to enter the full title or name. Search uses a “search as you type”
mechanism that displays search results as the subscriber enters search criteria, which provides
quicker response to search queries.
As the subscriber “types,” the search feature displays a list of currently playing TV programs,
future TV programs, PPV, and VOD assets that match the search criteria. Subscribers can
also limit their searches to Titles, People, and VOD-only. Subscribers can select the show
they want from the list and then watch or purchase it.
The following diagram illustrates how the SearchWS Web service interacts with other

server11sp32-27feb09-2009-0227-1757
Page 132
The following table describes the search subsystem software components.
SearchWS Web service Enables Microsoft Mediaroom clients to obtain media

descriptions from the MDWSPrivate Web service that match
various criteria for content (live TV, PPV, and VOD) that the
subscriber has entered.
mdws Web service Receives requests for media descriptions from Microsoft
Mediaroom clients. Each request specifies a piece of content
(for example, a VOD asset) by a GUID known as a “media
descriptor.” The mdws Web service provides clients with the
information required to assemble the channel map and Video
on Demand screen, which is used to identify and access
Microsoft Mediaroom services. The mdws Web service
contacts the service information (SI) subsystem to retrieve
service information about the content, and then gets listings
metadata for the content from the listings subsystem. The
mdwsWeb service uses the returned service information and
EPG metadata to create a media description for the requested
content and delivers it to the Microsoft Mediaroom client.
MDWSPrivate Web Receives requests for media descriptions from the SearchWS
service Web service. The MDWSPrivate Web service then handles
the requests in the same manner as the mdws Web service.
vodCatalogPrivateWS Web Builds the VOD catalog of assets that display in the Search
service screen for subscribers. The catalog of assets is the library of
content that the subscriber has requested. The client displays
these assets together in a listing that is viewable by the
subscriber.
The search subsystem periodically requests media descriptions from the MDWSPrivate Web
service (in Media Discovery Subsystem (p. 095)), and caches a local copy of the media
description in memory. The process enables the search subsystem to quickly perform searches
and return sorted lists of media descriptions when they are requested.
Because the search subsystem communicates directly with Microsoft Mediaroom clients, it is
typically deployed on a Client Gateway machine.
For more information on using the Microsoft Mediaroom client search feature, see
Subscriber’s Guide in the Microsoft Mediaroom Client documentation set.

server11sp32-27feb09-2009-0227-1757
Page 133
See Also
Asset Store Subsystem (p. 088)
Listings Subsystem (p. 090)
Service Information Subsystem (p. 098)

server11sp32-27feb09-2009-0227-1757
Page 134
Logging Subsystem
The logging subsystem manages various events within the Microsoft® Mediaroom servers and
Microsoft Mediaroom clients. These events cause the affected software components to
generate messages and send them to the logging subsystem for processing and storage. The
following types of events are logged by the Microsoft Mediaroom logging subsystem:
• Diagnostics. A set-top box sends diagnostics information.
• Subscriber activity events. A subscriber performs an activity on the client that is
being tracked, such as a channel change.
• System events. An error is detected on a Microsoft Mediaroom server or client; for
example, a service has stopped.
• Performance counters. Performance metrics are measured and reported.
• Audit events. Events are received that track changes made from the TV Services
Management tool or OSS/BSS APIs.
Components of the logging subsystem are installed on all Microsoft Mediaroom server
machines. These components route events to different storage entities based on a set of
routing rules, configured in the logconfig.xml file. Routing rules are based, in part, on the
type of event to be logged.
Depending on the type of event, the routing destination may be:
• A local Windows® Events Log.
• A local text file.
• A centralized SQL database.
• A remote debug console.
• A centralized Microsoft Operations Manager (MOM) console.
Diagnostics
Client diagnostics information such as crash logs enable service providers to determine the
cause of set-top box failures.
Subscriber Activity Events

Subscriber activity events enable service providers to gain a better understanding of the
services and features that subscribers are using on the Microsoft Mediaroom client. Service
providers can use this information to improve customer marketing campaigns, advertising
sales, and relationships with networks.

server11sp32-27feb09-2009-0227-1757
Page 135
Activity Log Information Flow
The following figure describes the flow for logging subscriber activity events in the Microsoft
Mediaroom system.
1) As subscribers perform prescribed tasks on the client, the client automatically logs an
event containing details about the task in its local activity logging cache.
2) When the client accumulates 500 events, it uploads the content to the logging
framework on the Microsoft Mediaroom server.
3) The logging framework stores the subscriber activity events in the subscriber activity
SQL database.
4) Service providers can use the SQL Reporting engine or third-party applications, such
as Crystal Reports, to generate subscriber activity reports.
Subscriber activity event logs are specific to each service group. Each service group has its
own subscriber activity event logging database that contains only events from clients serviced
by that branch.
Logged Subscriber Activities

Microsoft Mediaroom client creates a logging event when the subscriber:
• Tunes the set-top box to a new channel.
Note By default the set-top box must remain tuned to the channel for more than 20
seconds for an event to be logged. This value is configurable.
• Turns the set-top box on or off.
• Selects an item from any menu.
• Purchases a VOD asset.
• Purchases an RDP application.

server11sp32-27feb09-2009-0227-1757
Page 136
• Purchases a PPV event.
• Launches or closes the browse panel.
• Launches an RDP application.
• Disconnects from a launched RDP application.
• Navigates away from a launched RDP application.
• Transitions to a new trick state, such as fast-forward, play, or rewind.
• Runs a client-resident application, such as the menu or the program guide.
After the subscriber activity event log data is uploaded, operators can run reports, analyze the
data, and use the information to help plan and deploy additional services.
For more information on the contents of individual subscriber activity events, see Operations
Guide.
System Events
All Microsoft Mediaroom software servers use the logging subsystem to report system events.
System events flag errors, warn of potential problems, or provide notification of processes
that have taken place. Service providers can use system event information to tune system
maintenance and to troubleshoot problems.
Event Information
System events contain the follow types of information:
• Event name. Fully qualified class name and class namespace that generated the
event.
• Event ID. Unique number that identifies the event. Use this information to locate
event cause and corrective actions in Microsoft Mediaroom documentation.
• Event severity.
• Critical error. A critical system problem that prevents the Microsoft
Mediaroom system from functioning.
• Error. A significant problem, such as loss of data or loss of functionality. You
should not see any error message events under normal operating conditions. The
error level captures exceptions such as out-of-memory errors and errors returned
from a system call. An Error event indicates that the application or service
cannot continue processing the current request.
• Warning. An event that is not necessarily significant, but might indicate
potential future problems. You should not see any warning message events under
normal operating conditions. For example, when disk space is low, a Warning
event might be logged.

server11sp32-27feb09-2009-0227-1757
Page 137
• Information. An event that describes the successful operation of an application,
driver, or service. For example, when a network driver loads successfully, an
Information event is logged.
• Debug. An event that assists Microsoft support personnel in the debugging of
the code execution path on development workstations. These events are
suppressed in a Production environment.
• Universal date and time that the event occurred.
• Computer on which the event occurred.
• Application domain. .NET application domain of the component that generated the
event.
• Exception details. Exception type, exception message, stack trace, and other low-
level details about the event.
• Process Id. PID of the process that generated the event.
• Thread Id. ID of the thread that generated the event.
Event Storms
During an “event storm” the logging subsystem accumulates and consolidates similar system
events and posts a single event with a counter that reflects the number of times it received the
particular event. This process is called Event Storm Detection and Consolidation (ESDC).
ESDC occurs when the logging subsystem receives more than 400 events per second and it
has more than 1000 outstanding events to process. These thresholds are configurable and
ESDC can be turned off.
Service providers can customize which event stores they maintain in their system. They can
also define which events or event groups are sent to each event store. For details on
configuring the logging framework, see Operations Guide.
Performance Counters
As Microsoft Mediaroom operates over time, the values of the various counters begin to show
a pattern. Routine monitoring over periods ranging from days to months enables operators to
establish a baseline for system performance. The baseline is an indicator of how individual
system resources or groups of resources are used during periods of normal activity.
When determining a baseline, it is important to know the types of work being done and the
days and times when the work is being done. That information helps you to associate work
with resource usage and to determine the reasonableness of performance during those
intervals.
When operators acquire sufficient performance data reflecting periods of low, average, and
peak usage, they can make a subjective determination of what constitutes acceptable

server11sp32-27feb09-2009-0227-1757
Page 138
performance for the system. That determination is the baseline. Operators use the baseline to
detect when bottlenecks are developing or to watch for long-term changes in usage patterns
that require an increase in capacity.
The Microsoft Mediaroom system defines the performance data it collects in terms of objects,
counters, and instances. A performance object is any resource, application, or service that can
be measured. Using MOM, operators can select performance objects, counters, and instances
to collect and present data about the performance of system components or installed software.
Each object has performance counters that are used to measure various aspects of
performance, such as transfer rates for disks or, for processors, the amount of processor time
consumed. The object may also have an instance, which is a unique copy of a particular
object type; not all object types support multiple instances.
Specific performance counter numbers are not generally important. What matters is that the
continual performance is in an acceptable range. Typically, acceptable performance counter
ranges differ for each installation and are driven by factors such as:
• Number of set-top boxes supported.
• Number of services offered.
• Available bandwidth.
Audit Events
Audit events are useful to service providers in determining who has accessed the system and
for what purpose.
Logging Subsystem Software Components and

Data Flow
The following diagram illustrates how the logging subsystem components are distributed
across the Microsoft Mediaroom system.

server11sp32-27feb09-2009-0227-1757
Page 139
The following table describes each of the software components in the logging subsystem.
Client logger Handles events raised by Microsoft Mediaroom clients in response to

Web service subscriber activities and passes all events to the local log engine. The
client logger Web service typically resides on the Client Gateway
machine.
Logger Writes the events it receives from server software components to the
local event queue and then calls the log engine.

server11sp32-27feb09-2009-0227-1757
Page 140
Log engine Routes events into various sinks based on the information in the
logging configuration file.
Event Log sink Directs logging events to the local Windows Events log.
Trace sink Directs logging events from the log engine to TraceSink.Log, the
local, text-based, trace log file. This log “rolls over” when it reaches a
maximum size or at a specific interval (hourly/daily/monthly) as
defined in the configuration file. When rollover occurs, the current
TraceSink.Log file overwrites the history log file Tracesink.old.log
and an empty TraceSink.Log is created.
SQL sink Directs logging events to the log data Web service. The SQL sink bulk
inserts events based on an internal non-configurable timer. The timer
duration is based on heuristics such as the number of outstanding
events. This metric ensures that the timer does not “sleep” for too long
and it has a reasonable number of events to process at one time.
Debug sink Directs logging events to a debug console if one exists. You can set
the verbosity of the debug information and the port to route the debug
events in the logging configuration file.
Client Directs client diagnostic events to an external client diagnostics event

diagnostic sink agent Web service.
event sink Note Microsoft Mediaroom does not include an implementation of
the client diagnostics event sink agent Web service. Service providers
must use a Web service that implements the client diagnostics event
sink agent Web service API. For details on the client diagnostics event
sink agent Web service API, see OSS Web Service Reference in the
Microsoft TV Microsoft Mediaroom OSS/BSS Integration
documentation set.
logdata Web Receives log dumps from the SQL sink and writes them to the
service centralized subscriber activity log database and event log databases.
Subscriber Contains subscriber activity events such as channel changes, trick

activity log mode access, and application starts. Subscriber activity logs help
database service providers understand subscriber viewing patterns and usage.
Service providers can generate custom reports with reporting tools
such as SQL Reporting Services and Crystal Reports.
This database contains the subscriber activity logs from all Microsoft

server11sp32-27feb09-2009-0227-1757
Page 141
Mediaroom clients, which can become very large. Periodically,

operators must move the data from this database to an activity log
history database or prune the data tables.
The activity log database is partitioned into 24 tables with 1 master
view. The 24 tables represent the 24 hours in a day. Operators can
truncate or move records without affecting continuous logging. New
events continue to be logged while a section of the database is locked
for maintenance.
Event database Contains the server events. Events can be either informational, such as
letting an operator know that a process successfully completed, or an
alert regarding an error condition. Error events have severities of
warning, error, and critical error.
This database contains the events generated by the entire Microsoft
Mediaroom system (central repository).
Recycler job Trims respective database tables if they grow beyond a configurable
maximum size. By default, this SQL job is scheduled to run every
hour.
Activity log Contains historical subscriber activity logs.

history
database
See Also

server11sp32-27feb09-2009-0227-1757
Page 142
Client Management Subsystem
The client management subsystem facilitates the updating and provisioning of the Microsoft®
Mediaroom client software on set-top boxes. Through this subsystem, set-top boxes in the
field can be automatically updated with the latest client software.
Client Management Subsystem Software

The following diagram shows the software components of the client management subsystem
for devices that run a release prior to Microsoft Mediaroom Client 1.6.2 (1.6.2).

server11sp32-27feb09-2009-0227-1757
Page 143
The following diagrams show the software components of the client management subsystem
for 1.6.2 or later clients. The first diagram illustrates the bootstrap process:
The following diagram shows the DRA process:

server11sp32-27feb09-2009-0227-1757
Page 144
The following diagram illustrates the upgrade process:
The following table describes the software components of the client management subsystems.
Componen Description
t
bootstrap The first service that all Microsoft Mediaroom clients encounter when they go
Web through their startup sequence.
Service The bootstrap Web service authenticates the Microsoft Mediaroom client and
logs it on to the Microsoft Mediaroom system. It then contacts subscriber
management subsystem (SMS) to determine the subscriber’s level of service,
and returns a list of URLs for Web services (terminal service monitor, client
upgrade, and so on) from which the client acquires configuration data. For
more information on bootstrap Web service, see Bootstrap Web Service (p.
101). For more information on SMS, see Subscriber Management Subsystem
(p. 105).

server11sp32-27feb09-2009-0227-1757
Page 145
t
upgradeWS When a client is authenticated— at startup or when the session key expires—
Web the client sends its current software version to the bootstrap Web service. If
service the client software version does not match the resolved software version for
the device, the bootstrap Web service returns an upgrade message that
contains the URL of the upgradeWS Web service.
For devices that run a Microsoft Mediaroom Client release prior to 1.6.2, the
upgradeWS Web service downloads the stored client software to devices that
require upgraded software.
For devices that run Microsoft Mediaroom Client 1.6.2 or later, the
upgradeWS Web service constructs a download link to send to the client.
(The URL for this link is constructed with information about the OEM ID
obtained from the client certificate, the model ID that the client reported, and
the device software version that was resolved from the ServiceGroupDB
database.) The URL that is returned to the client points to the machine that
hosts the clientUpgradeFiles role from which the requesting client can
download the appropriate client image. The URL is in the following format:
http://<clientUpgradeFiles>/<OEMid>/<modelID>/Application_<version>.da
t
where clientUpgradeFiles is the address of the machine and
<OEMid>/<modelID>/Application_<version>.dat is the path and upgrade file
for the client to download.
For more information, see Client Upgrade (p. 180).
Sync The Sync Discovery Service Windows service provides clients with a
Discovery Disaster Recovery Application (p. 103) (DRA) that they can run at startup
Service when they are recovering from a failure. For more information on the Sync
Windows Discovery Service Windows service, see Sync Discovery Service Windows
service Service (p. 103).

server11sp32-27feb09-2009-0227-1757
Page 146
t
Sync and The “Sync Server” portion of the Sync Discovery Service Windows Service
Discovery provides a client with the Disaster Recovery Application (DRA) when the
Server client cannot boot normally, or when the client has no software at all, such as
when a new client is first connected. If a client cannot bootstrap and contact
the Microsoft Mediaroom server machine that contains the client upgrade
files, the client is diverted to the Sync and Discovery Server to obtain the
DRA.
The “Discovery Server” portion of the Sync Discovery Service Windows
service provides a client with the location of resources that it can contact
during regular start-up, or to recover from software failure, should it occur.
Client- The Client-Facing Service Group machine hosts the upgradeWS Web service
Facing and the upgrade files for clients that run a Microsoft Mediaroom Client
Service release prior to 1.6.2.
Group
IIS Cluster The IIS cluster, or another machine that hosts the clientUpgradeFiles role,
downloads the stored client software to 1.6.2 or later set-top boxes that
require upgraded software. Only the files for a particular version that need
updating are sent to replace the old versions on the set-top box.
When a client is authenticated— at startup or when the session key expires—
the client sends its current software version to the bootstrap Web service. If
the client software version does not match the resolved software version for
the device, the bootstrap Web service returns an upgrade message that
contains the URL of the IIS cluster machine with the clientUpgradeFiles role
that has the upgrade files the set-top box needs. For more information about
client upgrades, see Upgrading Devices (p. 582) in Operations Guide.

server11sp32-27feb09-2009-0227-1757
Page 147
NTP Server
The Microsoft® Mediaroom system uses Network Time Protocols (NTP) to synchronize time
between clients and servers as well as between servers. By using NTP, senders and receivers
can establish a correct and consistent interpretation of timestamps.
Microsoft Mediaroom clients use an NTP time source. Microsoft Mediaroom servers, which
are based on the Windows infrastructure, synchronize with the Windows Time service. The
Windows Time service also uses NTP to synchronize computer clocks on the network so that
an accurate clock value, or timestamp, can be assigned to network validation and resource
access requests.
Note The NTP source should exclude leap seconds to reduce the risk of platform problems
that could result from their insertion.
Unlike analog broadcast systems, where display time synchronization is inherent in the signal
itself, compressed video systems receive frames for display at different time offsets relative to
one another, and possibly out of order. Each frame is typically labeled with a “presentation
time,” which indicates when the frame is to be displayed. Because no two clocks progress at
exactly the same rate, compressed video systems must have a means of coordinating clocks
between the source and sink of the audio/video (A/V) information; otherwise the receiver
would play back at its own data rate. Significant differences in data rates can lead to frame
repeats or drops, and eventually to under running or overflowing the network reception buffer
from the source.
In a traditional broadcast system, clients and servers cannot synchronize time except to rely
on:
• Time information that is in the stream.
• Characteristics of the broadcast channel, such as fixed delays and fixed transport bit
rates.
Traditional MPEG transport systems handle time synchronization by assuming a constant
network delay (that is, it takes the same amount of time for each packet leaving an encoder to
arrive at a decoder). The MPEG transport defines a program clock reference (PCR), which is
basically a number carried in the stream that says “when you receive the last bit of this
number, the exact time is the value encoded by that number.” This time synchronization
method works well for systems such as satellite and coaxial broadcast, where the variance in
network delay is insignificant.

server11sp32-27feb09-2009-0227-1757
Page 148
The Microsoft Mediaroom transport does not have a constant channel delay, both because of
the nature of IP transport and because of the instant channel change (ICC) burst from the
Distribution Server (DServer).
Given that the Microsoft Mediaroom environment has two distinct time sources, NTP and the
Windows Time service, and that both are required, it is necessary for the forest root-level
domain controller to synchronize with an authoritative time source that is external to the
Windows infrastructure. This is important because various elements of the Microsoft
Mediaroom infrastructure are time dependent, thus requiring that the Microsoft Mediaroom
external time source and the Windows domain time source to remain synchronized for
sustained operation of the Microsoft Mediaroom system.
Maintaining A/V Timing

Timestamps are used to deliver A/V samples at the correct time as well as for set-top box
buffer management. In the Microsoft Mediaroom system, the timestamps associated with
audio and video samples are tied to NTP using correspondences in the Real-Time Protocol
(RTP) transport.
It is critical that the slope of change in time is low so that the Acquisition Server and set-top
box time do not drift apart. A drift in time can cause an A/V buffer underflow or overflow in
the set-top box.
Because the Microsoft Mediaroom system leverages the NTP server for clock reconstruction
between the Acquisition Server and client, the networking connection between the encoder
and Acquisition Server must have very low jitter. This minimizes the clock drift and enables
the Acquisition Server to inherently trust the PCR information emanating from the real-time
encoder.
When the Acquisition Server receives the PCR information from the real-time encoder, it
inserts a “correspondence” into the RTP stream. This correspondence associates a PCR
representing the real-time encoder time with an NTP timestamp from the NTP server system.
This association enables clock recovery to occur on the client.
Acquisition Servers and clients poll the NTP server once every five seconds for
approximately two minutes, and thereafter begin polling once every 64 seconds.

server11sp32-27feb09-2009-0227-1757
Page 149
Client Authentication and Rights Interpretation
Each Microsoft Mediaroom client is authenticated using certificates. For the certificate-based
client authentication to work properly, client and authentication servers must be time-
synchronized.
Additionally, the subscriber management subsystem (SMS) maintains the records of rights
and purchases for each subscriber account. For the rights management functionality to work
and for the client to have the appropriate keys to decrypt A/V content without interruption,
the branch servers and clients must be time-synchronized.
Server Authentication
Microsoft Mediaroom servers use integrated Windows authentication. This authentication
method relies on NTP to provide an accurate understanding of time between servers.
Windows Server 2003 implements an NTP stack to establish and maintain correct time within
a forest.
NTP Server Categories

NTP servers are usually categorized in terms of strata, where a lower stratum signifies a level
closer to the root of the hierarchy and typically higher time accuracy. A stratum 1 server
typically gets its time directly from an attached atomic clock or GPS receiver. A stratum 2
server gets its time from the stratum 1 server, and so on. Microsoft TV recommends the usage
of stratum 1 servers dedicated to the Microsoft Mediaroom deployment.
NTP Architecture
NTP is typically deployed in one of three different architectures:
• Star
• Peer-to-Peer
• Hierarchical
Microsoft recommends that NTP servers be deployed in a hierarchical fashion for reliability,
stability, and scalability.

server11sp32-27feb09-2009-0227-1757
Page 150
TV Services Management Tool
Microsoft® Mediaroom operators use the TV Services Management tool to configure and
administer all Microsoft Mediaroom server components and services. The TV Services
Management tool provides centralized management regardless of the geographical location of
individual server machines and components.
The TV Services Management tool is a Web application delivered by an Internet Information
Services (IIS) server and hosted by Microsoft Internet Explorer. The IIS server handles
management actions by interacting with the Web service interfaces of the Microsoft
Mediaroom servers. This configuration enables Microsoft Mediaroom operators to configure
multiple Microsoft Mediaroom servers in a simple, coordinated manner. For example, when
an operator adds a live video service, the TV Services Management tool updates the databases
for the related subsystems. Separate configuration and synchronization are unnecessary.
For information about starting and operating the TV Services Management tool, see
Operations Guide and TV Services Management Tool Reference.
TV Services Management Tool Pages and

Associated Tasks
You use the pages of the TV Services Management tool on the Live Backend Management
machine as follows to create Microsoft Mediaroom services.
TV Services Configuration tasks

Management tool page
Quick Search Search tool that is used to find clusters, servers, processes, or
services managed by the Live Backend Management machine.
Dashboard Display the current status of the clusters, servers, processes, or

services managed by the Live Backend Management machine.
Clusters Create a logical grouping of the Acquisition Servers that are

managed by the Live Backend Management machine.
Servers Add and manage Acquisition Servers to host live TV and music
services.
Processes Add and manage processes containing one or more ongoing

server11sp32-27feb09-2009-0227-1757
Page 151
tasks that must be performed by the same Acquisition Server
Services Add and manage live TV and music services.
You use the pages of the TV Services Management tool on the Branch Management machine
as follows to manage Microsoft Mediaroom.

Live Management Deploy live TV services from the Branch Management

machine.
Channel Map Manage service collections, channel maps, packages, offers,

and grants, and deploy channel maps to subscriber groups.
Modify validation rules and media profiles for VOD assets and
VOD Management
import and deploy the assets to the Microsoft Mediaroom
system.
Applications Add a new RDP application or URL service to the Microsoft

Mediaroom system and modify or delete an existing RDP
application.
Manage subscriber accounts, devices, and groups. You can
Subscriber Management
either use the Subscriber Management pages to manage
Microsoft Mediaroom subscriber information, or you can use
another account management tool that integrates Microsoft
Mediaroom with your business systems.
If you use the Subscriber Management pages to manage
subscriber information, you must configure a subscriber
account for each household that accesses Microsoft Mediaroom
services. You must associate at least one set-top box (device)
with each account.
Subscriber groups enable you to categorize subscribers with
common functional and access rights into a single set and
manage the group instead of individual subscribers. A
subscriber can be associated with more than one subscriber
group; however, only one of the subscriber groups assigned to a
subscriber account should have an assigned channel map.

server11sp32-27feb09-2009-0227-1757
Page 152
Configure Pay Per View (PPV) assets and add new PPV
PPV Management
service collections.
Manage the TimeShift Recording Servers and enable services
TimeShift
for Restart Anytime.
Note This link is available after you install Microsoft
Mediaroom Server 1.1 SP3.2 CP2.
Create and manage new digital terrestrial television (DTT)
DTT Management
services.
Live to VOD Configure and manage recording live TV streams that are
converted to VOD assets for deployment through the VOD
subsystem.
Settings Configure parental control, RDP applications, subscriber

activity logging, and various other settings for Microsoft
Mediaroom servers and clients .
See Also
Multiple and Simultaneous Interactions with TV Services Management Tool (p. 153)
Multiple and Simultaneous Interactions with TV

Services Management Tool
When users attempt to modify the same data at the same time, one user’s modifications have
the potential to adversely affect modifications from simultaneous users. A concurrency
control system is necessary to handle this situation.
There are different models for concurrency control. The TV Services Management tool
follows the last-in-wins model to manage concurrency. In this model, additions and changes
that are being written to the database are unavailable to users only while the database is
updated. No effort is made to compare updates against the original record. When you save
your updated information, the record is simply written out, potentially overwriting any
changes made by other users since you last refreshed the records. For example, if several
customer service representatives (CSRs) are updating subscriber records and two of them are
working on the same record, the information is updated based on the changes made by the last
person who saved the data.

server11sp32-27feb09-2009-0227-1757
Page 153
With a last-in-wins model, no check of the original data is made, and the update is simply
written to the database. It is understood that the following scenario can occur:
1) User A fetches a record from the database.

2) User B fetches the same record from the database, modifies it, and writes the updated
record back to the database.
3) User A modifies the “old” record and writes it back to the database.
In the preceding scenario, User A never sees the changes that User B made, and the database
does not reflect the change made by User B.

server11sp32-27feb09-2009-0227-1757
Page 154
OSS Web Services
The operations support systems (OSS) Web services enable the TV Services Management
tool and other OSS systems to manage the acquisition and delivery of live TV, VOD, and
RDP application services.
The following table provides brief descriptions of and links to more information about each
OSS Web service.
Web Service Description
Backend Blackout Management Web Enables OSS systems to manage service

Service (p. 157) (ossBackendBlackout) substitutions, also known as “blackouts,” at the
backend.
Blackout Management Web Service (p. Enables OSS systems to manage service
157) (ossBranchBlackout) substitutions, also known as “blackouts," at the
branch.
Branch Management Web Service (p. Enables applications to manage the

158) (ossbranch) configuration of service groups at a branch. For
details on service groups, see Service Group
Subsystem (p. 109).
Channel Management Web Service (p. Enables OSS systems to manage channel maps
158) (osschannel) and media descriptions, and to assign channel
maps to subscriber groups.
Content Distribution Web Service (p. Enables client applications to configure and
159) (ossContentDistributionWS) monitor the VOD content distribution system.
Client Configuration Web Service (p. Enables service providers to target the software
159) (upgrade) upgrades of Microsoft Mediaroom clients.
Diagnostics Notification Web Service Enables OSS systems to send requests for
(p. 159) (Diagnostics) diagnostics information through the notification
subsystem to all Microsoft Mediaroom clients
that are associated with a specific account.
Emergency Alert System Web Service Enables service providers to send alert
(p. 161) (EAS) messages to subscriber set-top boxes,
interrupting whatever programming the

server11sp32-27feb09-2009-0227-1757
Page 155
subscribers may be watching.
EPG Web Service (p. 161) (ossepg) Enables Web clients to fetch information about
the program schedule.
Fingerprint Web Service (p. 161) Enables the service provider to place a
(fingerprint) "fingerprint" on live video services to identify
the source of pirated content.
High-Priority Notification Web Service Enables service providers to send short, time-
(p. 161) sensitive messages to subscribers.
(ossHighPriorityNotificationWS)
Live Anytime Web Service (p. 162) Enables service providers to write custom
(ossLiveToVod) applications that monitor and configure the
Live Anytime subsystem.
Live Deployment Web Service (p. 162) Enables operators to assign and reassign live
(ossLiveDeploymentWS) services to clusters in a branch.
PPV Management Web Service (p. Enables OSS systems to manage the
163) (ossppv) deployment of PPV assets.
Remote Recording Web Service (p. Enables Web clients to remotely schedule
163) (ossremoterecord) recordings and modify previously scheduled
recordings.
Restart Anytime Web Service (p. 164) Enables operators to manage time-shifted
(ossTimeShift) offerings.
Service Substitution Web Service (p. Enables service providers to schedule service
164) (ossServiceSubstitution) substitution ("blackout") events.
UI Notification Web Service (p. 164) Enables OSS systems to deliver through the
(UI) notification subsystem short messages that
appear on the screens of Microsoft Mediaroom
clients.
URL Management Web Service (p. Enables service providers to create and modify
165) (ossurl) special services based on Browser applications
and Web content.
VOD Backend Management Web Service Enables the TV Services Management tool and
(p. 166) (ossVodBackendWS) other operations support systems (OSS) to

server11sp32-27feb09-2009-0227-1757
Page 156
manage VOD asset importation at VOD

backends.
VOD Branch Management Web Service Enables the TV Services Management tool and
(p. 166) (ossVodBranchWS) other operations support systems (OSS) to
manage VOD asset deployment at VOD
branches.
Backend Blackout Management Web Service

The backend blackout management Web service (ossBackendBlackout) enables OSS systems
to manage service substitutions at the backend. (Service substitutions are also known as
“blackouts.”) This Web service is mostly superseded by the service substitution Web service
(ossServiceSubstitution) as of release 1.1 SP3.1, but it still provides some functionality.
Note A number of different Web services must be used in concert to create and manage
substitution events. For details on the backend blackout management Web service API, see
"Real-Time Service Substitution" in OSS/BSS Integration Guide in the Microsoft®
Mediaroom OSS/BSS Integration documentation set.
Blackout Management Web Service

The blackout management Web service (ossBranchBlackout) enables OSS systems to manage
virtual channels for service substitution events. (Service substitutions are also known as
“blackouts.”) In previous releases, this Web service provided more functionality related to
service substitutions; however, as of release 1.1 SP3.0, this functionality has been superseded
by the service substitution Web service.
substitution events. For details on the backend blackout management Web service API, see
"Real-Time Service Substitution" in OSS/BSS Integration Guide in the Microsoft Mediaroom
OSS/BSS Integration documentation set.

server11sp32-27feb09-2009-0227-1757
Page 157
Branch Management Web Service
The branch management Web service (ossbranch) enables applications to manage the
configuration of service groups at a branch.
Note Service groups can only be created through the server layout on the branch (see
Configuring the Server Layout Files (p. 089) in Installation and Configuration Guide). The
branch management Web service supports only reading existing service groups and assigning
an existing service group to use as the default service group for new accounts.
For more details on managing and migrating service groups, see Managing Service Groups
(p. 032) in Operations Guide. For more information about the branch management Web
service, see “Branch Management Web Service” in OSS Web Service Reference (Microsoft
Mediaroom OSS/BSS Integration documentation set).
Channel Management Web Service

The channel management Web service (osschannel) enables OSS systems to manage channel
maps and media descriptions, and to assign channel maps to subscriber groups.
The following diagram shows how the channel management Web service interacts with other

server11sp32-27feb09-2009-0227-1757
Page 158
Content Distribution Web Service
The content distribution Web service (ossContentDistributionWS) enables client applications
to configure and monitor the VOD content distribution system. Using this Web service, client
applications developed by service providers can fetch information about content distribution
servers, receivers, tasks, and addresses. Client applications can also use this method to
remotely schedule content distribution tasks.
For more information about content distribution, see “Content Distribution Web Service” in
the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation
set).
Client Configuration Web Service

The Client Configuration Web service (upgrade) enables you to start and stop mass upgrades
of multiple set-top boxes. This Web service operates first in conjunction with the Principal
Management Web Service (p. 171) to determine which boxes need to be upgraded, and
then upgrades the set-top boxes during a time window determined by the service provider.
With the Client Configuration Web service, the following targeted software upgrades can be
made, at the service provider's discretion:
• To a single device.
• To all the devices or accounts in a special upgrade group.
• To all the devices in a service group.
• To all the devices in a branch.
The ability to specify which devices or group of devices receive an upgrade enables the
service provider to maintain a version hierarchy of client software.
For more information about client configuration, see “Client Configuration Web Service” in
the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation
set).
Diagnostics Notification Web Service

The diagnostics notification Web service (Diagnostics) enables OSS systems to send requests
for diagnostics information through the notification subsystem to all Microsoft Mediaroom
clients associated with a specific group or subscriber account. The notification subsystem
delivers the request messages to the Microsoft Mediaroom clients over UDP/IP. The

server11sp32-27feb09-2009-0227-1757
Page 159
Microsoft Mediaroom clients respond to the request by uploading diagnostic information to
the logging subsystem. The logging system can then upload the client diagnostics to a custom
client diagnostics event sink Web service.
The following diagram shows how the diagnostics notification Web service interacts with
other Microsoft Mediaroom software components.
See Also
Notification Subsystem (p. 116)
Logging Subsystem (p. 135)

server11sp32-27feb09-2009-0227-1757
Page 160
Emergency Alert System Web Service
The emergency alert system (EAS) Web service (osseas) enables service providers to send
alert messages to subscriber set-top boxes, interrupting any programming that subscribers are
watching.
For more information about the EAS, see “Emergency Alert System Web Service” in the OSS
Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set).
EPG Web Service

The EPG Web service (ossepg) enables Web clients to fetch information about a service's
program schedule. This information can be useful when scheduling recordings with the
Remote Recording Web Service (p. 163).
For more information about the EPG Web service, see “EPG Web Service” in the OSS Web
Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set).
Fingerprint Web Service

The fingerprint Web service (fingerprint) enables service providers to add a visible identifier,
or “fingerprint,” to live video services in a location specified by the service provider. The
fingerprint is a short text string that identifies the specific set-top box that is displaying the
video service. If the content is copied and distributed, the fingerprint can be used to identify
the subscriber who copied it.
Fingerprints are turned on and off on a per-service basis. If fingerprinting is enabled for a
service, every set-top box tuned to that service will periodically display the set-top box's
MAC ID code. The service provider can control how often and where on the screen the ID
code is displayed. The service provider can also choose whether to display the fingerprint for
one or more seconds, or just for a single frame.
For more information about fingerprints, see “Fingerprint Web Service” in the OSS Web
Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation set).
High-Priority Notification Web Service

The high-priority notification Web service (ossHighPriorityNotificationWS) enables service
providers to send short, time-sensitive messages to subscribers. This Web service prioritizes

server11sp32-27feb09-2009-0227-1757
Page 161
speed over reliability; if necessary, the Web service discards a message rather than deliver it
after a long delay. This contrasts with the UI notification Web service, which prioritizes
reliability and flexibility over speed of delivery.
For more information about high-priority notifications, see “High Priority Notification Web
Service” in the OSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration
documentation set).
Live Anytime Web Service

The Live Anytime Web service (ossLiveToVod) enables service providers to write custom
applications that monitor and configure the Live Anytime subsystem. The Live to VOD
subsystem automatically generates and deploys VOD assets from the programming on live
service groups.
The following diagram shows how the Live Anytime Web service interacts with other
Live Deployment Web Service

The live deployment Web service (ossLiveDeploymentWS) enables operators to assign or
reassign live services to clusters in a branch.

server11sp32-27feb09-2009-0227-1757
Page 162
When live services are added, moved, or removed in a cluster, the live deployment Web
service does not immediately cause those changes to "go live." Instead, the Web service keeps
track of all pending changes until the operator commits the changes.
PPV Management Web Service

The PPV management Web service (ossppv) enables OSS systems to manage the deployment
of PPV assets.
The following diagram shows how the PPV management Web service interacts with other
Remote Recording Web Service

The remote recording Web service (ossremoterecord) enables Web clients to remotely
schedule recordings, as well as view and manage previously-scheduled recordings, for a
particular set-top box. It interacts with the DVR scheduler subsystem, which in turn interacts
with the listings subsystem and with individual set-top boxes.

server11sp32-27feb09-2009-0227-1757
Page 163
See Also
EPG Web Service (p. 161)
Restart Anytime Web Service

The Restart Anytime Web service (ossTimeShift) enables operators to manage time-shifted
offerings. Using the Restart Anytime feature (also known as "timeshift"), service providers
can configure certain live services to be available for delayed play; a subscriber can watch the
time-shifted service at any time during an operator-configurable window.
Restart Anytime content is provided to subscribers by TimeShift Recording Servers. These
servers are grouped into clusters. When creating a Restart Anytime service based on a live
service, the service provider assigns the Restart Anytime service to one or more clusters and
specifies how many servers within the cluster should provide the time-shifted service. An
operator either designates a target number of servers to handle the service, which enables
Microsoft Mediaroom server software to distribute the service to appropriate servers
automatically (automatic assignment), or designates specific servers in the cluster to handle
the service (manual assignment).
Service Substitution Web Service

The service substitution Web service (ossServiceSubstitution) enables service providers to
schedule service substitution ("blackout") events. It is used in conjunction with the blackout
management Web service (ossBranchBlackout) and the principal management Web service
(BSS2).
substitution events. For details on how the various Web services are used, see "Real-Time
Service Substitution" in OSS/BSS Integration Guide in the Microsoft Mediaroom OSS/BSS
Integration documentation set.
UI Notification Web Service

The UI notification Web service (UI) enables OSS systems to deliver short messages that
appear on the screens of Microsoft Mediaroom clients through the notification subsystem.
Applications contact the UI notification Web service to schedule messages for delivery to
specific clients or for broadcast to all clients. The notification subsystem delivers the

server11sp32-27feb09-2009-0227-1757
Page 164
messages to Microsoft Mediaroom clients over UDP/IP. The Microsoft Mediaroom clients
display the messages on screen until the messages expire or until the subscriber dismisses
them.
The following diagram shows how the UI notification Web service interacts with other
Note If a message is larger than 2 KB, the UI notification Web service throws an exception.
See Also
Notification Subsystem (p. 116)
URL Management Web Service

The URL management Web service (ossurl) enables service providers to create and modify
special services based on Web content or “multi-view” (services that display several video
feeds at one time).

server11sp32-27feb09-2009-0227-1757
Page 165
VOD Backend Management Web Service
The VOD backend management Web service (ossVodBackendWS) enables the TV Services
Management tool and other operations support systems (OSS) to manage VOD asset
importation at VOD backends.
The following diagram shows how the VOD backend management Web service interacts with
VOD Branch Management Web Service

The VOD branch management Web service (ossVodBranchWS) enables the TV Services
Management tool and other operations support systems (OSS) to manage VOD asset
deployment at VOD branches.
The following diagram shows how the VOD branch management Web service interacts with

server11sp32-27feb09-2009-0227-1757
Page 166
server11sp32-27feb09-2009-0227-1757
Page 167
BSS Web Services
The business support systems (BSS) Web services enable BSS systems to manage the
acquisition and delivery of live TV, VOD, and RDP application services.
Billing Record Management Web Service Manages billing records in the subscriber
(p. 169) management subsystem (SMS).
Important This is a legacy Web service,
provided for backward compatibility. At
some point in the future, this Web service
may be removed. For future development,
you should use the Reporting Store Web
Service (p. 171).
Grant Management Web Service (p. Manages the activities (play, pause, record)
169) (GrantManagement) enabled on resources, such as live TV services,
VOD assets, and RDP applications.
Offer Management Web Service (p. Manages the details of offers (price, tax, and
170) (OfferManagement) expiration) associated with live TV services,
VOD assets, and RDP applications.
Package Management Web Service (p. Manages packages, which can contain either a
170) (PackageManagement) set of services or a set of other packages.
Principal Management Web Service (p. Manages Microsoft Mediaroom principals

171) (PrincipalManagement) (devices, subscribers, accounts, and subscriber
groups).
Reporting Store Web Service (p. 171) Enables applications to access billing records
(reportingstore) associated with subscribers in all service
groups.

server11sp32-27feb09-2009-0227-1757
Page 168
Note Microsoft Mediaroom includes legacy versions of BSS Web services for backward
compatibility with previous releases. The legacy Web services are deployed in different
virtual directories than the one in which they were originally deployed. For example, the
legacy version of the billing record management Web service has the following new
endpoint: http://servername/bss/legacy/1.0.1/BillingRecordManagement.asmx, whereas the
current version uses the following endpoint:
http://servername/reportingstore/BillingRecordManagement.asmx.
Billing Record Management Web Service

Important This is a legacy Web service, provided for backward compatibility. At some
point in the future, this Web service may be removed. For future development, you should use
the Reporting Store Web Service (p. 171).
The billing record management Web service provides an API through which BSS systems
manage billing records in the SMS. For example, custom applications can enable customer
service representatives (CSRs) to view or delete billing records.
The following diagram shows how the billing record management Web service interacts with
Grant Management Web Service

The grant management Web service (GrantManagement) enables BSS systems to manage the
activities (purchase and play) enabled on resources, such as live TV services, VOD assets,
and RDP applications. Grants are maintained in the SMS.
The following diagram shows how the grant management Web service interacts with other
The grant management Web service supports scenarios such as:

server11sp32-27feb09-2009-0227-1757
Page 169
• Granting the right to a resource for a subscriber; for example, free premium service
for the next two days.
• Extending a grant; for example, extending the expiration for VOD.
• Assigning the principals to a particular resource; for example, assigning all
subscriber groups for a particular VOD asset.
• Getting the resources for a particular principal; for example, getting all VOD assets
for a single subscriber group.
• Revoking a grant.
Offer Management Web Service

The offer management Web service (OfferManagement) enables BSS systems to manage the
details of offers (price, tax, and expiration) associated with live TV services, VOD assets, and
RDP applications.
The following diagram shows how the offer management Web service interacts with other
Offer details are maintained in the SMS.
Package Management Web Service

The package management Web service (PackageManagement) provides an API through
which BSS systems manage packages. Each package contains either a set of services or a set
of other packages.
The following diagram shows how the package management Web service interacts with other
Packages are maintained in the SMS.

server11sp32-27feb09-2009-0227-1757
Page 170
Principal Management Web Service
The principal management Web service (PrincipalManagement) enables BSS systems to
manage Microsoft Mediaroom principals (devices, subscribers, accounts, and subscriber
groups). Principals are maintained in the subscriber management subsystem (SMS).
The following diagram shows how the principal management Web service interacts with
There are currently two external interfaces to the principal management Web service; these
interfaces provide overlapping, but not identical, functionality. The older interface is called
the primary principal management Web service, or simply the principal management Web
service; the newer one is the principal management Web service (BSS2). Ultimately, all the
principal management functionality will be made available through the BSS2 interface to the
Web service, and the older interface will be deprecated. In the meantime, the interfaces are
complementary, handling different tasks.
Reporting Store Web Service

The reporting store Web service (reportingstore) enables applications to access billing records
associated with subscribers in all service groups. It exposes an API that is nearly identical to
the billing record management Web service, which resides at the service group level and has
direct access to the service group database. Although applications can access the billing
record management Web service, the reporting store Web service is designed specifically for
use by OSS and BSS applications.
The reporting store Web service is supported by an aggregation engine that collects billing
records from all service groups within a branch. Because the aggregation engine runs hourly,
billing records may appear up to one hour after they are created.
The reporting store Web service’s central billing aggregation point offers many advantages:
• The heavy load of monthly billing does not affect Microsoft Mediaroom clients.
• Deleting records from the central aggregation point does not affect Microsoft
Mediaroom clients.
• Applications do not have to access each service group individually.

server11sp32-27feb09-2009-0227-1757
Page 171
• The daily load associated with managing billing records is moved from the service
group server to the server running the reporting store Web service, which improves
service group performance.
• The reporting store Web service maintains a history of reference data so that at
month end, even if an asset is deleted from the branch, its details can be accessed and
used for billing purposes.
Note The reporting store Web service manages billing records that include more data than
the records managed by the billing record management Web service. Specifically, the
reporting store Web service billing records include rating and tax information.

server11sp32-27feb09-2009-0227-1757
Page 172
The Microsoft Mediaroom client is an IP-connected device that consumes video and data
services delivered by the Microsoft Mediaroom server machines. The Microsoft Mediaroom
client presents a user interface (UI) that enables subscribers to discover and view or interact
with those services.
Microsoft Mediaroom clients run Microsoft Mediaroom client software, which is used to
connect to and access Microsoft Mediaroom services. Each Microsoft Mediaroom device is
assigned a unique ID or a hardware key by the manufacturer, which enables it to authenticate
itself with the Microsoft Mediaroom server machines. After authentication, the Microsoft
Mediaroom client receives a list of the URLs of Microsoft Mediaroom Web services that
provide the configuration data the client requires to discover and use Microsoft Mediaroom
services.
The Microsoft Mediaroom client software is an embedded software component that runs on
Microsoft Windows® CE and can be installed on a set-top box or in devices such as
televisions, DVD players, digital video recorders (DVRs), or game consoles. The Microsoft
Mediaroom client software is designed to support extremely low-cost hardware
implementations.
The follow diagram shows the architecture of the Microsoft Mediaroom client.

server11sp32-27feb09-2009-0227-1757
Page 173
User Interface Framework
The Microsoft Mediaroom subscriber UI is a managed application that runs on the Microsoft
.NET Compact Framework (CF) with a custom rendering engine.
The subscriber UI uses .xml data files to define the text strings, graphics files, fonts, and other
elements in the UI. By modifying the content of these .xml data files, you can customize the
UI without having to rebuild the client software.
The Microsoft Mediaroom client enables you to customize the following UI elements:
• Logo
• Color
• Font
• Language
• Text strings
• Menu
• Graphics
• Triple-tap keys
For details on UI customization, see Client Customization and Localization Guide (Microsoft
Mediaroom Client documentation set).
Service providers can also create special URL services. These services deliver material
located on an HTTP server to client set-top boxes. The URL services can deliver two kinds of
data:
• Images (graphics in the JPEG or PNG formats)
• Browser application pages, which display one or more picture-in-picture frames, as
well as other text and/or graphics
Browser application pages are written in XHTML, and then converted to a special XML
format suitable for delivery to the set-top box. The converted XML file is actually hosted on
the HTTP server, and delivered to the client; the XHTML file is used only as source material
to generate that XML file.
For more information about creating and deploying URL services (whether single-image or
Browser application pages), see Configuring URL Services (p. 476) in Operations Guide.
Data Exchange
The UI consumes data that originates or is maintained at the Microsoft Mediaroom server
machines. Some of this data, such as listings and subscriber rights, are cached at the client to

server11sp32-27feb09-2009-0227-1757
Page 174
enable faster access. If the cached information changes at the server machine, a notification
message is sent to the client to update its cache. Similarly, if session keys or boundary keys
expire and are rejected or the client cannot connect to a Distribution Server (DServer), the
client requests updated information from the Microsoft Mediaroom server machines.
Microsoft Mediaroom clients communicate only with the Microsoft Mediaroom server
machines in the perimeter network, which is also sometimes referred to as the “demilitarized
zone” (DMZ). The Terminal Server, DServer, and VOD Server machines also reside in the
perimeter network, however, clients communicate with them through the Client Gateway
machine. Other Microsoft Mediaroom server components also send data to Microsoft
Mediaroom clients through the Client Gateway machine. The following diagram provides a
high-level overview of the data exchange between the Microsoft Mediaroom server machines
and Microsoft Mediaroom clients. For detailed interactions, refer to the specific subsystem
descriptions.

server11sp32-27feb09-2009-0227-1757
Page 175
Audio/Video Service Support
The Microsoft Mediaroom client includes an A/V engine that supports the acquisition,
decryption, and display of decompressed (both real-time and time-shifted) A/V data. The
Microsoft Mediaroom client uses command and control messages to synchronize with the
machines delivering the content.

server11sp32-27feb09-2009-0227-1757
Page 176
The A/V engine includes codecs that decrypt audio and video data and decode it into video
frames and uncompressed audio streams. The Microsoft Mediaroom client supports video and
audio content in several formats. For the most up-to-date information on A/V support, see
Audio Video Specification Guide in the Microsoft Mediaroom Common Reference
documentation set.
The A/V engine supports delivery of streams by Real-Time Protocol (RTP) transport. The
device interacts with the Client Gateway machine that interfaces with the branch. The branch
provides the device with keys that enable the subscriber to receive and consume media.
DVR Engine, Storage, and Management

The Microsoft Mediaroom subscriber UI enables subscribers to schedule a single recording or
a series of recordings using local storage on the designated recording device in the household.
DVR scheduling, however, is managed by the DVR Scheduler Subsystem (p. 125) on the
Microsoft Mediaroom server machines.
The Microsoft Mediaroom client keeps track of pending recordings and starts and stops the
recording based on these schedules. Recording schedules may be cached in volatile storage,
but when a Microsoft Mediaroom client powers up, it does not assume that pending
recordings are cached. Instead it queries the DVR scheduler subsystem for scheduling
information.
RDP Application Support

The Microsoft Mediaroom client includes a Remote Desktop Protocol (RDP) client software
module that enables subscribers to launch and interact with applications that run on the RDP
application subsystem. Subscribers access RDP applications through the client menu, custom
remote control key, or through the program guide.
RDP applications can be in the form of Web applications or stand-alone Windows
applications and can interact with remote resources, such as Web servers and databases.
To protect restricted content, the client receives the location of the RDP Application Server
machine only after the system authenticates the client through the bootstrap process. Every
version of RDP uses RSA Security’s RC4 cipher. RC4 uses secure network communications
like those found in protocols such as SSL.
In Windows Server 2003, administrators can encrypt RDP data using a 56-bit or 128-bit key.
By default, 56-bit keys are used in bidirectional encryption.

server11sp32-27feb09-2009-0227-1757
Page 177
Most PC Web-based applications include an option that, after initial logon, enables the user to
log on automatically during subsequent visits to the Web site from that PC. User credentials
are stored in a cookie in the Windows user profile on the PC and sent to the Web site on
subsequent visits. The same automatic logon experience works for Web-based applications
accessed over RDP by subscribers with Microsoft Mediaroom clients. Cookies are
automatically moved from the Windows user profile on the Terminal Server to the subscriber
database on disconnect, and are then moved back to the Windows user profile on reconnect.
The cookies are preserved no matter which Terminal Server and Windows user is active when
the subscriber accesses the application.
For additional information on RDP applications, see RDP Application Subsystem (p. 076).
Bootstrap and Client Authentication

The Microsoft Mediaroom client boot ROM contains instructions for powering-up the device,
initializing the system, and launching the Microsoft Mediaroom client software.
Microsoft Mediaroom clients support both dynamic host configuration protocol (DHCP) and
point-to-point protocol over Ethernet (PPPoE) for connecting to the Microsoft Mediaroom
server machines. This enables support for households with or without routers in their
networks.
Whenever a device is initialized, normally when it is powered up or after the connection to
the service is interrupted, the following client authentication sequence occurs:
1) The client establishes a connection with the bootstrap Web service, presents its (non-
A/V) certificate and a randomly generated value or “nonce,” and then requests a
ticket to contact services.
2) The bootstrap Web service validates the client certificate for authenticity. If the
certificate is not authentic, the bootstrap Web service logs the event, and then closes
the connection. If the certificate is valid, the bootstrap Web service does the
following:
a) Generates a symmetric key for session encryption (session key).
b) Encrypts the session key with the client’s public key.
c) Signs both the encrypted session key and the nonce.
d) Creates a client ticket.
The client ticket is fully opaque to, and not modifiable by, the client. The client
ticket contains the client’s non-A/V session key and the client ID, which are
encrypted with the branch key.

server11sp32-27feb09-2009-0227-1757
Page 178
e) Transmits to the client the signed, encrypted session key, the signed nonce (an
X.509 certificate identifying the branch and signing the challenge), the client
ticket, the server public key, and the server certificate.
3) The client decrypts the session key with its private key, validates the server
certificate, and then validates that the nonce was signed correctly by the server. If the
server certificate is not authentic or if the nonce was not encoded properly, the client
closes the connection, and then posts an error message to the screen.
4) If the client authenticates the server, the client attempts to log on to the service. The
client encrypts each session with the symmetric session key and presents its client
ticket to the bootstrap Web service.
5) The bootstrap Web service checks for cloning and, optionally, certificate revocation.
The bootstrap Web service queries the subscriber management subsystem (SMS) to
ensure that the client is not logged on to the system using a different IP address from
the one assigned to it or that the client certificate was not revoked. Revocation
involves permanently disabling a subscriber from accessing a piece of content. The
revoked device is no longer able to decrypt the revoked content. After content is
revoked, the only way to restore or regain access to the particular piece of content is
to reissue a license for it.
If the client is valid, the bootstrap Web service returns the service list to the client. If
either the cloning or the certificate revocation check fails, the bootstrap Web service
logs the event, and then closes the connection to the client.
6) When the client needs to contact a service, it looks up the service on the service list,
and then presents the client ticket to prove its right to access the service.
Client Remote Control

Both the Microsoft Mediaroom client and the set-top boxes support the Microsoft Mediaroom
infrared (IR) remote control. The remote control is designed to be familiar to any subscriber
and to provide quick access to features such as the Video on Demand screen and digital video
recordings.
The remote control includes the following functionality:
• Channel up (+), channel down (-), and number buttons are consistent with standard
TV remote controls.
• Playback control buttons enable fast-forward, rewind, pause, replay, skip, and stop
for digital video recording content.
• Directional navigation buttons enable subscribers to navigate the subscriber UI and
activate Browse mode to preview programs.

server11sp32-27feb09-2009-0227-1757
Page 179
• MENU and GUIDE buttons provide access to the two most frequently used
interactive applications.
• RECORDED TV and VIDEOS buttons enable quick access to recordings and the
Video on Demand screen.
• EXIT TO TV button dismisses the subscriber UI and returns the subscriber to full-
screen TV.
• INFO button invokes a description of the current or highlighted show.
• BACK button returns the subscriber to the previous screen.
For a complete description of the remote control buttons, see “Using the Set-Top Box Remote
Control” in Subscriber’s Guide in the Microsoft Mediaroom Client documentation set. For
information on how to assign one or more set-top box remote control buttons for launching
network (RDP) or Microsoft Mediaroom Browser application, see Customizing a Remote
Control Button to Launch an RDP Application (p. 468) and Customizing a Remote Control
Button to Launch a URL Service (p. 482) in Operations Guide.
Client Upgrade
The Microsoft Mediaroom system supports automatic upgrades of client software in the field.
During the client authentication process, the client sends its software version to the bootstrap
Web service on the Client-Facing Service Group machine. The bootstrap Web service
compares the client’s current software version to its resolved version. If the version numbers
do not match, the client is directed to one of the following resources to receive upgrade files
during the next maintenance window configured by the operator:
• Device upgrades for pre-1.6.2 devices are pushed to devices through the upgrade
Web service. This service is responsible for downloading the upgraded software
image to the set-top box. The upgrade Web service is installed by default on the
Client-Facing Service Group machine.
• Device upgrades for devices that run 1.6.2 or later are pushed to devices through a
machine with the clientUpgradeFiles role. The clientUpgradeFiles role is installed in
an Internet Information Service (IIS) cluster. Upgrade files are loaded into RAM for
a period of time after the first retrieval, which provides a significant performance
improvement over the upgrades for pre-1.6.2 devices.
Software version precedence is determined through a hierarchical version stack. During a
scheduled upgrade operation, the version the device had at its last bootstrap is compared to
the current resolved version. An upgrade notification is only sent to the device if there is a
difference. If there are multiple pending upgrade jobs for the same device, only one of the
jobs is performed. For example, if you perform an individual device upgrade during the

server11sp32-27feb09-2009-0227-1757
Page 180
device's usual scheduled upgrade window, the pending device group upgrade for that specific
device is performed ahead of all other devices in the service group scheduled for that window.
For more information about the software version precedence, see Software Version
Precedence (p. 583) in Operations Guide.
When a client’s software is upgraded, the set-top box receives only the files required to bring
it up to date. After loading the new files, the set-top box reboots and repeats the client
authentication process.
Operators uses the options available in the Client Upgrade Settings (p. 309) page in the TV
Services Management tool to configure a maintenance window for performing upgrades, set
the number of upgrades to perform per second, and choose whether a subscriber can defer an
upgrade:
• Enabled, user snooze allowed. Devices are notified of an available upgrade.
However, unless the upgrade is critical, the subscriber can choose to delay the
upgrade.
• Enabled, forced. Devices are notified of an available upgrade, and subscribers
cannot delay the upgrade.
• Blocked, notifications paused. Notifications are paused for normal upgrades.
However, critical upgrades that result from disaster recovery, new set-top box
initiation, and authenticator.xml minimum version changes still take place. Upgrades
that result from disaster recovery, new-set-top box initiation, and minimum version
changes in authenticator.xml are always enabled and forced.
For additional information, see Client Management Subsystem (p. 143) and Upgrading
Devices (p. 582) in Operations Guide.
Multiple Client Households

If a household has multiple set-top boxes and DVR Anywhere is enabled for the account,
subscribers can watch any recorded show from any set-top box. When a recording is
scheduled, Microsoft Mediaroom uses the account's designated recording device, which the
operator can configure in the Edit Account (p. 215) page of the TV Services Management
tool. (For more information, see Designating a Recording Device for an Account (p. 234)
in Operations Guide.)
An operator assigns a certain number of ingress streams to each account. The number of
ingress streams determines how many services the household can watch at a time, regardless
of how many devices are assigned to the account. When a subscriber watches one of the
following types of services, a corresponding SD or HD stream is used:
• Live TV programs.

server11sp32-27feb09-2009-0227-1757
Page 181
• Recording a live TV program or PPV event (although watching a recorded program
does not use a stream).
• Pay Per View (PPV) events.
• VOD or SVOD assets.
When a subscriber tries to use more streams than the account is entitled to, the Microsoft
Mediaroom client displays a conflict resolution screen, prompting the subscriber to select
which activities have higher priority.
In addition to a set number of ingress streams, each household is also allocated a maximum
ingress bandwidth. The household's maximum bandwidth is calculated automatically from the
number of SD and HD streams allocated to that household. If a subscriber tries to perform an
activity which would cause the household to exceed its maximum bandwidth, a conflict
resolution screen is shown.
For accounts with DVR Anywhere enabled, the operator also configures the number of SD
and HD egress streams, and egress bandwidth that the account's designated recording device
can serve to other playback-only devices in the household. When a subscriber plays back a
recorded program from a playback-only device, the egress stream profile applies. Just as for
playback on the designated recording device, none of the account's ingress stream or ingress
bandwidth allocation is used for playing back the recorded program. For more information
about the stream profiles, see Stream Management (p. 184).
For the latest information on the maximum number of streams that are supported for a
specific client, see the Microsoft Mediaroom Client documentation set for the version of the
client software you are deploying.
Client Streams
Every household is allocated a certain number of streams. The streams are used to allocate
full-stream video content. There are two different kinds of streams:
• A high-definition (HD) stream can be used to watch or record high-definition or
standard-definition content.
• A standard-definition (SD) stream can be used to watch or record standard-definition
content, but not high-definition content.
If a set-top box goes into standby mode and is not recording a program, it releases any stream
it may have, allowing another set-top box to use it. Similarly, if a customer is using a set-top
box to watch already-recorded content, the set-top box releases its stream.
If no subscriber activity occurs on a set-top box for an operator-configured period of time, the
stream is designated as "stale". If another set-top box needs a stream and no unused streams
are available, the set-top box uses one of the stale streams. If an HD stream is being used to

server11sp32-27feb09-2009-0227-1757
Page 182
play standard-definition content, the HD stream can also be designated as "stale". If a set-top
box has a standard-definition stream but the subscriber wants to tune to a high-definition
channel, the set-top box with the standard-definition stream can swap streams with the set-top
box that currently has the HD stream. However, that swapped stream is still received in SD
format at the set-top box.
Set-Top Boxes with and Without Hard Disks

If a household has several set-top boxes, generally only one set-top box has a hard disk. If
DVR Anywhere is enabled for the account, that set-top box handles all the recording for the
entire household. As long as the designated recording device is powered on, from other
playback-only devices in the household subscribers can watch recorded TV programs because
the playback devices play recorded content from the designated recording device.
Each set-top box communicates separately with the various Microsoft Mediaroom client-
facing servers, for example, for software upgrades and program guide updates.

server11sp32-27feb09-2009-0227-1757
Page 183
Stream Management
Microsoft® Mediaroom clients from Microsoft Mediaroom Client 1.6 (1.6) and later enable
each device in the account to manage streams for both ingress and egress. All streams—from
live TV, video on demand (VOD), digital terrestrial television (DTT), and hybrid DTT
services—are considered in the stream management profile. Each account has an ingress
profile which defines the number of incoming streams permitted for the household. A
recording device (DVR) can also have an egress profile, which defines the maximum number
of playback streams are permitted for the device (excluding the DVR device itself, which
does not use any of the allotted egress streams). The ingress profile is expressed as the
number of high-definition (HD), standard-definition (SD), and DTT streams, and the
maximum bit rate allowed for the account. The egress profile is expressed as the number of
high-definition (HD) and standard-definition (SD) streams, and the maximum bit rate allowed
for the device. Stream management events are captured as subscriber-activity logging events,
which provide valuable insight on subscriber activity and usage patterns (see Subscriber
Activity Log Events Reference (p. 617) in Operations Guide for more information).
Any request for a stream goes through stream management policy enforcement, even though
not all profiles apply perfectly to all devices.
A device for an account with DVR Anywhere enabled plays one of the following roles.
• A requester of remote playback streams. The requester is a playback device,
which cannot provide streams to any other device in the household.
• A provider of remote playback streams. The provider is the account’s designated
recording device and can provide recorded streams to the playback devices in the
household. Playback streams on the recording device do not subtract from the
number of playback streams that are available for the non-recording devices in the
household.
The following diagram shows how the existing WAN profile for Microsoft Mediaroom Client
1.2.x devices and the ingress and egress profiles for 1.6.x clients apply to each device in the
subscriber’s account. Incoming streams are streamed to the device. For accounts that have
DVR Anywhere enabled, outgoing streams are streamed from the account’s designated
recording device to other playback-only devices in the household.

server11sp32-27feb09-2009-0227-1757
Page 184
Stream Definitions
WAN Streams (p. 186) are defined at the account level, and define the number of each
ingress stream type that is shared by all devices in the household.
Each account can have a separate set of defined Ingress Streams (p. 186), and the recording
device can have a set of defined Egress Streams (p. 187). Account-level ingress streams are
defined through the StreamManagementProfile class of the principal management Web
service (BSS2). Device-level egress streams are defined through either the tv2config.xml file
or the StreamManagementProfile class. For information about using tv2config.xml to define
egress streams for an account, see “Configuring DVR Anywhere” in Client Configuration
Guide (Microsoft Mediaroom Client documentation set). For information about using the
BSS API to configure ingress streams for individual devices, and egress streams for an
account that has DVR Anywhere enabled, see “Principal Management Web Service (BSS2)”
(BSS Web Service Reference in the Microsoft Mediaroom OSS/BSS Integration
documentation set).
Note Stream profiles should only be deleted using the RemoveStreamManagementProfile

method in the principal management Web service (BSS2). For more information, see
“RemoveStreamManagementProfile Method” in BSS Web Service Reference (Microsoft
Mediaroom OSS/BSS Integration documentation set).

server11sp32-27feb09-2009-0227-1757
Page 185
WAN Streams
WAN streams represent how many of each supported ingress stream type is supported at the
account level. If not set for an account, the WAN stream profile that is configured as the
global default setting is used. For more information on using the TV Services Management
tool to define the global default account-level ingress profile, see Configuring the Global
Client Settings (p. 058) in Operations Guide.
Ingress Streams
Ingress streams define the number of each type of incoming stream that is allotted to an
account. The ingress-stream profile is applied to all devices configured for the account.
If the device is the account’s designated recording device, this profile represents the number
of each type of stream that can be used for recording. For playback (non-DVR) devices, this
profile is less relevant, because such devices can tune only to one full-screen service at a time.
Microsoft Mediaroom supports the following ingress streams. When there is contention for
ingress streams, they are considered in the order of priority shown.
1) DVR Anywhere recording streams (HD, SD, and DTT).

2) VOD streams (HD and SD).
3) Live TV streams (HD, SD, and DTT).
4) Local and remote pause buffer streams (HD, SD, and DTT).
5) Browser application or picture-in-picture (PIP) streams (counted only for bandwidth,
and not supported by DTT).
The ingress profile is expressed in terms of the maximum stream count and the account's total
ingress bit rate. Maximum stream count is expressed as a 3-tuple, which defines the number
of HD streams, the number of SD streams, and the number of DTT streams.
The account's total ingress bit rate is calculated by the following formula:
(HD streams × HD max bit rate) + (SD streams × SD max bit rate)
For example, if the account's ingress tuple is (2, 2, 2), the HD max bit rate is 9 Mbps, and the
SD max bit rate is 3 Mbps, the total calculated ingress bit rate is 24 Mbps:
Total calculated ingress bit rate = (2 × 3) + (2 × 9) = 24 Mbps
Ingress streams can come from live TV or VOD services, or from DTT. For live TV or VOD
streams, the total ingress bit rate is calculated with the preceding formula. For DTT services,
there is no bandwidth limitation. Operators who need to control DTT bandwidth can control
the number of DTT tuners through the device’s tv2config.xml file. For information, see “DTT

server11sp32-27feb09-2009-0227-1757
Page 186
Client Configuration” in Client Configuration Guide (Microsoft Mediaroom Client
documentation set).
The ingress profile is stored in the ServiceGroupDB database. There is a default global device
value that cannot be modified, and an account value that is configured through the BSS2 API.
If a stream setting is not specified for a stream type, the stream type’s ingress profile is set to
zero. An account's ingress profile can also be defined using the TV Services Management
tool. The global account default value is defined using the TV Services Management tool. If
an operator does not specify any stream values when provisioning an account, the global
default stream settings are used.
The account's ingress profile is the lesser of the WAN profile and the account-level ingress
profile, where lesser is defined as:
• The lesser value for HD streams.
• The lesser value for SD streams.
• The lesser value for DTT tuners.
For example, if the WAN profile is set at 3 SD and 1 HD streams, and the account's ingress
profile is set at 2 SD and 2 HD streams, the net ingress profile for that account is 2 SD and 1
HD. The server uses the ingress and WAN profiles to define the ingress profile for the
recording device, which equates to the number and type of streams allowed for recording.
It is important to note that while detuning a shared multicast live stream does not lower WAN
bandwidth consumption, it does lower a device’s ingress stream count and bandwidth
consumption.
For more information about using the BSS2 API to configure the account ingress profile, see
“StreamManagementProfile Class” in BSS Web Service Reference (Microsoft Mediaroom
OSS/BSS Integration documentation set).
For more information on using the TV Services Management tool to configure the ingress
profile for an account, see Modifying a Subscriber Account (p. 100) in Operations Guide.
For more information on using the TV Services Management tool to define the global default
ingress profile at the account level, see Configuring the Global Client Settings (p. 058) in
Operations Guide.
Egress Streams
Egress streams define the number of each type of outgoing stream that a DVR device can
serve to the account’s other devices that can perform playback-only functions. The value for
egress streams is defined for the account’s designated recording device.

server11sp32-27feb09-2009-0227-1757
Page 187
Remote or local playback streams do not have a priority associated with them. The playback
stream is unicast, and each playback stream is unique between two nodes, even if more than
one node is viewing the recorded playback of the same program. Playback on the designated
recording device does not count against the device’s egress profile. An HD playback stream
can be used for either HD or SD content; however, an SD stream can be used only for SD
content. Substitution of multiple SD streams for a single HD stream is not supported.
The playback stream bit rate for each recording is either calculated at runtime or stored as a
metadata value. For live TV and VOD recordings, the bit rate is stored with the recording. For
DTT recordings, the bit rate data is not stored, and thus, the maximum HD bit rate that is
defined in the device’s bootstrap.xml file is used.
The account’s designated recording device receives the current defined egress profile from
the server during bootstrap, or the device uses the local values that are defined in the
tv2config.xml file. If the device’s egress profile is modified after the device bootstraps, the
device does not honor the new settings until its next bootstrap.
During bootstrap, the client gets the egress profile values from the server, or the client uses
local values as outlined in this section. Changes to the egress profile that are made after the
client has booted are not honored until the client is rebooted to take the new values.
The egress profile can be based on bandwidth, stream count, or a combination of bandwidth
and stream count. If the egress profile is based only on bandwidth, the profile is expressed as
a total maximum bit rate. If the egress profile is based on stream count, the profile is
expressed as the number of HD streams and the number of SD streams. If the egress profile is
based on a combination of bandwidth and stream count, the profile is expressed as a 3-tuple
that defines the number of HD streams, the number of SD streams, and the maximum
bandwidth.
The following examples show several possible egress profiles:
• The operator specifies only the bandwidth. The resulting egress profile is: 0 SD
egress streams, 0 HD egress streams, and 10Mbps.
• The operator specifies only the stream count. The resulting egress profile is: 2 SD
egress streams and 1 HD egress stream.
• The operator configures both bandwidth and stream count. The resulting egress
profile is 1 SD stream, 1 HD stream, and 10 Mbps.
• DVR Anywhere is disabled by setting all egress profiles to zero (single-room DVR is
still enabled). The resulting egress profile is 0 SD streams, 0 HD streams, and 0
Mbps.
The egress profile is stored in the ServiceGroupDB database. There is a default global device
value that cannot be modified, and an account or device value that is configured through the
BSS2 API. The device value can also be specified in the tv2config.xml file for the device. If a
stream setting is not specified for a stream type, that stream type’s egress profile is set to zero.

server11sp32-27feb09-2009-0227-1757
Page 188
The device evaluates egress streams in the following order.
1) Device ingress policy

a) Total bit rate (calculated)
b) SD stream count
c) HD stream count
d) DTT tuner count
2) WAN policy
a) Total bit rate (calculated)
b) SD stream count
c) HD stream count
3) DVB policy
a) DTT tuner count
4) Device egress policy
a) Total bit rate (input)
b) SD stream count
c) HD stream count
Note If the device encounters a profile violation during the evaluation, a dialog screen is
displayed to the subscriber. For more information, see “Resolving Multiple-Stream Conflicts”
in Subscriber's Guide (Microsoft Mediaroom Client documentation set).
If the request for a specific stream type satisfies the profile that it is mapped against, the
request is granted and the corresponding stream is available for the subscriber to view. The
device successfully tunes to the requested stream.
If the request for a specific steam type does not satisfy the profile that it is mapped against, a
stream contention event occurs. Most stream contention events result in a dialog screen that is
displayed to the subscriber.
Note Detuning a shared multicast live stream does not lower the WAN bandwidth
consumption, but does lower the device’s ingress stream count and bandwidth consumption.
For information on how to configure egress streams, see “StreamManagementProfile Class”
in BSS Web Service Reference (Microsoft Mediaroom OSS/BSS Integration documentation
set).
For more information on how to configure egress streams in the device’s tv2config.xml file,
see “Configuring DVR Anywhere” in Client Configuration Guide (Microsoft Mediaroom
Client documentation set).

server11sp32-27feb09-2009-0227-1757
Page 189
For more information about the dialog screen that is presented when a requested stream is not
available because of contention with the configured stream counts, see “Multiple-Stream
Households” in Subscriber's Guide (Microsoft Mediaroom Client documentation set).
Stream Contention
When a device applies the stream profiles, it proceeds through them until one profile is either
satisfied or violated. None of the available profiles matching is treated as though one of the
profiles on the list was violated.
If the tune service being evaluated is an IP stream (for example, download, UDP multicast or
unicast stream, VOD, or application), it is evaluated in the following order and suborders:
• Ingress profile:
• HD stream count.
• SD stream count.
• Total bit rate.
• WAN profile:
• HD stream count.
• SD stream count.
• Total bit rate.
If the tune being evaluated is a DVB tune, it is evaluated in the following order:
• DVB profile:
• DTT tuner count.
If the request for a particular stream satisfies the profile it is mapped against, that request is
granted, and the corresponding stream is available for use. The device will successfully tune
to the request.
If the request for a particular stream does not satisfy the profile condition it is mapped
against, stream contention occurs. Most stream contentions result in a dialog box being
presented to the subscriber. For more information, see “Resolving Multiple-Stream Conflicts”
in Subscriber's Guide (Microsoft Mediaroom Client documentation set).

server11sp32-27feb09-2009-0227-1757
Page 190
server11sp32-27feb09-2009-0227-1757
Page 192

Architecture of Microsoft Mediaroom

Uploaded by

Copyright:

Available Formats

Architecture of Microsoft Mediaroom

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Architecture of Microsoft Mediaroom

Uploaded by

Copyright:

Available Formats

Architecture of Microsoft

Microsoft Mediaroom Server 1.1 SP3.2

Microsoft Mediaroom was formerly known as Microsoft TV IPTV