HK1142188B - A method to determine multimedia capabilities, the multimedia application server and the system for the same - Google Patents

Description

Method for determining multimedia capability, multimedia application server and system

Technical Field

The present invention relates to a system and method for handling multimedia conference calls in a telecommunications system.

Background

Multimedia conferencing in telecommunications networks has been the subject of standardization by a number of standardization bodies. For packet-based networks, ITU-T has proposed a number of recommendations for multimedia communication in the protection recommendation h.323. H.323 relates to a number of other recommendations such as the h.225.0 protocol describing call signaling, media (audio and video), stream packetization, media stream synchronization and control message formats, and the recommendation h.450 describing supplementary services. Another signalling protocol is SIP (session initiation protocol), which is specified by the IETF in the specification RFC 3261. RFC 3261 specifies a number of SIP messages and these messages carry the Session Description Protocol (SDP) specified in RFC 2327.

Currently, the initiative in the telecommunications community, such as 3GPP and 3GPP2 (third generation partnership project), is the next generation packet switched core network that specifies telecommunications services. In 3GPP, the core network domain is called IMS (IP multimedia subsystem). The 3GPP is currently proposing requirements including support of multiple supplementary services in the IMS (e.g. 3GPP TS 22.173). One example of a supplementary service is multimedia conferencing (or group calling), in which multiple multimedia terminals may be involved and each terminal may support a different media type. Media types are typically specified in accordance with the MIME standard (RFC 2046).

In addition, the Open Mobile Alliance (OMA) has defined a standard for push to talk over cellular (PoC). See, for example, push to talk over cellular (PoC) architecture, draft version 2.0-3 months 2007, open Mobile alliance, OMA-AD _ PoC-V2_0-20070326-D, which is incorporated herein by reference. The OMA PoC Specification set utilizes a number of existing specifications from IETF, 3GPP, and 3GPP2, including the capability of the 3GPP IP Multimedia Subsystem (IMS) and the 3GPP2 multimedia Domain (MMD) to enable IP connectivity and IP-based communications between mobile devices including multi-party conferencing.

In a telecommunications system, such as IMS where calls are set up and controlled by using SIP signalling, the way to determine the capabilities of remote terminals is to use the SIP method called OPTIONS described in IETF RFC 3261. This method allows a user terminal to query another user terminal or a proxy server about its capabilities. This allows the client to discover information about supported methods, content types, extensions, codecs, etc. without "ringing" the other party. The OPTIONS response is a so-called 200OK message with an attached SDP describing the media support of the remote end. The 200OK response may also include a feature tag indicating that the sender of the OPTIONS knows other capabilities that may be useful to it.

Disclosure of Invention

One limitation of the current OPTIONS method in SIP is that there may be only one OPTIONS response for each OPTIONS request. In multimedia conferencing, this is a problem because the user wants to know what all conference participants usually support. A conference call involving e.g. 5 participants cannot return 5 OPTIONS responses to a single OPTIONS request sent by one participant.

In the present invention, the above problems are solved by implementing the following methods: using a server located between the involved user terminals (clients), the server collects the supported capabilities (e.g. media types, supplementary services, etc.) of each of the participant's user terminals and aggregates a common set of supported capabilities and returns those capabilities in a single response message (e.g. a 200OK response) which then indicates support for the conference.

The solution is to send a service query message (e.g. an OPTIONS request) with a group call context and have the message terminate in a server (e.g. a group call server). The server sends a service enquiry message (e.g. an OPTIONS request) to each participant and waits for its response (e.g. in a 200OK response). Thereafter, the server analyzes the commonly supported capabilities received from the participant terminals. The server may optionally analyze any system policies, group policies, and subscriber policies that may prohibit some support (although the terminal supports it) due to non-subscription capabilities. After analyzing all these parameters, the server forms a collective 200OK response including SDP descriptions which are information about the supported capabilities. If 75% of the participants support video, the server may decide as a policy to include, for example, video as a possibility in the call.

