WO2008041831A1

WO2008041831A1 - System and method for ordered invite for session based group communication

Info

Publication number: WO2008041831A1
Application number: PCT/KR2007/004854
Authority: WO
Inventors: Jae-Kwon Oh; Sang-Kyung Sung; Jedigunta Venkateshwar; Mayuresh Madhukar Patil
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2006-10-03
Filing date: 2007-10-04
Publication date: 2008-04-10
Also published as: WO2008041831A8; KR101490520B1; KR20080031140A

Abstract

The present invention in general relates to the field of communication. The present invention is applicable to session based group communication, where session is established first before the group communication starts. The present invention provides system for establishing a group chat session, comprising a PTT (Push To Talk) over the Cellular (PoC) Client for sending an INVITE request including an URI (Uniform Resource Identifier) list for users and predefined rules for sending the invites to the users and an application server for receiving the INVITE request and sending the INVITE request as per the rules set in the INVITE request.

Description

SYSTEM AND METHOD FOR ORDERED INVITE FOR SESSION BASED GROUP COMMUNICATION

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention in general relates to the field of communication. The present invention is applicable to session based group communication, where session is established first before the group communication starts. The present invention relates to POC and IM applications. More specifically the present invention relates to system and method for ordered INVITE for session based group communication.

2. Description of the Related Art

The various IMS application uses SIP protocol for establishing the session for a group communication. The applications like SIMI³LE IM and POC uses SIP protocol for establishing the session for a group call. Currently SIP protocol allows creating an ad-hoc group session and pre-arranged group session. In case of pre-arranged group session there will be a group id for the pre-arranged group, and group information like URJ of participants etc will be stored in the server, so client will use this group id for sending the INVITE for establishing the session. Then server will individually sends the INVITE to all members of a group. Similarly SlP allows user to establish ad-hoc group, where initiator of session mention a group attributes like URI list for users in initial INVITE request body. Then server will extract the INVITE body and send the INVITE requests to the other users. This way SIP is used for establishing the group session.

Currently while establishing the session for group communication, server will send the initial INVITE to all users simultaneously. Note all these INVITEs sent to individual users will be independent of each other. Currently user can only mention the users need to be invited in body of INVITE request in case of the ad- hoc session, and in case of pre-arranged group user will maintain the group information into the server. This is the current state of art for the establishing the group communication.

The current state of art helps user to establish a group communication using SIP for ad-hoc and pre-arranged case. There are various user cases where user wants to set some priorities for establishing the session. The priorities mean setting priorities for sending the initial invites for other users. Basic user case for this is user A wants to establish a group communication with user B, C, D, E, and G. He wants to set up a session only when user B accept the invitation. In current state of art this is not possible to achieve. The priorities cannot be mentioned to the invites in the current state of art. There are various other use cases which also demands to set priorities to invites for e.g. user A wants to set up a session and if user C accepts the invitation then only send INVITE to user D other wise don't send invitation to user D. The current state of art doesn't allow user to do this. Specifically in group communication the initial invites will be sent independently, so in first use case, where user A wants session to be established only when users B accept invitation, as per current state of art, session will be establish even if B reject the invitation, so in this user has to manually tear down the session. This is a waste of time in many cases. Especially for the applications like POC where session initiation time is important unwanted establish session can waste time for user and resource or charges for a user. It is very beneficial when if user can specif}' some rules while establishing a session.

SUMMARY OF THE INVENTION

The present invention provides system and method for assigning the priorities for invitations.

The present invention further provides system and method for setting rules for sending the invitation for particular user.

The present invention aims to achieve setting priority and rules on establishing the group session.

The present invention proposes system and method for setting the priorities while sending the invitation for establishing the session.

The present invention further relates to the SIP INVITE method for achieving this.

The present invention further proposes to have priorities for invites.

The present invention further allows user to set some rules for sending the invitations for particular users.

The present invention further proposes to have INVITE body which will tell the priority and rules for setting up the session. The present invention further proposes the body structure for achieving above use cases.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other objects, features and advantages of certain exemplary embodiments of the present invention will be more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates the system architecture.

Figure 2 illustrates logical flow.

Figure 3 Alternate logical flow.

Throughout the drawings, the same drawing reference numerals will be understood to refer to the same elements, features and structures.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention proposes these use cases and provides the system and methods for solving it. The present invention is based on SLP protocol. There are various weakness for current state of art for the above said use cases. The following are the weakness for current state of art

