On extending open source IMS platform for

integrated IPTV and VoIP services over IPv6

Stanisław Janikowski, Jordi Mongay Batalla

National Institute of Telecommunications

Warsaw, Poland

{S.Janikowski;J.Mongay}@itl.waw.pl

Michał Hoeft, Krzysztof Nowicki

Gdańsk University of Technology

Gdańsk, Poland

{michal.hoeft;know}@eti.pg.gda.pl

Abstract— Even when IMS is the most popular platform for

multimedia services, the open versions of IMS ecosystem are

lacking in specified functionalities for IPTVv6 and VoIPv6

services. In this paper, we extend current client and server open

source software in order to provide reliability and security to

these multimedia services. As a part of our work the IMS

architecture for conferencing system with proposed mechanisms

to improve system availability is presented. The monitoring,

based on local and remote mechanisms, gives an ability to fast

and reliable failures detection. The proposed algorithm also

includes load balancing of the original initialized and restored

conferencing sessions on the MRF servers. The restoring

mechanism relocates conferences with media mixing and

management to one of the available media servers. Moreover, we

put many efforts on adapting current IPv4-oriented software to

IPv6 streaming. The importance of the presented results lie in the

impulse offered to the multimedia services over IPv6, which are

actually the main hindrance in IPv6 start.

Keywords - IMS; IPTVv6; VOIPv6; IPv6; open-source

I. INTRODUCTION

Current research in Multimedia communications is directed to overcome the actual limitations of packet switched networks on providing satisfactory Quality of Experience to the end users. Moreover, standardization institutions are still working in defining architectures and key interworking elements in order to expand Multimedia services in the Internet. In this paper we present the extensions performed in open source implementations of two notable multimedia services: IPTV and VoIP, which use the IP Multimedia Subsystem (IMS) as the common integrated communication platform. The proposed modifications center on adapting the services to IPv6 infrastructure as well as improving reliability, availability and security aspects of the open source implementations.

IP Multimedia Subsystem (IMS) is a recognized standard that the big operators are installing in their networks more frequently. IMS performs tasks related to interoperability, charging, roaming and security. The most important characteristic for networks operators is the capacity of IMS on adopting easily any feature of the IT domain.

Over this platform, different multimedia services (e.g., IPTV and VoIP) can be integrated and can cooperate for introducing enhanced services. IPTV systems have experienced an unexpected success in the network, gaining in popularity

compared with other television transmissions. The reason we may find in the fact that consumers, always more, “demand personalized TV experiences that are available anytime, anywhere, on any device” [18]. The capabilities of IP television to fulfill these requirements as well as the fact that the whole complexity of IPTV systems is actually transparent to the consumers give more and more popularity to IPTV systems.

On the other hand, the migration from traditional PSTN/ISDN systems to IP environment offers flexibility, easy integration with high level applications and ability in new features implementation. For example, RFC 4353 [6] emphasizes the capabilities of SIP protocol for providing conferencing in the Internet.

Several recent literature references about this thematic are presented in Section II. On the other hand, Section III shows particulars of IMS architecture. In Section IV, we present the work that we performed in the field of IPTVv6, whereas the work in VoIPv6 is presented in Section V. At last, Section VI concludes the paper.

II. RELATED WORKS

The challenges of IPTV systems are related to the high quantity of information carried by television streams. In fact, the IPTV is one of the killer applications in the Internet because of the necessity of bandwidth. The demand of higher quality of the image required by the consumers means in practice more and more bandwidth in the IPTV transmissions.

To this increasing image resolution, we should add the higher requirements of television 3D and interactive television. In the case of interactive television, some requirements are more similar to the interactive games than to the classical television.