The service enquiry message (e.g. an OPTIONS request) may be sent during an ongoing conference call or not related to any ongoing call.

One advantage of this solution is that the conference call can be set up by knowing in advance what capabilities the other user terminals can support. And therefore does not require multiple trial and error call setups.

Another advantage is that the capabilities available to each involved terminal in the conference call can be presented to the user on the terminal in a user-friendly way. For example, a mobile phone with a display may present icons representing the capabilities of the terminals involved. This makes the conferencing service more attractive to the user and will eventually encourage the user to generate more traffic in the network, which is beneficial for the network operator.

Yet another advantage is that new shared multimedia services can be employed to extend the method as they enter 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 now be described in more detail by means of preferred embodiments and with reference to the accompanying drawings.

Drawings

Fig. 1 is a block diagram illustrating a terminal group capable of accessing a group call server according to the present invention.

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

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

Detailed Description

Fig. 1 depicts a group 110 of terminals 111 and 114 having access to a server (group call server 100). The group call server 100 is adapted to receive a sip options request 121 from a terminal 111 in the group 110. The server 100 is further adapted to broadcast the SIP option requests 131, 141, 151 to a plurality of other terminals 112 and 114 in the group 110.

The group call server 100 comprises a memory area (cache) 105 adapted to store capabilities of the terminals 112 involved 114 in the group 110.

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

1) terminal 1111 sends a SIP OPTIONS request 121 in an ongoing SIP conference. The SIP OPTIONS request 121 is directed to the group call server 100.

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

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

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

5) The group call server 100 receives a SIP 200OK response 132 from the terminal 2112 indicating, for example, that it supports m-audio, m-video, m-messaging.

6) The group call server 100 receives a SIP 200OK response 142 from the terminal 3113 indicating that it supports m-audio and m-video, for example.

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

8) The group call server 100 checks any system, group or subscriber policy that may restrict the terminal 1111 from using video, for example, although it is supported by all participant devices. The group server 100 then creates a common SIP 200OK response 122 to the terminal 1111 with a common set of capabilities. In the above example, the SIP 200OK 122 contains an SDP with m-audio and m-video. This is because terminal 3113 does not support messaging despite terminal 2(112) and terminal 4114 support.

9) When terminal 1111 receives the 200OK response 122, it analyzes the attached SDP. If terminal 1111 has a display, an icon such as 'add video' is highlighted as a soft button on the display (for example). Pressing that button causes video streaming to terminals 2-4112-114.

By using this method, there is a way for terminal 1111 to learn the capabilities of all other terminals 112 and 114 involved in the conference call.

To save signaling, the group call server 100 can optionally store the responses 132, 142, 152 from the terminals 112 and 114 in the memory area 105. When another terminal sends a SIP OPTIONs request, i.e. if terminal 2112 in the configuration of fig. 1 sends a SIP OPTIONs request 171, the group call server 100 sends a SIP OPTIONs request 172 only to terminal 1111, since the content of the SIP 200OK response 142 from terminal 3113 and the SIP 200OK response 152 from terminal 4114 is already known by the server 100 before sending the SIP 200OK response 173 to terminal 2112.

Fig. 2 is a flow chart describing the claimed method of the present invention as seen from the group call server 100. In step 201, the group call server 100 receives a first service enquiry message 121 (e.g. an OPTIONS request) from a terminal 111 in the group 110. In step 202, the server 100 broadcasts a second service enquiry message (OPTIONS request) 131, 141, 151 to at least one of the other terminals 112 and 114 in the group 110. In step 203, the server 100 receives the respective first service response messages (e.g., 200OK messages) 132, 142, 152 from the queried terminal 112 and 114. Optionally, the server 100 stores all received service response messages 132, 142, 152 from the terminals 112 and 114 in the memory area 105. The server 100 analyzes the content in the received service response messages 132, 142, 152 in step 205 and determines a common set of services in step 206. This common set of services is then sent to the terminal 111 in a service response message (200OK message) in step 207.

