KR20100016394A - Group call capability query - Google Patents

Abstract

The present invention relates to a system and a method for handling multimedia conference calls in a telecommunication network. In order for a first terminal (111) in a group (110) to determine the capabilities of at least on other terminal (112-114) in the group (110), a query message can be sent to the other terminal (112-114). When using SIP (Session Initiation Protocol), the query is performed by the method of sending an OPTIONS message. A limitation with this method is that each terminal (111) in the group needs to send a query to all the other terminals (112-114) in the group in order to determine the capabilities of each other. The invention comprises a common server (100) which is adapted to collect information about the capabilities for the terminals (112-114) in the group and to determine a common set of capabilities which is sent to the first terminal (111).

Description

Group Call Capability Query {GROUP CALL CAPABILITY QUERY}

The present invention relates to a system and method for processing a multimedia conference call in a telecommunications network.

Multimedia conferencing in telecommunication networks has been a topic of standardization in many standardization bodies. For packet-based networks, the ITU-T has provided a number of recommendations for multimedia communications under comprehensive Recommendation H.323. H.323 Recommendations describing H.225.0 protocols and supplementary services that describe call signaling, media (audio and video), stream packetization, media stream synchronization, and control message formats Reference is made to a number of other recommendations. Another signaling protocol is the Session Initiation Protocol (SIP), which was specified by the IETF in specification RFC 3216. RFC 3261 specifies a number of SIP messages that have the Session Description Protocol (SDP) specified in RFC 2327.

Currently, leaders within telecommunications systems such as the 3rd Generation Partnership Project (3GPP) and 3GPP2 specify the next generation of packet switched core networks for telecommunication services. In 3GPP, a core network domain is called an IMS (IP Multimedia Subsystem). 3GPP is a current draft requirement (eg 3GPP TS 22.173) that includes support for supplementary services in IMS. One example of an additional service is a multimedia conference (or group call) in which a plurality of multimedia terminals may be included and each terminal may support a different media type. Media types are typically specified according to the MIME standard (RFC 2046).

In addition, the Open Mobile Alliance (OMA) has defined standards for Push-to-Talk over Cellular (PoC). See, eg, OMA, OMA-AD_PoC-V2_0-20070326-D, March 2007-Draft Version 2.0, Push-to-Talk over Cellular (PoC) -architecture, which is incorporated herein by reference in its entirety. The OMA PoC specification set uses a number of existing specifications from IETF, 3GPP, and 3GPP2, which include 3GPP IP Multimedia Subsystem (IMS) and 3GPP2 to enable IP-based communication and IP connectivity between mobile devices, including multi-party conferencing. Capabilities of the multimedia domain (MMD) are included.

In a telecommunications system such as an IMS where a call is initiated and controlled by SIP signaling, a method of determining the capabilities of a remote terminal is to use a SIP method called OPTIONS described in IETF RFC 3261. This method allows a user terminal to query another user terminal or proxy server for its capabilities. This allows customers to find out information about supported methods, content types, extensions, codecs, etc., without having to "call" the other party. The OPTIONS response is a so-called 200 OK message that includes an attached SDP describing the media support of the remote end. The 200 OK response may also include a property tag indicating another capability that may be useful for the sender of OPTIONS to recognize.

A limitation of the current OPTIONS method in SIP is that there can be only one OPTIONS response for each OPTIONS request. This is a problem when in a multimedia conference the user wants to know what all conference participants normally support. For example, a conference call involving five participants may not return a 5 OPTIONS response to a single OPTIONS request sent by one participant.

The problem is located between the included user terminals (customers) to collect the capabilities supported by each participant's user terminal (e.g. media type, supplementary services, etc.) It is solved in the present invention by implementing a method of using a server that gathers a common set and returns them in a single response message (e.g. 200 OK message) indicating the support of the conference.

The solution sends one service enquiry message (eg, OPTIONS request) with a group cell context and causes the message to terminate at a server, such as a group cell server. The server sends one service inquiry message (eg an OPTION request) to each participant and waits for their response (eg 200 OK message). The server then analyzes for commonly supported capabilities. The server may optionally analyze any system policy, group policy, and subscriber policy that may prohibit certain support even if it supports the capability due to non-subscription capabilities. After analyzing all these parameters, the server forms a collective 200 OK response that includes an SDP description that is information about the supported capabilities. The server may determine as one policy that, for example, 75% of the participants support the video as likely in the call if the video is supported.

