IPTV Middleware Operation Manual

VoDKATV Operation Manual
Manual
v1.0 – October 2011

Manual. VoDKATV Operation Manual
DOCUMENT HISTORY
VERSION NUMBER DATE CHANGE AUTHOR CHANGES
1.0 1st October 2011 Interoud Initial version
2.0 8th February 2012 Interoud Legal notices change
3.0 10th March 2012 Interoud Added new functionalities/screenshots for the new
interface
SCOPE OF THIS DOCUMENT
This document provides a guide through the common operations with the Interoud middleware
VoDKA.TV in order to build a complete user experience according to the customer specifications.
VoDKA.TV is a system that provides interactive services through a STB connected to a television.
It provides full functionality or the possibility of integration with third party software by using
extendable APIs.
VoDKA.TV middleware provides two base configurations oriented to different markets. On the one
hand the one destinated to Telco operators and on the other the one for Hospitality. Some
configuration differences take place between them and we will see them during this document.
This document outlines the steps needed to configure and operate a VoDKA.TV middleware and is
oriented to an operations or technical profile.
Blusens Networks - www.blusensnetworks.com 2 of 64

Legal Notices
Copyright © 2011, 2012 Interoud. All rights reserved.
This document contains confidential, proprietary information of Interoud Innovation SL. Unauthorized
copying, reproduction or disclosure of any portion of the contents of these materials by any means—
including printed or duplicated materials, onscreen publication or Web documentation—is expressly
forbidden.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEROUD INNOVATION

SL. PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY
INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. INTEROUD INNOVATION SL.
ASSUMES NO LIABILITY WHATSOEVER, AND INTEROUD INNOVATION SL DISCLAIMS ANY EXPRESS
OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEROUD INNOVATION SL
PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR
PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER
INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEROUD
INNOVATION SL. THE PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN
WHICH THE FAILURE OF THE PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY
OR DEATH MAY OCCUR.
Interoud may make changes to specifications and product descriptions at any time, without notice. Designers
must not rely on the absence or characteristics of any features or instructions marked “reserved” or
“undefined.” Interoud reserves these for future definition and shall have no responsibility whatsoever for
conflicts or incompatibilities arising from future changes to them. The information here is subject to change
without notice.
Interoud, VoDKA, HED, Antares, Pulsar and VoDKATV logo are trademarks of Interoud Innovation SL. Third
party trademarks and images shown are the property of their respective owners.
This DOCUMENT is neither affiliated with nor endorsed by the owners of the third party images, names and
logos displayed herein.

Table of contents
1.Introduction................................................................................................................................... 5
1.1.Definitions.............................................................................................................................. 5
2.VoDKATV MANAGEMENT............................................................................................................6
2.1.CORE SYSTEM CONFIGURATION......................................................................................7
2.1.1. System properties.........................................................................................................7

2.1.2.STB types..................................................................................................................... 10
2.1.3.Plugins.......................................................................................................................... 11
2.1.4.External Systems......................................................................................................... 12
2.1.5.Service Networks......................................................................................................... 13
2.1.6.Banners........................................................................................................................ 18
2.2.PROVISIONING. OSS CONFIGURATION...........................................................................18
2.2.1.Users............................................................................................................................ 18
2.2.2.Services area............................................................................................................... 21
2.2.3.STB.............................................................................................................................. 22
2.2.4.TV Channels................................................................................................................ 23
2.3.BUSINESS SUPPORT CONFIGURATION..........................................................................41
2.3.1.Permissions Management............................................................................................41
2.3.2.Pricing.......................................................................................................................... 43
3.OPERATION AND MONITORING...............................................................................................50
3.1.Messaging........................................................................................................................... 50
4.Logs............................................................................................................................................ 52
4.1.Firmware.............................................................................................................................. 54
4.2.Diagnosis and recovery procedures.....................................................................................55
5.VoDKATV new management graphical user interface overview..................................................57

1. Introduction
This manual is intended to provide a general vision about the functionalities provided by the
middleware server VoDKA.TV.
As a result of the software evolution, a full GUI remodeling is being performed so part of the
functionality takes place on the old admin interface and part on the new one. This guide will go
through the actions that the middleware implements showing how and where each one of them is
performed.
1.1. Definitions
• OSS: The Operations Support System (OSS) enable to manage, monitor and control the
telecommunications networks. Users, services and content provisioning.
• BSS: The Business Support Service manages all relationships between provisioned assets
and customers, like packaging, billing, subscription, access rights, etc...
• Quality of Experience: the quality of experience subsystem tries to assure automatically the
good quality of all services provided to the users
• CAS: The conditional access ensures that only authorized users can access services.
• STB: Set top box, the user system device at his digital home connected to the service
platform and providing the final user experience.
• VoD: Video on Demand
• Rooms: VoDKA.TV represents by room any physical location where a STB can be placed.
• Session: period of time that represents a user’s stay in a room. If the session has no end
date associated, this session will be active for a period of time not determined.
• Plugin: is a set of software components that adds specific abilities to a larger software
application. Most of the operators functionality of a VoDKA.TV middleware comes in the
shape of plugins.
• PMS (Property Management System): system used by hotels to manage and handle all in-
formation for the hotel, such as living room, billing, etc.

• VoDKA Asset Manager (codename BAHAMAS): metadata management of video on

demand assets.
• nPVR: network Personal Video Recorder, server side infrastructure responsible of liveTV
recording to provide on Demand time-shift services like: pause LiveTV, Start-Over or Catch-
UP TV
2. Login & Initial Screens

