Streaming Session Transfer between Registered User Agents

Transcription

1 Streaming Session Transfer between Registered User Agents Zelalem S. Shibeshi 1, Alfredo Terzoli 2, Karen Bradshaw 2 Department of Computer Science Rhodes University, P. O. Box 94, Grahamstown 6140 Tel: , Fax: zelalems@rucus.ru.ac.za 1 ; {A.Terzoli, K.Bradshaw}@ru.ac.za 2 Abstract The development of telecommunication technologies has simplified the delivery of interactive multimedia services anywhere, anytime, and on any device. As a result, it is now easy to obtain multimedia services, such as IPTV, on small hand-held mobile devices, in addition to computers and TVs. This has pushed users to demand innovative new services, including the transfer of media sessions across the different devices. The lack of free and open source media servers and, conversely, the availability of free and open source streaming servers, have contributed greatly to the emphasis placed on streaming servers by the research community for the development and testing of new multimedia services. The delivery of multimedia systems involves both session control and media delivery control units. Furthermore, to provide multimedia session transfer, both of these units must support mobility. In this paper, we demonstrate how an RTSP protocol, as a media control protocol, can be used to deliver and also transfer streaming sessions to user agents without RTSP capability. A streaming server controlling unit has been developed and integrated into a SIP Application Server (AS) to implement this service. This paper discusses the overall architecture of the system and presents the results of the research. It also highlights issues surrounding streaming session mobility 1. Index Terms Multimedia streaming, streaming servers, streaming session transfer. I. INTRODUCTION The traditional vertical integration of services in the telecommunication world has prevented operators from delivering converged services. On the other hand, the introduction of Next Generation Networks (NGNs) has paved the way for the development of reusable services across different and disparate networks. NGNs have resulted in the convergence of the service delivery architecture by detaching and placing it into a single layer thereby allowing users access to the same service using 1 This work is being carried out in the Distributed Multimedia Centre of Excellence at Rhodes University, with financial support from Telkom, Comverse, Stortech, Tellabs, Amatole Telecom Services, Bright Ideas 39, and THRIP. different access technologies, both fixed and mobile. A user who has subscribed to IPTV, for example, can access the service at the office (on a computer), or via mobile (on the way to home) or at home (using TV). As the infrastructure for convergence becomes more and more accessible, greater pressure is placed on telecom operators to come up with various new services to tap the benefit of the infrastructure. One particular area in which telecom operators can benefit from this NGN architecture, is by providing session transfer or session mobility services. Session transfer refers to a user s ability to maintain an active session while switching between terminals, also called User Agents (UA). As specified in [1], there are several advantages of session transfer, namely a) maintaining continuity for mobile users, b) achieving better quality of service (e.g., improve voice quality by switching from mobile terminal to fixed terminal or improving video screen resolution), c) avoiding the loss of a session (e.g., avoiding battery depletion of a mobile by switching to a fixed terminal), and d) lowering the communication cost (e.g., by switching access from cellular to WiFi or fixed line). Although there are many competing visions of how service delivery can be achieved in NGN, one framework is currently gaining considerable momentum - the IMS framework [2]. Another service development environment that is the focus of much attention in the research community is Mobicents [3]. In this research we have used the Mobicents service development platform to demonstrate our service. Multimedia session delivery involves the use of a session control protocol to control the session, and a media control protocol to control the media delivery. Media delivery in the standard IMS architecture, for example, is implemented with what is known as the Media Resource Function (MRF), which contains two distinct parts, namely the MRFC (MRF Controller) and MRFP (MRF Processor) or Media Sever. The MRFC uses a media control protocol to control the delivery of media by the Media Sever (MRFP). For example, the MRFC requests the MRFP to play a multimedia resource to the connected user agent using specific media control protocol. Due to the lack of free and open source media servers, researchers tend to use open source streaming servers instead of a fully fledged Media Server to test media services. In the case of SIP communication between two users, the