1. Possibilities of unnecessary invites, for e.g. if user C is not needed if user B is not there in session. In the current state of art there will be unnecessary [NVTTE send to the user C.

2. Sometimes there will be unnecessary establishment of group session, for e.g. user A wants to establish the session only when B accepts invitation. In the current state of art, user A cannot set rules like this in the INVITE for there is possibility of unwanted session establishment.

3. These unnecessary session and invites waste user time, resources, and money. -A-

The present invention addresses these issues and provides the system and method for achieving this.

In the prior art, ad-hoc or pre-arranged group session is established using SIP INVITE method. For pre-arranged group id and for ad-hoc session INVITE body is used for establishing the session. Client will send this INVITE and then server sends the individual invitation to other users. These invitations are independent of each other. So the user can not set some priorities or rules for sending the invitation. Suppose user A wants to set rules like if user B accept the invitation then only establish session, so this demands invitation should be sent first to B, and if B accepts the invitation then only send invitation to other users. This way user should be able assign these rules in the session set up in an initial INVITE request. The present invention proposes to allow user to set some rules/priorities so that user can avoid some unnecessary invites and unwanted session setup.

The present invention identifies the above requirement while setting up a group session. The present invention proposes a system and method for the same. Figure 1 shows architecture for any session based application like POC or IM.

Here Client A (100) wants to set up a group session with other users B (112), C (114), D (116), and E (118). Here user A (100) will send the INVITE request to server (1 10). Then server (110) will send INVITE request to other users and group session is established. Now this innovation proposes INVITE method with body for setting up the rules for the session set up. The present invention defines the body structure, which can be used for achieving this. So the basic method is client will send FJNTVITE request with body. For an ad-hoc session body will have URI list for users, plus it will have priorities and rules for sending the invites to the user. Server (110) will receive this INVITE request and extract the body and then send the INVITE request as per the rules set in the INVITE request. This is the basic method involved in the present invention.

Figure 2 shows basic flow diagram for present invention. In this logical flow user A wants to establish the group chat session with other users like B, C, and D. Here User A will send the INVITE request user A will include the body for indicating the URI list for users, user A also include user defined rules for sending the initial INVITE. The following steps are carried out in the present invention.

1. User A sends the INVITE request, user A also include rales into INVITE body and send to application server with through SIP CORE

2. SlP core forwards this request to application server.

a. Server receives this request, and extracts body and validates the body of INVITE request. b. Analyze the rules defined in the body, and send the FNVfTE request as per rules defined in the body

3. Application server will send IN VlTE request to user B only as defined in the rule and wait for response from the user B

4. SIP core forwards the INVITE request to user B

5. User B accept the request and send the 200 OK

6. SlP core forwards response to application server

7. Application server forwards the response to Client A

a. Application server checks for conditions and sends INVITE to other users

8 -9. Send INVITE to other users

10 - 11. SIP core forwards request to respective users C and D

12. User C accepts the request and sends the 200 OK response to application server via SIP Core

13. SIP forwards this response to application server

14. User D sends response to application server via SIP Core 15. SlP core forwards response to Application server

This is normal flow for the present invention. This invention also identified one more approach where the final response to Ordered INVITE is sent by the server as soon as server receives first 200 OK response. Figure 3 shows logical flow for that approach.

1. User A sends the SIP INVITE request, user A also include rules into SIP INVITE body and send to application server through SIP CORE

2. SIP core forwards this request to application server.

a. Server receives this request, and extracts body and validates the body of INVITE request.

b. Analyze the rules defined in the body, and apply those rules in sending the subsequent INVITE requests to the specified receiving users (i.e.. user B, user C, and user D.)

3. As per the identified rule in step, the application server will send the SIP INVITE request to user B only and wait for response from the user B

4. SIP core forwards the INVITE request to user B

5. User B accept the request and send the 200 OK

6. SIP core forwards response to the application server

7. As soon as sever receives first response, Server sends the response to initiator of ordered INVITE. Server sends 200 OK response through SlP Core.

8-9. As per the identified rule in step, after the INVITE acceptance from user B, the application server sends the SIP INVITE requests to other remaining users (or user C and user D). 10-11. SIP core forwards the requests to respective users C and D

12. User C accepts the request and sends the 200 OK response to the application server via SlP Core

13. SIP forwards this response to the application server

14. User D sends response to the application server via SlP Core

15. SIP core forwards response to the application server

Thus, in this alternate logical flow server will sends a response to ordered INYlTEi as soon as server receives a first response.

User will use the body defined in the next section for defining the rules in the INVITE request. This way user can define the priorities and rules for sending the INVITE request. The next section defines body structure.

i) Body structure

<?xml version^¹1.0" encoding="U^rIT-8"?>