A service inquiry message (such as an OPTION request) may be sent during an ongoing conference call or regardless of any ongoing call.

An advantage of this solution is that the conference call can be set up by knowing in advance which capacities other user terminals can support. Therefore, multiple test and error call setups are required.

Another advantage is that the capabilities available to the terminal included in each conference call can be provided to the user in a user friendly manner with the terminal. For example, a mobile phone with a display may provide icons representing the capabilities for each terminal included. This makes the conference service more interesting to users, which in turn will inspire users to generate more traffic in the network, which will benefit network operators.

Another advantage is that the method can be used for the newly shared multimedia service when the newly shared multimedia service enters the market.

It is therefore an object of the present invention to simplify the communication between multimedia terminals in a multimedia conference call.

The invention will be described in more detail as a preferred embodiment and with reference to the accompanying drawings.

1 is a block diagram illustrating a group of terminals that can access a group call server in accordance with the present invention.

2 is a flowchart illustrating the steps of determining the capabilities supported by the multimedia terminal according to the method of the present invention.

3 is a block diagram illustrating a server divided into a plurality of sub servers.

1 illustrates a group 110 of terminals 111-114 that can access a server, that is, a group call server 100. The group call server 100 is adapted to receive the SIP OPTIONS request 121 from the terminal 111 in the group 110. Server 100 is further adapted to broadcast SIP option requests 131, 141, 151 to a plurality of other terminals 112-114 in group 110.

The group call server 100 includes a memory area (cache) stored to store the capacities of the terminals 112-114 included in the group 110.

1 also shows the information flow between terminals 111-114 and group call server 100 in group 110:

1) Terminal 1 (111) transmits a SIP OPTIONS request 121 in an ongoing SIP session. The SIP OPTIONS request 121 is addressed to the group call server 110.

2) The group call server 100 transmits a SIP OPTIONS request 131 to the terminal 2 113.

3) The group call server 100 sends a SIP OPTIONS request 141 to the terminal 3113.

4) The group call server 100 transmits a SIP OPTIONS request 151 to the terminal 4 114.

5) The group call server 100 receives, for example, a SIP 200 OK response 132 from terminal 2 112 indicating that terminal 2 supports m = audio, m = video, m = messaging.

6) The group call server 100 receives, for example, a SIP 200 OK response 142 from terminal 3 113 indicating that terminal 3 supports m = audio, m = video.

7) The group call server 100 receives a SIP 200 OK response 152 from terminal 4 114, for example indicating that terminal 4 supports m = audio, m = video, m = messaging.

8) The group call server 100 checks for some system, group and subscriber policies that may restrict, for example, terminal 1 111 from using video even though all participant devices support video. The group server 100 then generates a common SIP 200 OK response 122 for terminal 1 111 to have a common set of capabilities. In the above example, SIP 200 OK 122 includes an SDP with m = audio and m = video. This is because the terminal 3113 does not support messaging even though the terminal 2 112 and the terminal 4 114 support messaging.

9) When the terminal 1 111 receives the 200 OK response 122, the terminal 1 111 analyzes the attached SDP. If terminal 1 111 has a display, an icon such as 'Add Video' is highlighted, for example, by a soft button on the display. By pressing the button, video streaming occurs on terminals 2-4 (112-114).

By using this method, terminal 1 111 becomes aware of the capabilities of all other terminals 112-114 involved in the conference call.