During the installation you will be provided with an URL to manage the middleware from your
preferred browser (i.e. https://10.121.55.204:8443/vodkatv/admin) and the proper credentials to
access it (recommended Mozilla Firefox).
Since the new interface became available, the login screen changed to:

And the initial screen:
3. VoDKATV MANAGEMENT
The following points will show a guide on how to set the basic system properties. This section will
go through the server properties, setting caching times, STB refresh rates, default values..., then
will show how to configure the basis for the platform (network, services, ports) and finally a brief
introduction to the STB types and GUI configs.
3.1. CORE SYSTEM CONFIGURATION
3.1.1. System parameters

Properties section (Configuration > Properties) allows the user to set the value of several system
generic properties. These properties include default values when no other configuration is set.
The following properties can be set:
• Seconds to request forced contents: an integer specifying how often forced contents are
requested (in seconds). Set-top-box consults VoDKA.TV periodically to check whether any
content should be forced to be played. A small value implies a high polling frequency, which
is useful when the target is precision; otherwise it adds an unnecessary verload to the
system.
When undefined, this kind of requests will not be performed, which is the best choice if this
functionality is not required.
• Seconds to refresh set-top-box cache: an integer specifying how often set-top-box cache
is refreshed. Some kinds of set-top-boxes keep some information in cache to ease access
to it (for example: channels information, menus. . . ). It is recommended to use a value not
as small to imply continuous cache updating (this would add an important system
overload), but not as big to make the information cached invalid. A 300 seconds value
should be a good choice.
• Minutes to synchronize PVR tasks: an integer specifying how often the STB will
synchronize the PVR tasks with the server.

• Currency: the symbol used for representing currency. This symbol will be appended to
every money amount shown. This implies VoDKA.TV works just as a mono-currency
system.
• Locate URL: full URL used by locate plugin.(Experimental)
• Seconds between new messages checking: an integer specifying how often the server
will be requested whether new administration messages exist (in seconds). This means set-
top-boxes request VoDKA.TV periodically checking for new administration messages. This
value sets how many seconds will go between the creation of a new message in
administration and the STB shows that message (assuming the set-top-box is active).
Small values add an overload to the system but allow new messages to be delivered to the
user quickly. Big values add less overload but the system will take longer to deliver
administration messages to the user.
• Seconds to reload a teletext page automatically: an integer specifying how often teletext
pages are automatically reloaded. This must be adjusted regarding the Teletext changing
rate.
• Expiration time for teletext images: an integer specifying the amount of milliseconds
used for caching teletext images when requested to the image generator. For more
information about teletext pages automatic reloading, see the operation and maintenance
manual of the used plugins handling teletext information.
• Default Purchase PIN: Sets a default PIN for all the purchases on the platform. Usually a 4
digits PIN is a good choice (i.e. 0000, 1234). Another PIN can be defined for each session
but it defaults to this on any error/misconfiguration.
• Default Parental Control PIN: Sets a default PIN for the parental control on the platform.
Usually a 4 digits PIN is a good choice (i.e. 0000, 1234). Another PIN can be defined for
each session but it defaults to this on any error/misconfiguration.
• Default Parental Control Level: Sets the default parental control level from a list of
parental controls available on the platform (Obtained from the VoDKA Asset Manager). If
none, all the contents are parental control free. The user can modify this later on the STB
preferences.
• Session time in seconds for parental control PIN: Specifies the duration for the parental
control PIN. During this time, there is no need to reenter the parental control pin while

searching or purchasing restricted contents from the STB.
• VHEDController URL: full URL to the static middleware contents.
• Welcome page URL: full URL to the welcome page to the system. Only used if VoDKA.TV
is configured on hospitality mode.
• Help page URL: full URL to the help page for the guests. Only used if VoDKA.TV is
configured on hospitality mode.
• HDMI-CEC: Indicates whether or not the HDMI-CEC should be available by default on the
platform. This parameter can be overwritten by the user configuration through the
preferences plugin if this option is enabled during installation.
• Interval to register watching data in CouchDB (in seconds): When an audimetry system
is configured, this parameter sets the frequency for updating data to this system. Smaller
values imply more accuracy but more network load.
• TV background application: Full URL to the background advertising application

(Experimental).
• PVR Trick modes: Indicates if the controls for PVR ffwd/rwd are available or not to the final
user. Under certain configuration of channel encryption the live indexing needed to provide
this functionality requires too much CPU or simply can not be done due to the algorithm
complexity. So that, the trick modes will not be available and disabling them is the safer
choice.
• Outputs protection: Some CAS providers require the graphical output to be protected in
order to make sure that no content can be copied from the STBs. This parameter
enables/disables the protection on the platform for HDMI and VGA outputs.
• Alarm clock sound: Specifies a VoD/AoD (available through VoDKA Asset Manager) to be
used as alarm on the STB. Only for hospitality.
3.1.2.Device types

VoDKA.TV Middleware is able to handle several STBs from different vendors. As this option may
appear in different configuration options, it is important to keep in mind which STBs are being
deployed and which functionality is desired for each of them.
List of supported STBs:
● Amino110 (Fresco)
● Hansun (Fresco)
● HED (WebKit) - [Local] - Deprecated
● HED (WebKit) - [Local v2] - Currently used by the BLU:SENS WebTV
● HED (WebKit) - [PROTOTYPE] - Experimental
● Macmini (Firefox)
● GenericPC (Firefox) (Only for testing)
● GenericPC (Generic) (Only for testing)

3.1.3.Plugins
The Service provider can manage how the end user will get its main menu configured. The
functionality is based on a plugin system. These plugins become available since the installation but
require further configuration to set the correct order, visibility and availability for each STB type.
This can be done from Configuration > Menu. First select the STB type and then drag the desired
plugins to the right to enable them or to the left to disable them and up/down to set the order.
Guest Services
Information regarding the configuration for the hotel plugin. Fields are self explanatory.
Webbrowsing
Information about the webbrowsing plugin, currently only available the disclaimer but generic

information/configuration will be placed here.

3.1.4.External Systems
For the VoDKA.TV middleware to be able to provide a full user experience, some auxiliary
subsystems need to be configured (this info is provided during installation).
These systems are used to provide the middleware with metadata for the channels/VoD, teletext
and other systems related to the QoE (Quality of Experience).
• Content server: IP or host name of the machine and port used to access the content
metainformation server VoDKA Asset Manager.
• Login: username to access the content metainformation server VoDKA Asset Manager.

• Password : password of the user used to access the content metainformation server
VoDKA Asset Manager.
• Annotations server (MAUI): IP or host name of the advanced metainformation server

VoDKA
• Image server: Full URL including protocol, host name (or IP) and port for accessing the
image server Limgen, http://LIMGEN_SERVER:LIMGEN_PORT. This URL must be
accessible from the set-top-box, which communicates directly with this server.
• Teletext server: IP or host name of the teletext server machine.

• CouchDB Server (Audimetry): IP or host name of the machine, port and database to
store the end user activity on the boxes. (Experimental).
• CouchDB Server (QoE): IP or host name of the machine, port and database to store QoE
related information that take place on the end user side (i.e. Bad TV Signals due to mcast
noise).
• CouchDB Server (EPG): IP or host name of the machine, port and database where the
persistent EPG is stored.
• EPG available hours: Default number of hours available for EPG.
• EPG Origin: This parameter can change from BAHAMAS (as live EPG provider) or
CouchDB if a persistent EPG system is installed.

• PMS Property Management System configuration.
The following parameter are required:
• Type: The type of PMS that is going to be used, for dummy PMS select
LambdaPMS.
• URL: The full URL where the dummy PMS is located.
• Port: The port where Fidelio is listenning.
• Other specific information may be requested depending on the PMS.
• CAS/DRM: Type and URL for the CAS Server.
3.1.5.Service Networks
The VoDKA.TV middleware manages how the STBs will get its contents and where this contents
are provided. In order to do that, it is necessary to tell VoDKA.TV how is our network and where

this content servers can be found.
VoDKA Rules
In Configuration > Servers it is possible to set rules that match under certain circunstances and
based on that, manage how the STBs are going to be distributed according to subneting or STB
types or both.
The first rule that matches is the one applied so they have to be created in strict application order.
Creating a rule is done through the Create link on the rule list screen. The following parameters will
be requested.

In the first place, the ones that define when the rule applies:
• Subnet and mask: the subnet and mask from were the request is sent, that is, the
configuration of the network where the set-top-box is located. Both values use aa.bb.cc.dd
format. To create a rule for any subnet, both field should be left empty.
Set-top-box type: different criteria can be defined for different set-top-box types. The
option Any creates a rule applying to any set-top-box type.
And then the parameters that will be used once the rule applies:
• Video Server: The host name or IP address of the VoDKA server where the set-top-box will
send RTSP, HTTP, MMS, or MMSH VoD requests (it does not apply to broadcast channels).
It is also possible to set a server list complying with following format:
• S_1(P_1),S_2(P_2),S_3(P_3)
• The semantics of this list are:
◦ S_X: VoDKA server IP address or host name.
◦ P_X: a number between 0 and 100 representing VoDKA selection likelihood.
• The selection process will select a random VoDKA server with the specified distribution
(P_X). The probabilities must total 100. If that is not the case, the values will be modified
internally so that they total 100, keeping the original proportion.
• On the contrary, if the playout configuration is Imagenio Mediabox, this field must be set
with Imagenio Mediabox ticket server asset purchase absolute URL (without parameters),
for example http://ws.ttv-hlg.terra.com.br/ttvwsmoc_proxy/PlayContent.aspx. In this case,
VoDKA.TV will set the parameters to complete the URL.
• contentId: content identifier in VoDKA Asset Manager, deleting the used VoDKA Asset
Manager node name in case a VoDKA Asset Manager node is being used instead of the
central storage.
• userIP: set-top-box IP, addressable from VoDKA.TV.
• For example: http://ws.ttv-hlg.terra.com.br/ttvwsmoc_proxy/PlayContent.aspx?

contentId=104947&userIP=193.144.63.20
• Video Server (Channels): IP address or VoDKA host name where set-top-boxes will
request RTSP or HTTP channels. It is also possible to set a server list with selection
likelihood (as explained for the video server field).
• Video Server (NPVR): IP address or VoDKA host name where set-top-boxes will request
RTSP or HTTP contents when Timeshift functionalities are used. It is also possible to set a
server list with selection likelihood (as explained for the video server field).
• RTSP frontend port: the port number used to play RTSP media.
• HTTP frontend port: the port number used to play HTTP media.
• MMS frontend port: the port number used to play MMS or MMSH media.
• RTSP frontend port (NPVR): the port number used to play timeshift contents using RTSP
protocol.
• HTTP frontend port (NPVR): the port number used to play timeshift contents using HTTP
protocol.
• Ticket server: Virtual ticket server IP address or host name. This field is ignored if not set.
Otherwise, virtual tickets will be used to generate the playback URLs for VoD if, and only if,
those URLs are generated using HTTP, MMS, or MMSH.
• Ticket server port: integer indicating the port used to generate tickets in the ticket server.
• VoD Collection: VoDKA Asset Manager collection used to preselect assets from the video
catalogue. That is, the video catalogue will contain only assets with this collection. VoDKA
Asset Manager asset meta-info server should be configured beforehand so that the
collection could be selected.
• Audio Collection: VoDKA Asset Manager collection used to preselect assets from the
audio catalogue. That is, the audio catalogue will contain only assets with this collection.
VoDKA Asset Manager asset meta-info server should be configured beforehand so that the
collection could be selected.
• Channels: Set-top-boxes use the following process to tune broadcast channels:

◦ Multicast: set-top-boxes will tune channels multicast group. For example:

igmp: //239.192.1.1/11111 o udp://@239.192.1.1:11111.
◦ RTSP: set-top-boxes will tune channels using the RTSP protocol, through VoDKA’s
multicast reflector. For example: rtsp://vodka/base/mcast/239.192.1.1/11111.
◦ HTTP: set-top-boxes will tune channels using the HTTP protocol through VoDKA’s
multicast reflector. For example: http://vodka/base/mcast/239.192.1.1/11111.
• VoD: Set-top-boxes use the following process to play video on demands contents:
◦ RTSP: set-top-boxes will play contents using the RSTP protocol. For example: rtsp:
//vodka/video.mpeg.
◦ HTTP: set-top-boxes will play contents using the HTTP protocol (not all set-top-boxes
support this protocol). For example: http://vodka/play?mo=video.mpeg.
◦ MMS: set-top-boxes will play contents using the MMS protocol (not all set-top-boxes
support this protocol). For example: mms://vodka/play?mo=video.mpeg.
◦ MMSH: set-top-boxes will play contents using the MMSH protocol (not all set-top-
boxes support this protocol). For example: mmsh://vodka/play?mo=video.mpeg.
◦ Imagenio Mediabox: set-top-boxes will play contents using a ticket requested to the
ticket purchase URL configured in the video server field.
• NPVR: Set-top-boxes use the following process to play timeshift contents (from NPVR
video server):
◦ RTSP: set-top-boxes will play contents using the RSTP protocol. For example: rtsp:
//vodka/pvr/channel/2010-10-10_10:25:30.
◦ HTTP: set-top-boxes will play contents using the HTTP protocol (not all set-top-boxes
support this protocol). For example: http://vodka/pvr/channel/2010-10-10_10:25:30.

3.1.6.Banners
The user interface reserves a space for advertising on the top bar. This advertising can be
configured from Configuration > Banners.
When creating a banner, it will show a file browser to upload the desired image. Due to the space
available on the screen, the following sizing guide must be followed:
● Amino: 640x52px
● Hansun: 135x62px.
● WebTV: 135x62px.
3.2. PROVISIONING. OSS CONFIGURATION
3.2.1.Services area
The services area is a logical classification of the users in a tree. It allows to establish the
availability of any content in the platform for a group of users. The root node tree is the main area.
All users have to have an associated area. The tree keeps inherit from top to bottom. A content
available for the Main Area is available for all the users.
On a hospitality deployment only makes sense one service area but on a telco deployments, we
can think on managing the channels, contents, permissions by ordering them into services areas
and then marking them as available to any STB only by assigning it to one of the leaves of the tree.

3.2.2. Households
VoDKA.TV structures the user provisioning within two layers. The PMS where the rooms and
sessions are defined and the middleware itself where the STBs are managed. Although the dummy
PMS is internal to VoDKA.TV this separation takes place because this dummy PMS can be
replaced with any third party software (as Fidelio PMS) where the rooms and sesions must be
managed externally.
This selection can be performed in External Systems > PMS. If the PMS is supported the next
steps will happen automatically. If we run an installation manually, we can create the households
by clicking new:

• Indentifier: A unique identifier for this room
• Description: A text describing this room.
• Tag Tree Node: The Service Area where the household will be located.
• Start Day: Date when the session starts to be valid.
• End Day: Date when the session ends.
• Name: A name to the session created over the room (i.e. The name of the guest hosted in
that room).
• Language: The preferred language for that room if available.
With the above steps, a session have successfully been created on the middleware. Now, we can
add a STB to that session.
3.2.3.STB
In the new/update household form we can add and edit STBs. The following fields need to be
fullfilled:

• Physicall ID: This will be the MAC/IP of the box depending how the platform was
configured.
• Description: Free text field describing the STB (i.e. the user name and a number)
• STB type: One of the supported types.
• Tag tree node: The Service area where this STB is associated. If empty, the household tag
tree node is inherited.
3.2.4.TV Channels
Adding a channel to the platform requires two steps. The creation of the channel itself and the
publishing of this channel.
The list of channels can be accessed on Contents > Channels. From this screen it is possible to
add, edit and delete channels.

Creating a channel
By clicking on new, the channels creation form will be shown:
The following fields are requested:

• Channels id: Mandatory. A unique string identifying the channel.
• Name: The name that will be shown when listing the channel.
• Channel Type: AUDIO | VIDEO. This field identifies the channel to be listed on TV or Radio
plugin.
• Parental rating: Rating for protected channels.
• Description: Free field for describing the content of this channel.
• Logo URL: URL where the channel logo may be find. As this is static content, it can be
served from a external server.
• Language: Only useful for channel listing.
• Country: Only useful for channel listing.
• Access Type: Categorizes the channel in one of the available types. Used for granting
access to this channel or not in the BSS.
• IP (Multicast Group): The multicast group for the channel if it is UDP.
• Port: The multicast port for the channel if it is UDP.
• EPG channel: Channel EPG associated.
• Teletext: The teletext channel to be associated to this channel (only if Teletext is

configured).
• Available EPG hours: Hours that the persistent EPG will be available for this channel. A
good value is the same as Available netPVR time.
• PVR Channel Name: The id of the PVR channel to be associated with this channel.
• URL: Base URL if the PVR is located in a specific place different than the default url.
• netPVR fragment size (seconds): The chunk size configured for the channel on the PVR
server (will be provided when configuring PVR).
• Available netPVR time (minutes): The recording size configured on the PVR server (will

be provided when configuring PVR).
• Pause support: If it will be enabled to pause the channel on air (only if PVR is installed and
configured for this channel).
• Pause Time margins(Start-End in minutes): Safety margins for pause live tv.
• Pre-Roll: A VoD to be played before starting over a program.
• Start over support: If it will be enabled to start over a program (only if PVR is installed and
configured for this channel).
• Start Over Time margins(Start-End in minutes): Safety margins for start over live tv.
• PVR Activated: If this channel allows local USB recording or not.
• Content Categories: The channel classification.
• Audio Pids: List of available audio pids inside the transport. Needed for audio changes on
the user interface.
• Network Configuration: Indicates how the channel is available:
◦ UDP: Channel available on the network on a multicast group.
◦ HTTP: Channel reflected by the VoDKA system encapsulated on HTTP.
◦ RTSP: Channel reflected by VoDKA encapsulated on RTSP.
◦ URL: Full URL to an external channel.
Now that the channel is created, we must publish it and set the order in the channel list. This order
is configured in Configuration > Servers and selecting the VoDKA Rule that we want to configure
clicking on Channels.

A channel list for video and audio will be shown. This page allows filtering channels by language
and country to ease the management when the number of channels grows bigger.
This page allows to set if a channel is visible or not and place a number to list this channel in the
proper order.
Also, as an extra feature, it is possible to overwrite the multicast channel specified during the
channel creation for debugging/testing purposes.
Welcome Channel

When a session is accessed for the first time, VoDKA.TV allows the platform administrator to force
some contents in the STB. This can be done from Media > Welcome Channel.
This page will show a list of the welcome channels created. By clicking the create button a form will
be show to select the language of the session and the channel from the ones previously created.
• Video On Demand. Video on Demand (VoD) can be added to the platform by using the
VoDKA Management Desktop User Manual. This manual covers the publishing of this VoD
to the final users.
• Available Movies. Through the section Media > Available movies it’s possible to get the
available media on the configured VoDKA Asset Manager metaserver.

The list is a complete list of contents that can be filtered by the following criteria
● Category.
● Genre: obtained directly from the configured VoDKA Asset Manager server.
● Age rating: obtained directly from the configured VoDKA Asset Manager server.
● Number of results.
Also, by clicking on (Date) or (title), the contents are sorted by date or title respectively.
Through this screen, it is also possible to add or remove contents to the static list of recommended
contents. To do this, the Recommend or Remove from recommended link must be clicked. That
list, of static recommendations, consists on a list of contents with the tahiti_recomended collection.
So that, it is also possible to use VoDKA Management Desktop to add or remove contents to the
recommended list, by adding or removing the collection tahiti_recommended.
VoDKA.TV also manages dynamic content recommendation by using a score system provided by
the users. This user puntuation depends on the implementation of the plugin, i.e. the videoclub
plugin could allocate 3 points to a content that has been seen by an user, 2 points when the
content was added to favorites and 1 point when the user views the details of a content.

A list of scores per user and content are stored on the system. These scores are reverted to the
user to increase his user experience in the shape of recommendations. First, VoDKA.TV gets the
user scores and, then, searches for other users which have the same videos as the most scored
and other videos that these users has as most scored or videos that other user (with the same
taste) has rated favourably.
When a plugin (for example videoclub) shows a recommended content, the first recommended
contents will be the static (with the tahiti_recommended collection), and then the dynamic ones.
Categories
Through the section Media > Categories it’s possible to configure the different content categories.
A content category refers the degree of seniority of the content. These grades of seniority are
configurable.
Categories list
The categories are useful for the following aspects:
• To define prices rules (this will be dealt on the BSS section).
• To show contents of the collection type premiere.
The degrees of seniority use creation date for the films, no the content date. It is also important to
note that the degrees of seniority are exclusive, say, if the following levels of seniority aredefined:
Category 1: less than 6 months.
Category 2: less than 3 months.
Category 3: less than 2 hours.

The films that will contain each one are:
Category 1: contents with a creation date between 3 and 6 months.
Category 2: contents with a creation date between 2 hours and 3 months.
Cateogry 3: contents with a creation date of less than 2 hours.
Creating categories
By clicking on the Create button, the creating categories form is accessed:
The following information is requested:
• Name: category name.
• Less than: number indicating years, months, days, hours, minutes or seconds as selected
on the dropdown, and serves to indicate that the category will correspond to the contents
that have a less seniority than indicated in this field.
• Premiere: if this field is checked, the contents with the category will be considered as
Premiere, so this category can be added to the video catalog.
Video Catalog
From the section Contents > Video Catalog it’s possible to configure a tree-shaped collection
catalog in the system, tagged as video catalog. That catalog may be consulted by plug-ins in order
to show it to the end user in a set-top-box.

Catalog configuration
On the left, it is displayed the list of available collections in the VoDKA Asset Manager node
configured (displaying identifier and name) accompanied by special VoDKA.TV collections:
My rents (TAHITI_RENTS): List of registered rented contents in the system, showing just those
contents rented by a higher than 0 price, and currently rented. Those expired rents won’t be
shown. Obviously the shown contents would be different according to the connected user.
Premieres (TAHITI_PREMIERES): List of contents with latest premiere field activated. It will
contain the same contents for every user.
My favorites (TAHITI_FAVORITES): List of contents added to the list of favorites of the user.
Suggestions (TAHITI_RECOMMENDED): Contents suggested to the user, will be formed by

merging static suggestions with dynamic ones. These contents will be user dependent.

These special collections will only have sense used as root collections (they will not work as
nested collections or with nested collections).
Tree shaped catalog with VoDKA Asset Manager collections. In order to add collections to this
catalog press the Add button after selecting desired ones from the list of available collections. In
order to be added as children collections, their parent collection must first be chosen in the catalog.
On the other hand, selecting collections from the catalog and pressing the button Delete will erase
those collections from the catalog (not from VoDKA Asset Manager). Last, selecting collections
from the catalog and pressing buttons Up and Down will make those collections move up or down
in the list.
Editing collection data: The following fields from a collection can be edited:
• Order: The following orders are available:
◦ By title, creation date, date or manual if it’s a VoDKA Asset Manager collection.
◦ By title, creation date, date or renting date if it’s a My rents collection.
◦ By title, creation date or date if it’s Premieres or Suggestions collection.
◦ By title, creation date, date o date when they were added to favorites if it’s
◦ Favorites collection.
• Type of ordering: Ascending or descending.
• New content placing: in manual order it’s possible to specify where new contents, still to
be manually ordered, will appear. The available options are:
◦ Placed at the beginning or the end.
◦ If ordered by title, creation date or date ascending or descending.
• Contents to be returned: A collection can be configured in order to return contents

according several criteria.
◦ With the collection, parent collections and none of its daughter collections.
◦ With the collections and parent collections.

◦ With the collection.
For example, if the categories tree is:

–A
∗ A1
∗ A2
· A21
· A22
· A23
–B
the collection A2 would return the following contents depending on its configuration4 :
• With the collection, with parent collections and none of its daughter
collections: Contents with collection A and A2 but without collections A21,
A22 and A23.
• With the collection and parent collections: contents with collection A and A2.
• With the collection: contents with collection A2
• When this collection will be returned: It may be specified when VoDKA.TV must
takeinto account this collection. The possible criteria are:
• Always.
• Never.
• Only when it has contents.
• Only when it has contents or daughter collections.
Type of ordering: Ascending or descending.
Protected collection: allows set a category as Protected Category. This value can be used by
plug-ins to restrict the access to category contents.
Through the Edit link shown in the screen Catalog configuration, once a collection is being edited,
a list with all the available languages for the collection is obtained. If the collection name is not
configured, by default it will be the collection name in VoDKA Asset Manager. For special

collections its name would be blank.
As a general rule, for selection the name to show in the user interface will follow these rules:
1. If there is a translation for the selected language, then that would be the one used.
2. If there is not a translation for the selected language, then the translation to the default
language would be used.
3. If there is not default translation (not recommended), then a random translation is

chosen.
4. In case of not having any translation, the name would be blank.
Creation of a new translation for a collection
The “creation of a new translation for a collection” screen can be accessed using the Create link.If
during the translation creation process the language is left as empty then this translation would be
used as the default translation, namely, that one that will be shown when the chosen language to
show a collection does not exist.
The Audio on Demand catalog can be configured exactly the same as de VoD Catalog.

Protected target audience
Used to choose which target audience will be mark as “protected”. The end user has the possibility
to activate/deactivate the restricted content option. Any media with the same target audience as
the ones we select in this screen will be filtering according to the end user configuration.
Cover
It is possible to configure which media will be shown in the VoD plugin on the end user. By
accessing Media > Cover, the list of configured content in the cover will be shown.
By clicking on the create button, the cover collection creation form will be shown:

The following fields will be asked:
• Identifier: A unique string identifying the cover collection. In order to be shown as default
on the VoD plugin, this must be called “main”.
• Name: A string for naming the collection. (i.e. main).
• Number of elements: An integer indicating the number of elements that will be shown.
• Collection: The VoD collection where the data will be pulled from.
• Order by: The ordering criteria for the contents.
• Ordering: Ascending / Descending when the “Order by” criteria is not manual.
• New Content: Where to locate the new content.
• Order by (new content): The ordering criteria for the new contents.
• Ordering (new content): Ascending / Descending when the “Order by” criteria is not
manual.

On the right, it will be shown a dynamic list with the result of the selected options. If manual is
selected, the elements can be drag&dropped to the desired location.
Ratings
Definition of the ratings for parental control based on the ratings obtained from the VoDKA Asset
Manager.
When creating a rating, a combo box with the possible ratings will be shown. Only the ratings
added to VoDKA.TV will be shown.
Plugin Configuration
Some of the plugins require aditional configuration. The section Plugin Configuration provides an
entry point for those plugins which require further
WWW
For each STB created on the platform, it is necessary to establish a set of urls for accessing while
using the STB webbrowser.

It is possible to set a tree of content where the leafs are URLs accessible by the STBs
webbrowser. Adding categories creates nodes for the tree and adding URLs sets the leafs.
Also, the name for this URLs can be internationalized by adding the name in several languages
using the lower form.
The requested fields for creating an URL are:
• ID: An id for the url.
• URL: The full URL for the link.
• TOP CSS, LEFT CSS, WIDTH CSS, HEIGHT CSS: By adjusting this values, the
webbrowsing window will be resized according to this values when showing this URL. Can
be left unsetted for default full screen values. The maximun size supported is 1280x720 px.
• Language, Values: Intenationalization goes here. Add as many languages as desired.
Once the form is fullfilled, it is necessary to press the “Save” button to keep the changes.

Guest Services
This form configures the Guest Services url as it may be located on an external server to
VoDKA.TV.
The requested data:
• URL: The full URL where the Guest Services data is located.
• TOP CSS, LEFT CSS, WIDTH CSS, HEIGHT CSS: By adjusting this values, the
webbrowsing window will be resized according to this values when showing this URL. Can
be left unsetted for default values.

3.3. BUSINESS SUPPORT CONFIGURATION

VoDKA.TV provides a BSS systems based on products/packages and subscriptions.
3.3.1.Products
VoDKA.tv allows the creation of products associated to channels/categories.
By clicking new it creates a new product. The fields are self explanatory and we can add as many
categories or channels as we want.

3.3.2.Subscriptions/Sessions
A list of the available sessions on the systems will be displayed allowing to manage which products
each session already has and purchase new ones.
When clicking purchase/new a list of the available products/packages will be shown allowing to
select the desired products assigning them to the selected session.
3.3.3.Permissions Management
For each session created in the middleware it is possible to manage how the end user will get its
user experience according to his contract with the operator.
From the menu “Rooms”, a list of the current valid sessions will be shown.

For each room it can be accessed more detailed info about the history of sessions by clicking on
the view sessions link.
For each session, it can be checked the user consumptions:

And the session current permissions in order to modify them by clicking on the accesses link:

The VoDKA.TV inteface allows the control for:
• Sections allowed: The installed plugins that a user can access on his TV.
• Video Sections allowed: The ratings that the user is allowed to see when purchasing VoD.
• Security options: Allow to set a specific PIN for the user or reset the current one.
• Recording options: Specify if the user is allowed to access the PVR functionality.
• Type of channels accessible: The type of channels that the user is allowed to watch.
• Parental control level: The default parental control level.
• Outputs protection: Specific configuration for HDMI/VGA encryption.
3.3.4.Pricing (Deprecated)
This section is deprecated and will be replaced with the packages/products.
This section describes the configuration of the prices associated to contents, this prices are not
directly associated to each content but price assignation will be made by defining generic rules with
a validity time.

The assignement of prices to contents is performed by the definition of rules. Each one of this rules
has a number of conditions that if fulfilled, the price will be assigned to the content.
The rules are grouped into collections of rules that will be valid during a specific time. Those
validity periods between collections can not overlap.
These rules are applied at the time of do the rental, as there are temporary factors that can change
the final price applied.
Thus, the rules of collections are sets of ordered rules, which will be applied gradually in the time of
doing the rental until one rule that fits the conditions of that rental is found. If no rules of the actual
rules collection matches, then the content price will be associated as 0.

List of rules collection (Calendar)
The rules collections are sets of rules for a period of time during the collection will be valid. By
section Prices > Prices Calendar is possible see all rules collections defined, both as a list as a
graphical calendar.
This screen contains the following elements:
• Graphical calendar with the validity of each of the rules collections. Each of this periods are
represented with a color that the system automatically assigns.
• Through the links Previous year and Next year or entering the year directly in the field
qualified to do so, the system will show the desired calendar. By default, shows the current
year calendar.
• List of defined rules collection, with the same information that displayed in the calendar, but
in a more detailed way:
Color: color to represent the collection of rules in calendar.
Name: name of the collection of rules
Start date: date when the rules collection starts to be valid. If the specified date is dd/MM/yyyy,

then the start date of validity will be exactly dd/MM/yyyy 0:00:00.
Finish date: date when the rules collection stops to be valid. If the specified date is dd/MM/yyyy,
then the end date of validity will be exactly dd/MM/yyyy 23:59:59.
Validity: indicates whether the collection of rules is currently valid or not according
to the period of validity and the current date.
Creation of rules collections
Through the link Create a form for creating new rules collection is accessed. This creation form has
the following data:
• Name: name of the rules collection.
• Start Day: date with format dd/MM/yyyy when the rules collection begins to be valid
(actually the exact date will bedd/MM/yyyy 0:00:00).
• Finish day: date with format dd/MM/yyyy when the rules collection is no longer valid
(actually the exact date will be dd/MM/yyyy 23:59:59).
Both, the start date and the end are mandatory for rules collection, as there must be a
validity period defined.
Once the rules collection is created, this collection will have no associated rule by default.

List of rules
Each one of the rules collection has a number of associated rules. By default, when creating a new
collection, that collection has no associated rule, they have to explicitly be created.
To view the rules associated with a collection of rules you must press the name of the rules
collection.
This screen shows the different rules defined for the collection arranged in order of application .
For each of the rules will be displayed its associated name and the price that applies. Anyway, it is
possible to consult all the details of the rule by dragging the mouse over the name of the rule you
want to view. These details are the following:
• Collection of rules: name of the rules collection to which belongs the rule.
• Name: name of the rule.
• Category: category (level of antiquity) that must have the content for this rule to be applied.
• Genre: genre (obtained from VoDKA Asset Manager) that has to have the content for this
rule to be applied.
• Collections: list of collections (obtained from VoDKA Asset Manager) that must have the
related content to apply this rule. It will check whether the content have all the selected
collections, not only some of them.
• Room: identifier of the room (as are defined in the PMS configured) where the content has
to be rented for this rule to be applied.
• Set-top-box: physical identifier of the set-top-box from where the content has to be rented
for this rule to be applied.
• Periodicity: days of the week or specific days, with a period of associated hours when the

rent has to take place for the rule to apply. For example, Tuesdays from 10:00 to 12:00, or
the day 10/12/2008 from 11:00 to 13:00, or every day from 11:00 to 11:30, or all Friday, etc.
• Price: final price to be applied. This price will be basic units of measurement. The final unit
to be displayed to the user will be the one configured in the generic properties.
All the conditions of the rule, for example, category, genre, collections, etc, are evaluated so that
the content must comply with all defined conditions, fails to meet a few, that is, acts as conditions
AND and not OR. Anyway, if any of the conditions are left blank, then that condition is not taken
into account to select the rule.
Rule creation
The creation of rules of prices is done in two steps, first the data related to the basic values (name,
category, genre, collections, etc) and then the temporal values (period when the rule is valid).
To begin the creation of rules associated with a collection use Create.
Through this link a form will be accessed requesting the following:
• Category: category that the content must have to apply the rule.
• Genre: genre (from the configured VoDKA Asset Manager) the content must have for this
rule to be applied.
• Collections: list of collections (obtained from configured VoDKA Asset Manager) that the
content must have associated to match this rule. All the selected collections must match,
not only one of them.

• Room: identifier of the room (as are defined in the PMS configured) where the content has
to be rented for this rule to be applied.
• Set-top-box: physical identifier of the set-top-box from where the content has to be rented
for this rule to be applied.
• Periodicity: days of the week or specific days, with a period of associated hours when the
rent has to take place for the rule to apply. For example, Tuesdays from 10:00 to 12:00, or
the day 10/12/2008 from 11:00 to 13:00, or every day from 11:00 to 11:30, or all Friday, etc.
• Price: final price to be applied. This price will be basic units of measurement. The final unit
to be displayed to the user will be the one configured in the generic properties.
After entering this data it will be possible to edit the periodicity of the rule. By using the Create
button shown a form requesting the following data will be shown:
• Day: specific day, in format dd/MM/yyyy, when the periodicity will apply.
• Day of the week: day of the week (Monday, Tuesday, . . . ) when the periodicity will apply.
• Start time: start time, in format HH:mm.
• Finish time: finish time, in format HH:mm.
For a periodicity to be valid it must satisfy all values established (day, day of the week, start time
and end time). None of these fields is mandatory.
It can be created as many periodicities as necessary. The rule system will check if the purchase
meets any of these periods so the rule can be applied.
In addition, it is possible to change the position of the rules through the links Up and Down
displayed on the list screen.

4. OPERATION AND MONITORING

VoDKA.TV provides a suite of tool for the operations related to the STBs and to run some checks
over the platform.
4.1. Messaging
VoDKA.TV provides a messaging system that allows the admin to send all kind of warnings or
messages to the STBs. These messages can be used for raising alarms, warn about platform
modifications or even, some special messages, to restart the STBs or set the fire alarm. This is a
powerful utility currently under heavy development so more features are about to come.
This messaging can be accessed through the notifications menu.
Create of a new notification
A form will be shown asking the following data:

• STB List: The whole list of the STBs in the network and the description associated to them.
This list allow the individual selection of STBs.
• Room List: The whole list of the rooms in the platforms. This list allows the selection of a
room and thus, all the STBs inside it.
• Send to all: Sends the message to all the STBs.
• Size of the message: The size that the message will have when shown on the TV screen
of the users.
• Predefined messages: A list with the previously created messages. Regard that some
messages will only work under certain environments.
◦ Reboot: This message will notify the user that the system is going to restart and after a
countdown will restart the box.
◦ Fire Alarm: This message will show the fire alarm with a precofigured url and will block
all the controls of the STB.
• Message content: Free text for creating a message. As html code is supported, it is
possible to add some formatting to the message.
Edit predefined messages
Whenever a message will be frequently used, VoDKA.TV allows to define it as a predefined

message. By clicking on the submenu “Edit predefined messages” it is possible to create and store
a message for send it anytime to the STBs.

The requested data for this form:
• Predefined Messages: Select “New Message” when adding a new message to the
platforms, otherwise, select the message to edit.
• Title identifier: A short string identifying the message.
• Message type: HTML for standard messages, other types are for debugging/testing
purposes.
• Message Size: The size that the message will have on the TV screen of the final users.
• Message Content: A free text field for the content of the message.
5. Logs
VoDKA.TV brings a small diagnosing tool for quickly check the logs for errors. It can be accessed
under “Monitoring”.


5.1. Firmware
The STBs firmware is distributed under the shape of compressed files with the extension .blu.
Each one of this files contain everything needed for the a full upgrade of the box. Only during the
upgrade proccess it is possible to write in the STBs partitions, so that, it is mandatory that the
firmware file contains exactly the needed files and configs to work into a given deployment.
There are two ways for upgrading STBs:
• Manual upgrade: This is the safest way for upgrading the STBs. Each STB is upgraded
one by one by using a USB key. Inside this usb the firmware is decompressed inside a
directory with a special name. Each time the USB is inserted into a STB, this directory’s
name is changed for safety so it is necessary to rename it again.
Example for the WebTV: Considering the files firmware.blu and the directory name
b1us3ns_f4ct0ry_upd4t3_v2, the procedure will be as follows:
1. Decompress the firmware inside the directory:
tar xvzf firmware.blu -C path_to_usb/b1us3ns_f4ct0ry_upd4t3_v2
2. Plug the USB in the STB. The STB will reboot, start the upgrade and then reboot
again fully upgraded. During the upgrade proccess a progress bar will be shown. It
is important to understand that any trouble/shutdown during this proccess can turn
the STB into a brick and it should be remited to the vendor to restore it if possible.
3. Unplug the USB, the directory should be renamed as

b1us3ns_f4ct0ry_upd4t3_v2.done and inside it can be found an log for the update
(update.log) in case that anything went wrong and remote support were required.
4. Rename the directory again to b1us3ns_f4ct0ry_upd4t3_v2 and it is ready to

upgrade a new box.
• Massive upgrade: VoDKA.TV provides an HTTP method for safetely upgrade the STBs
once deployed.
First we create a firmware on VoDKA.tv. Under System > STBs

Once create, we can send it to any service area/household and schedule the upgrade.
5.2. Diagnosis and recovery procedures

The VoDKA.TV middleware provides a series of error codes useful while debugging a problem on
the platform and to make easier the information retrieval from the end user. This errors are:
● 000: This is an unknown error. The error codes default to this when the problem doesn't
match any of the others. Further investigation is recquired as this error is not properly
caught.
● 010: This is a Javascript error. It can imply that there is either a bug in one of the
JavaScripts (in this case it should be easily reproducible and should affect a large number
of users) or a JS couldn't be properly loaded (In most of cases a reboot should solve the
issue in this second case). This can happen under some circumstances like a wrong
download of the JavaScripts from the server or a new plugin deployed without rebooting the
box. The first step for debugging, besides the above RC trick, should be try to find out what
the user was doing when he got the error. i.e. accessing the plugin TV, trying to play a

