Method and system for transmitting a multimedia stream

Description

Field of the Invention

[0001] The invention relates to a method and system for transmitting a media stream from a first terminal to a second terminal. More particularly, the invention relates to a method and system for transmitting a first media stream from a first terminal and receiving a second related stream from a second terminal. The invention further relates to a gate and device for use in said system.

Background of the invention

[0002] The IP Multi-Media Subsystem (IMS) as defined by the 3GPP and 3GPP2 standards opens the door to a whole range of new multimedia services such as Voice over IP (VoIP) and IPTV. The architecture of the IMS service enables the combination of various types of multimedia services.

[0003] One type of service may allow viewers at home to participate in real-time live TV programs using e.g. a home webcam. The multimedia streams generated by the webcam are transported from the user at home over the IP network to the TV studio using the Real Time Transport Protocol (RTP). In an IMS-based architecture, the streaming media sessions between clients are set up using the Session Initiation Protocol SIP, with the Real Time Streaming Protocol (RTSP) being typically used for streaming multimedia content. from server to client.

[0004] There are systems known in the art that provide an interface between SIP and RTSP domains, typically referred to as SIP-RTSP gateways. Within the ETSI TISPAN Standardization (WI2048, TS 182 027) an architecture has been proposed in which the terminal, contained in a device such as, for example, a set-top box (STB), personal computer, personal digital assistant (ang. Personal Digital Assistant (PDA) or a mobile phone with multimedia capabilities, uses SIP to set up a multimedia session with the selected content provider. After the session is established, RTSP is used to select, acquire and control the streaming content. In addition, Columbia University (Kundan Singh and Henning Schulzrinne, Unified Messaging using SIP and RTSP, IP Telecom Services Workshop, September 2000, Atlanta, Georgia, USA) has also developed the SIP-RTSP Gateway for Unified Multimedia Messaging.

[0005] These systems employ SIP and RTSP clients on the user side and SIP clients and RTSP servers on the network, thereby enabling the user to initiate a multimedia session setting in which multimedia content is streamed from the RTSP servers to the user.

[0006] Another gateway system that may be used to stream media between different protocol domains is described in TAKEIK IN. Design of gateway system between different signaling protocols of the multimedia session on the internet INFORMATION NETWORKING, 2001. PROCEEDINGS. 15TH INTERNATIONAL CONFERENCE JANUARY 31-FEBRUARY 2, PISCATAWAY, NJ, USA, IEEE, 2001, PAGES 297-302, ISBN: 0-7695-0951-7 / 01. This system was used for the mutual operation of the SIP and H323 domains. Both protocols are peer-to-peer protocols and allow for bidirectional session setup / initiation.

[0007] One problem with these known systems is that they do not provide all the functionality required for the above-described services that require the user to initiate the establishment of a multimedia session such that it is streaming user generated content from the user (broadcast end) to the studio (end receiving), with the studio wanting to control the stream of user-generated content. A known protocol for controlling the stream is RTSP, and the receiving end with RTSP client functionality may be able to pause, rewind or rewind the stream, or play the stream at a different speed. If, on the other hand, the transmitting end is only able to use the SIP protocol for setting up and maintaining a multimedia streaming session, then said services cannot be performed by prior art systems because the SIP protocol does not provide the means to control the flow in the way it is for example, a valid RTSP protocol.

[0008] Another media streaming problem that may arise with prior art systems is that when the receiving end is provided with only client functionality with a client-server protocol for multimedia reception, it may only be able to initiate a multimedia session. If the transmitting end using a peer-to-peer protocol such as SIP protocol wants to initiate a multimedia streaming session, the receiving end is not capable of responding to the invitation. Prior art systems such as the known SIP-RTSP gateways and the known SIP-H323 gateways do not provide a solution to this problem.

[0009] In the publication entitled A testbed for experimentation of innovative services in the B3G Framework from Fresa et al., On the course of the First International Conference on Measurement Stations and Research Infrastructures for Network and Community Development (Conference on Testbeds and Research Infrastructures for the Development of Networks and Communities) (TRI-DENTCOMO5) ISBN: 978-0-7695-2219-X / 05, a test stand developed by Co.Ri.TeL is described. The Presto Project consortium, which aims to provide a suitable and common platform, inspired IMS ideas to experiment with a wide range of mobile services based on B3G SIP. The services experimented at the top of the bench include multi-user video conferencing architecture, user-defined value-added multimedia services, audio-video mailbox, and video-on-demand infrastructure. All service delivery mechanisms are built within the framework of universal mobility and safety management,

-3 by providing an approach that is independent of the various possible primary radio access technologies. The security capabilities of the developed architecture, for example, include user and network authentication, service access authorization, and cryptographic signaling of the IP layer integrated into the mobility of the mobility layer.

[0010] In the Internet Draft of the MMUSIC Working Group from S. Whitehead et al. with the title An Evaluation of Session Initiation Protocol (SEP) for use in Streaming Media Applications; draft-whitehead-mmusic-sip-forstream-ing-media-02 summarizes the set of use cases and their related requirements, where convergence between the Session Initiation Protocol (Session Initiation Protocol) was suggested. Session Initiation Protocol (SIP) and the Real Time Streaming Protocol (RTSP and RTSP v2), which can be beneficial in media streaming applications. This benefit is especially apparent in the context of converged / mixed media services.

[0011] EP 1890463 A1 discloses a method for providing interactive services over a telecommunications network. In the method, an audio / video (A / V) stream and control data are exchanged between the application server and the multiplexing and access control module of the telecommunications network by means of an interactive multimedia bidirectional protocol. Internet Protocol Television Service Protocols Internet protocol television (IPTV) has been implemented within a telecommunications network to communicate with television equipment at customer premises, the IPTV protocols including a streaming protocol for transmitting the A / V stream to television equipment at customer premises received from the application server and a one-way interactive protocol for reception user commands in the multiplexing and access control module. User commands are further converted to bidirectional interactive protocol messages for transmission to the application server, and the response data is passed from the application server to the TV hardware at client premises from where the user command originated.

[0012] Many additional problems can arise in prior art systems when user-generated multimedia is to be streamed to multiple receiving ends. All these receiver ends may have different capabilities or performance to receive a media stream. One receiving end may need to receive the live stream while the other may need to be able to control the stream as described above. These preferences and possibilities, as well as the network addresses of the receiving ends, must not additionally be known to the transmitting end.

Summary of the invention

It is an object of the invention to reduce or eliminate at least one disadvantage of the prior art and to provide a method of transmitting a first media stream from a first terminal (12) and receiving an associated second media stream at a second terminal (16), the first and the second terminals are coupled to at least one gateway (15) to enable transmission of the first media stream and reception of an associated second media stream, the method comprises the steps of:

The first terminal initiates the exchange of information on the specifications of the first multimedia session between the first terminal and the gateway using the first protocol;

the gateway provides a trigger signal to the second terminal to inform the second terminal of the availability of a new multimedia stream and to initiate an exchange of information on the specifications of the second multimedia session between the second terminal and the gate using the second protocol; the trigger signal includes a gateway network address;

- in response to the provision of the trigger signal, the second terminal initiates the exchange of information on the specifications of the second multimedia session between the second terminal and the gateway using the third protocol, the third protocol is a client-server type protocol and is different from the second protocol and the first protocol; said second terminal includes a third protocol client side;

- transmitting a first media stream from the first terminal and receiving a second associated media stream at the second terminal.

The method thus allows the user of the first terminal to transmit the real-time user generated media stream to the second terminal, the first terminal employing a different media protocol to set the media stream to that used by the second terminal for receiving the associated media stream.

[0014] In the method of the embodiment, the gateway is capable of connecting a first terminal supporting a first protocol, e.g. SIP, to a second terminal supporting another (third) protocol, e.g. RTSP. Relative to the first terminal, e.g. the user-side (starting) SIP client, the gateway acts as a SIP (terminating) client. The gateway exchanges information about the specifications of the first multimedia session with the first terminal. In the first multimedia session, the media stream is transmitted from the first terminal. With respect to the second terminal, e.g., an RTSP client, the gateway acts as an RTSP server on behalf of the user, the second terminal using RTSP to exchange the specifications of the second multimedia session with the gateway. In the second multimedia session, the media stream is received at the second terminal.

The second terminal is called using a second protocol that is different from the protocol used by the second terminal for exchanging information about the second multimedia session, informing the second terminal of the availability of a new media stream and activating the RTSP client to connect to the gateway RTSP server function. . RTSP client activation can optionally only occur after the approval of the user of the other terminal. The approval stage is then simply part of a fully automated process.

[0016] The gateway functions as both a SIP client and an RTSP server, and may provide a trigger signal to a second terminal to connect the second terminal to the gateway. The invention is based on the idea that the trigger signal is provided using a different protocol to that used by the second terminal to organize the reception.

-5multimedia. This idea was based on the idea that certain protocols are only capable of initiating a multimedia session in one direction. The trigger signal (message) ensures that the SIP clients from the user and the RTSP clients from the studio can be coupled to each other to allow the transmission of user generated content from the first terminal to the second terminal.

[0017] In a further embodiment of the method according to the invention, the information exchange of the first multimedia session comprises providing at least a portion of the information of the second multimedia session to the first terminal, thereby initiating transmission of the first multimedia stream from the first terminal in response to said assurance. This is advantageous by providing additional flexibility to the method. It is no longer a gateway that provides the preconfigured specifications of both associated multimedia sessions to the terminals involved in transmitting and receiving the stream, but the gateway may apply the settings (requested) from the second receiving terminal and deliver them to the first transmitting terminal. Conversely, for the same benefit, the gateway may apply the settings (requested) from the first transmitting terminal and provide them to the second receiving terminal. In both situations, the broadcasting and reception of media streams, respectively, can only start after changing these settings.

[0018] In an embodiment of the method, the first protocol is a peer-peer protocol, preferably a Session Initiation Protocol (SIP). An advantage of the peer-to-peer protocol is that both parties can initiate the streaming session setup. Therefore, in the invention, it may be the first terminal offering the media stream or it may be a gateway requesting the media stream offer first from the first terminal. The SIP protocol is a very commonly used protocol in multimedia sessions, therefore many devices and network architecture support this protocol.

[0019] In the method, the third protocol is a client-server protocol, preferably a Real Time Streaming Protocol (RTSP). The client-server protocol is typically a protocol that is designed to support only one way initialization of the multimedia session setup. Only the client can typically initialize the setting. Therefore, an invitation is preferably used when the second receiving terminal only has the client capabilities of said protocol and therefore is not able to receive an invitation via said protocol. The use of the RTSP protocol may be advantageous when the second receiving terminal wants to control the incoming stream and apply special control options from this protocol.

[0020] In the method, the step of providing a triggering signal to the second terminal is initiated by a gateway. If the gateway rather than the first terminal, for example, provides a triggering signal, this may be advantageous when the first terminal does not have the proper triggering capability, does not know how to reach the second terminal, and with multiple receiving terminals to which it has arrive.

[0021] In the method, the triggering signal comprises a network address, preferably a URI or a gateway URI reference. This may be advantageous if the second terminal is not configured with the address

The default or the default (proxy) address used for receiving media streams is not applicable.

[0022] In another embodiment of the method, the information exchange of the first multimedia session comprises providing an identifier of the second terminal to the gateway. This may be advantageous if it is the gate that provides the trigger signal to the second terminal. In this situation, it is the gateway that needs to be able to identify the address of the other terminal to reach.

[0023] In a further embodiment of the method, the method comprises the additional step of decomposing the identifier of the second terminal into a network address by providing a triggering signal to the second terminal. This may be when the trigger signal is sent to the gateway and the identifier does not include the network address of the other terminal. The identifier may be a closed user group ID, in which case all network addresses of all receiving terminals must first be identified.

[0024] In another embodiment of the method, the first and second protocols are identical. This simplifies the implementation of the method. A situation similar to this may occur where the receiving terminal has both RTSP and SIP client capabilities. The trigger signal can then be provided using the SIP protocol, where the initiation and setting of the reception of the media stream can be performed using the RTSP client, thereby enabling control functionality (artificial play) which is lacking in SIP.

[0025] In another method embodiment, the second associated media stream is a multicast stream. This may be advantageous when there may be a live media stream offering for multiple receiver terminals. They may apply IGMP, after providing a trigger signal to them, and after receiving a multi-broadcast address from the gateway in the second multimedia session information, to sign up for multi-broadcast.

[0026] In a further embodiment of the method, the first media stream is a multi-broadcast stream. This is advantageous when the first transmitting terminal has (received) a multi-broadcast address which it can use in multi-broadcast of its media stream.

[0027] In yet another embodiment of the method, the first media stream is the same media stream as the second associated media stream. In this case (live) content can also be received live / without any significant delay from the first transmitting terminal. To allow additional functionality (control) to be played artificially, the broadcast media stream must be streamed and buffered first to a location under the control of the media server, such as an RTSP server, before it is retransmitted as a second associated stream to a second terminal. Additional control functions (e.g., forward, backward, pause) may then be performed on this second associated stream.

[0028] In another embodiment of the method, both the first terminal and the gateway are contained in the same device and the first protocol is an internal protocol. Maybe

This would be a preferred embodiment when the network (or studio / receiving end) does not have the gateway functionality of the invention. This situation can advantageously occur when there is a one-to-one relationship between the transmitting and receiving terminals and both terminals are included in the mobile devices.

[0029] In an example, the invention relates to a system according to claim 12. In a further embodiment of the system according to the invention, the gateway further comprises means for associating information of the first multimedia session with the information of the second multimedia session. This can be advantageous when the gateway does not have a default configuration how to instruct the transmitting and receiving terminals, and when a more flexible arrangement is required, how to accommodate setup requests and the capabilities of the terminals involved when setting up multi-broadcast sessions.

[0030] Yet another aspect of the invention relates to a gateway according to claim 11. In a further embodiment of the gateway according to the invention, the gateway further comprises means for associating the information of the first multimedia session with the information of the second multimedia session.

[0031] In yet another embodiment of the gateway according to the invention, the gateway comprises SIP client functionality and RTSP server functionality.

[0032] In yet another embodiment of the gateway according to the invention, the gateway is nested within an IMS network architecture, wherein the first protocol is SIP, the third protocol is RTSP, and wherein

the means for exchanging information of the first multimedia session is part of a Service Control Function within the IMS

- the means for calling the second terminal is part of the Service Control Function within the IMS

the means for exchanging information of the second multimedia session is part of the Media Function within the IMS

[0033] IMS is an architecture that is becoming more and more popular among operators for use in providing multimedia services to their customers. A distributed gateway according to an embodiment of the invention is particularly advantageous as it can be implemented using standard (standardized) components and functionalities that are already present in the IMS architecture.

[0034] In yet another object, the invention relates to a device according to claim 13. It may be advantageous if the network (operator) does not include or support a gateway according to the invention. For example, the device may be the first mobile device willing to offer a live stream to a home computer accessible over the Internet.

[0035] In a further example, the invention also relates to a computer program product having software code portions configured to, when operated in a terminal or gateway memory, perform the steps of the inventive method.

[0036] The invention will be further illustrated with reference to the accompanying drawing which schematically shows embodiments according to the invention. It should be understood that the invention is in no way claimed by these specific embodiments.

Brief description of the figures of the drawing

[0037]

Fig. 1 shows an exemplary system in which the invention may be practiced.

Fig. 2 shows a simplified example information flow using the SIP protocol.

Fig. 3 shows an exemplary information flow using the RTSP protocol.

Fig 4 shows an embodiment of the invention.

Fig. 5a illustrates the information flow between SIP Client, SIP-RTSP Gateway and RTSP Client in an embodiment of the invention.

Fig. 5b illustrates information flow between a SIP Client, SIP-RTSP Gateway, and RTSP Client in another embodiment of the invention.

Fig. 5c shows the information flow between the SIP Client, SIP-RTSP Gateway and RTSP Client in an embodiment of the invention whereby the first terminal and the gateway are included in the mobile device.

Fig. 6 shows an architecture configured for use in the invention.

Fig. 7 illustrates information flow in an exemplary IMS architecture configured for use in the present invention.

Detailed description

[0038] Fig. 1 shows an exemplary system in which the invention may be applied. At the home location, the first terminal 1, e.g. included in the set-top box, is connected to a display device, e.g. a TV. The first terminal further receives a TV signal 2 which is broadcast by a television studio and which includes a program for participation in live multimedia for the user located at home. In one embodiment, participation in user media may be performed using e.g. a webcam 3 connected to the terminal. The multimedia stream 4 generated by the web camera is streamed over the IP network 5 to a second terminal 6 located in the TV studio. In the TV studio, the second terminal 6 receives the user generated media stream 4. Live video feed from user to studio can thus be provided.

[0039] The service requires (i) a home user capable of setting up a multimedia session between the first home terminal 1 and the second studio terminal 6, the multimedia session enabling the streaming of user generated multimedia content 4 to the studio and (ii)

Allowing the studio to control (e.g., play, pause, stop) the media stream sent by the terminal located at home.

[0040] It will be appreciated that the home location system allowing multimedia participation as described in conjunction with Fig. 1 may be implemented in various alternative manners. It will be understood by those skilled in the art that the first terminal 1, the display device and the web camera can be integrated into one device, for example, such as a personal computer, digital assistant (PDA), multimedia capable mobile phone. For example, the studio system may similarly be a media server including a second terminal, the second terminal including an RTSP client for acquiring the media stream. The second terminal may alternatively be located on the mixer or transcoder and configured to adapt the media stream.

[0041] In a further variant, the second terminal can be part of a device that is located in a different (home) location and used to transmit the media stream from user to user. The device containing the second terminal may be a dedicated set-top box, a personal computer or a mobile phone containing media player software.

[0042] The first terminal may be considered as a functional unit in an apparatus or device capable of managing (initiating, negotiating, monitoring and controlling) the transmission of the media stream. The second terminal may similarly be considered a functional unit in a device or device capable of managing (initiating, negotiating, monitoring and controlling) the reception of a media stream.

[0043] The IMS architecture uses the SIP protocol to set up and / or negotiate a multimedia session between two SIP clients, e.g. two IP phones. Here, the term client may indicate a particular device or terminal capability. For example, a SIP client may relate to a device configured to use the SIP protocol or a terminal having SIP capabilities.

[0044] An exemplary flow using the SIP protocol is shown in Fig. 2. The first SIP client typically sends a SIP INVITE 7 to the second SIP client, which in turn accepts the invitation by sending a SIP 200 OK message 8 to the first SIP client. Both messages can carry information about the multimedia session. This information is exchanged using a Session Description Protocol SDP which may be encapsulated by the SIP protocol. The multimedia session information may include, but is not limited to, IP addresses, port numbers for RTP streams, media type (voice, audio, video, etc.), and codec information. The multimedia can then be streamed between SIP clients using the RTP protocol.

[0045] SIP is however designed to set up and support interactive media sessions. Although SIP also provides a form of streaming aggregation control (e.g., the ability to control multiple streams from different sites through a single control session), it does not provide efficient control as provided by the RTSP protocol used in

-10 streaming applications such as Video on Demand (VoD). The RTSP protocol allows the client to remotely control a streaming media server (RTSP) by issuing VCR commands such as play, pause, stop, fast forward, rewind etc. and allows time-based access to files on the server. In addition, legacy hardware may require the use of RTSP because legacy hardware cannot be provided with the SIP client. Fig. 3 is a schematic representation of an exemplary flow using the RTSP protocol. When setting up and controlling an RTSP multimedia session between the RTSP client and the RTSP server, standard RTSP messages (OPTIONS, DESCRIPTION, SETTINGS, PLAY) are exchanged between the client and the server to provide information to both parties required for the RTSP session. The way RTSP is designed to work is by the RTSP client initializing the setup of said session, not the RTSP server. Similar to SIP, RTSP session information is exchanged using a Session Description Protocol (SDP) that may be encapsulated by the RTSP protocol. Once the session is set up, media can be streamed from the server to the client 11 using the RTSP protocol, with the RTSP allowing the client to control the streaming.

[0046] Fig. 4 shows a schematic view of a system embodying an embodiment of the invention. In this embodiment, the first home terminal 12 includes a SIP client 13 that is capable of setting up a SIP session 14 with the SIP-RTSP gateway. The SIP-RTSP gateway may be placed in a device which may also include a second terminal 16 in the TV studio. The second terminal 16 includes an RTSP client.

[0047] With respect to the SIP (beginning) client of the first user-side terminal, the gateway acts as a SIP (terminating) client. The gateway confirms that it can receive the multimedia session from the first terminal and informs the first user-side terminal of the session details and RTP port number. This first media stream session information may be exchanged using the SDP protocol which may be surrounded by SIP messages.

[0048] The gateway may further be capable of converting an identifier received from the first terminal, used to identify the second terminal, into a network address of the second terminal. The conversion can be performed by the gateway or under the control of the gateway by another module. The identifier may already be the corresponding network address of the second terminal, in which case no processing is required.

[0049] In response to initiating the session information exchange of the first media stream, upon provisioning with the appropriate network address, the gateway may send the trigger message to the second terminal. The triggering message instructs the RTSP client to initiate an RTSP session with the gateway. The gateway does not need to send the trigger signal itself, but it can also instruct another module (such as the Short Message Service Center). Short Message Service Center - SMSC)) to do this on her behalf.

