Lade Inhalt...

Implementing ETSI standardised RTCP-based Interdestination Media Synchronization

©2011 Masterarbeit 141 Seiten

Zusammenfassung

Inhaltsangabe:Introduction:
This thesis represents the results of my research in synchronization of television during my graduation project. I will describe a solution, which is actually standardized and give a solution on how to implement it in this document.
It is a pleasure to thank the people who made this thesis possible. First of all these are my supervisors Oskar van Deventer and Michael Maruschke, who supported me by reviewing my work and discussion on content. I also would like to thank Ray van Brandenburg and Hans Stokking, who were always open for discussion.
This work was done at TNO Information and communication technology. The part of TNO this thesis is placed has its main research topic in media technologies and content delivery systems. Research is done in cooperation with Dutch and international companies as well, as with international research groups. TNO is also a member in the NGNLab project, which main purpose is Next Generation Networks and topics related to that.
The purpose of this thesis is to create a proof of concept of the synchronization system for IPTV described by ETSI TS 182 027 [2] and ETSI TS 183 063 [1] by using the protocol extension to RTCP from ETSI TS 183 063 Annex W. During planing, implementation and evaluation specifications have to be proofed and requirements, for a sufficient work have to be generated, if the standardized environment is not clear defined on some part of the implementation or not sufficient.
This document should give the reader an overview of the necessary requirements and the way of development of the proof of concept.
This thesis is divided into seven chapters. The first chapters are the theoretical base, followed by the planing and evaluation of the prototyped IDMS system.
In chapter two an overview of the thesis background and necessary protocols needed for communication is given. This is completed by a description of the network framework, which will be the platform for the synchronization approach. The extension for television usage of the network described in chapter two is explained in chapter three.
The Software analyzed for the usage in the prototyped implementation is described in chapter four. The necessary modifications and extensions to this software and structure of the applications used to build the environment for the described implementation completes the theoretical part of the thesis. Chapter five shows these software planing.
Chapter six gives and overview of […]

Leseprobe

Inhaltsverzeichnis


Torsten Löbner
Implementing ETSI standardised RTCP-based Interdestination Media Synchronization
ISBN: 978-3-8428-2046-3
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2011
Zugl. Deutsche Telekom Fachhochschule Leipzig, Leipzig, Deutschland, MA-Thesis /
Master, 2011
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2011

I
Abstract
In the last years researches in television systems have become more and more a migration
from isolated networks to a combined network of internet, telecommunication, television
and other services. One of the main aspects in that research topic is to guarantee, that
the user experience will be the same or better then the user expects from a common
television system
The purpose of this thesis is to show a possible protocol implementation for a television
system with a packet oriented underlying network. The thesis will show, that ETSI TS
183 063 [1] Annex W specified protocol extension to Realtime Control Protocol will extend
a common known network system to reach the goals for users quality needs.
Copyright c 2011 by Torsten L¨obner
All rights reserved. No part of the material protected by this copyright may be reproduced
or utilized in any form or by any means, electronic or mechanical, including photocopying,
recording or by any information storage and retrieval system, without the permission from
the author, Hochchule f¨
ur Telekommunikation Leipzig and Nederlandse organisatie voor
toegepast natuurwetenschappelijk onderzoek (TNO).

II
Contents
Abstract
I
Glossary
VI
Nomenclature
X
List of Figures
XI
List of Tables
XIV
1 Introduction
1
1.1
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Research Purpose and Related Work . . . . . . . . . . . . . . . . . . . . .
1
1.3
Subject of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.4
Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.5
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Theoretical framework
3
2.1
Next generation TV service . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
Watching TV together . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Evolution of TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.3
Quality needs for Social TV . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Protocols
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Session Description Protocol . . . . . . . . . . . . . . . . . . . . . .
9
2.2.4
Real-Time Transport Protocol . . . . . . . . . . . . . . . . . . . . . 10
2.2.5
MPEG-TS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.6
Real-Time Transport Control Protocol . . . . . . . . . . . . . . . . 13
2.2.6.1
Sender Report . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.6.2
Receiver Report
. . . . . . . . . . . . . . . . . . . . . . . 14
2.2.6.3
Receiver Summary Information . . . . . . . . . . . . . . . 14
2.2.6.4
Session Description . . . . . . . . . . . . . . . . . . . . . . 16
2.2.6.5
Extended Report . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.6.6
BYE Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.6.7
Measuring QoS values using RTCP . . . . . . . . . . . . . 19
2.2.6.8
RTCP architecture for multicast streaming . . . . . . . . . 20

