Method and devices for third-party session modification

ES 2 398 124 T3

DESCRIPTION

Procedure and devices for third party session modification.

Field of the invention

The present invention relates to a method, a system, a client device, a conference server and a computer program product for controlling the composition of media in a multi-shared conversation. According to a particular example, the present invention relates to the modification of media in the framework of Session Initiation Protocol (SIP) conferences.

Background of the invention

The SIP conferencing framework (defined in the draft-ietf-sipping-conferencing-framework-05.txt) establishes the basic procedures, functions, architecture and how participants can create a multimedia SIP conferencing session and take part in it, invite other participants to the session, exclude participants from the session, notice the addition of other participants to the session, etc. The conferencing framework has thus been adapted to many conferencing standards based on the SIP protocol, such as the 3GPP R6 IMS (3^rd Generation Partnership Project Release 6 Internet Protocol (IP) Multimedia Subsystem, specified for example in TS 24,147), OMA-PoC (Open Mobile Alliance - Push-to-talk over Cellular) and OMA-IM (Open Mobile Alliance - Instant Messaging) .

The above framework describes how the SDP (Service Description Protocol) offer / response mechanism, defined in the IETF (Internet Engineering Task Force) specification RFC (Request for Comments) 3264, can be used to add, remove and modify media streams and its attributes in the multimedia conference session.

In a multimedia conference session, the user should be able to start the session with a particular media (eg PoC audio, IM or full duplex, full duplex video, etc.) and add other media later. The conference control function should therefore communicate the added media to the other participants in the conference session, for example, through an SDP offer in a SIP re-INVITE or SIP UPDATE request as described in the IETF RFC 3311 specification. This way, other participants will know that new media has been added and that they can start using it during the session.

On the other hand, a participant can also use the same SDP offer / response mechanism to modify the connection part, that is, the call leg, between the participant and the central control point (for example, the focus on communication terminology). SIP conferences) of the conference only. In this type of session modification of the SIP conferencing framework, the focus should not modify the media sessions of the other participants. For example, in the SIP conferencing framework, if a participant wants to put the full-duplex audio media on hold, the SDP offer / response mechanism of re-INVITE / 200 OK is used between the participant and the focus, but the focus it should not send the re-INVITE request to the other participants, since they are not waiting and therefore they should be able to continue communicating as before.

Therefore, the central control point must be able to determine which SDP offers should be transmitted to the other participants and which offers are kept between the requesting participant and the focus alone. In some media modifications, the central control point can make this determination based on the attributes of the SDP offering. For example, if a participant puts the media of a conference session on hold, typically the central control point should not put the other participants on hold, but instead will hold the media modification within the particular SIP dialogue, ie that is, between the participant and the focus. However, with some SDP offerings, the central control point has no way of knowing if the media modification should reach other destinations. This happens, for example, if the conference session comprises audio and video media and a participant wants to exclude video from his leg alone (for example, if he moves to a cell that cannot offer enough bandwidth for video), but the rest of the participants do not have this limitation, that is, they want to continue with both audio and video.

The current SDP offer / response mechanism in SIP conferencing does not allow to determine whether media manipulation should be limited to one call leg or communicated to all participants. In IETF XCON, a similar use case is currently being solved. This working group defines a framework for a media control protocol that each participant can use to control the media policies of the other participants, for example remove the video of a certain participant, mute one of the participants (remove the ability audio send) and so on. Although the work of the XCON group has been very slow, the result will be a new protocol between the participant and the focus.

What the OMA-IM and OMA-PoC services need is a simple SIP solution for adding and removing media, since from a normalization schedule point of view, IM and POC services cannot wait for XCON results and cannot they require the complex XCON framework and the other more advanced capabilities of the media policy control protocol.

ES 2 398 124 T3

US 2006/083244 discloses a multi-resource management procedure in multi-party multimedia conference sessions. Document 2006/083244 discloses a system comprising a server and several clients. The server manages the session. During a session, the server can receive media from a client and can send it to all participants in the session. Participants and resources can be logical or physical resources. The physical resources can be, for example, a loudspeaker, a microphone, a screen, etc.

Johnston et al. Session Initiation Protocol Call control - Conferencing for User Agents [IETFSTANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. Sipping No. 7, June 3, 2005 (2005-06-03)], discloses a specification defining conference call control characteristics for Session Initiation Protocol (SIP). This discussion is intended to build on the documents on conferencing requirements and the framework for defining how a highly coupled SIP conference works. It deals with how to analyze an approach from the perspective of different types of user agent (UA): those that are insensitive to conference conventions, those that are sensitive to conference conventions, and those of focus. The use of URIs in conferences, the OPTIONS method for discovering capabilities, and call control using the REFER method are covered in detail with the flowchart examples for a call. The use of the focus feature tag is defined.