2 issue of session mobility becomes an issue for the signaling protocol (SIP) only. This is true only when no transcoding is required and the media server (MRF, in the case of IMS) is not involved in the communication. However, when the session involves media delivery (as is the case for Videomail and VoD), the issue of mobility becomes an issue for the MRF as well. As a result, both the media controller and the media processor need to support session mobility in order to provide this service. Researchers have approached the problem of session mobility in a number of ways. Some have tried to solve the problem of session mobility for call related services, which is especially important when there is no involvement from the media server. Others have proposed different solutions for multimedia session mobility, particularly when the client has an RTSP stack, a protocol stack which is necessary to contact and control a streaming server directly. Nevertheless, since it is not common to find a User Agent that contains an RTSP client, this type of solution may not be applicable in all cases. As mentioned above, the easiest way to deliver and control multimedia service is through the proper use of media controller that can understand the media control protocol of the Media Server involved, which in our case is the RTSP protocol. As a result, dealing with the mobility issue for streaming session for user agents without an RTSP client (stack) is an important aspect. The aim of this research is, therefore, to investigate how RTSP is used in streaming session mobility and to develop a streaming session transfer service. In this paper we discuss how an RTSP based streaming server controller can be used to control streaming servers to deliver streaming service to UAs without RTSP support and perform streaming session transfer. A streaming server controller is developed for this purpose and is explained in the paper. This research is an extension of our open source testbed development in the convergence research group. The paper is organized as follows. Section 2 presents background information about multimedia service delivery in an NGN environment, streaming service delivery techniques, and how SIP supports session mobility. Section 3 discusses related works. The architecture and implementation of the system are discussed in Sections 4 and 5, respectively. Section 6 presents a discussion and analysis of the results. Finally, Section 7 presents our conclusions. II. BACKGROUND A. Multimedia Service Delivery With regard to multimedia service delivery, most implementations of NGN contain three planes: the Transport (Access) Plane, Control Plane, and Application (Service) Plane. In the middle of the Control and Access plane (layer) lies the media control and delivery unit (MRF in the case of IMS), which is at times also referred to as the Media Plane. As mentioned in the previous section, the delivery and control functions of the MRF are carried out by two distinct elements, namely the MRFP and MRFC. In general, the MRF provides the home network with the ability to play announcements, mix media streams (e.g., in a centralized conference bridge), transcode between different codecs, obtain statistics, and perform a variety of media analyses. Mobicents also uses a similar approach for media delivery. It has both media controller and media server units. Figure 1 shows the Mobicents media service architecture. To control the service and provide value-added services, multimedia services are usually delivered through Application Servers (AS). Thus, a UA that requires a multimedia session contacts an AS. The AS then interacts with the media controller, which then contacts the Media Server to initiate the media delivery to the user. The media controller, or MRFC in the case of IMS, is just a controlling component and does not actually deliver the media. The reason why the MRFC is introduced is that different Media Servers understand different protocols making it difficult for Application Servers and User Agents to contact Media Servers directly. In addition to this the AS can also use business logic to terminate or change the media during the session. In the case of IMS, the MRFC is also involved in bandwidth allocation and charging for the requested media service. Figure 1: Mobicents media server architecture With regard to implementation of the MRFP, the assumption is that the MRFP is to be implemented as a fully fledged Media Server capable of supporting at least the default media controlling protocol specified in the specification (H248) to provide various media related functions. However, as mentioned above, the practice in the research community is to use open source streaming servers. Thus, to meet the standard of the media delivery architecture, a media controller (or a streaming server controller in our case) is required that can communicate with streaming servers to ensure the proper use of streaming servers in this type of scenario. This type of setting can also benefit UAs that don't have RTSP capability because the media negotiation is done by the media controller. Another advantage of having a separate streaming server controller is that it is easy to control the media transfer. With the AS and the streaming controller in between the streaming session, charging and other service control functions can easily be implemented because the AS can be notified when the user finishes watching the session or terminates it. So far, to the best of my knowledge, there is no publicly available streaming server controller for use in this situation. Consequently, we have developed a Streaming Server Controller (SSC) and integrated it into the AS. The SSC is used to develop the session transfer service. The next section discusses streaming service delivery.