Contents
III
2.3
Internet Protocol Multimedia Subsystem . . . . . . . . . . . . . . . . . . . 22
2.3.1
Basic call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4
IMS-based IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1
Overview of the Architecture
. . . . . . . . . . . . . . . . . . . . . 27
2.4.2
Watching TV using IMS-based IPTV . . . . . . . . . . . . . . . . . 28
3 Social TV made with IMS-based IPTV
32
3.1
Interdestination Media Synchronization . . . . . . . . . . . . . . . . . . . . 32
3.2
Synchronization of multiple media streams . . . . . . . . . . . . . . . . . . 33
3.3
Synchronization in IMS-based IPTV . . . . . . . . . . . . . . . . . . . . . 34
3.3.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.2
Data flow for synchronization . . . . . . . . . . . . . . . . . . . . . 38
3.3.3
RTCP part of synchronized IMS-based IPTV . . . . . . . . . . . . 39
3.4
Getting the clients in sync . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.1
Finding non-synchronized clients . . . . . . . . . . . . . . . . . . . 40
3.4.2
Calculation of the Presentation Timestamp . . . . . . . . . . . . . . 43
3.4.3
Calculation of the presentation delay . . . . . . . . . . . . . . . . . 44
4 Existing Software
45
4.1
IMS Environment (Open IMS) . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2
Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3
Multimedia players and libraries . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4
SIP-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1
linphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.2
UCT IMS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5
NTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6
Library for mathematical calculations (GSL) . . . . . . . . . . . . . . . . . 50
5 Structure of the Implementation of IDMS for IMS-based IPTV
51
5.1
Library for sending RTP and RTCP data . . . . . . . . . . . . . . . . . . . 51
5.1.1
Set local address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1.1
rtp synced session set local addr . . . . . . . . . . . . . . 52
5.1.1.2
msas session set local addr
. . . . . . . . . . . . . . . . . 53
5.1.2
Set remote address . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.2.1
msas session set server addr . . . . . . . . . . . . . . . . . 53
5.1.2.2
rtp synced session set remote addr full . . . . . . . . . . . 54
5.1.3
Create RTCP reports . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3.1
rtcp xr idms init . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3.2
make sr xr . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.1.3.3
make rr xr . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.3.4
make xr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.4
Send RTCP messages . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.4.1
msas session rtcp send . . . . . . . . . . . . . . . . . . . . 59
5.1.4.2
rtp session rtcp sync send . . . . . . . . . . . . . . . . . . 60

Contents
IV
5.1.4.3
msas rtcp send . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.5
Receive RTCP messages . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.6
Parse content of an XR report block . . . . . . . . . . . . . . . . . 63
5.1.7
Get pointer to the content of an XR IDMS report block . . . . . . . 63
5.1.8
Parse RTCP payload . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.9
Insert content into linked lists . . . . . . . . . . . . . . . . . . . . . 65
5.1.9.1
push to timestack
. . . . . . . . . . . . . . . . . . . . . . 65
5.1.9.2
insert ts to tcs . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.9.3
insert into tcs . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.9.4
set tcs item . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.9.5
msas session add client . . . . . . . . . . . . . . . . . . . . 68
5.1.9.6
msas session insert tcs item . . . . . . . . . . . . . . . . . 69
5.1.9.7
msas session insert tcs item msci . . . . . . . . . . . . . . 70
5.1.10 Get contents of linked lists . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.10.1 get item from timestack . . . . . . . . . . . . . . . . . . . 71
5.1.10.2 get item from tcs . . . . . . . . . . . . . . . . . . . . . . . 71
5.1.10.3 get last item from tcs . . . . . . . . . . . . . . . . . . . . 72
5.1.10.4 msas session get clients . . . . . . . . . . . . . . . . . . . 72
5.1.10.5 msas session get client by ssrc . . . . . . . . . . . . . . . . 72
5.1.10.6 msas session get client by msci . . . . . . . . . . . . . . . 73
5.1.10.7 msas session get tcs item . . . . . . . . . . . . . . . . . . 73
5.1.10.8 msas session get last tcs item . . . . . . . . . . . . . . . . 74
5.2
Media Delivery Function - RTP-sender part . . . . . . . . . . . . . . . . . 75
5.2.1
GStreamer Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.2
Thread for media encoding . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.3
Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.4
RTP-sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.5
Primary function of the application . . . . . . . . . . . . . . . . . . 79
5.3
Media Delivery Function - MSAS part . . . . . . . . . . . . . . . . . . . . 80
5.3.1
Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.2
RTCP server thread . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3.3
Primary function of the application . . . . . . . . . . . . . . . . . . 83
5.4
SC application on user side . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.1
GStreamer Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.2
Callback function for starting IPTV-Session . . . . . . . . . . . . . 85
5.4.3
Callback function for terminating IPTV-Session . . . . . . . . . . . 85
5.4.4
Function for starting the Decoder . . . . . . . . . . . . . . . . . . . 86
5.4.5
RTP receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.5
SC application on provider side . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.1
RTP receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.2
RTP sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.5.3
Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.4
Primary function of the application . . . . . . . . . . . . . . . . . . 92
5.6
Transcoder application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Contents
V
5.6.1
GStreamer Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.6.2
RTP receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.3
RTP sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.6.4
Media transcoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.6.5
Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . 96
5.6.6
Primary function of the application . . . . . . . . . . . . . . . . . . 97
5.7
Multistream source transcoder . . . . . . . . . . . . . . . . . . . . . . . . . 98
6 Evaluation
100
6.1
Evaluation of the protocol implementation . . . . . . . . . . . . . . . . . . 101
6.2
Evaluation of the applications . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.1
Timestamp estimation . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2.2
Measuring using one PC . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.3
Measuring using two PC . . . . . . . . . . . . . . . . . . . . . . . . 106
6.2.4
Measuring between two clients using VLC . . . . . . . . . . . . . . 107
6.2.5
Measuring the IDMS implementation . . . . . . . . . . . . . . . . . 108
6.2.5.1
Measurment with enabled pausing . . . . . . . . . . . . . 108
6.2.5.2
Measurment with disabled pausing . . . . . . . . . . . . . 111
6.2.5.3
Synchronization of two SC on one PC . . . . . . . . . . . 112
7 Conclusion and Future Work
117
7.1
The IDMS implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2
Recomandations for the protocol description . . . . . . . . . . . . . . . . . 117
7.3
Possible Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.1
Library
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.2
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.3
RTP-Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.4
Transcoder
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.5
MSAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4
Research questions for future work . . . . . . . . . . . . . . . . . . . . . . 119
Bibliography
v