For the correct management of heavy TV streams served to an increasing demand, the IPTV systems are developing and improving new solutions every day. In this sense, IP Television comprises many research areas related to telecommunications. These areas are, among others, storage technologies, video and audio encoding (for example, MPEG-2 codec or more recent MPEG-4 H.264 codec), data encryption, data distribution, transmission by the network (new control and data planes). The complexity of IPTV systems as well as their importance is also proved by the increasing number of projects dedicated to improvement of transmission of television streams by the

978-1-4673-1391-9/12/$31.00 ©2012 IEEE

Internet. Between all the projects within the 7th Framework Program funded by the European Union (EU 7FP) we may highlight the following ones: one of the most successful projects, which is currently finishing is the P2P-Next project [2]. Among other objectives, this project specified and implemented a Set Top Box with an interface for connecting to peer to peer networks which offers to the classical television sets the possibility of gaining access to the contents provided by peer to peer networks. Mobile3DTV [3] researches problems of moving 3D television to mobile environment. As known, mobility has strong limitations of bandwidth availability, which is not according to 3D television bandwidth requirements. Challenges as capture of 3D images, coding, and transmission are investigated in Mobile3DTV. Otherwise, CANTATA [4] is a project proposed inside the Information Technology for European Advancement (ITEA) and develops a subset of functionalities related with Interactive TV systems, which defines the requirements for this kind of television. Interactive TV enhances IPTV by offering to the consumer the possibility of interacting with the service provider for, e.g., shopping purposes. Many other 7FP projects aim at introducing content-awareness within the network, which will undeniably open many new business possibilities to the Internet television. In fact, the new proposed architectures interconnect the four actors delineated in IPTV systems: content providers, IPTV service providers, transport and distribution IP network providers and clients [5]. These projects are grouped together in the Future Media Networks cluster.

The inter-connection and inter-dependences of the different actors involved in IPTV delivery have been studied and presented by different workgroups defining IPTV architectures. ITU-T proposed an infrastructure for IPTV over Next Generation Networks (NGN) [1]. Another approach is to use multimedia platform (e.g., IP Multimedia Subsystem) for performing all the tasks necessary for IPTV delivery as, e.g., authorization, charging, service discovery, connection to NGN modules, etc. This approach has been deeply analyzed by ETSI-TSPAN in recent documents [11] and [12]. Also conferencing service may use IMS platform for all the tasks focused on service control and management.

The framework for centralized conferencing XCON presented in [8] could be adapted to IMS platform. It proposes a new approach in conference realization, where participants could use various call signaling protocols (e.g. SIP, H.323, Jabber). Moreover it introduces new protocols (CCMP, BCFP) for advance conference applications. As discussed in [14] Distributed Conferencing Framework (DCON) [15] extends the XCON framework and enables distributed conferencing on IMS domains.

The paper [13] presents an advance conferencing management by means of the OSA Parlay X Multimedia Conference Web Service, which is an interface for high flexibility, scalability, and interoperability conference service maintaining.

Although IMS conferencing may be considered as an example of the tightly coupled conference, Sim, Tieu and Kim proposed an interworking framework between loosely coupled conference and IMS conferencing system in [10]. The authors

introduce new architecture elements for the integration of systems and signaling and media processing.

III. IMS SERVICE ARCHITECTURE

The IP Multimedia Subsystem (IMS) is considered as a service delivery platform for the Next Generation Networks (NGN) and not only. In fact, many operators implement IMS even when they do not implement NGN for assuring end-to-end Quality of Service. It defines collections of logical entities which allows providing of SIP-based services. Figure 1 depicts an exemplary implementation that puts together implementation framework for IPTV (see[24]) and for VoIP (see [14]) services. As shown in the figure, there are entities of the IMS core system, the IPTV system and the VoIP system. IPTV and VoIP systems contain the Media Resource Functions (MRF) servers and the Application Servers (AS). The MRF is the content server which storages content (IPTV) or service (VoIP), whereas the AS is in charge of finding the appropriate MRF for each request. Inside the IMS core, we can distinguish the following modules:

P-CSCF – Proxy Call Session Control Function is the first element processing the SIP messages sent by subscribers. It is responsible for filtering, routing the messages and performing security tasks.

S-CSCF – Serving Call Session Control Function is the main entity in the IMS architecture, in which service discovery is performed (appropriate Application Server or end subscriber discovery) routing to appropriate Application Server or subscriber is performed.

I-CSCF – the main task of the Interrogating Call Session Control Function is to determinate the S-CSCF for given subscriber. It queries the HSS database in order to obtain the name of S-CSCF.

HSS – Home Subscriber Server is the centralized database involved in tasks related to user authentication, authorization, accounting and session management.

Figure 1. IMS service architecture

IV. IPTVV6

IP television favored changes in business models for the Internet. While before IPTV introduction, users connected

more or less occasionally, now with IPTV (classical television or Video on Demand) the users just do not disconnect the computers from the Internet. The result is that many more consumers are constantly connected and the classical IPv4 addressing is not enough for service provider to end user communication. IPTV demands IPv6 to offer static addressing to all the users. Moreover, another reason for the introduction of IPv6 to carry IPTV streams is the mobility of terminals (UMTS, LTE, etc.). As known, popular mobility solutions like Mobile IP or Proxy Mobile IP are more efficient and easier to implement in IPv6 environments. On the other hand, we should also consider enhanced multicast of IPv6 transmission compared to earlier version of Internet Protocol.

Japan was the first country, which implemented a complete IPTV system working on IPv6 (IPTVv6). This first system is NTT Plala Hikari TV [19] and its implementation resulted indispensable since Japan developed only-IPv6 network. In any case, Hikari TV resulted very successful and currently has hundreds of thousands of consumers. Toshiba was the first hardware-specialized company commercializing IPTV devices working on IPv6.

These systems base on commercial (generally expensive) software solutions. The work that we performed in the IPTVv6 field consists of enhancing open source modules of Open IMS [20] and IPTV clients and servers in order to offer a more efficient and secure service of IPTV on an IPv6 network by using the IMS platform. Specifically, we introduced modifications and specific configuration in Open IMS modules, UCT IMS Client [23] and VLC server which are the modules highlighted in red in Figure 2. The modified modules are accessible in ftp://ftp.itl.waw.pl/IMS_IPTVv6_VoIPv6 (GNU License).

Figure 2 presents the IPTV/IMS architecture proposed by ETSI-TSPAN [11]. Note that in relation with the general IMS architecture presented in Figure 1, there are more entities involved (e.g., SSF, SDF, etc.). These are responsible for additional functionalities of IPTV service and are out of the scope of this paper. Moreover, the names of the interfaces changed in ETSI-TSPAN architecture. This way, the interface Mr in universal IMS architecture (Figure 1) is named interface y2 in ETSI-TSPAN architecture. The major components of this architecture specific to IPTV are: Service Discovery (SDF) and Selection (SSF), Service Controller (SCF), and Media Control (MCF) and Delivery (MDF). Apart from this, the other components in the architecture include the Transport Function (ECF/EFF) which is responsible for Transport, Network Attachment and Resource Reservation tasks, and the IMS core. The IMS core contains all the core elements (see Figure 1) of IMS architecture specified by the various standard bodies and controls the IMS network, managing the signaling messages and all the sessions in the network.

In Figure 2, we marked in red the open source software for which we extended functionalities in order to acquire integrated IPTV/IMS system as proposed by ETSI. The modifications are related with two main problems that we detected. The first one is that not all the modules properly run over IPv6 platform and the second one is that there is a lack of communication between Open IMS and content server in current open source

implementations (interface y2 in Figure 2). Problems with IPv6-awareness we found in the client, the core and the server. The lack of communication between IMS and streaming server touched modules in Open IMS and IPTV Media Control Function (MCF) module in the content server.

Figure 2. IPTV/IMS architecture defined by ETSI-TSPAN [11]