Summary of the invention

The present invention is set forth in the independent claims.

One of the objectives of certain embodiments of the present invention is to attempt to provide a simple session manipulation system, whereby media components can be added and removed in a simple and flexible manner.

According to one aspect of the present disclosure, a method is provided for controlling the media composition of a multi-shared conversation in which a central control point intervenes, said method comprising the following steps:

on a participant of said multi-shared conversation, selecting the scope information that indicates the members of said multi-shared conversation;

adding said scope information to a session modification request;

transmitting said session modification request to said central control point and initiating a media modification on said indicated members in response to said scope information.

According to another aspect of the present disclosure, that a client device is provided to control the composition of media in a multi-shared conversation in which a central control point intervenes, said client device comprising:

· A selection means for selecting scope information indicating the members of said multi-shared conversation;

· Adding means for adding said selected scope information to a session modification request and · transmission means for transmitting said session modification request to said central control point.

According to another aspect, a conference server device is offered to take central control of a multi-shared conversation, said conference server device comprising:

· Means of det ection to detect range information indicating the members of the multicompartida conversation in a modification request received session and · means start, sensitive to such information available to initiate a change directed media to those members indicated in such scope information.

According to yet another aspect, a computer program product is provided comprising code means for generating the selection, addition and transmission steps of the above procedure when executed on a computing device. On the other hand, the above objective is achieved by a computer program product comprising code means for generating the starting stage of the above procedure when executed on a computing device.

ES 2 398 124 T3

According to yet another aspect, a system is offered for controlling the composition of media in a multi-shared conversation, said system comprising at least one client device as defined above and a conference server device as defined above.

Consequently, a customer or participant can individually control the scope of the media modification, ie the members of a multi-shared conversation to whom the requested media modification is to be applied. For example, the requesting participant can select whether the media modification applies to the entire conference or only between the client and the conference server (ie, the central control point). In that case, the requesting client can exclude one or more media components locally or globally for the entire conference.

According to a first aspect, the scope information can be added as a new header parameter of the session modification request.

According to a second aspect, the scope information can be added as an attribute of the session modification request. This attribute can be, for example, an SDP attribute and the scope information can then be added as a line value to.

In a specific example, the scope information can indicate whether the media modification will apply only to the participant or to all members of the multi-shared conversation.

According to a third aspect, the scope information can be added as a list of addresses of the participants to whom the media modification is to be applied. This address list may comprise, for example, at least one SIP Uniform Resource Identifier (URI).

In the first to third aspects above, the session modification request can be a SIP reINVITE request or a SIP UPDATE request.

According to a fourth aspect, the session modification request may indicate a recipient who must contact a third party using the scope information. In this case, the session modification request may comprise a header parameter used to communicate to the central control point that an existing dialog is to be modified, rather than creating a new one. As an additional option, the session modification request may comprise information on the capabilities of the recipient of the call indicating how the dialogue is to be modified. In the fourth aspect, the scope information can be added as an address list. This address list can comprise, for example, at least one SIP URI.

Other convenient modifications are defined in the dependent claims.

Brief description of the drawings

Hereinafter, the present invention is described in greater detail on the basis of the embodiments, with reference to the attached drawings in which:

Figure 1 represents a schematic diagram indicating a multi-party conference architecture, in which the present invention can be implemented;

Figure 2 represents a schematic block diagram of a media modification system according to preferred embodiments;

Figure 3 represents a listing of an example of a re-INVITE request as used in a second embodiment;

Figure 4 represents a listing of an example SDP attribute as used in a third embodiment;

Figure 5 represents a list of an example of a REFER request as used in a first example of a fourth embodiment and Figure 6 represents a list of an example of a nested REFER request as used in a second example of the fourth form of realization.

Description of the preferred embodiment

The preferred embodiments are described below based on a SIP multi-party conferencing architecture as depicted in Figure 1.

ES 2 398 124 T3

In the present specification, the term conference is used to designate a particular multiparty conversation, in which a single point of control, which can be a SIP user agent called focus 50, maintains a dialogue through respective legs. Call 70 with each of the participants P1 10 to P4 40. Each participant is a piece of software or routine running on a computing device or client terminal that connects a user or device to a conference. At a minimum, a SIP user agent is implemented, although non-SIP-specific mechanisms can also be implemented for additional functionality. This SIP user agent can be a PC application, a SIP IP phone, or a gateway to the public switched telephone network (PSTN). It can also be another focus.