<xs:schema xmlns="urn:oma:params:xml:ns:SessionConditioti" xmlns:xs="http://www.w3.org/2001 /XMLScheraa" targetNamespace="urn:oma:params:xml:ns:SessionCondition">

<!-- Defination of Simple Elements — >

<xs:attribute name="URI" type- 'xs:anyURT7>

<xs:attribute name=Triority"=^Mxs:decimal7> <xs:element name="lF"> <xs:complexType>

<xs:restriction base="xs:slring">

<xs: enumeration value="Acccpl"/> <xs ".enumeration value="Rcject"/> </xs :restriction>

<xs:attribute ref="URl"/>

</xs :complexTypc>

</xs:element>

<xs:element name="Condition"> <xs : complcxTypO

<xs:elcment rcf="IF" minθccurs= 1 maxOccurs="unbounded"/>

</xs :complexType>

</xs:element>

<xs: clement name="Entiy"> <xs:complexType>

<xs:e]emenl reJN'Condition" minOccurs-"0" maxOccLirs="unboιindcd"/>

<xs:attributc ref="URl" usc="required"/> <xs:attribute ref="Priority"/> </xs : complexType>

</xs:element>

<xs:element name=" invite-order ">

<xs:element ref="Entry" miiiθccurs=" 1 "

</xs :compiexType>

</xs:eiement>

</xs:schema>

Table 1 : Body Structure Schema format

Table 1 shows a schema format for the content in the initial SIP FNVITE request that contains the rules for application server to generate the subsequent INVITE requests for group communication. The schema has one root element called "invite-order". This schema allows user to define priorities for sending INVtTEs and setting some rules on INVlTEs. For this schema defines element called "Entry" in root element. User can add one or more "Entry" elements in the root element. "Entry" element is used to specify users in a group communication. In case of ad-hoc group communication "Entry" element is used to define users in a group communication and rules associated with it. In case of pre-arranged group "Entry" is used to define some rules.

"Entry" element has two attributes URI and Priority. "URI" attribute is used to specify URl of users. In case of ad-hoc group session initiation, this will used to specify users in the group. "Priority" element is used to specify the priority for sending the INVITE requests. For e.g. there are two users in group, and initiator of session wants one particular user should receive invitation first then second user should receive invitation. So user can set priorities to INVlTEs using this "Priority'" attributes. "Entry" element has one child element called ''Condition". This condition element is used to specify the condition related to the user specified in the "URI" attribute of "Entry" element.

The "Condition" element has one child element called "IF", and this IF element has one attribute called "URI". This "IJRI" attribute is used to specify user on which this condition is dependent. "IF" element can take two values "Accept" or "Reject". This is used to specify the conditions, for e.g. User A wants to set condition like if User B accept invitation then only INVITE user C, so for this "Entry" element URl will tell user C,. and "IF" element's URl will specify User B₅ and value of 'TP" element will be set as "Accept". So this way this "Condition" element will be used for setting some condition on session set up.

This way the schema will be used for setting priorities and setting some rules into the session setup. The next section explains the client and server side processing rules of above schema.

a) Client side processing rules

Client will use above schema format for creating the ordered INVITE. When client wants to initiate the ad-hoc group then user will use one or more "Entry" element and specify the URI attributes for specifying the user list. Client device can include one or more "Entry" element. Client wants to specify some priority on sending the INVITE request he can do it by specifying the priority using the attribute "Priority".

Client can also define some rules using above schema. Suppose client wants to set rules like if particular user accept or reject invitation then send invitation to particular user. Client can use the "Condition" element and specify condition using "IF" element. Client can use one or more "Condition" element. Client can specify one or more condition using this element. Following are the examples for the various scenarios. Example 1 : User A wants to establish a ad-hoc session with users β, C, D, E with condition if B accepts then only send invitation to user C other wise don't send invitation to C, send invitation to D, E normally

<?xml version="1.0" encoding="UTF-8"?>

<Invite-order xmlns=="um:ietf:params:xml:ns:SessionCondition"> <Entry URl="B@example.coin" Priority=l/>

<TF UR]="B@example.com"> Accept </IF>

</Condition> </Entry>

Example 2: User A wants to establish group session with user B, C, D with condition if B accept then only initiate session

<?xml version="1.0" encoding="UTF-8"?>

Accept

</.IF>

</Condition> </Eαtry>

Accept

</IF>

Example 3: User A wants to establish session but session, with condition if user B reject then send invitation to user C other wise don't send invitation

<?xml version=" l .0" encoding="UTF-8"?>

<Invite-order xmlns="urn:ietf:params:xml:ns:SessionCondition"^; <Entry URI="B@example.com^M Prior ity=l/>