IPv6-awareness

The first component that we modified is the UCT IMS Client.

There are more clients for services as IPTV and Video on Demand (VoD), which are IMS-capable in the market. Anyway, any of them satisfies the assumed requirements (IPTV/VoD + IMS-capable + IPv6-aware + open source software). Mercuro is an IMS client developed by Inexbee for SIP/IMS/3GPP compliance. Nowadays, Inexbee provides three editions of its client for Windows platforms only. The Bronze Edition is freeware and supports 3GPP/IMS release 7 requirements, Voice/Video Calls, OMA/IETF SIMPLE IM, OMA/IETF SIMPLE Presence, XCAP, File Transfer and other features. The Silver and Gold editions are not open source but they support, among others, IPv6 transport.

MyMONSTER Telco Communicator Suite (TCS) is a telecommunication package from the myMONSTER toolkit. MyMONSTER is being developed at the Fraunhofer Institute FOKUS in cooperation with the associated Technische Universität Berlin. The software has been created in Java and enabled in different platforms (Linux, Windows Vista/XP/7, Mac, Windows Mobile). The application enables Instant Messaging and Conferencing, VoIP, Video Telephony, Chat, Presence and GeoLocation. It is also possible the integration of additional applications using Web service, SOAP and JSON APIs. The application provides support for IPv6 but it does not provide IPTV and VoD service.

VLC Client is part of the VideoLAN project developed by both volunteers and non-profit organizations released under the GNU General Public License. VLC is mostly used as a media player with the benefit that it supports the great majority of audio formats. Streaming is done according to the protocols: RTP/UDP; RTSP; Raw UDP, HTTP. VLC supports IPv6 protocol. Anyway VLC client is not prepared to work together with IMS, so it is not suitable for us.

UCT IMS Client Live 555 streaming server

OpenIMS

y2

SSF

SDF SCF

UPSF Core IMSMCF

MDF

UEECF

Ut

Xa

Xa Ss’

ISCISCSh Sh

Cx

Gm

Xc

Dj

Xd

SIP/SDPRTP/RTCPDiameterRTSPHTTPIGMP/MLDDVBSTP or FLUTENot defined

Legend: IMS based IPTV model

Transport processing functions

UCT IMS Client is an IMS client under the GNU General Public License for LINUX distributions developed by the University of Cape Town (South Africa). It is particularly designed to work together with the Open IMS core. Although it has stability problems due to its bond with old dependencies, it is the unique free IMS client that supports IPTV and VoD services. The software, however, does not support IPv6. We decided to use this client and our efforts centered on solving the lack of IPv6 support.

In order to register the UCT IMS Clients by IPv6, we had to replace the socket (IPv4 socket) for the correspondent one working on IPv6-base. Most of open source software for IPTV clients and servers are based on live555 library. Unfortunately this library does not support IPv6 for RTSP protocol. For this reason, the next necessary step was to extend the live555 library by adding IPv6 support and next rebuilding of UCT Client and live555 streaming server.

These changes were related with client and server. On the other hand, for doing Open IMS as an IPv6-capable application, we made basic installation, where all IMS components were installed on one physical computer over Linux 11.3 OpenSUSE operative system. Were installed the next modules: I-CSCF, P-CSCF, S-CSCF and FHoSS. The libraries bison, flex libxml2 (> 2.6), libmysql, curl and libcurl4-gnutls-dev are necessary for running the system. The compilation was performed in the next environment: GCC3/4, make, JDK1.5, ant. Then, we modified three modules of Open IMS (i.e., pcscf.cfg, scscf.cfg and icscf.cfg files) in order to include IPv6 addresses of the appropriate servers and port numbers used for SIP communication. For Diameter [9] communication, it was necessary to configure the IPv6 addresses and ports in the following files: pcscf.xml, scscf.xml and hss.xml.