The focus 50 plays the role of a centralized administrator of the conference, and is accessed via a conference URI, for example, a URI that is generally a SIP URI indicating the focus 50 of the conference. Focus 50 is a logic function that maintains a SIP signaling relationship with each participant, eg P1 10 to P4 40, in the conference. Focus 50 is responsible for guaranteeing, in some way, that each participant receives the media that make up the conference. Focus 50 also implements conference policies.

The status of the conference comprises the status of focus 50, the set of participants 10 to 40 connected to the conference, and the status of their respective dialogues. A notification service for the conference is offered as a logical function of focus 50 which can therefore act as a reporter component, accepting subscriptions for the conference state and alerting subscribers to changes in that state.

In addition, a conference policy server 60 may be available as a logical function that can store and manipulate the conference policy. This logical function is not specific to the SIP protocol and may not physically exist. This function refers to the component that interconnects a protocol with the conference policy, which is the complete set of rules that govern a particular conference.

In addition, a mixer (not shown) can be provided that receives a set of media streams of the same type and combines the media in a specific way for each type, redistributing the result to each participant 10 to 40.

A conference server is a physical server that contains, at a minimum, the focus functions. Said server may also comprise the functions of the conference policy server and the mixer.

As can be seen from Figure 1, the central component of the SIP conferencing architecture is focus 50, resulting in a star topology. Focus 50 is responsible for ensuring that the media streams that make up the conference are available to participants 10 to 40 in the conference. This is accomplished through the use of one or more mixers, each of which combines a series of input media streams to generate one or more output media streams. Focus 50 uses a media policy to determine the correct configuration of the mixers.

Focus 50 has access to the conference policy for each conference. Actually, the conference policy can be thought of as a database that describes how the conference should work. The person responsible for enforcing these policies is focus 50, which in addition to needing read access to the database, needs to know when changes are made to it. Such changes can result in SIP signaling (for example, the exclusion of a user from the conference using the SIP BYE method), being necessary, in the case of changes that affect the conference state, to send a notice to the subscribers via the conference notification service.

Each conference has a unique focus 50 and a unique URI that identifies that focus 50. Requests to the conference URI are routed to focus 50 of the particular conference. Typically, users join the conference by sending an INVITE request to the conference URI. To the extent permitted by the conference policy, focus 50 accepts the INVITE request and the user joins the conference. Users can leave the conference by sending a bYe message, just as they would on a normal call.

Similarly, focus 50 can terminate a dialogue with a participant, in case the conference policy changes to indicate that the participant is no longer admitted to the conference. The focus 50 may also initiate an INVITE method for incorporating a participant into the conference.

The participant can communicate with the conference policy server 60 through some type of non-SIP-specific mechanism, which can affect the conference policy. This is indicated in FIG. 1 by the arrow located between the P4 participant 40 and the conference policy server 60, which does not have to be present in every particular conference, even though a conference policy is always present.

The interfaces between focus 50 and conference policy, and conference policy server 60 and conference policy are not SIP specific. For the purposes of conducting a SIP-based conference, these interfaces do not represent a physical decomposition, but serve as logical functions involved in the

ES 2 398 124 T3 conference.

The conference URI is unique, so no two conferences will have the same conference URI, which can be a SIP URI. Contextual information surrounding the URI (for example, SIP header parameters) may indicate that the URI represents a conference. When a SIP request is sent to the conference URI, that request is routed to focus 50. The conference URI can represent a durable conference or discussion forum, such as the one described in sip: discussion-on-dogs@example.com. The focus indicated by this URI will always exist and will always lead the conference, regardless of the participants currently participating in the conference. Other conference URIs can represent short conferences, such as a conference for a specific purpose. The call recipient capabilities parameters are also used to indicate that the focus 50 supports the conference notification service. This can be achieved by declaring support for the SIP SUBSCRIBE method and the corresponding packet (s) in the call recipient preference characteristics parameters associated with the conference URI.

As already mentioned and represented in FIG. 1, focus 50 is the center of the conference. All 10-40 participants in the conference are connected to the conference through a SIP dialog. The focus 50 is responsible for keeping the dialogs connected to the conference and ensuring that the dialogs are connected to a set of participants who are authorized to intervene in the conference, as established in the admission policy. Also, the focus 50 uses the SIP protocol to manipulate the media sessions to ensure that each participant gets all the media for the conference. For this, the spotlight 50 uses the mixers. Through that interaction, it is ensured that all valid participants 10 to 40 have received a copy of the media streams, and that each participant sends the media to a mixer IP address and port so that it is properly mixed with the other media of the conference.