Fig. 3 shows a group call server 300 divided into several servers according to applications such as 3gPP multimedia telephony or OMA PoC. FIG. 3 includes an autonomous server (ad hoc server)310 and a plurality of sub-servers 311 and 313. The autonomous 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 suitable for, for example, MMte1 (multimedia telephony) autonomous group calls or 1-1PoC sessions and autonomous PoC sessions.

The server 311-.

The autonomous server 310 aggregates the received responses 322 and 324 from the sub-servers 311 and 313 and may apply group policies such as subscription OPTIONS and service provider's local policies before sending the OPTIONS response 321 to the terminal 1111.

In the described embodiment, the invention is basically applicable to PoC push-to-talk over cellular. Those skilled in the art will apply the inventive concept to a number of other network scenarios, such as 3GPP multimedia telephony, MMte1 autonomous groups, and so on.

The following is a detailed description of the OPTION method extracted from RFC 3261.

The SIP method OPTIONS allows a UA (user agent) to query another UA or a proxy server for its capabilities. This allows the client to discover information about supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before the client inserts a request (Require) header field into the INVITE listing an option that it does not determine whether the target UAS (user agent server) supports, the client may query the target UAS with OPTIONS to see if this is returned in a Supported (Supported) header field. All UAs must support the OPTIONS method.

The target of the OPTIONS Request is identified by a Request-URI, which may identify another UA or a SIP server. If the OPTIONS is for a proxy server, then the Request-URI is set without the user part, in a similar way to setting a Request-URI for a REGISTER Request.

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

This behavior is the same as HTTP/1.1. This behavior can be used as a "traceroute" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with increasing Max-Forwards values.

As is the case with normal UA behavior, the transaction layer may return a timeout error if OPTIONS does not produce a response. This may indicate that the target is unreachable and, thus, unavailable.

The OPTIONS request may be sent as part of an established conversation to query peers for capabilities that are available later for the conversation.

The OPTIONS request is composed using standard rules for SIP requests as discussed in RFC 3261 section 8.1.1.

The Contact header field may be present in OPTIONS.

An accept (accept) header field should be included to indicate the type of message body that the UAC (user agent client) wishes to receive in the response. This is typically set to a format for describing the media capabilities of the UA, such as SDP (application/SDP).

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

Example OPTIONS request:

OPTIONS sip：carolchicago.com SIP/2.0

Via：SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877

Max-Forwards：70

To：<sip：carolchicago.com>

From：Alice<sip：aliceatlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66710

CSeq：63104 OPTIONS

Contact：<sip：alicepc33.atlanta.com>

Accept：application/sdp

Content-Length：O

the response to OPTIONS is structured using standard rules for SIP responses as discussed in RFC 3261 section 8.2.6. The response code chosen must be the same as that chosen when the request is an INVITE. That is, return 200(OK) if the UAS is ready to accept calls, return 486 (busy here), if the UAS is busy, etc. This allows the OPTIONS request to be used to determine the basic state of the UAS, which may be an indication of whether the UAS will accept the INVITE request.

The OPTIONS request received in the dialog generates a 200(OK) response, which is identical to the response constituted outside the dialog and has no effect on the dialog.

This use of OPTIONS has limitations due to the difference in proxy handling of OPTIONS and INVITE requests. While a forked (fork) INVITE may result in multiple 200(OK) responses being returned, a forked OPTIONS results in only a single 200(OK) response because it is treated by the proxy using a non-INVITE process. For standard details, see RFC 3261, section 16.7.

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

The response does not contain a message body.

The allowed (low), accepted (Accept), accepted-Encoding (Accept-Encoding), accepted-Language (Accept-Language) and Supported (Supported) header fields should be present in the 200(OK) response to OPTIONS. If the response is generated by an agent, it should be omitted when the header field is allowed to be ambiguous, since the agent is method agnostic. The contact header field may be present in the 200(OK) and have the same semantics as in the 3xx response. That is, they may display a set of alternative names and methods to reach the user. There may be a Warning (Warning) header field.