Other minor configuration modifications were related to the DNS server and Mysql server. For our installation we used BIND DNS server and MYSQL 5.1 server, which were included in Linux OpenSUSE 11.3 distribution. By introducing DNS naming, it is possible to use domain names of IMS modules instead of IP addresses. The DNS server was installed on the same computer as the IMS modules. The main configuration tasks were related to AAAA records, which are suitable for IPv6. Specifically, we had to change the whole communication with DNS server for introducing messaging exchange considering the AAAA records.

In the next step we installed the database, which stores information about IMS modules and IMS users. The database installation required hss_db.sql and icscf.sql configuration files. The first one describes the structure of tables for storing information, i.e., IMS accounts, application servers and user charging information. The second one (I-CSCF) stores information about IMS domains and S-CSCF servers. Both the files were modified for supporting IPv6 parameters.

Communication between Open IMS core and MCF module

The modifications in the Open IMS S-CSCF module and MCF module were more exhaustive and have the scope of enabling direct communication between Open IMS core and MCF module in the streaming server (interface y2 in Figure 2).

The basic problem is that none open source streaming server has implemented SIP for interworking with IMS platform. This results in lack of IMS full control over the access to IPTV services. In example, in the solution proposed by UCT (IPTV over IPv4) where VLC streaming server is used, IMS platform has possibility to verify user rights to access IPTV content and if pass then platform sends to client RTSP address of requested content via SIP signaling. But if client gets a RTSP address all communication between client and steaming server proceeds directly over RTSP protocol without any notification to IMS. This is the weak point of this approach because unauthorized access to IPTV content is possible.

As shown in Figure 2, there are several control protocols involved during the IPTV service delivery process. Let us explain the different uses of two of them: Session Initiation Protocol (SIP) and Real Time Streaming Protocol (RTSP). Both SIP and RTSP are session setup and control protocols and they contain many overlapping capabilities.

SIP is used for controlling conversational communications, but also for Presence and Instant-Messaging. SIP is defined in [7] and supports several extensions. SIP has the following properties:

acts as a rendezvous protocol (with many capabilities),

carries the session description protocol,

supports invitation to unicast or multicast sessions.

SIP is treated as common control protocol in an IMS architecture. IMS assumed that SIP is used by clients as well as application servers to provide them all applications (voice calls, IM, multimedia services). It’s important that IMS provides user authorization, admission to the content and accounting based on SIP signaling.

RTSP is used for controlling of streaming communications such as the delivery of IPTV including Video On Demand. RTSP is defined in [17] and has the following properties:

acts as a lightweight rendezvous protocol,

supports trick plays and media control (pause/rewind/forward/...),

carries the session description protocol,

supports invitation to unicast or multicast sessions.

In general, RTSP protocol is suitable to provide setup and control functions for IPTV as it is in Internet (without IMS). But interworking of IPTV with IMS platform requires to support SIP by IPTV clients and streaming server. It is necessary to use facilities that IMS offers (i.e. authorization, accounting). The ETSI specification makes clear that the client uses RTSP to communicate with MFC for the purpose of media control. However the client as well as MFC use SIP to communicate with IMS core for other purposes.

Once the client sends the request to the IMS system, this must resend the request to a valid content server. The redirection of the request is performed by the so-called Application Server. The Communications Research Group of

the University of Cape Town created Application Server, which is an attempt of IMS based IPTV and VoD services. The main function of Application Server is to serve requests from users by mapping the requested channel in SIP protocol to a specific RTSP address. In addition, UCT Research Group has created software modules (Charging Modules) responsible for handling video streaming sessions in IMS core. These modules are responsible for controlling content, users, and charging. Anyway, the Application Server developed does not communicate directly with content servers (lack of implemented modules) and all the message exchange is performed with IMS core.

Typical VoD session scenario is:

1. IMS Client sends INVITE request with information about the desired content and codec. This request is forwarded to the Application Server by the IMS core module (after authorization and other sanity and security functionalities).