Each conference is made up of a particular media set managed by focus 50. For example, a conference may contain a video stream and an audio stream. Participants 10 to 40 can change the set of media streams that make up the conference. When the conference media set changes, focus 50 should generate a re-INVITE request for each participant in order to add or remove the media stream for each participant. A participant can use a SIP re-INVITE request to add or remove a media stream. This is accomplished by using standard offer / response techniques to add media streams to a session. This will trigger the generation and transmission by the focus of your own re-INVITE requests to the other participants 10 to 40 of the conference.

Figure 2 represents a schematic block diagram indicating the units or functions of a participant 10 or its respective client hardware device and the focus 50 or its respective conference server hardware device, which intervenes in a modification system of proposed third-party session, by means of which the participant 10 can easily and flexibly manipulate the media components.

According to FIG. 2, the participant 10 comprises a selection unit or functions 102 for selecting the desired scope of the media modification, that is, the specific conference participants to whom the media modification is to be applied. A software functions or a hardware input function arranged in the respective client device can control this selection. In response to said input or control operation, the selection functions 102 generate scope of modification information (SoM) which is added via a message generation unit or functions 104 to a session modification request. This request can be any suitable request that can be used to initiate any type of session modification. Examples of such modifications are described below based on the SIP conference architecture example.

A message signaling unit or functions 106 of participant 10 transmits or routes to focus 50 the extended session modification request with the added SoM scope information, based on the conference URI. At focus 50, a similar message signaling unit or functions 506 receive and facilitate the extended session modification request to a range detection unit or functions 502 that detect the SoM range information. The detected SoM range information is supplied to a message generating unit or function 504 of the focus, and the requested media modification is initiated, by means of the message signaling functions 506 in combination with a respective mixer functions (not represented), in relation to the participants indicated in the SoM scope information.

It should be noted that the above units or functions 102, 104 and 106 of the participant 10 and the above units or functions 502, 504 and 506 of the focus 50 can be implemented as routines or software components that cooperate or are integrated in the respective control programs ( eg, SIP user agents or the like) of participant 10 and focus 50, respectively. Alternatively, the units or functions indicated may be implemented as hardware units of the respective client device or conference server device, respectively. As is evident, a part or all of the rest of participants 20 to 40 can have the above units or functions 102, 104 and 106, as well.

ES 2 398 124 T3

Hereinafter, different embodiments are described that can be differentiated depending on the type of message and the part of the message that transmits the SoM scope information.

According to the first through third embodiments, the re-INVITE or UPDATE requests are modified to provide participants with an easy and flexible way to selectively modify the media compositions of a conference. These mechanisms are used when a session needs to be modified and no participant is added or excluded. Re-INVITE or UPDATE requests are used to modify the session media. The UPDATE method service is optional for the network, the participant or client being able to find out about the network capacity during the establishment of the session. Although for simplicity the UPDATE method is not always mentioned herein as an alternative method to re-INVITE, it should be considered as an alternative to all use cases of re-INVITE in connection with the first to third embodiments.

As a particular example, this report proposes that the re-INVITE request contains as SoM scope information a parameter that indicates whether the media modification proposed by the client should be applied to the entire session or only to the requesting client. This indication can be transmitted in the SIP headers or in the SDP payload of the INVITE or UPDATE requests.

In the first embodiment, a new SIP header is disclosed, for example the MediaHandling (Conference / Client) header. Since an INVITE request can be used to modify multiple media, the SIP header parameter value applies to all media that are negotiated in the re-INVITE request. In case some media modifications of the re-INVITE request are directed to the entire conference and some to the media or the call leg of the participant alone, the participant should send a separate re-INVITE request.

As a further option for the first embodiment, some available SIP headers, for example the SIP Request-Disposition header, can be used to transmit the SoM scope information.

In the second embodiment, the SIP URI list service is proposed to transmit the SoM scope information. In this case, the SIP INVITE / UPDATE request contains SIP URI list as the request payload. The SIP URI list service is used to indicate which of the participants the media modification should apply to. The SIP URI list service may also contain the conference URI that indicates that media modifications are applied to all conference participants. As in the first embodiment and by default, all proposed media modifications (several m lines in Figure 3) are applied to the indicated participants in the SIP URI list service. If the participant wants to add one media to the conference pool, and other media to a subset of participants only, two separate re-INVITE / UPDATE requests are required.