To save signaling, group call server 100 may optionally store responses 132, 142, 152 from each terminal 112-114 in memory area 105. If another terminal sends a SIP OPTION request, i.e., when terminal 2 112 in the architecture in FIG. 1 transmits a SIP OPTIONS request 171, a SIP 200 OK request 142 from terminal 3 113 and Since the content in the SIP 200 OK request 152 from terminal 4 114 is already known by the server 100 before sending the SIP 200 OK response 173 to terminal 2 112, the group call server ( 100 merely transmits the SIP OPTIONS request 171 to the terminal 1 (111).

2 is a flow chart describing the claimed method in the present invention as verified by the group call server 100. In step 201, the group call server 100 receives a first service inquiry message from the terminal 1 111 in the group 110. In step 202, server 100 broadcasts a second service inquiry message (OPTIONS request) 131, 141, 151 to at least one of the other terminals 112-114 in group 110. In step 203, server 100 receives a first service response message (such as a 200 OK message) 132, 142, 152 from each inquired terminal 112-114. Optionally, server 100 stores all received service response messages 132, 142, 152 from terminals 112-114 in memory area 1055. In step 205, server 100 analyzes the content in the received service response messages 132, 142, and 152, and in step 206, determines a common set of services. The common set of services is then sent to terminal 111 in the form of a service response message (200 OK message) in step 207.

3 shows a group call server 300 divided into several servers according to an application, for example a 3gpp multimedia phone or an OMA PoC. 3 includes an ad hoc server 310 and a plurality of sub servers 311-313. The ad hoc server 310 is accessible from the terminal 111 and the sub-servers 311-313 are accessible from the terminals 112-114, respectively.

FIG. 3 is an example of a multi-server configuration applicable to, for example, a multimedia telephony (MMtel) ad-hoc group call or a 1-1 PoC session and an ad-hoc PoC session.

The servers 311-313 serving the terminals 112-114 may modify the contents of the received service response message 200 OK 351-353 based on the subscription of the serviced user and the service provider regional policy.

The ad-hoc server 310 collects the responses 311-313 received from the sub-servers 311-313 and sends the OPTIONS response 321 to the terminal 1 111, such as subscription selection and service provider local policy. You can apply Group Policy.

The present invention basically applies to Puch-to-talk over cellular (PoC) for cellular in the described embodiment. Those skilled in the art will apply the concept of the invention to many other network scenarios, such as 3GPP multimedia telephony, MMtel ad-hoc groups, and the like.

Below, the OPTION method deduced from RFC 3261 is described in detail.

SIP method OPTIONS allows a UA (User Agent) to query another UA or proxy server for its capabilities. This allows the customer to find out information about supported methods, content types, extensions, codecs, etc. without "calling" the other party. For example, before a customer inserts a Require header field into an INVITE that lists options that are not sure that the destination user agent server supports it, the customer queries the destination UAS as OPTIONS. You can check if this is returned in the supported header fields. All UAs must support the OPTIONS method.

The target of the OPTIONS request is identified by the request-URI, which can identify the UA or SIP server. When OPTIONS is addressed to a proxy server, the request-URI is set without the user part, similar to how the request-URI is set for a REGISTER request.

Alternatively, a server receiving an OPTIONS request with a Max-Forwards header field value of 0 may respond to the request regardless of the request-URI.

This behavior is identical to HTTP / 1.1. This behavior can be used as a "transroute" function to check the capability of individual hop servers by sending a series of OPTIONS requests with incremental maximum-transmit values.

For normal UA behavior, the transaction layer may return a timeout error if OPTIONS does not generate any response. This will indicate that the target is unreachable and therefore unavailable.

The OPTIONS request can be sent as part of a conversation established to query the peer for capabilities, which part will be used later in the conversation.

The OPTIONS request is constructed using the standard norms for SIP requests as discussed in section 8.1.1 of RFC3261.

The Contact header field may be present in OPTIONS.

The Accept header field SHOULD MUST be included to indicate the type of message body that the UAC (User Agent Clinet) wants to receive in the response. Typically this is set to the format used to describe the media capabilities of the UA, such as SDP (application / sdp).

The response to the OPTIONS request is assumed to be scoped to the request-URI in the original request. However, it is only guaranteed that future requests will be received by the server guaranteeing OPTIONS when OPTIONS is sent as part of an established conversation.

Example OPTIONS request:

OPTIONS sip: [email protected] SIP / 2.0

Via: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4bKhjhs8ass877

Max-Forwards: 70

To: <sip: [email protected]>

From: Alice <sip: [email protected]>; tag = 1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: <sip: [email protected]>

Accept: application / s

Content-Length: 0

The response to the OPTIONS is constructed using the standard norms for SIP responses as discussed in section 8.2.6 of RFC3261. The response code selected should be the same as if the request was selected as INVITE. That is, 200 (OK) will be returned if the UAS is ready to accept a call, and 486 (Busy Here) will be returned if the UAS is on a call. This allows the OPTIONS request to be used to determine the basic state of the UAS, which may be an indication of whether S will accept the INVITE request.

The OPTIONS request received within the conversation is the same 200 (OK) response as the response configured outside the conversation and has no effect on the conversation.

The use of such OPTIONS has limitations due to differences in proxy processing of OPTIONS and INVITE requests. Forked INVITE can generate multiple 200 (OK) responses returned, while forked OPTIONS will only generate a single 200 (OK) response, because it uses a proxy that uses non-INVITE processing. Because they are processed by them. See section 16.7 of RFC3261 for details according to the norm.

If a response to OPTIONS is generated by the proxy server, the proxy returns 200 (OK), listing the server's capabilities.

The response does not include a message body.

Allow, Accept, Accept-Encoding, Accept-Language and Supported Header fields MUST be present at 200 (OK) for OPTIONS. If the response is generated by a proxy, it must be omitted because the proxy is method independent and the allowed header fields are not clear. The connection header field may exist at 200 (OK) and have the same meaning as in the 3xx response. That is, the connection header field may list a set of alternative names and methods of reaching the user. There may be a Warning header field.

The message body may be sent, the type of the message body being determined by the accept header field in the OPTIONS request (application / sdp is the default if the accept header field does not exist). If the type is of a type capable of describing media capabilities, then the UAS must include a body in the response for this purpose. If the application / sdp is described in RFC 3264, the details of the construction of such a body are described.

Example OPTIONS response generated by the UAS (corresponding to the request described above):

SIP / 2.0 200 OK

Via: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4Khjhs8ass877; received = 192.0.2.4

To: <sip: [email protected]>; tag = 93810874

From: Alice <sip: [email protected]>; tag = 1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: <sip: [email protected]>

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE

Accept: application / s

Accept-Encoding: gzip

Accept-Language: en

Supproted: foo

Content-Type: application / s

Content-Length: 274

(SDP not shown)

Claims (15)

In a method in a telecommunications network for determining multimedia capabilities supported by a plurality of multimedia terminals 111-114 constituting a group 110: Receiving (201) a first service inquiry message (121) from a first multimedia terminal (111); Transmitting (202) a second inquiry message (131, 141, 151) to at least one of the other multimedia terminals (112-114) in the group (110); Receiving (203) a first service response message (132, 142, 152) from the other multimedia terminal (112-114) in response to the second service inquiry message (131, 141, 151); Analyzing (205) the received capabilities in the first service response message (132, 142, 152); Determining 206 a common set of capabilities; And transmitting a second service response message 122 to the first multimedia terminal 111 that includes a common set of capabilities as a response to the first service inquiry message 121. Way from. The method of claim 1, Determining the common set of capacities further comprises applying a policy. The method of claim 2, The policy is: System policy; Group policy; Any one of subscriber policies or a combination of said policies. The method of claim 1, Storing (204) said received capability. The method of claim 4, wherein Receiving a third service inquiry message (171) from a second multimedia terminal (112); Transmitting a fourth service inquiry message (171) to the first multimedia terminal (111); Analyzing the capabilities received in the third service response message (172) together with the stored capabilities; Determining a second common set of capabilities; Sending a fourth service response message 173 to the second multimedia terminal 112 that includes a second common set of capabilities as a response to the fourth service inquiry message 121. Method in a telecommunications network, characterized in that. The method according to claim 3 or 5, The service inquiry message (121, 131, 171) is a SIP OPTIONS request and the service response message (122, 132, 172) is a SIP 200 OK response. 7. The method according to any one of claims 1 to 6, And said multimedia terminal (111-114) in said group (110) is used for a multimedia conference call. In a multimedia application server 100 in a telecommunications network accessible from a group 110 comprising a plurality of multimedia terminals 111-114: Collect capabilities from at least one second multimedia terminal (112-114) in said group (110) in response to a service inquiry message (121) received from a first multimedia terminal (111); Analyze the collected capabilities and determine a common set of capabilities; Multimedia application server (100) adapted to return a service response message (122) to the first multimedia terminal (112-114) comprising the common set of capabilities. The method of claim 8, The multimedia application server (100) further comprising a memory area (105) adapted to store the collected capabilities. The method of claim 9, Multimedia application server (100), characterized in that it is further adapted to apply a policy when determining a common set of capabilities. The method of claim 10, Multimedia application server (100), characterized in that it is further adapted to analyze the collected capabilities together with the capacities previously stored in the memory area (105). The method according to any one of claims 8 to 11, Multimedia application server (100), characterized in that it is adapted to connect with at least one other multimedia application server (310-313). A system (300) comprising a plurality of multimedia application servers (310-313) according to claim 12 connected to one another. The method of claim 13, The system (300) comprising a plurality of multimedia application servers characterized in that the servers (310-313) are connected to each other in configuration according to the application. The method of claim 14, One server is an ad hoc server 310 and the other server is a sub-server 311-313 connected to the ad hoc server 310 and the ad hoc server 310 is the sub-server 311-313. A system (300) comprising a plurality of multimedia application servers, further adapted to collect service response messages (322-324) received from.

Images