[0050] Therefore, relative to the second terminal including the RTSP client 18, the SIPRTSP gateway acts as an RTSP server, thereby allowing the RTSP client to have session control.

- 11RTSP over the RTP stream 19 which is transmitted from the first terminal (SIP client) and received as an associated second media stream at the second terminal (including the RTSP client).

[0051] The first media stream may be the same stream as the second associated media stream. In this case, the content is directly streamed from the first to the second terminal. The transmitted first stream is not buffered under the control of the RTSP server prior to its further transmission as the second associated stream to the second terminal. This is advantageous in that the content is presented in the "live module" to the second terminal. In this module, the artificial playing functionality (pause, fast forward, etc.) of the RTSP client cannot be used to control the stream.

[0052] Fig. 5 (a) shows an embodiment of an information flow between a SIP client (included in the first terminal), the SIP-RTSP Gateway and an RTSP client (included in the second terminal). In a first step, the session information exchange of the first multimedia stream (SIP session) is initiated by the SIP client in the first terminal which sends a SIP INVITE to the gateway indicating that it wants to stream the first stream to the second terminal. In further embodiments, the first terminal may use a different protocol to initiate an exchange of session information of the first media stream, such as the Delivery Multimedia Integration Framework (DMIF) H.323 Default Signaling Protocol (DDSP) or MPEG-4.