In addition to the SIP URI list service specified in draft-ietf-sipping-uri-services-05.txt, some additional indication may be needed in the re-INVITE / UPDATE request to tell focus 50 how to use the SIP URI list information . The SIP URI list service might already be present in the re-INVITE / UPDATE request for other reasons. Therefore, the proposed mechanisms may be available in combinations such as the SIP URI list service and the SIP header, the SIP URI list service and the SDP attribute, and furthermore the SIP URI list service itself could contain a new field. to indicate that the list is used for that particular purpose.

Figure 3 represents an example of a listing of a re-INVITE request according to the second embodiment, which contains two groups, the SDP protocol and the SIP URI list service for a PoC service.

In the third preferred embodiment, a new SDP attribute, for example Conference / Clientonly or media-treatment Conference / Client-only, is disclosed to transmit the SoM scope information, for example, as a line value to .

Figure 4 represents a listing of an example of the proposed SDP attribute. In this case, a new value from line to conference indicates that the media modification applies to the entire conference, and a new client-only value indicates that the media modification applies only between the particular requesting participant and the conference server. .

This new SDP attribute is more flexible, since the participant can add several media to the same re-INVITE request and request a different treatment for each of the media. The conference server, that is, the focus 50, can negotiate modifications of the leg itself immediately, while the new media for the whole conference can take some time.

According to the fourth embodiment, the REFER method described in IETF RFC 3515 is used as a session modification request to which scope information is added.

In particular, a new SIP Alternates header could be inserted (as opposed to Replaces). This header is used in the SIP REFER method to warn the reference element, that is, focus 50, that the request

ES 2 398 124 T3

INVITE sent upon receipt of REFER should modify the existing dialog, rather than create a new dialog. Also, the capabilities of the called party can be used in conjunction with the contact URI in the Refer-to header of the REFER method. The capabilities of the called party along with the new Alternates header tell focus 50 how the dialogue should be modified.

As an additional option, the SIP URI list service can be used for the REFER method to generate the re-INVITE request for all participants 10 to 40 of the conference session. With the SIP URI list service, it is also possible to request that the re-INVITE request be generated and sent only to some of the conference participants. In this case, the requesting participant or client can add the participant list to the REFER request as a SIP URI list service.

This new REFER-based mechanism that uses the Alternates header can be used whenever the participant wishes to modify the sessions of other participants. If the participant wishes to modify his own call leg 70 to focus 50, he must use the usual SDP offer / answer mechanism described in the third preferred embodiment.

Figure 5 represents a listing of a first example of a REFER request according to the fourth embodiment, in which user A wishes to exclude the video of all participants in the audio / video multimedia conference session. User A sends a REFER request to focus 50. The REFER request contains a Refer-to header with the focus URI. The focus URI of the Refer-to header indicates that the method should be sent to all participants currently participating in the session with focus 50.

The focus 50 then generates a re-INVITE request for each participant currently participating in the session. In addition, focus 50 adds an SDP offer to the re-INVITE request based on the currently negotiated media in each participant's session. Depending on the capabilities of the call recipient (audio, in this example) provided in the Refer-to header of the REFER request, the focus 50 generates an SDP offer that comprises only the audio media. As a response from each participant, the video is excluded from all participants.

Another way to exclude video in a second example of the fourth embodiment is to send a nested REFER request to the focus.

Figure 6 represents a listing of the REFER request according to the second example. The nested focus generates a REFER request for each participant. This second REFER request comprises the new Alternates header and, based on this, the participant generates a re-INVITE request to send it back to the focus. This reINVITE request comprises an SDP offer that excludes video media from the ongoing dialogue.

As a specific example, the simple and flexible media modification mechanisms disclosed above in connection with the first through fourth embodiments can be implemented in OMA PoC 2.0 technology. Therefore, a new media is offered for a PoC feature, in which a session can contain multiple media.

In summary, described herein is a method, a system, a client device, a conference server device, and a computer program product for controlling media composition in a multi-shared conversation involving a checkpoint. central. In a participant of said multi-shared conversation, scope information indicating the members of said multi-shared conversation is selected, and said information is added to a session modification request. The session modification request is transmitted to the central control point which initiates a media modification on the indicated members in response to the scope information. In this way, the client can control whether a media modification applies to the entire conference, selected participants, or just between the client and the conference server.

It should be noted that the present invention is not limited to the above-mentioned and preferred SIP protocol-based embodiments, but can be applied in connection with any kind of media modification for multi-shared conversations, where they can be used session modification requests to modify media components. Any new header, part, or payload parameter can be used or incorporated to add and convey the proposed scoping information. The preferred embodiments may thus vary within the scope of the appended claims.