A message body may be sent, the type of which is determined by the accept header field in the OPTIONS request (if the accept header field is not present, application/sdp is the default). If the types include types that can describe media capabilities, the UAS should include a body in the response for this purpose. Details on the construction of such a body in the case of an application/sdp are described in RFC 3264.

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

SIP/2.0 200 OK

Via：SIP/2.0/UDP pc33.atlanta.com；branch＝z9hG4bKhjhs8ass877；received＝192.0.2.4

To：<sip：carolchicago.com>；tag＝93810874

From：Alice<sip：aliceatlanta.com>；tag＝1928301774

Call-ID：a84b4c76e66710

CSeq：63104 OPTIONS

Contact：<sip：carolchicago.com>

Contact：<mailto：carolchicago.com>

Allow：INVITE，ACK，CANCEL，OPTIONS，BYE

Accept：application/sdp

Accept-Encoding：gzip

Accept-Language：en

Supported：foo

Content-Type：application/sdp

Content-Length：274

(SDP not shown)

Claims (15)

1. A method of determining multimedia capabilities supported by a plurality of multimedia terminals forming a group in a telecommunications network, characterized by the steps of:

-receiving a first service enquiry message from a first multimedia terminal;

-sending a second service enquiry message to at least one of the other multimedia terminals in the group;

-receiving a first service response message from the other multimedia terminal as a response to the second service enquiry message;

-analyzing the received capabilities in the first service response message;

-determining a common set of capabilities;

-sending a second service response message to the first multimedia terminal as a response to the first service enquiry message, the second service response message comprising the common set of capabilities.

2. The method of claim 1, wherein the step of determining the common set of capabilities further comprises the step of applying a policy.

3. The method of claim 2, wherein the policy is any one or a combination of:

-a system policy;

-a group policy;

-subscriber policy.

4. The method of claim 1, further comprising the step of storing the received capabilities.

5. The method of claim 4, further comprising the steps of:

-receiving a third service enquiry message from the second multimedia terminal;

-sending a fourth service enquiry message to the first multimedia terminal;

-receiving a third service response message from the other multimedia terminal as a response to the third service enquiry message;

-analyzing the received capabilities and the stored capabilities in the third service response message;

-determining a second common set of capabilities;

-sending a fourth service response message to the second multimedia terminal as a response to the fourth service enquiry message, the fourth service response message comprising the second common set of capabilities.

6. A method according to claim 3 or 5, wherein the service enquiry message is a SIP OPTIONS request and the service response message is a SIP 200OK response.

7. The method according to any of claims 1-5, wherein the multimedia terminals in the group participate in a multimedia conference call.

8. A multimedia application server accessible from a group comprising a plurality of multimedia terminals in a telecommunication network, wherein said multimedia application server is characterized in that it comprises:

-means for collecting capabilities from at least one second multimedia terminal of said group in response to a service enquiry message received from the first multimedia terminal;

-means for analyzing the collected capabilities and determining a common set of capabilities;

-means for returning a service response message comprising the common set of capabilities to the first multimedia terminal.

9. The multimedia application server of claim 8, further comprising: a memory area adapted to store the collected capabilities.

10. The multimedia application server of claim 9, further comprising means for applying a policy when determining the common set of capabilities.

11. A multimedia application server according to claim 10, further comprising means for analyzing said collected capabilities and capabilities already stored in said memory area.

12. A multimedia application server according to any of claims 8 to 11, further adapted to be connectable to at least one other multimedia application server.

13. A system comprising a plurality of interconnected multimedia application servers according to claim 12.

14. The system of claim 13, wherein the servers are interconnected in an application-dependent configuration.

15. The system of claim 14, wherein one server is an autonomous server and the other servers are child servers connected to the autonomous server, and the autonomous server is further adapted to aggregate service response messages received from the child servers.