[0053] In a second step 21, the gateway accepts the invitation and provides a trigger signal to the second terminal in response to start an RTSP session with the SIP-RTSP gateway. The gateway may first optionally need to process the second terminal identifier transmitted by the SIP client at the first terminal before providing the trigger signal. The processing to obtain the network address of the second terminal may include DNS, ENUM, or some other database query.

[0054] The gateway may add additional information to the triggering signal, such as a gateway-generated identifier that can be used by the gateway to associate an incoming RTSP query from a second terminal (an RTSP query being part of the second multimedia stream session information exchange) with the SIP session. Information in the trigger signal may be included in the RTSP URI.

[0055] The trigger signal may be a trigger message, such as an Indirect Request SIP (RFC 4483), a Short Message Service (SMS) message, or an Unstructured Supplementary Service Data (SMS) message. USSD). The trigger message may further be forwarded to the RTSP client using a proprietary application programming interface (API). Application programming interface API) or control interface at the RTSP client, for example Web Service interface using SOAP, Remote Procedure Cali (RPC) or

-12 telnet interface. Said interfaces may simulate "manual user input" requesting a media stream.

[0056] The incoming trigger message may be interpreted by a triggering protocol stack (e.g., a SOAP stack or an RPC stack), which may be configured to instruct the RTSP client to request a media stream or instruct another module to do so. The second terminal may alternatively use a different protocol for requesting a media stream, such as the Microsoft Media Server protocol. Microsoft Media Server - MMS) or Hypertext Transfer Protocol (HTTP).