VI
Glossary
Notation
Description
3GPP
3rd Generation Partnership Project
A
Authentication
AAC
Advanced Audio Coding
AS
Application Server
BC
Broadcast Session
BGCF
Breakout Gateway Control Function
CoD
Content on Demand
CRS
Content Recommendation Services
CSCF
Call Session Control Functions
CSRC
Contributing Source Identifier
CSV
Comma-Separated Values
DLRR
Delay Since Last Receiver Report Block
DLSR
Delay Since Last Sender Report
DVB
Digital Video Broadcast
DVB-C
Digital Video Broadcast - Cable
DVB-T
Digital Video Broadcast - Terrestrial
DVD-S
Digital Video Broadcast - Satellite
ECF
Elementary Control Function
EFF
Elementary Forwarding Function
ETSI
European Telecommunications Standards Institute
FT
Feedback Target

Glossary
VII
Notation
Description
GSL
GNU Scientific Library
GUI
Graphical User Interface
HD
High Definition
HSS
Home Subscriber Server
HTTP
Hypertext Transfer Protocol
I-BGF
Interconnect Border Gateway Function
I-CSCF
Interrogation - Call Session Control Functions
IDMS-RB
Inter Destination Media Synchronization Report
Block
IMS
Internet Protocol Multimedia Subsystem
IMS MGW Internet Protocol Multimedia Subsystem Media
Gateway
IP
Internet Protocol
IPTV
Internet Protocol Television
LSR
Last Sender Report
MCF
Media Control Functions
MDF
Media Delivery Function
MF
Media Function
MGCF
Media Gateway Control Function
MPEG
Moving Picture Experts Group
MPEG-TS
Moving Picture Experts Group - Transport Stream
MRF
Media Resource Function
MRFC
Media Resource Function Controller
MRFP
Media Resource Function Processor
MS
Media Sender
MSAS
Media Synchronization Application Server
MSCI
Media Stream Correlation Identifier

Glossary
VIII
Notation
Description
NGN
Next Generation Networks
NTP
Network Time Protocol
NTP TS
Network Time Protocol Time Stamp
OWD
One-Way Delay
P-CSCF
Proxy - Call Session Control Functions
PC
Personal Computer
PRACK
Provisional Response Acknowledgment
PT
Payload Type
PTP
Precision Time Protocol
PVR
Personal Video Recorder
QoE
Quality of Experience
QoS
Quality of Service
RR
Receiver Report
RRT
Receiver Reference Time Report Block
RSI
Receiver Summary Information
RTC
Real Time Clock
RTP
Real-Time Transport Protocol
RTP TS
RTP Timestamp
RTSP
Real Time Streaming Protocol
RTT
Round Trip Time
S-CSCF
Serving - Call Session Control Functions
SC
Synchronization Client
SC'
Transcoder
SCF
Service Control Function
SD
Standard Definition
SDES
Session Description
SDF
Service Discovery Function
SDH
Synchronous Digital Hierarchy

Glossary
IX
Notation
Description
SDP
Session Description Protocol
SIP
Session Initiation Protocol
SLF
Service Locator Function
SPST
Synchronization Packet Sender Type
SR
Sender Report
SS#7
Signaling System No. 7
SSF
Service Selection Function
SSRC
Synchronization Source Identifier
TAI
Targeted Advertisement Injection
TCS
Time Correlation Stack
TISPAN
Telecommunications and Internet Converged Ser-
vices and Protocols for Advanced Networks
TNO
Nederlandse organisatie voor toegepast natuurweten-
schappelijk onderzoek
UA
User Agent
UE
User Equipment
UPSF
User Profile Server Function
VLC
Video Lan Client
VLM
Video Lan Media Server
VoIP
Voice over Internet Protocol
XML
Extensible Markup Language

X
Nomenclature
i
number of the client
n
amount of clients
RT P T S
11
i
RTP timestamp of the first packet used for approximation
RT P T S
12
i
RTP timestamp of the second packet used for approximation
RT P T S
1
i
RTP timestamp that belongs to the time that is approximated
RT T
1
i
RT T
i
of first packet used for approximation
RT T
2
i
RT T
i
of second packet used for approximation
t
11
i
t
1
i
of first packet used for approximation
t
12
i
t
1
i
of second packet used for approximation
t
0
time of send the RTP-packet by media server
t
2
time of send SR
1
in multicast mode to the clients
t
6
time of send SR
1
in unicast mode to MSAS
t
7
time of reception of SR
1
by MSAS
t
1
i
time of reception the RTP-packet by Client
i
t
3
i
time of reception of SR
1
by Client
i
t
4
i
time of send RR
1
by Client
i
t
5
i
time of reception of RR
1
by MSAS sent by Client
i