3 B. Streaming Service Delivery The RTSP protocol is used to initiate streaming session with streaming servers [4]. The protocol can also be used to control streaming session with trick play functions. An RTSP client sends a DESCRIBE command together with the URL of the media to the streaming server to obtain detailed information about the media that it wants to receive. If the request is properly formed and the server can access and play the requested media file, the streaming server responds with an OK message by including the detailed information about the media. The information included in the OK message includes the track id, i.e., an id for each track, and the codec type with which each track is encoded, among others. Once the OK messages have been received, the client, if it is able to decode the tracks, sends back a separate SETUP request to the server for each track including transport parameters. The transport parameter basically contains the transport protocol the client wishes to use (usually RTP) and the port number on which the client wishes to receive the track. The server responds with an OK message if the request is properly sent. Finally, the client sends a PLAY request to start the media session. The RTSP protocol also specifies a destination parameter in the transport section of a SETUP request to set up the destination of the media. This field needs to be included in the transport section of each setup request for which a different destination is needed. If the server supports this feature, it sends the media to the specified destination when the media delivery begins, but continues to send the RTSP responses to the location that initiated the RTSP session. The RTSP specification also mentions that the SETUP command can be used to modify the transport parameters of an already established streaming session, which include the destination of the media. The work presented in this paper was motivated by this feature of the RTSP protocol. sends a SIP REFER command to the second UA to contact the third party. Once the second UA has contacted the third party, it notifies the first UA about the status and the first UA hands over the session and leaves. The flow diagram in Figure 2 shows how the basic SIP REFER method is used to transfer a session. III. RELATED WORK Session mobility has been at the center of research in the NGN arena for quite some time. Much research has been carried out to demonstrate different ways of session mobility particularly for SIP based communication. However, as the concern of this paper is on multimedia session transfer, we present the related works in this context. In this regard, the authors in [1], for example, show how a complete service context (e.g. the currently watched video session and its caller ID service on IPTV) can be migrated via IPTV session transfer. The authors, however, failed to mention how the media is controlled or how the media session is transferred. In general, the paper focuses on how CallId is transferred between different devices and does not explicitly address the media transfer aspect. Ref. [6], on the other hand, shows how an msctp (Mobile Streaming Control Protocol) supports QoS provisioning and adaptation for mobile nodes when moving in a heterogeneous wireless environment. The emphasis of this research, is predominantly on wireless technology. The theoretical work presented in [7] discusses the idea of session mobility in an IMS environment and proposes a Mobility Server, which is essentially a session continuity application server. The paper focuses on developing an IMS session continuity standard and does not provide any implementation details. The combination of presence and RTSP to transfer IPTV sessions is demonstrated in [8]. This paper shows how the SIP Refer method can be used to transfer multimedia sessions. The streaming request, however, is done by a UA with an RTSP stack. So, the work cannot be applied to other User Agents that do not have an RTSP stack. The integration of other media sessions (like video call between the media session transfer) is another feature described in the paper. A similar work, albeit for ubiquitous media players, is presented in [9]. This research again considers session mobility for clients with an RTSP stack. Figure 2: Session transfer using the SIP REFER method C. Session Mobility in SIP Session mobility from a SIP signaling point of view is mostly done using the SIP REFER method [5]. Two different cases can be considered: attended and unattended transfer. For example, in the case of a basic session transfer (unattended), the UA that wants to forward the session IV. ARCHITECTURE OF THE SYSTEM Many components are required to provide a multimedia service in an NGN environment. However, for the sake of simplicity, we only explain the interaction of a UA, an AS, and the MRF in this paper. On the other hand, while the IMS specifications separate the AS, the MRFC, and the MRFP, implementations can combine one or more of these elements into a single node [10] [11]. In this work we integrated the media controller into the AS. Considering this simplification, the block diagram in Figure 3 presents a high level view of our service development environment.

4 V. IMPLEMENTATION Due to the possibility of DoS attacks, the destination parameter described previously, is not supported by many of the popular streaming servers. An investigation of the different streaming servers revealed that different streaming servers also specify some parameters of the RTSP protocol differently. Surprisingly, this includes even the standard fields. For example, the way the Track Ids are described and set by streaming servers is completely different and one needs to know how each server specifies the fields and the values it assigns or expects in order to parse the responses, as well as send commands correctly. We see this as a major problem for developers. Figure 3: Architecture of the streaming session transfer service The block diagram shows how our architecture fits into the different standard components required to provide multimedia session transfer in an NGN environment. The AS is always present and with regard to the streaming server controller, the SSC can be considered as one component of the media controller. In other words, when the media controller has to deal with streaming servers, it can use the SSC. The different signaling protocols used in the interaction of these components are also depicted in the diagram. Figure 4 depicts a high level flow diagram that shows the messages (commands) that are passed from one component to another and the important actions performed by each component. In general, with regard to support for the destination parameter, from our investigation, the popular open source streaming servers, VLC [12] and Darwin [13] do not support the use of this parameter. Darwin sends an Invalid Code error code whereas VLC just ignores it. On the other hand, using a certain configuration setting, Live555 [14] allows the use of this parameter. For this purpose we used the Live555 streaming server to demonstrate this feature. Figure 5: Flow diagram of streaming session transfer service Figure 5 shows a detailed flow diagram of the streaming session transfer service using the SIP and RTSP signaling methods and the following subsections briefly describe how the different components are implemented. Figure 4: Higher level flow diagram The next section briefly describes the implementation considerations and detailed interaction between the different components to deliver the service. A. The Application Server The architecture presented above was originally developed to deliver streaming session to UAs without RTSP support. Later, it was modified to deliver the streaming session transfer service as well.