[0057] Then, in the third step 22, the gateway handles the information exchange of the second multimedia session with the RTSP client contained in the second terminal, by transmitting the SDP information to the RTSP client and acquiring from the RTSP client the correct RTP port to which the RTP stream should be sent. During this exchange, the gateway issues instructions to the RTSP client including, for example, the RTP port number that should be used for receiving the (second bundled) media stream or for example multi-broadcast - or another address from which the stream can be obtained.

[0058] In the fourth step 23, the gateway confirms the SIP session to the SIP client using the SIP 200 OK message and provides the RTP port number for the SIP client for use in transmitting the first media stream and confirms the SDP information. Finally, in the fifth and last step 24, the first terminal starts streaming the RTP media stream to the second terminal.

[0059] Ending a combined SIP / RTSP session (not shown in Fig. 5 (a)) may be handled similar to inviting said session as described above. If the SIP client (of the first terminal) indicates that it wants to end the session, the gateway may translate the SIP BYE message to an RTSP REDIRECT message (without site header). The RTSP REDIRECT message can be found in the draft of an updated version of RTSP (as seen in the web draft of RFC 2326 version 16 of Real Time Streaming Protocol 2.0 dated November 19, 2007 from Schulzrinne et al.). If the RTSP client (of the second terminal) indicates that it wants to end the session, the gateway translates the RTSP TEARDOWN message into a SIP BYE message (which is then to be sent in sequence to the SIP client contained in the first terminal).