XI
List of Figures
2.1
TCP/IP-stack and the protocols for IPTV . . . . . . . . . . . . . . . . . .
6
2.2
Typical clock synchronization using NTP[6] . . . . . . . . . . . . . . . . .
7
2.3
NTP frame[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4
Basic message format of the Session Initiation Protocol[7, page 264] . . . .
9
2.5
SDP contents for a TV session . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6
RTP frame [14, 15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7
Frame structure for mpeg-ts frames [16] . . . . . . . . . . . . . . . . . . . . 12
2.8
RTCP-message: Sender Report[14] . . . . . . . . . . . . . . . . . . . . . . 13
2.9
RTCP-message: Receiver Report[14] . . . . . . . . . . . . . . . . . . . . . 14
2.10 RTCP-message: Session Description[14] . . . . . . . . . . . . . . . . . . . . 16
2.11 RTCP-XR-message: Receiver Reference Time Report Block[20] . . . . . . . 17
2.12 RTCP-XR-message: Delay Since Last Receiver Report Block[20] . . . . . . 17
2.13 RTCP-XR-message: Inter Destination Media Synchronization Report Block[20] 18
2.14 RTCP-message: BYE[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.15 Structure for a RTCP multicast environment[22] . . . . . . . . . . . . . . . 21
2.16 Structure for a RTCP multicast environment [22] extend for usage with a
Transcoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.17 IMS overview [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.18 Basic call flow for a audio and video session using IMS [27] . . . . . . . . . 25
2.19 Overview of IMS-based IPTV architecture [2] . . . . . . . . . . . . . . . . 27
2.20 Start-up of User Equipment[27][2] . . . . . . . . . . . . . . . . . . . . . . . 28
2.21 Initialization of Broadcast Session[27][2]
. . . . . . . . . . . . . . . . . . . 29
2.22 Establishing of the delivery channel[27][2] . . . . . . . . . . . . . . . . . . . 29
2.23 Modification of the Broadcast Session[27][2] . . . . . . . . . . . . . . . . . 30
2.24 Release of the Broadcast Session[27][2] . . . . . . . . . . . . . . . . . . . . 31
3.1
Packet flow and presentation overview for group synchronization [31] . . . 32
3.2
Synchronization done between SC and MSAS without Transcoder [27, 2] . 34
3.3
Synchronization done between SC and MSAS with Transcoder [27, 2] . . . 35
3.4
Synchronization done on provider side without Transcoder [27, 2] . . . . . 36
3.5
Synchronization done on provider side with Transcoder [27, 2] . . . . . . . 37
3.6
Synchroniyation in IMS-based IPTV[2] . . . . . . . . . . . . . . . . . . . . 38
3.7
Packet flow for synchronization in IMS-based IPTV . . . . . . . . . . . . . 39
3.8
Additional packet flow for finding unsynchronized clients . . . . . . . . . . 40
4.1
overview of the Open IMS structure[35] . . . . . . . . . . . . . . . . . . . . 45

List of Figures
XII
5.1
Function: rtp synced session set local addr . . . . . . . . . . . . . . . . . . 52
5.2
Function: msas session set local addr . . . . . . . . . . . . . . . . . . . . . 53
5.3
Function: msas session set server addr . . . . . . . . . . . . . . . . . . . . 53
5.4
Function: msas session set server addr . . . . . . . . . . . . . . . . . . . . 54
5.5
Function: rtcp xr idms init . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6
Function: make sr xr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.7
Function: make rr xr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.8
Function: make xr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.9
Function: msas session rtcp send . . . . . . . . . . . . . . . . . . . . . . . 59
5.10 Function: rtp session rtcp sync send . . . . . . . . . . . . . . . . . . . . . 60
5.11 Function: msas rtcp send . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.12 Function: msas session rtcp recv . . . . . . . . . . . . . . . . . . . . . . . . 62
5.13 Function: xr report block parse . . . . . . . . . . . . . . . . . . . . . . . . 63
5.14 Function: rtcp XR sync get report block . . . . . . . . . . . . . . . . . . . 63
5.15 Function: rtp session parse rtcp payload . . . . . . . . . . . . . . . . . . . 64
5.16 Function: push to timestack . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.17 Function: insert ts to tcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.18 Function: insert into tcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.19 Function: set tcs item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.20 Function: msas session add client . . . . . . . . . . . . . . . . . . . . . . . 68
5.21 Function: insert into tcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.22 Function: msas session insert tcs item msci . . . . . . . . . . . . . . . . . . 70
5.23 Function: get item from timestack
. . . . . . . . . . . . . . . . . . . . . . 71
5.24 Function: msas session insert tcs item msci . . . . . . . . . . . . . . . . . . 71
5.25 Function: get last item from tcs . . . . . . . . . . . . . . . . . . . . . . . . 72
5.26 Function: msas session get clients . . . . . . . . . . . . . . . . . . . . . . . 72
5.27 Function: msas session get client by ssrc . . . . . . . . . . . . . . . . . . . 73
5.28 Function: msas session get client by msci . . . . . . . . . . . . . . . . . . . 73
5.29 Function:msas session get tcs item . . . . . . . . . . . . . . . . . . . . . . 74
5.30 Function: msas session get last tcs item . . . . . . . . . . . . . . . . . . . 74
5.31 GStreamer pipeline for server application . . . . . . . . . . . . . . . . . . . 75
5.32 Media server - media encoder thread . . . . . . . . . . . . . . . . . . . . . 76
5.33 Media server - gui thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.34 Media server - RTP sender thread . . . . . . . . . . . . . . . . . . . . . . . 78
5.35 Media server - main function . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.36 Media server - gui thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.37 RTCP server thread of the MSAS . . . . . . . . . . . . . . . . . . . . . . . 82
5.38 Main function of the MSAS . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.39 GStreamer pipeline for decoding and presentation . . . . . . . . . . . . . . 84
5.40 Callback function for starting the IPTV functions . . . . . . . . . . . . . . 85
5.41 Callback function for stoping the IPTV functions . . . . . . . . . . . . . . 85
5.42 Function for starting the Decoder . . . . . . . . . . . . . . . . . . . . . . . 86
5.43 RTP receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.44 RTP receiver of provider side SC . . . . . . . . . . . . . . . . . . . . . . . 89

List of Figures
XIII
5.45 RTP sender of provider side SC . . . . . . . . . . . . . . . . . . . . . . . . 90
5.46 Provider side SC - GUI thread . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.47 Main fucntion of provider side SC
. . . . . . . . . . . . . . . . . . . . . . 92
5.48 Gstreamer pipeline of the transcoder . . . . . . . . . . . . . . . . . . . . . 93
5.49 RTP receiver of the transcoder
. . . . . . . . . . . . . . . . . . . . . . . . 94
5.50 RTP sender of the transcoder . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.51 Transcoder function of the transcoder application . . . . . . . . . . . . . . 96
5.52 Transcoder - GUI thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.53 Main function of the transcoder . . . . . . . . . . . . . . . . . . . . . . . . 97
5.54 GStreamer pipeline for multisource transcoder . . . . . . . . . . . . . . . . 99
6.1
XR IDMS reports measured with Wireshark . . . . . . . . . . . . . . . . . 101
6.2
Estimation of the received presentation timestamps . . . . . . . . . . . . . 103
6.3
Estimation of the received presentation timestamps (zoomed)
. . . . . . . 104
6.4
Test set for proving the instantiation of library and client . . . . . . . . . . 105
6.5
Measurement results for two instances of the SC . . . . . . . . . . . . . . . 105
6.6
Test set using two PC for measuring . . . . . . . . . . . . . . . . . . . . . 106
6.7
Measurement without MSAS on two PC . . . . . . . . . . . . . . . . . . . 106
6.8
Reference measurement with VLC on two PC . . . . . . . . . . . . . . . . 107
6.9
Measurement with MSAS on two PC - pausing enabled . . . . . . . . . . . 108
6.10 Results IDMS measurement 1 . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.11 Reference measurement 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.12 Reference measurement 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.13 Reference measurement 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.14 Estimation Error - disabled NTP client . . . . . . . . . . . . . . . . . . . . 116

XIV
List of Tables
2.1
Synchronization Packet Sender Type . . . . . . . . . . . . . . . . . . . . . 18
4.1
GStreamer Modules for ETSI IDMS infrastructure . . . . . . . . . . . . . . 48
6.1
Useful Wireshark filters for IDMS XR reports . . . . . . . . . . . . . . . . 102
6.2
Absolute error between received timestamps and estimated timestamps . . 104
6.3
Measurement results using two clients with enabled pausing . . . . . . . . 109
6.4
Measurement results using two clients with dissabled pausing . . . . . . . . 111
6.5
Results of measurement 3 and 4 . . . . . . . . . . . . . . . . . . . . . . . . 113

1
1 Introduction
1.1 Preface
This thesis represents the results of my research in synchronization of television during
my graduation project. I will describe a solution, which is actually standardized and give
a solution on how to implement it in this document.
It is a pleasure to thank the people who made this thesis possible. First of all these are my
supervisors Oskar van Deventer and Michael Maruschke, who supported my by reviewing
my work and discussion on content. I also would like to thank Ray van Brandenburg and
Hans Stokking, who were always open for discussion.
1.2 Research Purpose and Related Work
This work was done at TNO Information and communication technology. The part of
TNO this thesis is placed has its main research topic in media technologies and content
delivery systems. Research is done in cooperation with Dutch and international companies
as well, as with international research groups. TNO is also a member in the NGNLab
project, which main purpose is Next Generation Networks and topics related to that.
1.3 Subject of this Thesis
The purpose of this thesis is to create a proof of concept of the synchronization system for
IPTV described by ETSI TS 182 027 [2] and ETSI TS 183 063 [1] by using the protocol
extension to RTCP from ETSI TS 183 063 Annex W. During planing, implementation
and evaluation specifications have to be proofed and requirements, for a sufficient work
have to be generated, if the standardized environment is not clear defined on some part
of the implementation or not sufficient.
This document should give the reader an overview of the necessary requirements and the
way of development of the proof of concept.

1.4 Thesis Outline
2
1.4 Thesis Outline
This thesis is divided into seven chapters. The first chapters are the theoretical base,
followed by the planing and evaluation of the prototyped IDMS system.
In chapter two an overview of the thesis background and necessary protocols needed for
communication is given. This is completed by a description of the network framework,
which will be the platform for the synchronization approach. The extension for television
usage of the network described in chapter two is explained in chapter three.
The Software analyzed for the usage in the prototyped implementation is described in
chapter four. The necessary modifications and extensions to this software and structure
of the applications used to build the environment for the described implementation com-
pletes the theoretical part of the thesis. Chapter five shows these software planing.
Chapter six gives and overview of the measurements for proving, that the created imple-
mentation works sufficient. This is completed by the summary in chapter eight.
1.5 Document conventions
This thesis follows the following conventions:
· Important terms are italicized when first used, like Quality of Service (QoS).
· All code fragments are highlighted like function or in an verbatim environment.
· Names of functions are marked with trailing parentheses. Example: function().
· References are made like chapter 2, or figure 2.19, which indicates the type and level
the reference points to.
· Figures and tables are numbered on a per chapter basis.
· References to figures and tables are made without page numbers, except the figure
or table in question is more than 3 pages away from the reference.
· Footnotes are numbered consecutively from the beginning to the end of the docu-
ment.

3
2 Theoretical framework
This chapter will give a summarized overview of the background of the thesis and the
theoretical basics needed for planing and implementation of the prototyping implementa-
tion.
2.1 Next generation TV service
2.1.1 Watching TV together
With the progress made in the communication systems around the world, we are now able
talk or chat with people on the other side of the world in a high quality. TV broadcasts
with sports, movies or TV shows brought people from the past till now to talk about the
seen things. Bringing this together to a solution, where the client gets TV and is able to
communicate about the contents with friends is the main goal of research on social TV.
The Telecommunications and Internet Converged Services and Protocols for Advanced
Networks (TISPAN) group, as a part of the European Telecommunications Standards
Institute (ETSI) has specified IMS-based Internet Protocol Television (IPTV) (see: [2] and
[1]) as an addition to the Internet Protocol Multimedia Subsystem (IMS). This framework
supports services for communication and presence as well as services needed for television.
These frameworks are discussed later in section 2.3. First of all some background on how
TV systems have evolved till now are given in the next point, which is finalized by a
summary on quality descriptions for social TV.
2.1.2 Evolution of TV
At the beginning of television broadcasts, the content was delivered by as radio signals.
Later these signals were also broadcasted via satellite and cable systems. By using these
systems there was no need for the content provider to think about quality differences
between the receivers. The hole structure was using analog signals and at the clients was
no need for a preprocessing. Users of that TV systems got to know that it is possible to
talk about the things happened on TV, almost during the show they saw. If there was
the same system
1
used, no delay was recognized by the viewers.
The following generation of TV systems used digital system, which need special prepro-
cessing before sending and preprocessing before presentation. One of these systems is
1
radio signal, satellite system or cable system as broadcast system

2.1 Next generation TV service
4
Digital Video Broadcast (DVB). There are three main systems Digital Video Broadcast -
Terrestrial (DVB-T), Digital Video Broadcast - Satellite (DVD-S), Digital Video Broad-
cast - Cable (DVB-C) used, which have different preprocessing. This fact leads to a higher
delay between these systems and a delay between different receiver types of the same sys-
tem could also have a different playout time.
In the mean time data services reached the main bandwidth in communication. At this
point the telecommunication networks of the next generation were planed. One of them
is IMS, which is a framework inside of the Next Generation Networks (NGN). IMS is
a very flexible framework for implementation of services and their administration. This
high flexibility makes this framework the perfect choice to give the users of such networks
the ability to watch TV from the same network as they got voice, chat internet and other
services. It also leads to a high interoperability between content providers at low costs.
IMS is described in detail in section 2.3.
The usage of NGN depends on a IP-based network, which runs best with a packed ori-
ented lower layer. Data connections where made as data links in synchronized networks
like Synchronous Digital Hierarchy (SDH) and have now be moved to a packet oriented
network. Such networks have one big disadvantage for television services. Data streams
are divided into packets, which are transmitted with different delays. This is a result of
the per packet scheduling witch is done in packet oriented networks. For further informa-
tion on that topic see [3].
TV over the internet is called IPTV, which was first used as a simple broadcast of TV
content over the internet. At this point it is possible, that users are not viewing the
content at the same time. Talking about the content has become a worse, because the
opponent of the talk knows things, that will happen later. To face this problem a network
has to be designed, that gives the users the known experience of viewing. This makes
it necessary to find values for the quality, that could measured and compared to fixed
values. As a result there should be a indication of good or bad quality. Two well known
quality parameters to solve this problem are described in the next point.
2.1.3 Quality needs for Social TV
The main description for quality in communication networks is described by Quality of
Service (QoS). This is not only one value it is a complete description of parameters of
the service. In the past telecommunication networks used synchronous networks, which
are optimized for realtime communication. This networks are not very cost-efficient and
scalable. For that reasons modern communication networks are packet oriented, which
makes them flexible and effective in the usage of their bandwidth. For the usage of
telecommunication services over this packet oriented networks new systems for realising
QoS are needed and QoS has become one of the most important factors during network
development. Delay between sender and receiver, jitter and bandwidth are not only in

2.1 Next generation TV service
5
telecommunication networks important to solve these problems. For television services
these values are also important, with the difference that the delay between sender and
receiver is not that important then the delay between the receivers, because mostly mul-
ticast systems are used.
Quality of Experience (QoE) is related to the in the last section described QoS. QoE is
no description of the parameters needed by the service, it is the experience the user has
during the usage of the service. This could differ between the content of the same service.
In practice mostly QoE is measured and QoS parameters are generated as a result of such
a measurement.
For social TV the important value for Quality is the delay in presentation between each
receiver. This value should lead to the QoS requirements.
"While currently telecom operators are aiming at the synchronization level
found in telecommunication tests (150ms) our results show that voice chat-
ters only start noticing differences above 2 seconds delays. Most text chatters
do not notice synchronization differences between 0 and 4 seconds, however
active text chatters notice synchronization differences similar to when using
voice chat. As the highest levels of togetherness were also observed with ac-
tive text chatters and all voice chatters, we recommend synchronization of
approximately 1 second (which was not noticeable by this group) for a seam-
less shared experience. These results put into doubt the 150ms value from
telecommunications research as the target synchronization bound required for
social video watching applications. A first implication for software designers
is that they can concentrate on implementing simpler mechanisms that aim at
a synchronization level of 1 second (which was not noticeable by this group)
for a seamless shared experience. These results put into doubt the 150ms value
from telecommunications research [...]"[4]
This leads to a maximum delay between each receivers presentation of the same video
frame of 1s, that has to be evaluated with the solution described in this thesis.

2.2 Protocols
6
2.2 Protocols
IMS uses a packet oriented network, based on Internet Protocol (IP). The necessary
protocols for describing an establishment, modification, termination and the main point
of view the synchronization are shown in figure 2.1.
Ethernet
MAC
IP
TCP
UDP
SIP
HTTP RTSP RTP RTCP
MPEG-TS
XCAP
Layer 1
Layer 2
Layer 3
Layer 4
Layer 5
Figure 2.1:
TCP/IP-stack and the protocols for IPTV
These protocols are described in the following subsections.
2.2.1 Network Time Protocol
An important step in synchronization is time measurement. To get a correct timestamp
all clocks have to be synchronized. One solution for that purpose is Precision Time Pro-
tocol (PTP) as described in [5]. It describes a solution for clock synchronization with a
low error in smaller networks. For synchronizing larger networks Network Time Protocol
(NTP), as described in [6], is mostly used, because it supports asymmetric delays between
server and client. Another advantage to PTP is, that client and server are available as
open source software. For the IDMS, described by ETSI TISPAN, it is also mandatory to
synchronize all clients clocks using NTP and signaling the source to the application level
Media Synchronization Application Server (MSAS). How these clocks are synchronized is
described in figure 2.2.

2.2 Protocols
7
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Timestamp generated
org
rec
xmt
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Timestamp generated
org
rec
xmt
t1
t2
t3
t4
t5
t6
t7
t8
t1 = clock
t4 = clock
t5 = clock
t8 = clock
t2 = clock
t3 = clock
t6 = clock
t7 = clock
0
0
T1
t3<>0?
T4
t1==T1?
T3
T4
T5
t7<>T3?
T8
t5==T5?
T1
T2
0
T1
T2
T3
t5<>T1?
T6
t3==T3?
T5
T6
T7
t1
0
0
t3
t1
t2
t5
t4
t3
t5
t6
t7
T0
T0
T0
t1
0
0
T0
t3
t1
t2
T0
T0
t5
t4
t3
T0
t5
t6
t7
T0
Figure 2.2:
Typical clock synchronization using NTP[6]
First the clients sends a packet with its local time (Reference Timestamp - see figure 2.3)
and the time of sending the packet (Origin Timestamp - see figure 2.3). The server adds
the time of reception (Receive Timestamp - see figure 2.3) and the time of sending the
packet back to the client (Transmission Timestamp - see figure 2.3) to the packet and
sends it back to the client. The client is now able to calculate a new local time, which is
used to do all the step a second time. With all these times the client is able to calculate
the new local time, the clock drift and the average computation time of the server. This
algorithm is explained in RFC1305[6]. For the IDMS implementation it only necessary
to know, that the usage of NTP improves the clock accuracy but it could not be used for
every timestamp, because of the bandwidth usage, which leads to an error made, because
of the existing clock drift every Real Time Clock (RTC) has.

2.2 Protocols
8
0
7
15
23
31
LI
VN
Mode
Stratum
Poll
Precision
Root Delay
Root Dispersion
Reference ID
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Extension Field 1
Extension Field 2
Key Identifier
dgst
Figure 2.3:
NTP frame[6]
Figure 2.3 shows the NTP frame used for clock synchronization. A more detailed
description and the description of the necessary local registers (variables) of server and
client can be found in RFC1305[6].
2.2.2 Session Initiation Protocol
The Session Initiation Protocol (SIP) is described by RFC3261 - RFC3265 ([7, 8, 9, 10,
11]). It is mostly used for creation, modification and termination of multimedia sessions.
SIP is encapsulated in UPD-datagrams, because of its Three-Way-Handshake, but it is
also possible to use it in combination with TCP.
SIP is used for signaling in Voice over Internet Protocol (VoIP) based telecommunication
systems as well as modified in the IMS. It is the replacement of Signaling System No. 7
(SS#7) for internet based communication.

2.2 Protocols
9
INVITE sip:alice@open-ims.test SIP/2.0
VIA:SIP/2.0/UDP10.10.125.123
Call-ID:1234567890@testbed.open-ims.test
From:<sip:bob@open-ims.test>
To:Alice<sip:alice@open-ims.test>
CSeq:1 INVITE
Subject: Alice, come here.
Content-Type:application/sdp
Content-Length:885
<CRLF>
Start Line
General Header
Entity Header
Request Header
SDP Daten
Figure 2.4:
Basic message format of the Session Initiation Protocol[7, page 264]
Figure 2.4 shows the INVITE message of SIP. It is like Hypertext Transfer Protocol
(HTTP) a text based protocol, which makes it flexible in usage. The figure shows the
parts of such a message. A detailed description on SIP messages and its contents could
be found in [7]. The important part for IDMS, is the content of the session description,
which is described in Session Description Protocol (SDP) part of the message.
2.2.3 Session Description Protocol
For a description of the session the SDP is used. It is described by [12]. This protocol
could be used very flexible, because of its ASCII-based architecture it could be modified
without modification of the core protocol.

2.2 Protocols
10
v=0
o=- 15115003341359513177 15115003341359513177
IN IP4 mdf.open-ims.test
s=Unnamed
i=N/A
c=IN IP4 224.0.0.9/255
t=0 0
a=tool:vlc 1.1.8
a=recvonly
a=type:broadcast
a=charset:UTF-8
a=control:rtsp://mdf.open-ims.test:8080/channel1.sdp
m=video 8000 RTP/AVP 33
b=RR:0
a=rtpmap:33 MP2T/90000
a=control:rtsp://mdf.open-ims.test:8080/channel1.sdp/trackID=0
a=rtcp-xr grp-sync,:sync-group=<SyncGroupId>,
Figure 2.5:
SDP contents for a TV session
Figure 2.5 shows an example description for an IPTV session. The important line of the
shown message is a=rtcp-xr grp-sync,:sync-group=<SyncGroupId>, which contains
the SyncGroupId value, which is equal to the Media Stream Correlation Identifier (MSCI)
used as value for the RTCP communication. A detailed description of the values could
be found in [13] and [1].
2.2.4 Real-Time Transport Protocol
The Real-Time Transport Protocol (RTP) (see: [14]) is used to encapsulate multimedia
contents for transmission from the sender to the receiver. For IMS-based IPTV this
0
7
15
23
31
V
P X
CC
M
PT
SEQ_NUM
RTP_TS
SSRC
CSRC
Header Extensions
Payload
V: Version
P: Padding
X: Extension
CC: CSRS Count
M: Marker
PT: Payload Type
RTP_TS: RTP Timestamp
SSRC: Synchronization Source Identifier
CSRC: Contributing Source Identifier
Figure 2.6:
RTP frame [14, 15]
protocol is also used to transmit the TV contents. Figure 2.6 shows a typical RTP
frame. RTP Timestamp (RTP TS) and Synchronization Source Identifier (SSRC) are

2.2 Protocols
11
the important values for IDMS in IMS-based IPTV. The RTP TS is the common base
for synchronization between the receivers, because this is the unique identifier for the
packet. The packet sender is identified by the SSRC. The Contributing Source Identifier
(CSRC) field is not used in IPTV, because there is only one media sender. this results in
a shortened header without this field.
2.2.5 MPEG-TS
Moving Picture Experts Group (MPEG) is one of the groups, which standardizes digi-
tal formats for video and audio encoding. These formats are used for all DVB systems
as well as for IPTV. All these formats could be encapsulated in RTP directly, but this
leads to separate data streams for audio and video. For television that could lead to a
decrease in performance, because synchronization of audio and video has to be done at
the receiver
2
. This problem could be solved by Moving Picture Experts Group - Trans-
port Stream (MPEG-TS), which encapsulates audio, video and subtitle streams to a joint
stream. The receiver is now able to decapsulate these streams with now need of synchro-
nization
3
.
2
The problem of synchronization of separate RTP-streams is described in section 3.2
3
The synchronization of playout has to be done and is not meant by this.

2.2 Protocols
12
Figure 2.7:
Frame structure for mpeg-ts frames [16]
For IMS-based IPTV
4
the MPEG-2 transport MUX packet is used, because error recogni-
tion, the advantage of the other frame formats, is done by cheksum in the Ethernet frame
(see: [3] for a detailed description).
4
For a detailed description of the packet format see [1]

2.2 Protocols
13
2.2.6 Real-Time Transport Control Protocol
The missing hand-shake system from UDP[17], requests a separate signaling to the sender
about the quality of the transmission. RTCP closes this gap, by giving the opportunity
to send information of packet sending to the receiver and giving feedback of the recep-
tion to the sender. Some of the messages sent by RTCP are described in the following
subsections. These are the most interesting ones for synchronization and quality of the
session. Important for every RTP / RTCP implementation is the way the packets take in
the network. This has to be the same for RTP and RTCP and should not change during
the session for best performance, because every route change will lead to inter arrival
jitter. This jitter is never zero, because every routing decision takes time, which changes
depending on the network traffic (see [18]).
2.2.6.1 Sender Report
The Client is able to measure the one-way delay of the transmission, if the sender is
configured to send Sender Report (SR) messages to the client. These messages are send
regularly, but not for every RTP packet.
0
7
15
23
31
NTP_TS
V
P
RC
PT
Length
Sender SSRC
RTP_TS
Sender's Packet Count
Sender's Byte Count
SSRC1
Fraction lost
Cumulative Number of Packets lost
Extended highest Sequence Number received
Interarrival Jitter
LSR
DLSR
RTCP Header
Report 1
SR Header
Packet-specific extensions
Figure 2.8:
RTCP-message: Sender Report[14]
For IPTV only the SR header is interesting, because it contains the combination of
RTP TS and Network Time Protocol Time Stamp (NTP TS), which indicates the ex-
act sending time of the RTP packet it reports on. In a two-way RTP connection, the
Sender Report could also be used to send information about the reception to the other
participant. Report Blocks are added to the message for each sender to report on. One of
the goals for these reports is the measurement of the round trip time. The time stamps
Last Sender Report (LSR) and Delay Since Last Sender Report (DLSR) are used for that
calculation. LSR represents the lower 16 Bits of the seconds and the higher 16 Bits of
the fractional part of the NTP TS of the last received SR. The delay between reception

2.2 Protocols
14
of a SR and sending of the current report is represented by the DLSR, that contains
the seconds in the higher 16 Bit and the 1/65365 part of a seconds lower 16 Bits. A
more detailed description of this delay measurement is described later. A more detailed
description about the other contents of this message and there use could be found in
RFC3550[14].
2.2.6.2 Receiver Report
The Receiver Report (RR) contains a report block as described in section 2.2.6.1.
0
7
15
23
31
V
P
RC
PT
Length
Sender SSRC
SSRC1
Fraction lost
Cumulative Number of Packets lost
Extended highest Sequence Number received
Interarrival Jitter
LSR
DLSR
RTCP Header
Report 1
RR Header
Packet-specific extensions
Figure 2.9:
RTCP-message: Receiver Report[14]
This message is used in a one-way RTP connection like IPTV, because its one purpose is
to report about reception of RTP and RTCP messages.
2.2.6.3 Receiver Summary Information
In a multicast environment, the sender sends its RTP stream and RTCP messages to a
multicast group with an unknown amount of receivers. If the receiver transmits its RR to
the same multicast group, all the other receivers will also receive this message. To save
bandwidth it is possible to aggregate receiver information of several receivers to only one
message. This avoids sending of unneeded RR to receivers. IP multicast is described by
RFC3171[19]. The Receiver Summary Information (RSI) is the message which should be
used to send aggregated receiver information to the sender.

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2011
ISBN (eBook)
9783842820463
DOI
10.3239/9783842820463
Dateigröße
2.5 MB
Sprache
Englisch
Institution / Hochschule
Fachhochschule der Deutschen Telekom in Leipzig – Institut für Kommunikationstechnik, Studiengang Informations- und Kommunikationstechnik
Erscheinungsdatum
2011 (September)
Note
1,0
Schlagworte
iptv synchronization client media
Zurück

Titel: Implementing ETSI standardised RTCP-based Interdestination Media Synchronization
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
book preview page numper 20
book preview page numper 21
book preview page numper 22
book preview page numper 23
book preview page numper 24
book preview page numper 25
book preview page numper 26
book preview page numper 27
book preview page numper 28
book preview page numper 29
141 Seiten
Cookie-Einstellungen