5 The streaming session delivery service is done as follows. The system has been developed based on the concept of IPTV with a UA sending streaming session requests in the form of a channel. As a result, when an INVITE message arrives at the AS for the first time, it sends a SIP TRYING message to the user agent. It then checks the lookup table to extract the URL that relates to the requested channel. After extracting the SDP information attached to the INVITE message, the AS calls the createmediasession method of the SSC by supplying the SDP information and the URL as parameters to create the media session. On receipt of the track information of the requested channel from the SSC, the AS forms an SDP and sends an OK message to the client. The SDP information includes the port number of the streaming server for each track and also the codec types used to encode the tracks, amongst others. The sendonly parameter is also used in the SDP, so that the UA knows that the media session is a one way communication. Finally, when the AS receives an ACK from the UA, using the startmediasession method, it requests the SSC to start the media session and the user starts to receive the media. To accomplish these tasks, the AS uses an open source SDP API to parse and form an SDP object and is developed based on the JAIN-SLEE service building block specification[15]. Session transfer, as mentioned above, is mostly used with the SIP REFER method. However, the SIP REFER method is not implemented in the current version of Sip- Communicator which we have used for the SIP User Agent. Consequently, we use the Re-INVITE method to signal the session transfer request to the AS. Basically, according to our implementation, the AS performs the following tasks when streaming session transfer request comes: initiate a steaming media session with another user agent, and then instruct the SSC to change the direction of the stream to the new User Agent. Technically speaking, the AS sends an INVITE message, using the SDP information of the media that was formed previously, to all devices registered to the same user that requested the transfer. In addition, it also requests the SSC to modify the session. When an OK message is received from any one of the UAs, the AS follows the same procedure described above to start the media session to the other device. B. Streaming Server Controller The SSC is implemented as a separate Java class and instantiated in the AS. It has four public interfaces, namely createmediasession, startmediasession, stopmediasession, and mofidymediasession, to interact with the AS. When the SSC gets a createmediasession request from the AS, it contacts the streaming server to create a session and when the session setup is ready, it returns the track information of the channel to the AS. When the AS gets an ACK message from the client, and asks the SSC to start playing the streaming session using the startmediasession method, the SSC sends a PLAY command to the streaming server, which then starts sending the video directly to the client. Next, when the user wants to transfer the session and when the SSC is informed about this by the AS, it sends a PAUSE command to the streaming server, modifies the transport parameter of the streaming session, sends a new SETUP request, and waits for the AS to issue the startmediasession command. The rest follows the same procedure discussed above. VI. DISCUSSION AND ANALYSIS As discussed in the previous section, it was compulsory for us to use the destination parameter of the SETUP request to develop the service. However, we came to realize that, because of the possibility of DoS attacks, most streaming servers do not allow the use of the destination parameter in the SETUP request. This, we believe, will complicate the development and implementation of multimedia services, like streaming session transfer. Owing to the various IETF recommendations [16][17] that can be employed in streaming servers to avoid DoS attacks, we see no reason why this feature cannot be implemented. In fact, the RTSP specification itself advice implementors so that streaming servers can use this parameter provided they verify the client's identity, either against a database of known users using RTSP authentication mechanisms (preferably digest authentication or stronger), or other secure means[4]. In general, a stricter security feature can be deployed between the streaming server and the SSC. This would allow researchers to use this feature to conduct innovative research, particularly since streaming servers are becoming more and more popular in the research community to develop and test multimedia services. As for the SIP session, there are various security features that can be implemented. A detailed discussion on such security mechanisms is beyond the scope of this paper. An alternative to requiring streaming servers to support destination parameter is, to develop an RTSP Proxy with an RTP relay feature. There will definitely be some delay in sending the stream (RTP packets) to an intermediary (the proxy), and furthermore, managing all the network connections and sessions by the proxy might be overwhelming. But this can help develop session transfer applications that can be used with any type of streaming server, without the need for modification. The way that streaming servers present parameters makes the task of developing a streaming server controller (like SSC) very difficult. Code written for the Darwin Streaming Server may not work with the VLC streaming server. This implies that, the SSC we developed should be robust enough to be able to communicate with the different streaming servers and adjust itself accordingly. VII. CONCLUSION In this paper we have demonstrated how streaming session transfer can be implemented using streaming server proxy. RTSP, as the streaming session control protocol, can be used to develop a streaming media controller that can be used to control and transfer multimedia services. The paper also discussed the issues related to streaming servers and how they differ when referring to the different parameters and fields in RTSP messages. With regard to the