[0060] In another embodiment, the media streaming may be initiated by the gateway first. In this case, the gateway provides a trigger message to the RTSP client contained in the second terminal and invites via its own SIP client functionality of the first terminal to set up a SIP session. The information flow between the SIP Client, Gateway and RTSP Client is shown schematically in Fig. 5 (b).

[0061] In yet another embodiment, a gateway may be located at the first terminal. In this case, the first protocol used for the exchange of session information of the first media stream may only be an internal protocol. The session may then be triggered by stimulating the user interface of the first terminal.

This diagram is shown schematically in Fig. 5 (c), where the first terminal can be contained in a mobile device. The stimulus received by the first terminal may alternatively also come from an external source. In this case, the SMS received by the mobile device may, for example, trigger a session.

[0062] Fig. 6 shows an embodiment of the invention in an IMS based IPTV architecture as described in ETSI TISPAN. The architecture may for example be used for a scenario where a first subscriber of an IMS based (user generated) content service issuing a command to a first terminal (UE1 601) wants to stream its own media stream to a second subscriber by issuing a command to a second terminal (UE2). 602).

[0063] In this embodiment, the gateway of the invention is of the distributed type, the exchange of session information of the first media stream with UE1 is typically handled by a Service Control Function (SCF 603), and the exchange of session information of the second media stream with UE2 is supported by the Media Function (MF 605). The provision of a trigger signal to UE2 may be controlled and / or performed by SCF 603. In an embodiment, the Service Control Function of the MCF 606 in the MF may send a trigger signal and instruct the Media Delivery Function of the MDF 607 how to deliver the media stream. In this example, the first subscriber uses SIP to set up a multimedia session for transmission of the first media stream, the second subscriber using RTSP to receive the associated second media stream.