videoclub media and so on.
● 020: These are internal errors on the VoDKA.TV servers. Rebooting the box does not
grant it to work again as the problem could be persistant. This problem requires further
investigation over the server's logs. Some examples of this problem could be:
○ A user rents a movie and he keeps the "Watch movie" screen open. This rent
finishes and then the user tries to watch it. As the rent is over, the expected answer
from the box doesn't match the server's so it raises this error.
○ Same thing should happen if the cost of a movie changes during the renting
proccess.
○ An error while accessing the DB from the servers can also cause this error to
happen as the answer to the box will be wrong.
Fortunately, all these errors are logged so debugging should be fast.
● 030: This is a timeout from VoDKA.TV it can mean either a network problem (if the network
is saturated) or VoDKA.TV saturation problem. The first case should affect a limited range
of users (the ones under the saturated node) that can go from 1 (if the node is the user's
router) to most of them if the node is one of the headend, the second one can cause
problems to all the users connected to the saturated VoDKA.TV node. It should mean that
the users affected are spread over several networks. A report is required to check where
the issue is.
● 031: This error is caused by a "Connection Refused", it's similar to the previous one but it's
much likely that the problem is located in VoDKA.TV. Several users should be affected. A
report is required to solve the issue.
● 032: A request to VoDKA.TV returns a "Network unreachable". This error raises when the
box is bad configured. Pressing the reset button can solve the issue but it must be taken
into account that, for now, it can cause the user PVR recordings to be erased. It is possible
to solve this issue by connecting to the box but it depends on the circumstances and the
urgency of the user.
● 040: This error raises if the box does not have the right configuration. It can be due to a
bad update on the box. If the firmware version is the correct one, pressing the reset button
should solve the issue.