6 support for mobility by streaming servers, the paper discussed the measures that streaming servers can take in order to avoid DoS attacks and allow the use of the destination parameter. Streaming servers can implement security measures indicated in RTSP protocol or other IETF recommendations mentioned in the previous section. In our opinion, the use of this feature far outweighs the risk it poses. We trust that more streaming servers will allow this feature in the future to assist researchers in developing different types of multimedia services using it. We envisage extending this work in the following ways. The session transfer service will be more interesting if it is coupled with presence information. Users will then be able to call their friends, talk about the video they are watching and eventually be able to transfer it to them. This is one of the areas that we aim to investigate. As both Darwin and VLC are open source streaming servers with a broad file type support, we also intend modifying these servers to include support for destination parameter, which can be used for session transfer. At present, when a session transfer request is received, the current system merely sends out an INVITE to all registered equipment for the same user that requests the session transfer. It would, however, be beneficial if the AS could send the transfer request to a device that is capable of decoding the current stream. In the event that the user does not have a device capable of decoding the stream, this can also be done by incorporating a unit that transcodes the media into an appropriate format before sending to the target device (this, in fact, will provide a seamless session transfer capability). So, device capable session transfer will be the next area of work that will be carried out in relation to this. In order to handle high traffic, load balancing features will also be included in the SSC. Time Streaming Protocol (RTSP) for Feature-rich Session Continuity in the IP Multimedia Subsystem (IMS). In SATNAC'09: Proceedings of the 12th Southern African Telecommunications Networks and Applications Conference. Ezulwini, Swaziland, 30 August to 2 September [9] J-M. Lee et al. Proxy-based Multimedia Signaling Scheme Using RTSP for Seamless Service Mobility in Home Network. IEEE Transactions on Consumer Electronics, vol. 54, no. 2, pp , [10] J Grecco et al. Using Intel Technologies to Build Next- Generation Media Servers. Intel Technology Journal. vol. 10, issue 1, pp , Feb [11] Dialogic. The Architecture and Benefits of IMS. White Paper [12] VLC. VideoLAN, Free streaming and multimedia solutions for all OS. Available Online, URL. [13] Darwin, Open Source Streaming Server, Available Online, URL: server/streaming. [14] Live555. Internet Streaming Media, Wireless, and Multicast technology, services, & standards. Available Online, URL. [15] JAINSLEE.org. Available Online, URL. [16] J. Rosenberg. The Real Time Transport Protocol (RTP) Denial of Service (Dos) Attack and its Prevention. Internet Draft. [17] J. Arkko, et al. Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP). Internet Standard. REFERENCES [1] I Más, V Berggren, R Jana, J Murray, and C W Rice. IPTV Session Mobility. Available Online, URL: gies_ , Accessed March 1, [2] E. Burger. Media Services in the IMS: Evolution for Innovation, Cantata Technology, [3] Mobicents-Public. URL: group /mobicents-public/web [4] The RTSP RFC. [5] The SIP REFER RFC. [6] N. H. Thanh, N. T. Hung, T. N. Lan, and M Thomas. msctp-based Proxy in Support of Multimedia Session Continuity and QoS for IMS-base Networks, 2nd International Conference on Communications and Electronics, 2008, June 2008 [7] M Mani, N. Crespi. Session Mobility between Heterogeneous Accesses with the Existence of the IMS as the Service Control Overlay, 10th IEEE International Conference on Communications Systems, ICCS, [8] K Marungwana, and N Ventura. Presence and Real Mr. Zelalem S. Shibeshi holds an MSc in Information Science, Diploma in Computer Science, and BSc in Physics, all from Addis Ababa University, Ethiopia, and is currently working towards his PhD in the Computer Science Department at Rhodes University. Alfredo Terzoli is a Professor of Computer Science at Rhodes University, where he heads the Telkom Centre of Excellence in Distributed Multimedia. He is also Research Director of the Telkom Centre of Excellence in ICT for Development at the University of Fort Hare. His main areas of academic interest are converged telecommunication networks and ICT for development. Dr. Karen Bradshaw is a Senior Lecturer in the Computer Science Department at Rhodes University.