[0064] In order for the first subscriber to invite the second subscriber to receive the media stream, the following steps are performed as shown in the flow chart of Fig. 7. In the first step 701, the first subscriber (using UE1 601) may want to share its media stream with a second subscriber (using UE2). 602) by setting up a SIP session with the Service Control Function of SCF 603 via IMS core 604. The SIP INVITE request may contain a list of terminal subscriber addresses, for example using a list contained in the URI, or the list may be sent to a Service Control Function (SCF) outside the session, for example using the XCAP XML Access Configuration Protocol ( XML Configuration Access Protocol XCAP) whose identifier may be included in the SIP INVITE request. Alternatively, for a service such as Social TV (closed user group) where addressing needs to be done simultaneously for a large number of subscribers, the SIP INVITE request may only contain a link to the community in the form of a Community ID (closed user group) which will need to be processed before providing multiple trigger signals to all community subscribers.

[0065] In a second step 702, the SCF may act as a backto-back user agent (B2BUA) and sends a session request to the Media Control Function (MCF) 606 via possibly an IMS core. The session request for the MCF contains information on where to receive the media stream and how to distribute it. SCF may alternatively use a different protocol to MCF such as MEGACO / H.248 or SOAP.

[0066] In the third step, the MCF can send the media stream information to MDF 607 to set the RTP port and address for the first media stream and associate it with the RTSP URI. MCF may for example use SIP or MEGACO / H.248 for exchanging media stream information.