<IF URJ="B@example.com"> Reject </IF> </Condidon>

</Entry> </Invite-order>

- Example 4: Complex condition like if user B accept then user C shoud be called and if C accept then no need for user D. ( USE OF Priority attribute) <lnvite-order xinlns⁼="ιuⁱn:ietf :params :xml :ns : SessionCondition"> <Entry UR]="B@exaraple.com" Priority= l/>

Accept

</IF>

</Condition> </Entiy>

<IF URI="C@examρle.com"> Reject </lF> </Entry> </Invite-order>

b) Sender side processing rules

Server will use this schema for validating the ordered ITMVITE request body. So when server receives the ordered INVITE request he will extract the body and validate the body with above schema. Server then assign analyze the body and then send the FNVTTEs to other users. There can be two types of group session request. One is ad-hoc and other one is pre-arranged group session. In case of ad-hoc group session the INVITE body also tells user list and rules associated with it. In case of pre-arranged group user can still include the body to specify the rules, but complete user list will be available to server. In pre-arranged session establishment case where use wants to set condition like if user B accept invitation then only establish the session other wise don^'t establish a session. So user can still use this body structure to define the rules.

As soon as sever validated the body of ordered INVITE, then server will check for the priority attributes and then send the INVITE request with increasing priority. Server will sent the INVITEi first to highest priority request, then to lower priority users. Server will also checks for the condition element so that particular user accepts or rejects the request then to send the request to other users or not, so server will make these decisions and then send the invitations, and establish the session.

ii) Alternate approach using different body structure

This section identifies different approach for same use case. This proposes simple approach to priorities the SIP requests. This proposes only one priority element in the FNVlTE body. This Priority element specifies the invitation order in which INVITE requests needed to be sent. The basic proposal can explained using following examples.

a) Approach 1: Ad-Hoc Group case:

In case of ad-hoc group,

INVITE sip:application-server@example.com SIP/2.0

Via: SIP/2.0/TCP example.com;branch=z9hG4bKhjhs8ass83

Max-Forwards: 70

To: "Application Server " <sip:application-server @example.com>

From: Alice <sip:req-user@example.coiri>;tag^::=3233 1

Call-ID: d432fa84b4c76e66710 1 CSeq: 1 INVITE

Contact: <sip:req-user@gsr.example.com>

Allow: INVITE, ACK, CANCEL, BYE, REFER

AUow-Events: dialog

Accept: application/sdp, message/sipfrag

Require : recipient-list- invite

Content-Type: multipart/mixed;boundary^:=:"boundary 1 " Content-Length: 690

—boundary 1

Content-Type: application/sdp

v=0 o-req-user 2890844526 2890842807 IN 1P4 gsr.example.com

c=JN 1P4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtρmaρ:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtρmap:31 H261/90000

— boundary 1

Content-Type: application/resource-lists+xml

Content-Disposition: recipient-list

<?xml version="L0" encoding^s "U TF- 8 "?>

<resource-lists xmlns=¹'miκietf:params:xml:ns:resource-lists'¹ xmlns:sp="urn:oma:params:xml:ns:SessionCondition"> <list>

Th e value of 'invite-priority' parameter shows the 'must' ordering for INVITE processing by the Server, which in the above case would be A->D- >B,C,E- So, the server will send INVITE to A first; upon the successful response from A, initiate INVITE to D; upon successful response from D, initiate INVITE at the same time to B, C, and E.

The possible value for 'invite-priority' is from 0 ~ 1 and the default value of the 'invite-priority' parameter is 0, which is no priority. So, in the above example, B, C, E can be regarded having

b) Approach II: Ad-Hoc Group case:

The above achieves the ordered invitation by defining 'invite-priority' attribute extension to the existing uri-list for ad-hoc group. Instead, those could be specified separately from the 'uri-list', as proposed in this IDF.

The difference of this Approach Il from Approach I is that, the rules are now separated. from the uri-list.

INVITE sip:app.licatιon-server@example.com SIP/2.0

Via: STP/2.0/TCP example.com;branch=z9hG4bKhjhs8ass83

Max-Forwards: 70

To: "Application Server " <sip:application-server @example.com>

From: Alice <sip:req-user@example.com>;tag— 32331

Call-ID: d432fa84b4c76e66710

CSeq: 1 INVITE

Contact: <sip:req-user@gsr.example.com>

Allow: INVITE, ACK₅ CANCEL, BYE, REFER

Allow- E vents: dialog

Accept: application/sdp, message/sipfrag