2. The Application Server receives database queries (xml file) and obtains the address of the RTSP stream desired.

3. The procedure calculating the volume of data carried out by charging modules: Charging Trigger Function Charging Data Function and Charging System Online.

4. Application Server responses to the IMS core with the content server address. The IMS core module contacts the content server (MCF module) for authorizing the content download. Note that this functionality could be performed directly by the Application Server (as allowed by ETSI in [16], but in the current open source implementations, the Application Server does not perform such a functionality.

5. At last, the address of the Content Server is returned in response to the customer IMS Client and she/he initiates the download stream by RTSP from the VLC server.

The fourth step is the one that required modifications in the Open IMS core modules as well as in the content streaming server for authoring the content download. Our work focused on the implementation of signaling between the server (IMS S-CSCF) and the VLC server, which is the last step for full integration.

The message exchange between Open IMS core and MCF (in VLC Server) is completed with only two messages. Open IMS forwards SIP INVITE message and MCF responses with SIP Offer Response message. Moreover, one more functionality is provided to the MCF module: when the request from the user arrives to the VLC server, then the MCF module checks whether this user is authorized for downloading the content. Information for such an authorization process is provided in the SDP information of the SIP INVITE message. Security aspects could ask for sending token or other parameters, but this has not been implemented in our modules.

The communication between S-CSCF server and VLC server is directed to ensure that the IMS system controls the downloads from the server (the user cannot directly connect the content server). This communication is missing in the FOKUS IMS implementation.

V. VOIPV6

Also in the implemented VoIPv6 conferencing system the core IMS is extended with some additional entities: Application Server (AS) and Media Resource Functions (MRF) server. The MRF server is a composition of two logical elements – Media Resource Function Processor (MRFP) and Media Resource Function Controller (MRFC). They are responsible for media manipulation (mixing, transcoding etc.) and media processing control, respectively. The application server (AS) functionality depends on the assumed implementation. In the described system it plays an important role for providing load-balancing, sessions monitoring and failover, among others. Moreover it hosts web application for conference management.

Communication between AS and MRF is provided in two different ways. SIP massages are sent via IMS/CSCF servers to ensure signaling control. Whereas, other information like session state, management parameters are sent directly via Cr interface. The Cr interface protocol has not been standardized yet. The presented implementation uses a custom text protocol.

During the conference, the participants are able to manage their sessions by means of a web application. They can adjust media session parameters like volume, gain, energy or mute and deaf functions.

The key feature, which we are centering on, is the reliability. Reliability is provided by means of fault detection and session failover, if needed. The proposed algorithm also includes load balancing of the original initialized or restored conference sessions on the MRF servers.

To maintain conference quality, we provide restoring of media parameters during the conference failover. In order to minimize the delay between media and management sessions failover, we use the custom SIP header field X-Conference-Parameters. This header allows to connect the participants to one of available media servers and to adjust the management parameters with the same values as they had before of the server failure. Figure 3 shows an exemplary failover scenario for conferencing service. As you can see in the figure, after initiating the conferencing session, the monitoring system detects a fault (MRF1 fault detection) and the AS triggers a failover by sending INVITE message to the S-CSCF module. When the MRF2 is prepared for the conference (the AS received the 200 OK message from the MRF2), then the AS initiates the failover at the clients’ side by sending an INVITE message to the clients.

In our implementation, the application server (AS) and media mixing servers (MRF) are connected to the core for providing conference services. The Application Server uses Kamailio [21] system for routing with load-balancing and dedicated Python modules for communication with MRF servers, which are FreeSWITCH [22] with several custom modifications. Once again, Python modules are used for Cr interface implementation.

The implementation work consisted of the modification of AS and MRF modules in order to incorporate the failover scenario (including fault detection and reporting) as well as the extension of ISC and Cr interfaces to support the necessary

exchange of messages for this scenario. Let us remark that the whole failover scenario runs over IPv6.

Figure 3. Conferencing failover scenario

VI. CONCLUSIONS

This paper is centered on implementation issues of IPTVv6 and VoIPv6 services for interworking with IMS. Specifically, we modified modules of UCT IMS Client, VLC server (live555 library) and Open IMS core in order to exchange signaling messages over IPv6.

On the other hand, we implemented new interfaces for IPTVv6, which were specified by ETSI-TSPAN IPTV/IMS architecture but were not implemented in open source software at the moment. These interfaces are used for indicating to the content server that a new user is authorized to download given content.

The last added functionalities are related with the Application Server and Media Resource Function module for VoIPv6 conferencing services. They provide new mechanisms improving service reliability by means of conferencing session failover. We used new SIP header field to minimize failover delay.

The implementations presented in this paper are a step straightforward for full integration of the IPTV and VoIP services with IMS on a IPv6 network. The new and modified modules we put on the Web (ftp://ftp.itl.waw.pl/IMS_IPTVv6_VoIPv6) and can be used by researches under GNU license.

ACKNOWLEDGMENT

This work has been partially supported by the Polish Ministry of Science and Higher Education under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045/09-00 Future Internet Engineering. We would also like to thank our project partners who have implicitly contributed to the ideas presented here.

REFERENCES

[1] ITU-Telecommunication Y.1910: “IPTV functional architecture”. 09/2008

[2] p2p-Next webpage: www.p2p-next.org

[3] Mobile3DTV project webpage: http://www.mobile3dtv.eu/

[4] Content Aware Networked systems Towards Advanced and Tailored Assistance project webpage: www.itea-cantata.org

[5] David H. Ramirez, "IPTV Security: Protecting High-Value Digital Contents". Wiley ISBN: 047051924X. January 2008

[6] J. Rosenberg, “A Framework for Conferencing with the Session Initiation Protocol (SIP)”, RFC 4353, February 2006

[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002

[8] O. Novo, G. Camarillo, Ericsson, D. Morgan, J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012

[9] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003

[10] J. Sim; T. H. Tieu; Y. Kim; "Conferencing service interworking between overlays and IMS networks", 2011 International Conference on Information Networking (ICOIN), vol., no., pp.513-518, 26-28 Jan. 2011

[11] ETSI TS 183 063 V3.5.2 "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification", March 2011

[12] ETSI TS 182 027 V3.5.1 "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV Architecture; IPTV functions supported by the IMS subsystem", March 2011

[13] M. Gomez, "Advanced IMS Multipoint Conference Management Using Web Services", IEEE Communications Magazine, Volume: 45, No. 7, 2007

[14] A. Buono, S. Loreto, L. Miniero, S. P. Romano, "A Distributed IMS Enabled Conferencing Architecture on Top of a Standard Centralized Conferencing Framework", IEEE Communications Magazine, March 2007

[15] S P. Romano, A. Amirante, T. Castaldi, L. Miniero, A. Buono, "A Framework for Distributed Conferencing", IETF Internet-Draft, December 2011

[16] Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); "IP Multimedia Subsystem (IMS)". ETSI TS 182 006. May 2008

[17] M. Eisler, "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999

[18] Ericsson E2E TV webpage:

http://www.ericsson.com/campaign/televisionary/

[19] Commercial Hikari Television webpage: www.hikaritv.net

[20] Open IMS core: http://www.openimscore.org/

[21] Kamailio SIP Server: http://www.kamailio.org

[22] Freeswitch: http://www.freeswitch.org

[23] UCT IMS Client: http://uctimsclient.berlios.de/

[24] J. Arnaud, D. Negru, M. Sidibe, J. Pauty and H. G. Koumaras, “Adapted IPTV Service within novel IMS Architecture”, ACM 1-58113-000-0/00/0004, MobiMedia’09, London, September 7-9, 2009