The present invention relates to sharing a media stream, such as a multimedia stream, in a communications system.
One special feature offered in mobile communication systems is group communication. The term “group”, as used herein, refers to any logical group of two or more users intended to participate in the same group communication. One example of group communication is a group call, which is a call in which all participants may take turns to speak and to listen to each other.
Conventionally, group communication has been available only in trunked mobile communication systems, such as Professional Mobile Radio or Private Mobile Radio (PMR) systems, such as TETRA (Terrestrial Trunked Radio), which are special radio systems primarily intended for professional and governmental users. Thanks to the evolvement of communication technology, particularly IP-based communication technology, and end user terminals, a group communication service is now available also in public mobile communication systems. An example of such a service is Push-to-talk over Cellular (PoC), which allows user voice communications to be shared with a single recipient (1-to-1) or between groups of recipients as in a group chat session (1-to-many) over mobile networks. The PoC service is implemented so that a PoC server, or a server system, receives voice from one participant in the conversation and sends it to other participants of the session.
While the communication technology has evolved, also user requirements have evolved, one of the requirements for the group service being that sharing contents in a media server should be possible without a user first loading the contents to his/her user terminal. A problem with the above described arrangement is that, for the time being, no mechanism exist with which a PoC server would be able to share contents in another server to group members.
An object of the present invention is thus to provide a solution as to how to implement sharing of multimedia contents from a media server to participants. The objects of the invention are achieved by a method, a system, a user terminal, a communication server, and a computer program product which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.
The invention is based on realizing the problem and solving it by a user terminal setting up a transport mechanism for a media stream between a communication server providing sharing of information to user terminals and a media server containing the information to be shared, and controlling the media stream between the servers by the user terminal.
The present invention provides an easy-to-implement solution for sharing a media stream originating from a media server. An advantage is that the media server needs not to know that the stream goes to a group server and the group server and other participants receiving the stream need not to know that the stream originates from the media server.
In the following the invention will be described in greater detail by means of preferred embodiments and with reference to the attached drawings, in which
The following embodiments are exemplary. Although the specification may refer to “an”, “one”, or “some” embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.
The present invention is applicable to any user terminal, server and/or to any communication system or any combination of different communication systems that support group communication and provide(s) sharing of contents between group members. No limitations exist to the contents type, nor to the group type. The communication system may be a fixed communication system or a wireless communication system or a communication system utilizing both fixed networks and wireless networks. The protocols used, the specifications of communication systems, servers and user terminals, especially in wireless communication, develop rapidly. Such development may require extra changes to an embodiment of the invention. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the invention.
The term group communication covers here all communication involving a usage of an entity, such as a server, that maintains information on participants of the communication. Such group communication may include data calls, audio calls, video calls, multimedia calls, messaging, electronic mail, etc. Examples of service applications providing such group communication include PoC, conferencing and different chatting applications. Contents to be shared may be any kind of data which may be shared in real-time or near real-time, such as text, voice, video, multimedia, application specific data, etc., and which may include both live data feeds and stored data or data clips.
In the following, embodiments will be described using, as an example of a system architecture whereto the embodiments may be applied, an architecture based on SIP (Session Initiation Protocol) providing a tool to build a multimedia architecture and PoC providing group communication without restricting the embodiments to such an architecture, however. SIP is an Internet Engineering Task Force (IETF) defined application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. SIP is not vertically integrated into a communication system but a tool to build multimedia architecture. More detailed information on SIP, such as IETF specifications and Internet Drafts, can be found at http://www.ieff.org. PoC specification is an industry specification which is developed currently by a PoC working group under the OMA (Open Mobile Alliance). PoC can be provided as a packet-based user-level or application-level service so that the underlying communications system only provides the basic connections (i.e. IP connections) between PoC communications applications in user terminals and a PoC service provided by a communication server system, or a communication server illustrated by PoC AS in
A general architecture of a communication system providing a group communication service utilizing SIP and PoC is illustrated in
The user terminal A 1-1 illustrates a generic functional block diagram for a device according to an exemplary embodiment. The device also includes means and functionalities which are not shown in
The user terminal A 1-1 comprises a PoC client 1-11 allowing, among other things, PoC session initiations and offering of media streams to share contents with other session participants, and a media client 1-12 for set-ting up a transport mechanism for a continuous media stream from the media server. The PoC client, or the user terminal in which the PoC client according to an embodiment resides, or a control unit or any other corresponding means in the user terminal, is configured to share a media stream from the media server by controlling the setting up of the transport mechanism for the media stream, as described in detail below, especially in connection with
PoC AS 1-3, i.e. the PoC application server, provides the group communication and contents sharing, and is the signalling endpoint of the PoC service. In other words, PoC AS receives media from user terminals and sends it further to other user terminals. In addition, PoC AS 1-3 according to an embodiment is configured to contain a functionality to be described below, especially in connection with
In the example of
The media server 1-4 is a server providing at least playback services for one or more media streams which may be combined into a multimedia presentation. (Typically, an audio stream and a video stream are different media streams.) In the example of
Because the other media stream is to be offered to other participants, PoC AS sends an SDP offer in INVITE requests 2-2 and 2-2′ to the user terminals B and C; the requests containing one media stream offer for the contents.
In the example, the user of the user terminal B accepts the offered media stream but the user of the user terminal C does not accept the offered media stream, i.e. does not wish to obtain the contents. Therefore, the user terminal B sends an SDP answer in 200 OK response 2-3 to PoC AS but the user terminal C does not accept the offered media stream and sends a response 2-4 to PoC AS. In this example, the response 2-4 is a 200 OK indicating in an SDP answer that the offered media is not accepted.
In the example, after receiving the responses/SDP answers, PoC AS sends an SDP answer in a 200 OK response 2-5 to the user terminal A. The SDP answer contains acceptances of both offered media streams with addresses. In other words, the response 2-5 contains an address for each media stream, at which PoC AS, or more precisely, MRFP, will receive the offered media stream. In addition, PoC AS will store or otherwise maintain media stream-related information indicating the accepted media streams and their details.
The user terminal A initializes contents transport from the media server by sending an RTSP DESCRIBE in message 2-6 to the media server, said message identifying the contents and asking for a description of the contents. The media server sends a 200 OK response 2-7 including an SDP description with details relating to a media stream for the contents, such as the coding. This transport initialization may be performed during the above-illustrated signalling, or before it (in order to find out the details of the contents, for example).
After receiving the response 2-5, the user terminal A knows an address in PoC AS whereto the contents is to be delivered in order for the contents to be shared, and it starts (provided that transport initialization has been performed) setting up a transport mechanism for the continuous media stream intended to deliver the contents by sending an RTSP SETUP in message 2-8 to the media server; the RTSP SETUP presenting the address in PoC AS as a destination address whereto the media stream is to be sent. The media server sends a 200 OK response 2-9 including, among other things, an address in the media server at which it receives instructions relating to the media stream.
Now the user terminal A knows the address wherefrom the contents are delivered and other actual media details and sends another INVITE request 2-10 to PoC AS, said other INVITE request including an updating SDP offer with proper details about the media stream between the media server and PoC AS. The request 2-10 contains the two media stream offers for the contents in request 2-1 with updated media details, one of the updated detail being the address in the media server, as a source address for the media stream.
In response to receiving the request 2-10, PoC AS updates the media stream-related information to be in accordance with the information in the request 2-10. If a media detail in the media stream offer that was offered to the other participants has been updated, i.e. is not the same as in request 2-1, PoC AS will update the media stream information to the user terminal B. However, in the example of
As a result, a transport mechanism for the contents is set up between the servers so that the media stream will pass from the media server to PoC AS but the control of the media stream is with the user terminal A. As can be seen from the above, PoC AS does not know that the media stream is received from the media server, and the media server does not know that the media stream is sent to PoC AS.
When the transport mechanism has been set up, the user of the user terminal A wishes to share the contents and sends an RTSP PLAY in message 2-12 to the media server. In response to the RTSP PLAY, the media server responds with an RTSP 200 OK response 2-13 and sends the contents in an RTP stream 2-14 to PoC AS. When receiving the RTP stream 2-14 PoC AS notices that media streams grouped together and having the same media type and coding exist as the received RTP stream, said media streams allowing PoC AS to send media streams. Therefore, PoC AS relays the contents in RTP streams 2-14 to the user terminals A and B, i.e. to participants that accepted the contents offer, and to the participant from whom the contents offer originated. They receive the contents approximately at the same time.
For example, if the contents consists of video, the user of the user terminal A can start, hold/resume, forward, rewind etc. the contents and tear down the media stream between PoC AS and the media server. This enables, if voice has been negotiated to bee included the PoC session, the users of the user terminal A and B to discuss the contents, for example.
The above-described embodiment may also be implemented when a floor control is used for media streams. In such a case, the user terminal A performs the floor control request and release, and PoC AS that grants the floor, is prepared to receive media streams from any source controlled by the user terminal A.
As can be seen from the above, an advantage of the illustrated embodiment is that the group server and the media server need not support the same negotiation protocol since the user terminal negotiates with each server using the negotiation protocol the server supports. However, the servers may support the same protocol(s).
The message 3-1 in
A message 4-10 in
In the example illustrated in
In the example illustrated in
After that the user, and the user terminal controls (step 508) the media stream between the media server and the communication server although the contents delivery is (will be) from the media server to the communication server.
As can be seen from the above, according to an embodiment, tasks of a user terminal are to control setting up a transport mechanism for contents between a media server and a communication server by obtaining required media details from the servers and delivering required media details to the servers, to control to whom the contents are to be offered by the communication server and to control the delivery of the contents between the media server and the communication server. The required media details include address information in the servers.
The communication server waits (step 601) until it receives, in step 602, a media stream-related message. If the message contains one or more media stream offers (step 603), the communication server takes, in step 604, a media stream offer, and checks, in step 605, whether or not the media stream offer is to be offered to other participants in the group communication in question. If yes, the communication server offers, i.e. sends, in step 606, the media stream offers to the other participants, waits for their responses, receives the responses and stores, or otherwise maintains, media stream-related information, such as whether or not the offered media stream was accepted and value(s) of one or more associating attributes of the stream, discussed above in connection with
If the media stream offer is not intended to other participants (step 605), the communication server proceeds directly to step 607 to check whether or not all media stream offers have been processed.
After all media stream offers have been processed (step 607) and responses received, the communication server allocates, in step 608, preferably for each media stream, a port or corresponding access point and sends, in step 608, a response to the participant from whom the message containing the media stream offers was received. The response contains address information to the communication server, said address information indicating the addresses of the access points or ports to be used with media streams. Next, the communication server returns to step 601 to wait for another message.
If the message contains contents (step 609), i.e. is the actual media stream, the communication server searches, in step 610, for other relating media streams. The other relating media streams are found on the basis of the value(s) of the one or more associating attributes. In the illustrated example it is assumed, for the sake of clarity, that at least one media stream is found. Then the communication server takes, in step 611, a media stream that was found, and checks, in step 612, whether or not the media stream allows sending from the contents server to the other end of the media stream, and if sending is allowed, forwards, in step 613, the contents to the other end. Then (or meanwhile) the communication server checks whether or not all media streams have been processed (step 614). If no, the communication server takes another media stream to be processed. In other words, it returns to step 611.
If the media stream does not allow sending (step 612), the communication server proceeds directly to step 614 to check whether or not all media streams have been processed.
After all relating media streams have been processed (step 614), the communication server returns to step 601 to wait for another message.
If the message contains no offer (step 603), nor contents (step 609), it contains an update of at least one media stream, and the communication server performs, in step 615, the updating, and sends, in step 616, a message acknowledging the received message. Then the communication server returns to step 601 to wait for another message.
In another embodiment, the communication server is further configured to transcode contents received from a media server to a media type supported by user terminals, if transcoding is necessary.
As can be seen from the above, no need exists to arrange the communication server to control the media stream originating from the media server; it can be handled as if it were received from a user terminal.
The steps, points and signaling messages shown in
Although in the above embodiments the media stream “not to be offered” is indicated, it is obvious to one skilled in the art how to implement embodiments in which the media stream “to be offered to other participants” is indicated instead, and a media stream without such an indication is interpreted as not to be offered to other participants.
Although in the above embodiments it is assuming that the contents are shared in one-to-many communication, it is obvious to one skilled in the art that the communication may as well be one-to-one communication.
Apparatuses, such as the user terminal, communication server or corresponding server component and/or other corresponding device implementing the functionality of a corresponding apparatus described with an embodiment comprises not only prior art means but also means for sharing information in the manner described above. More precisely, they comprise means for implementing functionality of a corresponding apparatus described with an embodiment and they may comprise separate means for each separate function, or means may be configured to perform two or more functions. Although in the above each apparatus has been depicted as one entity, different modules and memory may be implemented in one or more physical or logical entities. Present apparatuses comprise processors and memory that can be utilized in the functions according to an embodiment. For example, the PoC client 1-11, the media client 1-12, the conference server 1-31, the MRFP 1-32, and/or the MRFC 1-22 may be a software application, or a module, or a unit configured as arithmetic operation, or as a program (including an added or updated software routine), executed by an operation processor. Programs, also called program products, including software routines, applets and macros, can be stored in any apparatus-readable data storage medium and they include program instructions to perform particular tasks. All modifications and configurations required for implementing functionality of an embodiment may be performed as routines, which may be implemented as added or updated software routines, application specific integrated circuits (ASIC) and/or programmable circuits. Further, software routines may be downloaded into an apparatus. The apparatus, such as a server, or a corresponding server component, or a user terminal may be configured as a computer or a microprocessor, such as single-chip computer element, including at least a memory for providing storage area used for arithmetic operation and an operation processor for executing the arithmetic operation. An example of the operation processor includes a central processing unit. The memory may be removable memory detachably connected to the apparatus.
It will be obvious to a person skilled in the art that as technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
Number | Date | Country | Kind |
---|---|---|---|
20065137 | Feb 2006 | FI | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/FI2007/050095 | 2/22/2007 | WO | 00 | 8/25/2008 |