Investigation of IMS in an IPTV context
by
Tobias Gustafsson
LITH-IDA-EX--06/058--SE
Investigation of IMS in an IPTV context
by
Tobias Gustafsson
LITH-IDA-EX--06/058--SE
Supervisor: Åsa Detterfelt
Attentec AB
Examiner: Arne Jönsson
Dept. of Computer and Information Science
using IP for allsorts of service deliveryranging fromvoice calls to TV.The
next natural step in this evolution is toprovidethe same set of services to
the end users independent of the accesstechnology and device used. TheIP
MultimediaSubsystem (IMS)is anIP based telecommunications platform
whichtargets this and lets the operatorsdevelop new services once which
can then be used onmany dierentdevices.
This thesisexamines the integration of IPTVand IMS. Can IMS beused to
deliverTV services and can the IPTV set-top-boxes of today be used as
clientsin IMS? Since this is anew and previouslyunexamined area an
explorativeapproach istaken. The aimis toidentify how suchan
integration could be performed and the possible problems which have to be
solved. Toassist in this explorationa TV-push service based onIMS
technology isconstructed.
A number of problems crucial tosolve for asuccessful integration are
identi edand possible solutionstothese are discussed.
examiner,for the hours of their precious time that we havespent discussing
the subject of this thesis and forthe help which they have provided.
I would also like tothank Anders Lundelland Johan Östman atOracle for
the supportwhichthey have provided despite the hectic work which
Oraclesacquirement of Hotsip meant.
Finally I would liketo thank my girlfriend, CeciliaGullberg and everyone
List of Tables xi
List of Figures xiii
1 Introduction 1 1.1 Background . . . 1 1.2 Purpose . . . 2 1.3 Research questions . . . 3 1.4 Method . . . 3 1.5 Limitations . . . 4 1.6 Contents overview. . . 5 I Theoretical Background 7 2 Session Initiation Protocol 9 2.1 What is SIP . . . 9
2.2 History. . . 9
2.3 SIP today . . . 10
2.4 De nitionsand Vocabulary. . . 10
2.5 SIP message . . . 12
2.5.1 Standard SIP Methods . . . 12
2.5.2 SIP Responses. . . 13
2.5.3 Message header . . . 14
2.6 SIP Transaction . . . 14
2.7 The INVITE dialog state machine . . . 15
2.8 SessionDescription Protocol . . . 16
2.9 Example,session setup . . . 17
2.10 SIP extensions. . . 18
2.10.1 SUBSCRIBE-NOTIFY . . . 19
2.10.3 REFER . . . 20
2.11 Security . . . 20
2.12 BuildingSIP services . . . 21
2.12.1 CallProcessingLanguage . . . 21
2.12.2 SIP Common Gateway Interface . . . 22
2.12.3 SIP Servlets . . . 23 3 IP Multimedia Subsystem 25 3.1 What isIMS. . . 25 3.2 History . . . 25 3.3 Goals of IMS . . . 26 3.4 Design philosophy . . . 27 3.5 Architectural overview . . . 28 3.5.1 Proxy CSFC . . . 29 3.5.2 Interrogating CSCF . . . 30 3.5.3 Serving CSCF . . . 30 3.5.4 ApplicationServers . . . 30 3.5.5 MRFC and MRFP . . . 31 3.6 Policycontrol . . . 31 3.7 Providing services . . . 31
3.8 Identities and Identi cation . . . 32
3.9 Protocols used . . . 33
4 IPTV 35 4.1 What isIPTV . . . 35
4.2 The attractiveness of IPTV . . . 35
4.3 Alternatives . . . 36
4.3.1 Nondigital . . . 36
4.3.2 Ordinarydigital transmissions . . . 36
4.4 IPTV network architecture . . . 37
4.5 Architecture of the IPTV set-top boxes . . . 38
4.5.1 Media encoding and transport . . . 39
4.6 Video onDemand . . . 39 4.7 RTSP . . . 40 4.7.1 RTSP Methods . . . 40 4.7.2 RTSP state machine . . . 42 4.8 Multicasting . . . 42 4.8.1 Multicastrouting . . . 44 4.8.2 QoS . . . 44 4.9 Mobile TV . . . 45
4.9.2 MBMS . . . 46
II The TV-push service 47 5 Service description 49 5.1 Functionality . . . 49
5.2 Realworld scenario . . . 50
6 The construction of a development architecture 51 6.1 Restrictions and simpli cationsmade toIMS . . . 51
6.1.1 Security . . . 52
6.1.2 Billing/Charging/Provisioning . . . 52
6.1.3 Roamingand mobility between dierent networks . . . 53
6.1.4 The gateways and access points . . . 53
6.1.5 Quality of Service . . . 53
6.1.6 Conclusions . . . 53
6.2 Populatingthe platform . . . 54
6.2.1 The SIP applicationserver . . . 55
Restrictions impliedby the choice of AS . . . 55
6.2.2 The CSCF . . . 55
Restrictions impliedby the choice of CSCF . . . 55
6.2.3 The client . . . 56
Demands onthe client . . . 56
J2ME client . . . 56
Symbian C++ client . . . 56
Writing a javaclient fromscratch . . . 57
Usingthe existing client SIP Communicator . . . 57
Usingthe existing client Windows Messenger . . . 58
Usingthe existing client Active Contacts . . . 58
Conclusion and Decision . . . 59
6.2.4 The streaming server . . . 60
Demands onthe server . . . 61
The alternatives . . . 62
Writing a server . . . 62
Conclusion. . . 62
6.3 Choosing a signalingscheme . . . 63
6.3.1 SUBSCRIBE - NOTIFY . . . 64
6.3.2 REFER . . . 64
6.4 The architecture . . . 66
7 IPTV in IMS 69 7.1 An IPTV architecture in IMS using SIP . . . 69
7.2 Motivation for a serverside solution. . . 71
III Results 75 8 Results 77 8.1 Unicast . . . 77
8.2 Video onDemand . . . 78
8.3 Suitabilityfor wired devices . . . 78
8.4 Suitabilityfor mobile devices. . . 79
8.5 Using IPTV STBsas clientsin IMS . . . 79
8.6 Conclusion . . . 80
8.6.1 Changes and improvementsof IMS to support IPTV . 80 8.6.2 Can the IPTV STBs beused as clientsin IMS . . . 80
9 Discussion 81 9.1 Solving the unicastproblem . . . 81
9.1.1 Multicastin anUMTS environment . . . 81
9.1.2 Multicastin awired broadband environment . . . 82
9.2 Solving the VoD problem . . . 82
9.2.1 UsingSIP . . . 82
9.2.2 UsingRTSP . . . 83
9.2.3 UsingSIP and RTSP inconjunction . . . 83
9.3 Integrating IPTV STBs intoIMS . . . 84
9.3.1 IPTV Snooping . . . 84
9.3.2 Usingwired devices inIMS . . . 85
9.3.3 IPTV Transport stream . . . 86
9.4 The future of Mobile Television . . . 86
Acronyms 88
2.1 SIP client INVITE dialog states explained. . . 15
2.2 Anexample SDP with linenumbers. . . 16
4.1 RTSP client states explained. . . 42
6.1 J2MEclient pros and cons.. . . 57
6.2 Symbian C++ client pros and cons. . . 58
6.3 Java clientpros and cons. . . 59
6.4 SIP Communicatorasclient, pros and cons. . . 60
6.5 Windows Messenger as client,pros and cons. . . 61
1.1 Information ow . . . 4
2.1 SIP INVITE-dialogclient state machine. . . 15
2.2 Sessionsetup and tear-down message ow. . . 18
2.3 SUBSCRIBE-NOTIFY message ow. . . 20
2.4 MESSAGEmessage ow. . . 21
2.5 REFER message ow. . . 22
3.1 The IMS layered architecture. . . 28
4.1 IPTV architecture. . . 37
4.2 Simpli edSet-top-box architecture. . . 39
4.3 RTSP client state machine.. . . 42
4.4 Unicast vs. Multicast. . . 43
6.1 The simpli edIMS architecture. . . 54
6.2 TV/Videoand telephony codecs . . . 63
6.3 The mediapush architecture. . . 66
7.1 IMS IPTV architecture. . . 70
7.2 Serverside vs client side solution . . . 72
Introduction
This chapter willgive the reader anintroductionto the thesis. It includesa
background tothe work performed, the purpose of the thesis, a short
description of the methods used and anoverview of the thesis layout.
1.1 Background
Today everybody speaks of Triple play 1
and network operatorsare eager
todeliverservices such asTV, telephony and broadband Internet access
using the same access technology and the same protocolfor data transport,
namely the InternetProtocol(IP). The next naturalstep in this evolution
toward a converged network would beto integratethe dierent ways of
accessing the network and providing the user with the same set ofservices
regardless of if he uses a cellphoneor a stationarycomputer with a wired
connection toaccess the network. The Always BestConnected (ABC)
principleshould be appliedmeaningthat the user isconnected in the way
that providesthe best current service (bandwidth, coverage quality, etc.).
The 3rd Generation Partnership Program(3GPP) 2
has an answer tothis
evolution named the IP MultimediaSubsystem (IMS).IMS is developed to
be aplatform under whichmany dierent access technologiesfor telephony
and communication can be gathered and onwhichservices can be created
withoutrespect to the underlyingaccess infrastructure. In order toachieve
this IMS has been designed with an All-IP visionin mindwhere IP is the
commonplatformover which allcommunicationand signalingis performed.
1
Thedeliveryofdata,voiceandTVoverthesamebroadbandconnection
2
Even thoughIMS originally was thought fortelephony and communication
services the use of IP and the agile SessionInitiation Protocol(SIP)for
session setup,service deliveryand callcontrol shouldmakeit possible to
introduce new services such asTV and Video onDemand (VoD) into the
telephony networks. Since IP is the protocolused inIMS muchof the
technologyand many of the techniques for delivering TVover IP (IPTV)to
our homes today should alsobe reusable in amobile context.
Lookingat itfrom the other side it shouldbe fairly easy tointegrate
telephony and communication intothe IPTV Set-Top-Box (STB) by using
the IMS platform todeliver these services.
From anend users pointof view this integration is interesting becauseit
would make the TV services available atall times according tothe ABC
principleand possibly provide new typesof value added services.
From anoperators point of viewit isinteresting because itprovides them
with the means todeliver more services tothe users as well asintegrated
services wheretelevision and communication isused, services which make
one plus one more than two and tightens their relationship with the
customers.
But howshould this integration bedone, what pitfallsare there and what
steps haveto be taken? That iswhat this thesis willtry to clarify.
1.2 Purpose
This thesis was performedat Attentec AB 3
in Linköping together with
OracleSvenska AB. There are three main motivestothe work performed in
this thesis.
1. Toexplore the integration of IMS and IPTV. This includesthe
investigationof two dierent areas. How IPTV services can be
delivered using IMS and howthe IPTV set-top-boxes can be used to
take part of the communication services oered by IMS.
2. Todemonstrate the new type of services possible tocreate with IMS.
This willbe doneby constructinga TV-push service based onOracles
SIP server.
3. Toprovide deeper knowledge inthe areasof IMS and IPTV to
Attentec.
1.3 Research questions
Given the purpose, two questions arise which this thesis aims to answer.
1. Arethere any changes orimprovementsneeded toIMS inorder touse
itfor IPTV services? Ifso,what are those changes? Ifnot, an
example architecture shouldbepresented and anexplanation to how
this ful llsthe requirements fromIPTV shouldbe given.
2. Is it possibleto use the IPTV set-topboxes asclientsin the IMS? If
so,how? If not, why? What has tobe done inorder to achive this?
1.4 Method
Because the area of investigationis new and previously untouched an
explorativeapproach willbe taken. The aimof anexplorativeinvestigation
is togather asmuch informationas possible withina speci c area. This
knowledge can then serve asa base for further and more speci c research of
the topic [1].
In short the followingsteps will beperformedin order toanswer the
questions insection 1.3.
1. A literature study of SIP, IMS and IPTV complemented with
interviews.
2. The de nition of a TV-pushservice.
3. The de nition of anarchitecture for a TV-pushservice.
4. Evaluationof available software which can be used for the service.
5. Design of the software whichmust be written.
6. Implementation of the design.
7. A transformationof the architecture used for this service into an
IPTV service for IMS.
8. A discussion around the above architecture and the results of the
whole process.
The construction of aTV-push service willserve as aguide in the
achieved and aspects important fora successful integration are more likely
tobe discovered. Figure 1.1illustratesthe information ow fromthe
dierent activities.
Figure1.1: Dierent activities and the information ow between them
It shouldbenoted however that building this service does not prove
anything else than that SIP can be used to set up TV-sessions should it
succeed.
Step 2to 8are mainlyconnected toresearch question 1. Question 2 willbe
answered by the knowledge gainedin step 1.
1.5 Limitations
Sincethe integration of IPTV and IMS is ahuge topic with many dierent
aspects some limitationshave to be made.
This thesis isnot aimingat givingacomplete technical solution tothe
integration of IPTV and IMS, that is aquest far beyond a project of this
size. It shouldinstead provide somehints of how such anintegration could
beperformedand alsoenlightenaspects whichhave tobe investigated more
closely for asuccessful integration to take place.
The focus of this thesis willmainlybe ondata transportand session setup.
Importantquestions suchas security considerations, content protection and
Analog devices willnot beconsidered in this thesis asthese (regular
phones, analog videophones, etc.) are not likely tobe used for TV.
1.6 Contents overview
The thesis has been divided intothree parts each consisting of anumberof
chapters. This sectionwillgive abrief introductionto the content of each
chapter.
Part I : Theoretical Background
This part of the thesis serves as anintroduction tothe technologieswhich
willbe used and discussed inparts II and III. It isquite extensivesince it
is important that the readerhas knowledge inthese areas inorder to fully
understand the reasoning in laterchapters.
This thorough background alsoful llspurpose 3 of the thesis.
Chapter 2 SessionInitiation Protocol
This chapter describes the Session InitiationProtocol. It contains
de nitions of the vocabulary used, explains howservices can bebuilt
using SIP and providesexamples of SIP usage.
Chapter 3 IP MultimediaSubsystem
This chapter gives anintroduction tothe IP MultimediaSubsystem
which is anew platform for IP-based communication. It introduces
the basic architecture, the elements whichit ismade up of and
explains howservices are executed.
Chapter 4 IPTV
This chapter describes atypicalIPTV architecture, the protocols
used andthe twomost importantservices, TVand Video onDemand.
Part II : The TV-push service
This part explains the TV-push service which was constructedand provides
anexample IPTV-IMS architecture.
Chapter 5 Service description
Chapter 6 The constructionof a development architecture
This chapter describesthe process of creatinga development
architecture onwhichthe TV-push service was to be built. It starts
by explainingthe simpli cationsmade tothe IMS architecture and
then describesthe process of choosing the software to be used forthe
dierent parts. Finallythe wholearchitecture is presented.
Chapter 7 IPTV in IMS
This chapter expandsthe TV-pusharchitecture intoa full-blown
IPTV architecture based onIMS. This isdone using the knowledge
gainedin the previous chapters. This architecture willthen serve asa
startingpoint for the results and the discussion.
Part III: Results
In this part the results of the thesis are presented and a discussion around
these isperformed.
Chapter 8 Results
This chapter willpresent the problems and pitfallswhich are
necessary to overcomein order touse IMS to deliver TVand to use
IMS todeliver communication services tothe IPTV STBs.
Chapter 9 Discussion
This chapter discusssome possiblesolutions tothe problems
presented in the previous chapter and tries toanswerhow mobile TV
willbe provided inthe future.
Acronyms This chapter contains explanations to allacronymsused in the
thesis. As the tele and data communication worlds are bloatedwith
acronyms and abbreviations this chapter mightproveto become the
Session Initiation Protocol
This chapter gives the reader anintroductionto the Session Initiation
Protocol. This includesthe structure of the protocol, the dierent network
units involved and anumberof extensions. It alsointroduces the Session
DescriptionProtocolwhich isoften used together with SIP.
2.1 What is SIP
SIP isan application-layercontrol(signaling)protocol for
creating, modifying,and terminating sessions with one ormore
participants. These sessionsinclude Internet telephone calls,
multimediadistribution, and multimediaconferences.
This de nition is taken fromRFC3261 1
[2]. In short this means that SIPis
used to establishdata sessions between clients and control these sessions
during their lifetimeas well asterminating them. SIP can beused to
establishany type of session asthe data content is not speci ed inthe SIP
protocolbut by some other protocoltaking care of the actual data transfer.
SIP iscompletely textbased and therefore readable to humans and rather
easy tounderstand.
2.2 History
SIP emerged fromthe two famous protocols HyperText TransportProtocol
(HTTP) 2
and SimpleMail Transfer Protocol(SMTP) 3
[3]. Itsawday light
1
Requestforcomment,adocumentthatdescribesastandardfromtheIEFT
2
Protocolusedto deliverwebpages
3
inthe mid-1990s whenHenning Shulzrinne, Associate Professor of the
department of Computer Science, ColumbiaUniversity and hisresearch
team issued adraftfor Multipart MultimediaSession Control(MMUSIC) 4
.
This draftwas submitted tothe Internet Engineering Task Force (IETF) in
1996 and containedmany of the key elements of SIP aswe know it today.
In 1999 Schulzrinnesubmitted a new draftto the IETF, more streamlined
than the previous one with components formedia contentremoved, based
onthis draft IETF issued the rst SIP speci cation, RFC 2543. IETF
continued their workwith SIPand in 2001 they released RFC3261 which
contained all the fundamentalparts of SIP.Since then several new RFCs
have been released with additions, enhancements and extra functionality
suchas event noti cation, described in section2.10.1.
2.3 SIP today
LatelySIP has gained bigmomentum as ithas been selected by the 3G
Community asthe sessioncontrolmechanism for the next generation of
cellularnetworks, Microsoft has chosen to deploy SIP in their operating
systems and there are extensive ApplicationProgrammersInterface (API)
speci cations forit inSun Microsystems' Java[3].
2.4 De nitions and Vocabulary
Beforeheading intoan explanation of the SIP protocolitselfand the
network elementsinvolved inhandling itwe need tomakesome de nitions.
URI Uni ed Resource Identi er, used toidentify SIP entities in the
network. The URI has the followingform: sip:user@company.com.
As can be seen itis very similarto ane-mail addresswhichis not so
strangeconsidering that a bigpart of the SIP syntax is taken from
the SMTP used for electronic mailservices. Usingthe same syntax
alsohas the big bene t that many ofthe Internet core services such
asDomain Name System (DNS) 5
servers can bere-used with noor
very smallmodi cations.
Registrar The responsibilityof the Registraris tokeep track of where the
users are located. It isa database with records containingthe users
4
Workinggroupwithin the ietf which developsprotocolsto support Internet
telecon-ferencingandmultimedia communications
URI and their real location(the IP address and port number). This
typically looks like this: sip:user@1.2.3.4:5060. The SIP registrar
islogicallyconsidered a separate server but because of the tight
couplingtothe proxy these are usually co-located.
SIP Proxy The main taskof the SIP proxy isto route the SIP messages
fromthe invitingclientcloser tothe client invited. The invitation
messagewillusually pass anumberof proxies before endingup at the
intended receiver.
User Agent The Internet end point using the SIP services. These can be
applicationsexisting on the end users computer such asprograms for
Voice overIP (VoIP).For user agentthe abbreviationUA willbe
used.
User Agent Client A role taken by the UA when it acts asa client. A
clientsends requests and receives responses. The abbreviation UAC
willbe used for this.
User Agent Server A role taken by the UA when itacts as a server. A
server receives requests and sends responses. The abbreviation UAS
willbe used for this.
Back-to-back UA A UA acting asboth aUAS and a UACreceiving
requests asa server and then forwarding themas a client,possibly
afterchanging the content of the request. The abbreviation B2BUA
willbe used for this.
Transaction A transaction isa way of grouping SIP messages (See
section 2.5) together. A transactionalways consistof one request and
allresponses to thatrequest. The notionof transactions willbe
explainedfurther in section2.6.
Dialog A dialog is aSIP relationship between UAs that persist for some
time. It isidenti ed by the Call-id and tags in the From and To
elds inthe SIP message header(See section 2.5.3). The CSeq eld is
2.5 SIP message
The SIP messageis writtenin plain text. It can beeither arequest from
clientto serveror aresponse from server toclient[2]. In short the message
consistsof the following parts:
Start-line Either arequest method(See section 2.5.1) ora response code
(See section2.5.2).
Message-header Used tokeep routing and session information,itis
described in section2.5.3.
Empty line The header must be separated from the messagebody by an
empty line.
Message body Can contain arbitrarydata but oftencarries the Session
DescriptionProtocol(SDP), used todescribe data sessions. This
includesmedia type, encoding, etc. SDP isfurther explained in
section2.8.
The syntax and format of the SIP message carriesgreat resemblanceto
that ofHTTP/1.1. The authorsof [2]however carefullypoints out that SIP
isnot anextension of HTTP.
2.5.1 Standard SIP Methods
A SIP request isrecognized by havinga method name,Request-URI and
SIP version numberin the start line. In [2]there are six methodsde ned,
these are described below.
INVITE Used by acaller to invitea callee tojoin asession. The body of
aninvite messagetypicallycontains adescription of the type of
sessionthat the callerwishes to establish. This description is often
speci edusing SDP (See section 2.8).
ACK Used by the callerto acknowledge that it has received a nal
response to anINVITE earliersent. This is the lastmessage sent in
the 3-way handshake of a session setup.
BYE Used totear down anestablished session.
OPTIONS Used when aUA wishes to queryanother UA for its
capabilities. The response to this is amessage containingthe
supported methods, extensions, mediacodecs, etc. of the targeted
UA.
REGISTER Used by the UA to registerwith a SIP registrar.
Registration with aregistrar isthe rst thinga UA should dowhen it
is startedto notifythe registrarof its'existence. The headerof
registermessage contains informationonwhichSIP URI tobind as
well asthe actual address tobind this URI to.
In additionto the above methodsthere are numerous extensions toSIP of
whichsome are mentioned in2.10.
2.5.2 SIP Responses
When aUA oraSIP proxy receivesa request itmust send a response. This
is true forall requests except ACK which does not triggerany replies[4].
The responses are very similarto requests but dierin one important
aspect, the rst line contains a reply code whichis aninteger from 100 to
699. The replycode signals the results of the request and there are 6
dierent response classes.
1xx Provisionalresponses, tellthe recipient that the request is being
processed but the result isnot yet available.
2xx Positive nal responses, means that the request was successfully
processed. These responses alsosignal the end of a transaction.
3xx Redirect, redirects acaller. The response contains informationabout
the new locationof a user orsome other service that mightful ll the
needs of the caller.
4xx Negative nal responses, indicate that the request could not be
processed, either becauseit contains a syntax error or because the
requested service isnot implementedat the server side.
5xx Negative nal serverside response, means that the server cannotful ll
the request right now. The clientusually makesa retry upon
2.5.3 Message header
The messageheader iswhat carries most of the informationof the SIP
protocol, here it willbe examined abitcloser.
Theheader ofa SIPmessageis very similartothat of anHTTP message[2].
Itconforms tothe generic headerformat speci edin RFC2822 [5]and each
header eld consists of a eld nameand a eld value separated by a colon.
Thereare numerous header elds speci ed in[2] but onlysix of them are
mandatoryfor every SIP message, these are:
Call-ID All SIPmessages withina dialog have the same Call-ID.
CSeq Contains aninteger and a method name. This eld isused to
uniquely identify atransaction (See section 2.6) within adialog. It is
used todetect retransmissionsof requests.
From Contains the initiatorof the request in formof a URI identifying
him/her.
Max-Forward An integer value which limitsthe the number of times a
messagecan be forwarded untilit is discarded. Every proxy that the
messagepasses decreases this value by one. When the value is zero
the messageis discarded.
To Speci es the logical recipientof a request inform of aURI.
Via Contains addresses to allSIP entities whichthe request has passed on
itsway tothe destination. These addresses are then used to send
responses over the same path withouthaving to perform new DNS
look-ups.
All dialogcreating messages and REGISTER messages must alsocontain
the contact eld which contains the IP address and portnumber towhich
consecutiverequests withinthe dialog should be sent.
2.6 SIP Transaction
The notionof transaction is important inSIP and it issaid tobe a
transactionalprotocol[4]. A transactionconsists of arequest and all replies
tothat request. The replies consist of zero ormore provisionalresponses
the transaction. Ifit is apositive nal response the ACK is sent ina
transaction of itself.
SIP entities (proxies, UAs, etc.) that have anotion of transactions are
called stateful. These usually keep an internal state relatedto the
transaction which lasts during the transactions lifetime. This internalstate
is then updatedevery time anew message within thatsame transaction is
received.
2.7 The INVITE dialog state machine
A SIP INVITE dialog can be in anumberof dierent states, there is no
strict de nition of the state machine for this but a modelof the states and
the transitions between them fromthe UAC side is given in gure 2.1.
Figure2.1: SIP INVITE-dialogclientstate machine.
State Comment
1 Init,The initialINVITE issent inthis state
2 Early, a provisional response has been received in
re-sponse tothe INVITE
3 Con rmed, the dialog and possible session parameters
are negotiated. These can later be re-negotiated by
sendinga new INVITE.
4 Terminated,the dialoghas been terminated,eitherbya
BYE request or anon-positive nal response
2.8 Session Description Protocol
The SessionDescription Protocol(SDP)is an applicationlayer protocol
used todescribe multimediasessions [6]. It is not a standalone protocolfor
communication but iscarried by some otherprotocolsuchasSIP. The work
with nalizingthe speci cation is inprogress but there isan earlyversion
described in RFC2327[7]. Asmentioned aboveSDP isoften used in
combinationwith SIP. This is done ina socalled oer/answer modelwhere
the involved partiesin asession oer their capabilitiesand then negotiate
which protocols and codecs touse for the session. SDP is best understood
by example, table 2.2shows a simple SDP.
1 v=0 2 o=- 0 0 IN IP4 192.168.28.43 3 s=A session 4 c=IN IP4 192.168.28.43 5 b=CT:1000 6 t=0 0 7 m=audio 48642 RTP/AVP 97 3
8 k=base64:soDHsn2GVW2Z9wtWy76 VQ2Q tU0j InWD fGKf nk4X rYXU
9 a=rtpmap:97 red/8000
10a=rtpmap:3 GSM/8000
11a=encryption:optional
Table 2.2: An example SDP with linenumbers.
Line 1describesthe version of SDPto be used,becausethe standard isstill
adraft this value is always set to0.
Line 2 describesthe originof the sessiondescription, it includesIP address
of the host who issued it and informationsurrounding which networktype
and addressing that is used.
Line 3 isthe session name and could be set to anything.
Line 4contains connectioninformationand describes wherethe data should
be sent, this does not necessarily have to be the same asthe originof the
SDP itself.
Line 5 describesthe maximum bandwidthwhichis allowed forthis session
inkbit/s.
Line 6 describeswhen the session starts and stops. In this example the
session isstarting immediatelyand the length isunknown (a typical
Line 7 contains amedia descriptor, it holdsinformationon the type of
media which isdescribed, whichportitis to bereceived on, the protocolto
use for transmission and a listof numbers which referto the codecs that
the host understands. Line 8 contains akey which could be used for
encryption of the media.
Lines 9 to11 are socalled attribute elds,these are used todescribe
dierent attributes of the session, they are alsothe primary way of
extendingSDP. Lines 9 and 10contain descriptions of the codecs which
were previously referred to online7.
We can now see that this host istrying tostart a voice conversation and
that it understandsthe red and GSM codecs. Line 11 tellsusthat
encryption is optional,if we would liketo encrypt the data we shoulduse
the key online8.
An SDP couldcontain many media lines (likeline7) which describe
dierent types of mediawith dierent attributes connectedto them.
2.9 Example, session setup
Figure2.2 shows a exampleof session setup. In this example Ted is a
customer at the operator Telebig,he wishes tomake avoice call tohis
friend Fred who is a customer atTelesmall. To dothis Teds UA sends an
INVITE request to Fred. This messagecontains an SDP body which
describesthe connection parameters. He sends this requestto hisSIPproxy
which immediatelyresponds with a 100 Trying response indicatingthat it
has received the request and is processingit.
Telebigs proxy then does aDNS look up todetermine the address of
Telesmalls SIPproxy and forwards the request to this proxy.
Upon receivingthe request Telesmallsproxy performs alookup inits
registrarto nd out the IP address of Fred. Fred has previously informed
hisregistrar about this by aREGISTER request. When this isdone the
request is nallyforwarded toFred. Alongthe way all SIPentities respond
with 100 Trying responses toindicatethat they havereceived the request
and are processing it.
When Freds phone starts ringingit indicatesthis by sendinga
180 Ringing response back toTed. This response traverses the proxies
before reaching Teds phone whereit results ina localplayback tone
indicatingtoTed that Freds phone isringing.
Fred decidestoanswerthe phone, this resultsina 200OK response which
eachothers IP addresses through the Contact elds in the INVITE and
200 OK messages. This meansthat the ACK message tocon rm the
session setup and nish the 3-way-handshake can be sent directlyfrom Ted
toFred without passingthe proxy. When this isdone the sessionis
established and voice data owbetween Ted and Fred.
Aftera whileFred gets tired of talkingto Ted and hangsup. This results in
aBYE request which is responded by a200 OK tocomplete session tear
down.
Figure 2.2: Sessionsetup and tear-down message ow.
2.10 SIP extensions
1. A UAS generating aresponse to arequest may only make use of an
extensionif itis explicitlymentionedin the Support header eld of
the request.
2. The extensions used must be de ned in astandard RFC.
Apart from the extensionof SIP with new header elds SIP has alsobeen
extended with anumberof new methods whichprovide completelynew
functionality. Going from the six SIPmethodsoriginally de ned in [2]a
total of 14SIP methodsare now registered with the InternetAssigned
Numbers Authority (IANA) 6
.Some of these methodsare of special interest
for this thesis and willbeexamined closerin the followingsections together
with examples of their usage.
2.10.1 SUBSCRIBE-NOTIFY
The SUBSCRIBE and NOTIFY methodsof SIP are de ned in RFC3265
[8]. The names of thesemethodscorrespond wellwith the usage of them. A
UACcan subscribe to the state of a UASand receive noti cations
whenever the state of the UAS changes. The content of the noti cation
bodyre ects the new state of the UAS. In order to knowwhat state
informationthe UAC wants tosubscribe to,the SUBSCRIBE request has
tocontain exactly one Event header, this headercontains a token which
de nes the state informationrequested. These tokens must beregistered
with IANA and the semantics surroundingthem must bespeci edin an
RFC. For presence 7
, whichis arather commonapplication, the token is
presence and itssemantics is de ned in RFC3856[9]. Figure 2.3shows the
message ow using SUBSCRIBE and NOTIFY.
2.10.2 MESSAGE
The MESSAGE method isde ned inRFC3428[10] and provide away of
sendingInstant Messages (IM) using SIP. The contentof the messageis
contained withinthe message body of the SIP request. A message request
can be sent eitherwithin adialog orasa standalone request. The signaling
owis very simpleand shown in gure 2.4.
6
OrganizationwithwhichstandardsregardingInternetareregistered
7
Figure2.3: SUBSCRIBE-NOTIFY message ow.
2.10.3 REFER
The REFER method isde ned inRFC3515[11]. REFER was created as a
way of handlingcall transfer by referring toa third party. The reference
doesnot have tobemade to aSIP URI but can be done toa web-page,
mailaddress, etc. The UA which issues the REFER receives noti cations
which indicatethe currentstate of the transfer. The signaling owof the
REFER messagecan beseen in gure 2.5.
2.11 Security
As security is not in focus in this thesis it willonlybementioned very
brie y. SIP uses two lowerlayer protocols to providesecurity [6], these are
IP Security (IPsec) and the protocol Transport Layer Security (TLS).
IPsecis implemented onthe IP level and providessecurity through tunnel
mode ortransport mode. In transport mode the payloadof the IP packet is
encrypted while in the tunneling mode the whole IP packet, including
header, is encrypted.
Figure2.4: MESSAGE message ow.
Code (MAC) toprovide data integrity. The use of TLS isrecognized by the
use of a SIPSURI which diers from anordinary SIP URI inthat itbegins
with sips:. A simplekind of authenticationcan be used toensure the user
identity,this is the so called HTTP digest (de ned inRFC2069[12]). In
short this works as follows. The SIP server and the clientshare a common
secret, some kindof password. Uponregistration (or any other event for
that case) the server responds with a401 Unauthorized or407 Proxy
Authentication Required,together with this response the server sends a
randomdigest. The clientreceiving this response concatenates itsuser
name and password tothe digest and runs an irreversible checksumon this
string (by defaultthe MD5 checksum). This checksum isthen attached toa
new registration request which is sent to the server. The server performs
the same procedures and compares the checksum received with the one it
calculated. Ifthey match the user is considered authenticated.
2.12 Building SIP services
Except from the basic telephony services provided by SIP and the SIP
proxies and registrars there are alsoa number of ways to de neand build
services ontop of SIP. Examples of such services mightbe voice mailboxes,
re-direction orpresence information. The most commonly used way to
build SIP services are presented inthe followingsections.
2.12.1 Call Processing Language
Figure2.5: REFER message ow.
actionsbasedonthe originofthe call,the destinationofthe call,the timeof
day,etc. Since the expressive powerof CPL islimited and the functionality
can be easilyrestricted, itis suitablefor end user service creation. The user
could forexample de ne aset of rules inCPL (by utilisinga user friendly
editor)for when and where he wants to bereached during the day. This
script isthen uploaded to the SIP proxy of the user which executes itevery
time someone tries to contact the user todetermine where toroute the call.
2.12.2 SIP Common Gateway Interface
SIP CGIis described inRFC3050[14] and corresponds closely to HTTP
CGIwhich isa well adopted standard since many years. Just likein the
HTTP case the SIP request body ispassed through the commongateway
interface fromthe SIP serverto anexternal process whichperforms some
kindof operation and returnsa response. The data inthe messageheader
elds are oftenpassed to the process inpre-de ned environment variables.
Unlike the HTTP, which mainlyis arequest/response protocol, SIP
introduces operationssuch asproxying whichcomplicates things abit.
ThereforSIP CGI applicationsmust oftenhave a notionof state inorder to
keep track ofmessages belongingto the same transactionor sent withinthe
incomingSIP messagetriggeringrules can beused. The format of these are
implementationspeci c. SIP CGI provide a powerful and exible way of
writingSIP applications inany language, the close relationship toHTTP
CGI programmingshouldmakeit rather straight forward touse.
2.12.3 SIP Servlets
The Java response to SIPservice creationis something calledSIP Servlets,
these are de ned inJSR116 8
[15]. Just like the SIP CGI scriptsthe SIP
Servlets are derived fromtheir HTTP counterpart. SIP Servlets are java
objects whichrun onJ2EEApplicationservers. The SIP Servlet API
de nes abase class SipServlet which everySIP servlet must extend. This
class de nes methods tohandle SIPrequests and responses which can be
overridden in order tode ne the preferred behavior. SIP requests and
responses are handled as objects in the Java languageand a number of
methods are de ned tomodify them.
Servlets can act both asUAS, UACand SIP proxies. A SIP server can run
several SIPServlets concurrently, in order toknow which of these servlets
toinvoke onanincomingrequest a trigger leis used. This le(sip.xml)is
anXML-based set of rules and actions. It corresponds quiteclosely to the
lter criteriadescribed inthe chapter onIMS, section 3.7.
IP Multimedia Subsystem
This chapter willexplain the goals of the IMS, the architecture and the
dierent elements that it consistsof. It willalsogivea more indepth
description of some concepts and entities particularlyimportantfor this
thesis.
3.1 What is IMS
IMS is anarchitecture based ona number of orthogonal protocols 1
such as
SIP toprovide voice aswell asdata for mobile units inreal time over the
Universal Mobile Communications System (UMTS) 2
. It is developed as a
collaborationbetween 3GPP and IETF.
3.2 History
Much of the earlywork by the 3GPP was based onthe Global System for
Mobile communications (GSM) 3
developed by European
Telecommunications Standard Institute (ETSI)[16 ]. The rst GSM
standards emerged in the late 80s and the lastGSM standard appeared as
late as1998 which wasthe sameyear that 3GPP wasfounded. The purpose
of 3GPP was, and is, todevelop a third generation mobilesystem basedon
Wideband Code Division Multiple Access (WCDMA) and Time
Division/Code Division MultipleAccess (TD-CDMA) forradio access.
1
Eachprotocolhavetheirwellde nedandlimitedareaofresponsibilitywhichdoesnot
overlapwithotherprotocols
2
Oftenreferredtoasthe3rdgenerationmobilecommunication,3G
3
Oftenreferredtoas2G,the rstwidelyuseddigitalstandardformobile
The rst 3GPP release was nishedalready in 1999 and wascalled 3GPP
release99.
The next release, 3GPP release 4,contained the allIP visionwhichwas
later tobe IMS. There washowever not enoughtime to includeIMS in this
releaseand itwaspostponedfor 3GPP release5. The 3GPPr5wasfrozen in
March2002 and included IMSbut it wasstilllackinga lotoffeatures which
were planned for release6. 3GPPr6 wasreleased inearly2005 and xed left
overs from 3GPPr5. Today there isan ongoingwork on release7 and 8.
3.3 Goals of IMS
The goals and advantages with the IMS All-IP architecture are many but
this section willexplain some of the most important. The overall visionof
the IMS project can be described infour punch lines [16].
•
Tocombine the latest trends intechnology•
Tomakethe mobileInternetparadigmcome true•
Tocreate a commonplatform todevelop diverse multimediaservices•
Tocreate a mechanismto boostmargins due toextra usage of mobile packet-switched networks.In orderto ful llthis visionanumberof demands must be regarded. These
willbe explainedbelow. The architectural overview (see section 3.5) will
then explain which parts of the network that corresponds to which
demands.
Multimedia session setup The IMS must supportsetup of audio and
videosessions overpacketswitched networks. Multimediasessionsis
nothingnew to the telecommunication world but performing them
overIP is.
Quality of Service The abilityto negotiate acertain Quality of Service is
fundamentaltoprovide good, high quality multimediaservices tothe
end customers. It isalso important toavoidnetwork overload and to
dierentiate dierentusers.
Interworking The IMS must beable to interwork with other types of
networksas well. This includes interworking with the circuitswitched
Roaming Roaming between dierent networks has been and still isa very
important issue. It shouldbepossibleto access the home network
seamlesslyfrom a dierent operatorif aroamingagreement exists
between the home and foreign operator.
Service Control The operatorshould be able to controlthe services
provided tothe end users. This controlshould be applicableboth as
generalrules whichapply toallusers in the network and speci c rules
onlyconcerning the individual user. These rules could forexample
restrictbandwidth usage.
Rapid service creation The time tocreate and implement anew service
into the networksshould be kept toa minimum. In the past services
havebeen eithercompletely standardized, whichhas delayed the
creationprocess, or proprietary,whichhas made themunusable when
roamingtoa dierentnetwork.
Multiple access IMSshould handledierentaccess technologies. Upuntil
nowmost of the focus has been on GeneralPacket Radio Service
(GPRS) over2G and 3Gaccess and over the PSTN. In the future the
IMS should evolveto admitall sorts of access technologiessuch as
WLAN, xDSL and bre.
3.4 Design philosophy
The main idea behind the IMS architecture is the use of alayered design
(ordierent planesas they are alsocalled). There are three principallayers
inthe IMS design. These willbe described shortly below. An overview of
the IMS architecture is given in gure 3.1.
Application layer Consists of applicationservers whichprovide
additionalservices tothe end users.
Control layer Handles signalinginthe network This includessession
setup, Quality of Service (QoS) handling, security and billing.
Transport layer Handles data transport. Routes mediatra c between
end users and servers.
The layered design isimportantas itprovides asimpler viewof this very
Figure3.1: The IMS layered architecture.
isthat the applicationsprovided in the upperlayer can be used by the end
customer regardless of the type of terminalhe/she uses (intheory). This
makes itpossible tocreate new services faster and cheaperwhichis
attractive tothe telecom operators.
3.5 Architectural overview
Thereare six major classes of entities inthe IMS network with dierent
functionality and responsibility[6], includingthe User Entities this makesit
seven intotal.
Session management and routing families Routes signalingwithin
the network. Inthis class the dierent CallSession ControlFunctions
(CSCF) reside. These are all dierent kindsof SIP proxies.
Databases Keeps user related information. The Home Subscriber Server
(HSS) and SubscriptionLocater Function(SLF) belong tothis class.
Interworking elements Interprets signalingand data tra c between
dierent domainssuch asPacket Switched (PS) toCircuit Switched
(CS).The Breakout Gateway ControlFunction(BGCF) Function,
Services Provideservices built on top of IMS to the end users. The
ApplicationServers (AS)providethe actualbrains behind the
services while the Media Resource FunctionController(MRFC) and
Media Resource FunctionProcessor (MRFP) providecontentsuch as
customized ring tones, voice mailboxes and other mediaservices.
Support entities A number of units which havesupporting functionality
suchas con guring QoS, set up by the Policy Decision Function
(PDF), intra domainsecurity, performed by the Security Gateway
(SEG) and TopologyHiding Functionality (THIG)used tohide the
inner structure of the network fromthe outsideobserver.
Charging IMS support two dierent typesof charging,online and o ine.
Onlineis used for pre-paidservices while o ine isused forservices
which are paid for afterwards. Two units, the Charging Gateway
Function(CGF) and the Charging Data Function(CDF) are
responsiblefor collectingcharging informationfromthe entities of the
IMS network and report them tothe business system of the operator.
User Entities These are the devices whichare used toaccess the network.
These couldbecellphones, computers, IPTV STBs, etc.
The followingsections willdescribe the entities seen in gure3.1 which are
most importanttothe workin this thesis. Since focus ison data delivery,
data transportand sessionsetup this willincludethe CSCFs, the
application servers, the MRFC and the MRFP. Some parts of the HSS
functionality willalsobe mentioned.
3.5.1 Proxy CSFC
The P-CSCF is the contact point of the IMS network fromthe User
Entities (UE)pointof view, allSIP signalingfrom the UE tothe other IMS
nodes passes through the P-CSCF.
Besides forwarding signalingto the other CSCFs the P-CSCF is also
responsibleto set up asecurity association with the UE, this is done using
IPsecand guarantees theintegrity of the SIPmessages exchanged. It isalso
responsiblefor setting up QoS overthe accessnetwork used by the UE,this
is done by the PDF which is oftenco-locatedwith the P-CSCF.
Since bandwidthis often limitedin the access networks the signalingis
and decompression is performed by the P-CSCF, while doing this it also
controls the syntax of the SIP messages toensure correctness.
The P-CSCF isalways locatedinthe samenetwork as the GGSN(Gateway
GPRS Support Node) of the UE which means that incase of roaming it
mightbelocatedin the visited operatorsnetwork. Todetermine whereto it
shouldforward the SIP messages it performs a DNS lookup of the domain
part of the users URI. This lookup willreturn the addressof the I-CSCFof
the users home network.
3.5.2 Interrogating CSCF
The I-CSCFresides at the edge of anoperators domainand serve as access
pointfor networks outside the domain.
The main functionality of the I-CSCFis to forward the SIP message toan
appropriateS-CSCF. In order toaccomplish this the I-CSCFcontacts the
HSSusing the Diameter protocol(See section 3.9)andretrievesinformation
onwhichS-CSCF the user shouldbeserved by. Dierent users may be
served by dierent S-CSCFs depending ontheir dierentpro les and needs.
3.5.3 Serving CSCF
The S-CSCFis the heartof the signalinginthe IMS network. It is basically
aSIP proxy with registrar functionality.
Uponreceiving a registrationrequest from a UE itdownloads the
authenticationvectors fromthe HSS using Diameter (See section3.9).
These vectors are then used to authenticate the user. Once the user is
authenticatedthe S-CSCF informs the HSSabout this and downloadsthe
service pro leof the user fromthe HSS.
The service pro le includesinformationonwhat services the user is
privilegedto use, this is described in the so calledinitial lter criteria (See
section3.7). All signalingtoand from the user willfromthis pointpass the
S-CSCF which has been allocatedto the user.
3.5.4 Application Servers
Services inthe IMS network are built on top of so calledApplication
Servers. Theapplicationservers interactwiththe IMSthrough theS-CSCF.
They can reside in the home network or inthird party providers networks.
In case the AS islocatedin the home network itmay also have aninterface
typesof application servers aswell, these must then bebuilt ontop of an
extra layer of abstraction which translates fromSIP to asuitable format.
Support exists for the Open Service Access (OSA) Parlay framework and
Customized Applications forMobile network Enhanced Logic (CAMEL) 4
.
This supportis mainlyprovided for backward compatibilityas many
services in todays telecomnetworks are built using them.
The application servers can act asSIP UAs, B2BUAs, proxies orredirect
servers.
3.5.5 MRFC and MRFP
The Media Resource Function(MRF) is used inthe IMS to providemedia
content, mixingof audio for conferencing, etc. It isdivided intotwo units
the MRFC, which residesin the controllayer and the MRFP which is
located inthe transportlayer. The MRFCprovidesa SIP interface toward
the S-CSCF, this is used toset up sessions. It alsoprovidesthe abilityto
perform charging based onthe functionalityused. When receiving media
requests the MRFC instructs the MRFP to perform the operations
requested by using the protocolMEGACO/H.248 (See section3.9).
3.6 Policy control
To restrictthe actionstaken by the users anumberof policies are de ned.
These may regulatethe access speed (and QoS)and services provided and
could be basedon howmuch the user has payed for his/hersubscription for
example.
The policy controlisperformedby the PDF and S-CSCF inconjunction.
3.7 Providing services
IMS is anarchitecture for providingservices, tobeable to deliverthe right
services tothe rightuser the system must be able to pass service request
fromthe user tothe right AS.IMS managesthis by using a so called lter
criteria.
The lter criteriais unique for every user and isa part of that users service
pro le. The lter criteria isstored in the HSS and downloaded tothe
S-CSCF when the user registers. The most important part ofthe lter
criteriaare the service point triggerswhich are used by the S-CSCF to
determine whether a certainAS shouldbecontacted ornot. The service
pointtrigger has the following structure.
Request-URI The URI that the request is destined for.
SIP Method The SIP method of the request
SIP Header Triggers onthe presence orabsence of a SIPheader elds or
content of the elds.
Session Case Session can be either Terminating,Originating or
Terminating Unregistered. Originating refers to that the calling user
isserver while terminating meansthat the called user is served
Session Description Can be used totrigger onthe content of anSDP
descriptor inthe message body. Forthis regular expressions can be
used.
The lter criteriais compared toall initialincomingrequests toand from a
user, if more than one service point triggeris matched the one with the
highestpriority ispicked rst (they allhave anassigned priority,the lower
number the higher priority) and the ones with lowerprioritythereafter.
Once one ischosen the corresponding AS(de ned inthe user pro le) is
contacted. The user pro le is constructedusing XML.
3.8 Identities and Identi cation
In IMS two dierent types of identities exist, the private and the public
identity.
The private identity isa globally unique identi er which isde ned by the
users home network. It does not identify the user but ratherthe users
subscription. It is mainlyused for authenti cation, administrationand
billing. The identi er has the form of a Network Access Identi er (NAI) 5
and isstored in the IP MultimediaServices Identity Module (ISIM) 6
(locatedon a smartcard) and in the HSS and can not be modi ed by the
UE. Itis contained withinall registrationsand de-registrations.
The public identity is referred toas the user identity in IMS networks. It is
used for communication with others and can be published in telephone
books etc. The public identity takes the formof a SIP URI or atelephone
5
Lookslikeane-mailaddress
6
URI (tel:+1-201-555-0123, de ned inRFC3966[18]). At least one public
identity willbe stored inthe ISIM applicationand thesecannot be changed
by the UE. It is possible to registermultiple publicidentities with one
single SIP REGISTER.
The user can have any number of private identities and these can inturn
correspond to anumberof public user identities. This makesit possible for
the user to bereachable onseveral dierent devices usingthe same identity,
it alsomakesit possible to registermany publicidentities for the same
device.
3.9 Protocols used
IMS utilize numerous dierent protocols for dierent parts of the network.
Because of the complexity and the many functionsof IMS using one single
protocolsuitablefor every aspect would be impossible. Instead a number of
(reasonably) smallprotocols have been adopted, each with their speci c
usage and functionality. This is oftenrefered to asusing orthogonal
protocols and helps tokeep the complexity low. The most commonof these
dierent protocols and their usage willbe mentionedbelow.
Forexcellent examplesof signalingin IMS see [19].
COPS Common Open Policy Service (COPS), designed by the IETF and
speci ed inRFC2748[20], is used foradministration,con guration
and enforcement ofpolicies. It is a client-server protocolwhere the
clientsare called Policy Enforcement Point (PEP) and the servers
Policy Decision Point (PDP). The PEPcan either question the PDP
for authorizationwhen certainevents occurs orit can downloada
complete policy which is thenonly updated fromthe PDP when it
changes. In IMS anextension toCOPS called COPS Policy
Provisioning (COPS-PR) is used between the GGSNand the PDF to
perform media authorizationand chargingcorrelation.
Diameter Diameter isa protocol used for Authenti cation, Authorization
and Accounting (AAA) described inRFC3588[21]. Just like many
other protocols used inIMS itis developed and standardizedby the
IETF. Diameter islooselybased onthe protocolRadius whichwas,
and stillis, used for the same purpose for dial-upconnections etc.
The protocolcan be usedon top ofthe Transmission ControlProtocol
oriented relationship between Diameter peers better than TCP. In
IMS Diameteris currently used for three services.
BySIP servers (CSCFsetc.) to determine if aclient isauthorized to
access the services provided by the server. This is done by contacting
the HSS.
Forreal time credit control. Thisservice isheavily used together with
pre-paidservices which are becomingincreasinglypopular.
In3GPP release 6Diameter is speci edfor communication between
the P-CSCF and the PDF for policy control.
MEGACO MEdia GAteway COntrol protocol (MEGACO), which also
goesunder the name H.248, is used between the MRFCand the
MRFP tohandle session management duringa multimediasession
such as avideo conference. The collectionof data sources and
destinationswithin asession isreferred toasa context and MEGACO
isused to manipulate this context by adding orremoving sourcesand
destinations. MEGACO isde ned inRFC3015[22].
RTP Real-timeTransport Protocol(RTP) is used for alltransmission of
mediabetween dierententities in the transport layer. RTP is built
ontop of UDP and providesservices for measuring packet loss, jitter
and delay inthe transmission. The statisticsof these measurements
are thensent tothe transmittinghost by using the RealTimeControl
Protocol (RTCP). In response tothis the transmitter can adjust the
data rate inorder tooptimize quality.
IPTV
This chapter willgive anoverview of the IPTV phenomena and some ofthe
technologiesbehind it. The focus will be onthe services TV and Video on
Demand asthese are the core services of IPTV today and the most
interesting to look atin anIMS context. There are of course other services
availablesuch ase-mail, gaming,etc. These are however not IPTV speci c
and willonly be mentioned very brie y.
To conclude the chapter two technologiesfor mobile TV are presented.
4.1 What is IPTV
IPTV is TVwhich istransmitted using IP.UnlikeSIP and IMS IPTV is
not a standard. Dierent operatorsand vendors implementIPTV networks
indierent ways, the only thing they have incommonis using IP.
4.2 The attractiveness of IPTV
Unlikemany other IP based services suchas VoIPand broadbandin
general,the opinionamong analysts isthat IPTV willincrease the average
revenue fromeach customer [23]. It willprobably be acritical question for
the operators tomanage toadopt tothe new wave of tripleplay in order to
survive.
One of the majorpros ofIPTV is the ability for total interaction. Sincethe
data is not limitedto goingin one direction, as isthe case with normal
broadcasting,the user can interact withoutthe need of extra devices such
Another very appealingfact is that itis possible to broadcastTV at a
much lowercost. This givesnew opportunities for localand more
specializedcontent witha smaller audience.
The abilityof the system tomake suggestions and recommendations based
onyour viewing habits couldalso be appealing. This alsogivesthe
operatorsand content providers a good groundfor future channel
programmingand programplanning asthey have direct access tovery
accurate statistics[24]as opposed to today when statisticsbased onasmall
groupof customers isused[25 ].
4.3 Alternatives
Thereare three basic ways used for transmitting TV-signals,by
broadcastingthem over the air,by cable or by satellite.
4.3.1 Non digital
The non digital,or analogue, transmission isthe old fashion way of
transmittingTV. The dierent channels are sent ondierent frequencies
and the receiverhas totune in tothe rightfrequency in orderto receive the
transmissions. The main drawbacks of analoguetransmissionsare [25].
1. Thereis a limitedspectrum of frequencies that can be used, this
limitsthe number of channelsthat can beaired at the same time.
2. I consumes a lotmore power than digital transmissions,up to 1000
kW for ananalogue transmittercompared to around50 kWfor a
digital.
4.3.2 Ordinary digital transmissions
Just likeIPTV ordinary digital transmissionsuse apacketbased
transmissiontechnique and the MPEG-2 technique for compression of the
data. The maindierence and drawback toIPTV is that there isno ability
for true interaction since the receiveris not able to transmitsignals. This
alsolimitsthe ability forVoD as the user is not able to makerequests.
Thereare services today where alimited number of channelsare dedicated
toso calledPay-per-view and you get access tothem for the time of the
channels broadcasts onlystart at certaintimes and the rangeof available
programs is very limited.
4.4 IPTV network architecture
Figure 4.1: IPTV architecture.
Since IPTVas wellasother data oftenshare the same network links (Triple
play) the topologyis pretty muchthe same asin the rest of the Internet.
There are nostandard IPTV architecture and asnoted in[27] there are lots
of techniques used today. Anoverview of what a typical IPTV architecture
could look like (given the informationfromthe interviews [28, 29, 30])can
be seen in gure 4.1.
There isusually ahigh capacity backbone through which allof the channels
are sent. The nodes are then connected, directly or indirectlyvia the
service providers backbone, tothis backbone overanaccess network (xDSL,
Passive Optical Networking (PON) 1
etc.) receivingthe datain accordance
tothe channels they are watching. The content of the IPTV network is
provided by a Video Head End whichreceives feeds of contentfrom
satellites,cable or bre. This content isthen encoded, compressed and
packaged intoIP-packets beforebeing sent out over the back bone.
Unlike the Internetthe IP-networksfor IPTV are private and speci cally
designfor their purpose whichgivesthe provider the ability toguarantee
QoS givingthe data packets related toTV higherpriority than other data
packets [31].
The capacity of the network is crucialas the QoS is animportantfactor in
IPTV.Nobody wantsto watchTV fromanoperator wherethe picture goes
blurredordisappearsevery nowand then becauseof network overload. The
demands onthe network are thusquite high consideringthat an ordinary
televisionrequires around1,5MB/sand the new up-coming HighDe nition
TV(HD-TV) 2
standard requires as much as6 up to 10MB/s. Withup to
hundreds of channelsin the network and VoD (See 4.6) ontop of that the
need forbandwidth is huge. In order tohandle this the distribution of
mediain the IPTV network isusually done usingsomething called
multicasting. This isnecessary inorder to provide ascalable solutionwhich
can serve thousands of users with TV inparallel. Multicast is closer
explainedin section4.8. The applicationservers shown in gure4.1 deliver
suchservices as Electronic Program Guides(EPG), games, e-mail,etc.
These services are oftenweb-based and the protocolused todeliverthem is
HTTP.
4.5 Architecture of the IPTV set-top boxes
Thereis nostandardized architecture for the IPTV set-top boxes. Many of
them are built using standard PC architectures and with stripped down
versions of ordinary PC operating systems such asLinux.
Mostof the IPTV STBs used in Sweden today downloadall software
needed from acentralserver upon power-on, this simpli escon guration
and upgrade of the system software.
Figure4.2shows asimpli edversion of anSTB architecture. Many of the
applicationsbuilt for IPTV today are basedon dynamic web-pages using
JavaScript. Thesescripts can access functionality of the underlying STB
through JavaScriptAPIs supplied by the STB vendor. In this manner
EPGs can bebuilt as web pages and channelswitching is performedby
callingthe underlyingAPIs. The web pages for EPGs and other services
are oftencached locallythe rst time used to improve performance in
successive requests. The APIs are not standardizedbut vendorspeci c, this
meansthat dierent web-pages are needed for STBsfrom dierent vendors.
Figure4.2: Simpli edSet-top-box architecture.
This isusually not averybigproblemsince the numberof dierenttypes of
STBs inthe IPTV-networks are often limitedand the operatorshave good
controloverthem.
4.5.1 Media encoding and transport
The data inIPTV networks is usually encoded and compressed tokeep the
bandwidth requirementsto aminimum. The by far most common
compression technique today is that of MPEG-2 which providesDVD
quality overreasonably low bandwidth. MPEG-2 is not however able to
handlethe demands of compression required forthe HD-TV standard.
MPEG-4 is anew upcoming standard whichprovides much higher
compression rates atequalquality.
Fortransportationof the media the by far most widely used protocolis the
MPEG Transport Stream(MPEG-TS). It runs ontop of User Datagram
Protocol(UDP) and chops the audioand videodown intosmall(188 byte)
packages [32]. These packages are then interleaved and sent over the same
connection.
4.6 Video on Demand
Video ondemand is anattractive service tothe customers which has not
been available inthe old broadcastingnetworks. The idea behind VoDis
oldthough, tohire movies. The dierencefrom oldtimes is that you're not
supposed tohave toleavethe couch and go tothe video store but choose
toimplementin principlebut having thousands of customers watching
dierent movies atthe same time means that we havesomething close to a
unicastsituation(as opposed tomulticasting, see section4.8) which
consumes a lotof bandwidth. This isnot acceptable.
One way of approaching this isby placinglocalvideo servers close tothe
customers. This would take away some of the load from the central
backbone. By always keepingthe most popularmovies onthese servers the
load onthe total network can be kept down as the data does not have to
travel that far.
4.7 RTSP
ForVideoonDemand andother on demand servicesRealTimeStreaming
Protocol(RTSP) isone of the most widely used protocols. RTSP is aIETF
standard described inRFC2326[33] used for controllingthe deliveryof data
with real time properties. It is aapplication level,clear textprotocoland
has many similaritieswith HTTP and SMTP syntactically.
Does it sounda lotlikeSIP? Indeed,H. Shulzrinne who is one of the men
behind the SIP protocol isalsovery involved with RTSP. But the aimed
areas of usage are abit dierent [34].
•
SIP isprimarly used for invitingusers to real time conferences while RTSP is used for initiatingand controllingunicast and multicaststreams.
•
The data streamsset up by SIP are usually bi-directionalwhile they are uni-directionalwith RSTP,from server touser or viceversa.•
RTSP provides meansfor caching of data, something that SIP lacks and doesnot needin itsoriginal contextsince data caching is notapplicablein real time communication.
4.7.1 RTSP Methods
Just likeSIP RTSP has a number of methods, these will bedescribed
brie y below.
ANNOUNCE This methodhas two areas of usage. When the client
sends anannounce to the server itcontains amedia description for a
given URI announcingfor a example anew conference. When sent