[0067] In fourth step 704, the MCF response to the SCF may include information such as the RTP address or port to which the first media stream should be transmitted and / or the RTSP URI to be used by UE2 to contact the gateway RTSP server functionality.

[0068] In the fifth step 705, the SCF sends a response back to the UE1, while exchanging session information of the first media stream, using the SIP client functionality.

[0069] In a sixth step 706 UE1 601 transmits the media stream in a manner and / or to a location indicated by the MCF.

[0070] In the seventh step 707, the SCF uses information from the MCF to provide a triggering signal to UE2. The trigger may be an indirect SIP content request. The request may include an RTSP URL provided by the MF or some other indication to UE2 on how to contact the gateway. The trigger signal may also be sent within an existing SIP session with UE2 or by making a SIP REFER request.

In an eighth step 708, invited UE2 602 initiates an RTSP session with the MDF in response to an indirect SIP content request (session information exchange of the second media stream 708 in Fig. 7), to receive multimedia content (second associated media stream 709). The RTSP URI may include an identifier provided in the trigger message for the MDF to associate the RTSP session with the SIP session. The RTSP session (second associated media stream) can be unicast or multi-broadcast. If multicasting is used, the MF distributes the incoming (unicast) first multimedia stream UE1 as a multi-broadcast stream. UE2 then sends, in response to the established RTSP session, an IGMP request to receive the second associated media stream.

[0072] In the ninth step, the MF may send SIP NOTIFY messages to the SCF to keep the RTSP session status informed to the SCF if the SCF has shown interest by sending a SIP SUBSCRIBE message to the MF (not shown in Fig. 7).

[0073] The invention is not limited to the above-described embodiments which can be varied within the scope of the appended claims. For example, the term studio should not be interpreted as meaning only a professional broadcasting studio. Studio within the meaning of this invention applies to all systems that should provide studio-like multimedia functionality, e.g. a personal computer system or other multimedia system that is capable of streaming live content to the user at the home location and in response to receiving user generated content from the user.