Besides this error codes, it is possible to get a more detailed information about the error by
entering a remote controller code. This has to be entered while the error page is on the screen and
consists on a symetric combination of the RC colors (red - blue - green - yellow - yellow - green -
blue - red).

6. VoDKATV new management graphical user interface

overview
This chapter is part of the product roadmap and is entitled to provide an overview of the next
product version system graphical user interface. All the concepts, items, and configurations
explained in this operation manual are still valid and present in the next product version as the
main system change is to improve usability at platform operation.
Note that all the designs provided in this chapter are only previous designs and this systems are
still not available.
The new management interface incorporates three different areas, the main menu, the context
menu, and the configurations area. Depending on the user administration rights the main menu
system will provide him access only to the specific allowed sections.
The main menu is always visible and provides three levels deep of access, which makes easier to
find the right place for a specific configuration. Items on this menu are organized by specific groups
of functionality and access profiles being:

● Core configuration
● OSS
● BSS
The context menu provide a second level menu with specific configurations and options for a
menu option.
The configuration area allows the specific management of configurations. It can have two basic
views:
● Form view
● List view
No matter the kind of view, the configurations area shows all the available options about the
selected contents and configures the buttons available or not depending on the status. It also
includes the possibility to filter results or to import/export configurations.


IPTV Middleware Operation Manual

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