Require: recipient-list-invite, ordered-invite Contetit-Type: multipart/mixed;boundary="boundary 1 " Content-Length: 690

— boundary 1

Content-Type: application/sdp

v-0 o=req-user 2890844526 2890842807 TN IP4 gsr.example.com

C=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtρmap:0 PCMU/8000 m=video 20002 RTP/AVP 31. a=rtρmaρ:3 1 H261/90000

— boundary 1

Content-Type: application/resource-lists+xml

Content-Disposition: recipient-list

<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="um:ietf:params:xml:ns:resource-lists"> <list>

<entry uri="sip:userE@exaraple.net" /> </list> </resource-lists> — boundary 1

Content-Type: application/vnd.oma.ordered-invite +xml Content-Disposition: Rule for ordered invite

<invite-order xmIns="urn:oma:params:xml:ns:SessionCondition"> <entry uri-"sip:userA@example.com" invite-priority-" 1^"7> <entry uri-^~"siρ:userD@example.com" invite-priority-^~~'O.5'7> </invite-order>

— boundary 1

c) Approach 111: Pre-arranged Group case:

If this kind of rules are to be something static, then it could be embedded within the group member listing (just like similar to Approach I in the Group document. But, this static invitation rules in the group document could be overridden by dynamic rales as specified within the INVfTTi request just like Approach IT.

For example,

INVITE sip:PoC-Grouρ @examρle.com SIP/2.0

Via: SIP/2.0/TCP example.com;branch-z9hG4bKhjhs8ass83

Max-Forwards: 70

To: "PoC Group" <sip:poc-group@cxamplc.com>

From: Alice <sip:req-user@example.com>:tag=32331

Call-ID: d432fa84b4c76e66710

CSeq: 1 INVITE

Contact: <sip:req-user@gsr.exarnple.com>

Allow: INVITE, ACK, CANCEL. BYE, REFER Allσw- Events: dialog

Accept: application/sdp, message/siplτag

Require: recipient-list-invite, ordered-invite

Content-Type: multipart/mixed;boundary="boundary I "

Content- Length: 690

— boundary 1

Content-Type : app iication/sdp

v=0 o=req-user 2890844526 2890842807 IN IP4 gsr.example.com

C--=:_ c=IN 1P4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 20002 RTP/AVP 31 a=rtpmap:31 H261/90000

-boundary 1

Content-Type: appϋcation/vnd.oma.ordered-invite +xml Content-Disposition: Rule for ordered invite

<invite-order xmlns="urn:oma:params:xral:ns:SessionCondition"> <entry uri="sip:userA@example.com" invite-priority^" 1'7> <entry uri=" sip :userD@exampl e .com" invite-pri ority="0.5 "/> </invite-order>

— boundarvl In the above, the dynamic rule specifying that user A has invite - priority="l" and user D has "0.5" will override any possible static invite priority rule specified in the PoC group document.

This innovation provides the system and method to enable the user Io set session set up condition so that user can set some rules for establishing the session. This will help user to set priorities for invitation. User can set some rules for sending the invitation so that this will avoid unnecessary invitations. This also helps in avoiding the unnecessary session setup, when there is no need for session set up if particular user reject the invitation.

Claims

WHAT IS CLAIMED IS:

1. A system for establishing a STP based group chat session. comprising; a group chat initiating client for sending an SIP(Session Initiation Protocol) INVITE request to initiate the group chat session, which including a predefined rule that describes the orders for an group chat application server receiving the SIP INVITE request to follow in sending the group chat invitations to other users in the group chat; an group chat application server for receiving from the said group chat initiating client the SIP INVITE request with the said predefined rule on the group chat invitation sending orders, then subsequently sending the SIP INVITE requests to other users in the group chat as per the rule regarding the group chat invitation sending orders.

2. The system of claim 1, wherein the SIP INVITE request from the group chat initiating client includes in the predefined rule the priorities for the group chat application server to follow in sending the invitations to other users in the group chat.

3. A method for establishing a group chat session, comprising; sending an SIP INVITE request by a group chat initiating client, Io initiate the group chat session, which including a predefined rule that describes the orders for an group chat application server receiving the SIP INVITE request to follow in sending the group chat invitations to other users in the group chat; receiving by an group chat application server from the said group chat initiating client, the SIP INVITE request with the said predefined rule on the group chat invitation sending orders, then subsequently sending by the group chat application server the SIP INVITE requests to other users in the group chat as per the rule regarding the group chat invitation sending orders.

4. The method of claim 3, wherein the SIP INVITE request from the group chat initiating client includes in the said predefined rule the priorities for the said group chat application server to follow in sending the invitations to other users in the group chat.