IPTV Middleware Operation Manual

Uploaded by

Copyright:

Available Formats

VoDKATV Operation Manual

v1.0 – October 2011

VERSION NUMBER DATE CHANGE AUTHOR CHANGES

1.0 1st October 2011 Interoud Initial version

2.0 8th February 2012 Interoud Legal notices change

SCOPE OF THIS DOCUMENT

Blusens Networks - www.blusensnetworks.com 2 of 64

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEROUD INNOVATION

Blusens Networks - www.blusensnetworks.com 3 of 64

2.1.CORE SYSTEM CONFIGURATION......................................................................................7

2.1.1. System properties.........................................................................................................7

4.2.Diagnosis and recovery procedures.....................................................................................55

5.VoDKATV new management graphical user interface overview..................................................57

Blusens Networks - www.blusensnetworks.com 4 of 64

• VoD: Video on Demand

Blusens Networks - www.blusensnetworks.com 5 of 64

• VoDKA Asset Manager (codename BAHAMAS): metadata management of video on

2. Login & Initial Screens

Blusens Networks - www.blusensnetworks.com 6 of 64

And the initial screen:

3.1. CORE SYSTEM CONFIGURATION

3.1.1. System parameters

Blusens Networks - www.blusensnetworks.com 7 of 64

The following properties can be set:

Blusens Networks - www.blusensnetworks.com 8 of 64

• Locate URL: full URL used by locate plugin.(Experimental)

Blusens Networks - www.blusensnetworks.com 9 of 64

searching or purchasing restricted contents from the STB.

• VHEDController URL: full URL to the static middleware contents.

• TV background application: Full URL to the background advertising application

Blusens Networks - www.blusensnetworks.com 10 of 64

List of supported STBs:

● HED (WebKit) - [Local] - Deprecated

● HED (WebKit) - [Local v2] - Currently used by the BLU:SENS WebTV

● HED (WebKit) - [PROTOTYPE] - Experimental

● GenericPC (Firefox) (Only for testing)

● GenericPC (Generic) (Only for testing)

Blusens Networks - www.blusensnetworks.com 11 of 64

Blusens Networks - www.blusensnetworks.com 12 of 64

information/configuration will be placed here.

Blusens Networks - www.blusensnetworks.com 13 of 64

Blusens Networks - www.blusensnetworks.com 14 of 64

• Annotations server (MAUI): IP or host name of the advanced metainformation server

• Teletext server: IP or host name of the teletext server machine.

Blusens Networks - www.blusensnetworks.com 15 of 64

• EPG available hours: Default number of hours available for EPG.

Blusens Networks - www.blusensnetworks.com 16 of 64

• PMS Property Management System configuration.

The following parameter are required:

• URL: The full URL where the dummy PMS is located.

• Port: The port where Fidelio is listenning.

• Other specific information may be requested depending on the PMS.

• CAS/DRM: Type and URL for the CAS Server.

Blusens Networks - www.blusensnetworks.com 17 of 64

this content servers can be found.

Blusens Networks - www.blusensnetworks.com 18 of 64

• The semantics of this list are:

◦ S_X: VoDKA server IP address or host name.

◦ P_X: a number between 0 and 100 representing VoDKA selection likelihood.

• userIP: set-top-box IP, addressable from VoDKA.TV.

• For example: http://ws.ttv-hlg.terra.com.br/ttvwsmoc_proxy/PlayContent.aspx?

Blusens Networks - www.blusensnetworks.com 19 of 64

• Channels: Set-top-boxes use the following process to tune broadcast channels:

Blusens Networks - www.blusensnetworks.com 20 of 64