Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming

Abstract

A method of signaling and negotiation between a client and a server in a multimedia streaming service regarding the adaptation of the data delivery process. In order to make sure that the client supports the adaptation mechanisms or capabilities to be used in data delivery, one of the parties provides information indicating the adaptation mechanism or capability that it supports to the other party. Upon receiving the information, the other party uses well-defined RTSP response to indicate the support of that mechanism or capability. Either the server or the client can initiate the negotiation. The implementation of the signaling and negotiation covers an AVPF usage, RTP Retransmission Playload Format usage, and an SPTP usage in a particular 3G PSS session.

Description

[0001] This patent application is based on and claims priority to U.S. Provisional Applications No. 60/447,264, filed Feb. 13, 2003; No. 60/448,309, filed Feb. 14, 2003; No. 60/448,284, filed Feb. 14, 2003 and No. 60/448,299, filed Feb. 14, 2003.

CROSS REFERENCES TO RELATED PATENT APPLICATIONS

[0002] This patent application is related to U.S. Patent Applications, Docket No. 944-001.103-4, and Docket No. 944-001.103-6, both assigned to the assignee of the present patent application and filed on even date herewith.

FIELD OF THE INVENTION

[0003] The present invention relates generally to multimedia streaming and, more particularly, to signaling of streaming quality adaptation and control mechanism.

BACKGROUND OF THE INVENTION

[0004] In a multimedia streaming service, there are three participants involved: a streaming server, a streaming client and an underlying network which provides the connectivity between the server and the client. The server provides the functionality to deliver the multimedia streaming content to the client. For that purpose, the client and server communicate with each other over the network regarding the methods of capability exchange, content delivery method negotiation, content delivery control, and so forth. Such information exchange can be carried out via well-defined network protocols.

[0005] For a multimedia streaming session to be set up and started successfully, the server and the client need to support a minimal set of protocols, which are selected as standard protocols by the service. An example of such a service can be found in 3GPP TS 26.234 V5.1.0, “Transparent End-to-End Packet Switched Streaming Service (PSS); Protocols and Codecs (Release 5)”, June 2002, hereafter referred to as TS 26.234). Furthermore, in order for a service to be successful from the data delivery and playback performance point of view, the data delivery control mechanisms in the service must also be well-defined. Such mechanisms are used to adapt the data delivery process in order to cause the changes of behavior in the underlying network characteristics.

[0006] Three possible adaptation processes based on the decisive control location of the adaptation mechanisms or capabilities are as follows:

[0007] Client-Driven Adaptation

[0008] The client has control of the adaptation functionality or capability and makes the necessary decisions for adaptation. The decisions are based on information gathered from the network, the server, or other sources of information within the service definition.

[0009] Server-Driven Adaptation

[0010] The server has control of the adaptation functionality or capability and makes the necessary decisions for adaptation. The decisions are based on information gathered from the network, the client, or other sources of information within the service definition.

[0011] Cooperative Adaptation

[0012] Control of the adaptation functionality or capability is distributed between the server and the client. Both the server and the client can take actions for adaptation based on the information gathered from the network, the server, the client, or other sources of information within the service definition.

[0013] Within the service context, there may be more than one adaptation mechanism or capability defined within the context of each of the above-mentioned adaptation processes. It may be the case that each of these adaptation mechanisms or capabilities is standardized within the service, but kept optional for a server or client to implement.

[0014] Therefore, there is a certain need for a capability identification mechanism to identify the supported adaptation mechanisms or capabilities and an adaptation capability signaling and negotiation mechanism for the server and client to agree on the usage of a particular set of adaptation mechanisms or capabilities defined within the service context.

[0015] In prior art, Annex G of 3G PSS (Rel.5) defines a signaling mechanism, which can be used to signal the usage and support parameters, but this is not a complete solution.

SUMMARY OF THE INVENTION

[0016] The present invention provides a method of signaling and negotiation between a client and a server in a multimedia streaming service regarding the adaptation of the data delivery process. The method can be carried out using a capability exchange mechanism, or using a multimedia streaming control protocol. The method of signaling and negotiation, according to the present invention, can be implemented in AVPF (Extended RTP profile for PTCP-based feedback) usage in a particular 3G PSS session; RTP retransmission payload format usage in a particular 3G PSS session; and SRTP usage in a particular 3G PSS session.

[0017] The method, according to the present invention, can be carried out when the Multimedia Streaming Service has well-defined and/or standardized adaptation processes, and each adaptation process is composed of well-defined and/or standardized mechanisms, which are tools to render the adaptation functionality or capability functional. Furthermore, each adaptation mechanism or capability has an attribute that is well-defined and/or standardized within the service context, or well-known between the server and the client.

[0018] Accordingly, the present invention provide a method for signaling and negotiation between a client and a server in a multimedia streaming service, wherein a plurality of adaptation mechanisms or capabilities for use in the service for data delivery are supported by the client, each adaptation mechanism or capability having an attribute. The method comprises:

[0019] the client providing information indicative of the attributes defining the adaptation mechanisms or capabilities that are supported by the client;

[0020] the server selecting one or more of the attributes based on the provided information; and

[0021] the server providing further information indicative of the selected attributes so as to allow the client to know the one or more adaptation mechanisms or capabilities defined by the one or more attributes selected by the server.

[0022] According to the present invention, the client provides the information via a capability exchange mechanism, or via a multimedia streaming control protocol.

[0023] Alternatively, the method comprises:

[0024] providing by one of the two parties to the other of the two parties information indicative of one or more attributes defining one or more of the adaptation mechanisms or capabilities; and

[0025] conveying a message from said other party to said party, in response to the information, acknowledging supporting of said one or more adaptation mechanisms or capabilities.

[0026] Either the client or the server can initiate the negotiation. If the client initiates the negotiation, the client provides a plurality of attributes to the server; and the server selects one or more of the provided attributes based on the provided information for acknowledging the support.

BRIEF DESCRIPTION OF THE DRAWING

[0027] FIG. 1 shows a declaration by a client as part of the signaling and negotiation process, according to the present invention.

[0028] FIG. 2 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the present invention.

[0029] FIG. 3 shows the SDP description in an RTSP message sent by the server.

[0030] FIG. 4 shows an RTSP DESCRIBE response sent by the server.

[0031] FIG. 5 shows a declaration by the client as part of the signaling and negotiation process, according to another embodiment of the present invention.

[0032] FIG. 6 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the other embodiment of the present invention.

[0033] FIG. 7 shows the SDP description in an RTSP message sent by the server.

[0034] FIG. 8 shows an RTSP DESCRIBE response sent by the server.

[0035] FIG. 9 shows a declaration by the client as part of the signaling and negotiation process, according to yet another embodiment of the present invention.

[0036] FIG. 10 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the present invention.

[0037] FIG. 11 shows the SDP description in an RTSP message sent by the server.

[0038] FIG. 12 shows an RTSP DESCRIBE response sent by the server.

[0039] FIG. 13 is a flowchart illustrating the method of signaling and negotiation between a client and a server regarding the adaptation of a data delivery process, wherein the client initiates the negotiation.

[0040] FIG. 14 is a flowchart illustrating the method of signaling and negotiation wherein the server initiates the negotiation.

DETAILED DESCRIPTION OF THE INVENTION

[0041] The method of signaling and negotiation between a client and a server in a multimedia streaming service regarding the adaptation of the data delivery process, according to the present invention, can be carried out via a capability exchange mechanism or via a multimedia stream control protocol. The adaptation of the data delivery process is based on one or more attributes of one or more adaptation mechanisms or capabilities, which are used to determine the adaptation processes in a Multimedia Streaming Service.

[0042] When the signaling and negotiation is carried out via a capability exchange mechanism, the procedure is described as follows:

[0043] The client declares in its capability profile defined for a capability exchange mechanism the attributes of the adaptation mechanisms or capabilities implemented by the client;

[0044] The server obtains the capability profile;

[0045] As the server knows which adaptation mechanisms or capabilities are implemented by the client, the server selects a subset of the attributes that do not conflict with the adaptation processes. According to the selected subset of attributes, the server tailors the multimedia session description and declares the session description to the client; and

[0046] Based on the session description, the client knows the adaptation mechanism or capability selection carried out by the server for the particular multimedia session. The client accepts the adaptation mechanisms or capabilities declared in the session description by default, because the declared description contains a subset of the attributes or adaptation mechanism capabilities declared by the client.

[0047] When the signaling and negotiation is carried out via a multimedia streaming control protocol, the procedure is described as follows:

[0048] The client includes the attributes of the adaptation mechanism or capability implemented by the client in the Multimedia Streaming Control Protocol defined for the control of the streaming session;

[0049] Based on those attributes, the server knows which adaptation mechanisms or capabilities are implemented or required by the client. The server selects a subset of attributes that do not conflict with the adaptation processes and signals to the client the selected or non-selected attributes. Depending on the current phase of the control communication, the server may tailor the multimedia session description according to the selected attributes and declare the session description to the client; and

[0050] Based on the response from the server, the client knows which attributes are selected by the server. The client accepts by default the adaptation mechanisms or capabilities defined by the attributes selected by the server, because the selected adaptation mechanisms or capabilities are a subset of the adaptation mechanisms or capabilities declared by the client.

[0051] The method of signaling and negotiation, according to the present invention, can be implemented in the multimedia streaming service based on TS 26.234 or later releases. The implementation covers the definition, signaling and negotiation of the following mechanisms:

[0052] an AVPF usage in a particular 3G PSS session (see, for example, IETF draft-ietf-avt-rtcp-feedback-04: “Extended RTP profile for RTCP-based Feedback (RTP/AVPF)”, Ott et al., 2002, hereafter referred to as draft-avpf-04);

[0053] an RTP Retransmission Payload Format usage in a particular 3G PSS session (see, for example, IETF dradt-ietf-avt-rpt-retransmission-05: “RTP Retransmission Payload Format”, Rey et al., 2002, hereafter referred to as draft-retransmission-05); and

[0054] an SPTP usage in a particular 3G PSS session (see, for example, IETF draft-ietf-avt-srtp-05: “The Secure Real-time Transport Protocol”, Baugher et al., 2002, hereafter referred to as draft-srtp-05).

[0055] I. AVPF Usage in a Particular 3G PSS Session

[0056] If AVPF, as defined in draft-avpf-04 is supported by the client, and the client signals the AVPF support, then the server may use any combination of AVPF features as defined in draft-avpf-04 in the adaptation process. The client may also signal each supportable feature of AVPF (e.g., immediate feedback mode, early RTCP packet support, etc.) separately, if there's a well-defined mechanism identifier for that feature.

[0057] Let the attribute “AVPFSupport” be defined in the RDF (Resource Description Framework) Schema vocabulary to signal the support of AVPF defined in draft-avpf-04 for audio and video media.

[0058] Let the attribute “UnSupportedAdaptationSupport” be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is supported by the client, but not by the server.

[0059] Let the attribute “SupportedAdaptationSupport” be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.

[0060] Let “x-avpfsupport” be a well-defined SDP (Session Description Protocol) attribute, which is included in the audio and video (or the session-level for usage in both media types) media section of the SDP when AVPF is supported.

[0061] Let “x-unsupportedadaptationsupport” be a well-defined SDP attribute, which is included in the SDP (session or media level) when supported.

[0062] Let “x-supportedadaptationsupport” be a well-defined SDP attribute, which is included in the SDP (session or media level) when supported.

[0063] A. Signalling and Negotiation via a Possible Capacity Exchange Mechanism:

[0064] The client sends an RTSP DESCRIBE request to the server with a URI pointing to the client capability information residing in a capability exchange server.

[0065] The server fetches the capability declaration of the client from the capability exchange server. The declaration includes a part for the client-side streaming capabilities, as shown in FIG. 1.

[0066] The bold lines in the declaration represent the adaptation mechanism support capabilities of the client. It should be noted that when an attribute value is TRUE, the mechanism or capability is supported by the client. Conversely, when the attribute value is FALSE, the mechanism or capability is not supported by the client. For example, if the attribute AVPFSupport is TRUE, it declares that the client has the AVPF support for audio and video media components in a particular session.

[0067] Seeing this capability, the server tailors the SDP description to be sent to the client including the AVPF capability and the SupportedAdaptationSupport capability. The SDP description is shown in FIG. 2. The server does not include the SDP attributes based on the UnsupportedAdaptationSupport, because it does not have support for it. The bold lines in the SDP description indicate the usage of the AVPF and the support for SupportedAdaptationSupport.

[0068] By receiving this SDP description, the client knows that AVPF will be used for the video component, but not for the audio component. It is also possible that AVPF be used for both audio and video media components. In such a case, “a=x-avpfsupport” would be a session-level SDP attribute. Client also understands that UnsupportedAptationSupport will not be used and SupportedAdaptationSupport mechanism or capability will be used for both audio and video media.

[0069] B. Signalling and Negotiation via a Possible Multimedia Streaming Control Protocol:

[0070] In 3G PSS, RTSP protocol is used to control the multimedia session.

[0071] Let “x-avpfsupport” be a well-defined RTSP option tag, which indicates AVPF support on the client.

[0072] Let “x-unsupportedadaptationsupport” be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client. It is assumed that the mechanism represented by this tag is not supported by the server.

[0073] Let “x-supportedadaptationsupport” be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.

[0074] The client is assumed to know the RTSP URL for the multimedia session.

[0075] The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:

[0076] Client->Server:

[0077] DESCRIBE rtsp://foo/twister RTSP/1.0

[0078] CSeq: 1

[0079] Require: x-avpfsupport, x-unsupportedadaptationsupport, x-supportedadaptationsupport

[0080] The client uses the RTSP Require request header to signal the supported mechanisms or capabilities.

[0081] In order for the server to successfully tailor the SDP according to the mechanisms or capabilities supported by the client, the client signals the mechanisms or capabilities supported in an RTSP request prior to or at RTSP DESCRIBE method.

[0082] The server checks the RTSP request and sees that it can use x-avpfsupport and x-supportedadaptationsupport, but not x-unsupportedadaptationsupport.

[0083] The server has two possible ways to respond:

[0084] Alternative 1:

[0085] Server sends an RTSP 551 “Option Not Supported” Response, including the unsupported mechanisms and capabilities in the message body:

[0086] Server->Client

[0087] RTSP/1.0 551 Option not supported

[0088] CSeq: 1

[0089] Unsupported: x-unsupportedadaptationsupport

[0090] Client issues another DESCRIBE request with only the supported mechanisms or capabilities:

[0091] Client->Server:

[0092] DESCRIBE rtsp://foo/twister RTSP/1.0

[0093] CSeq: 2

[0094] Require: x-avpfsupport, x-supportedadaptationsupport

[0095] Server responds with an RTSP 200 OK message, also containing SDP description as shown in FIG. 3.

[0096] Alternative 2:

[0097] Server sends a RTSP DESCRIBE response, containing unsupported mechanism/capability information without an RTSP 551 status response. The RTSP DESCRIBE response is shown in FIG. 4.

[0098] Server uses RTSP Unsupported response header to signal the unsupported mechanism or the adaptation mechanisms or capabilities that are not possible to use for the particular session, and uses the appropriate SDP attributes to signal the usage of the selected adaptation mechanisms or capabilities.

[0099] When the client receives the DESCRIBE response with the SDP description, it knows which set of adaptation mechanisms or capabilities are selected for usage in this particular session.

[0100] In the case that the client receives the SDP description from another source, e.g. via MMS, the client can analyze the SDP description and find out the RTSP session URL. Then, it can send an RTSP DESCRIBE request to signal and negotiate the adaptation mechanisms or capabilities. The client can tailor the set of adaptation mechanisms or capabilities by analyzing the MMS retrieved SDP description beforehand. This solves the confusion on the server side, because the server does not exactly know the content of the SDP description in such a usage scenario.

[0101] II. RTP Retransmission Payload Format Usage in a Particular 3G PSS Session

[0102] Let the attribute “RtxSupport” be defined in the RDF Schema vocabulary to signal the usage of the RTP retransmission mechanism defined in draft-retransmission for audio and video media. RTX Support is automatically defined AVPF support on the client side.

[0103] Let the attribute “UnSupportedAdaptationSupport” be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is not supported by the server, but the client.

[0104] Let the attribute “SupportedAdaptationSupport” be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.

[0105] Let “x-rtxsupport” be a well-defined SDP attribute which is included in the audio and video (or the session-level for usage in both media types) media section of the SDP when RTP retransmission payload format is supported.

[0106] Let “x-unsupportedadaptationsupport” be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.

[0107] Let “x-supportedadaptationsupport” be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.

[0108] A. Signalling and Negotiation via a Possible Capability Exchange Mechanism

[0109] The client sends an RTSP DESCRIBE request to the server with a URI pointing to the client capability information residing in a capability exchange server.

[0110] The server fetches the capability declaration of the client from the capability exchange server. The declaration includes a part for the client-side streaming capabilities, as shown in FIG. 5.

[0111] The bold lines in the declaration represent the adaptation mechanism support capabilities of the client. RtxSupport, when TRUE, declares that the client has the RTP retransmission payload format support for audio and video media components in a particular session.

[0112] Seeing this capability, the server tailors the SDP description to be sent to the client, including the RTP Retransmission capability and the SupportedAdaptationSupport capability. The SDP description is shown in FIG. 6. The server does not include the SDP attributes based on the UnsupportedAdaptationSupport, because it does not have support for it. The bold lines in the SDP description indicate the usage of the RTP Retransmission payload format and the support for SupportedAdaptationSupport.

[0113] By receiving this SDP description, the client knows that RTP retransmission will be used for the video component, but not for the audio component. It also understands that UnsupportedadAptationSupport will not be used and SupportedAptationSupport mechanism or capability will be used for both audio and video media.

[0114] B. Signalling and Negotiation via a Possible Multimedia Streaming Control Protocol

[0115] In 3G PSS, RTSP protocol is used to control the multimedia session.

[0116] Let “x-rtxsupport” be a well-defined RTSP option tag, which indicates RTP retransmission payload format is supported by the client.

[0117] Let “x-unsupportedadaptationsupport” be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client. Assume that the mechanism or capability represented by this tag is not supported by the server.

[0118] Let “x-supportedadaptationsupport” be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.

[0119] The client is assumed to know the RTSP URL for the multimedia session.

[0120] The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:

[0121] Client->Server:

[0122] DESCRIBE rtsp://foo/twister RTSP/1.0

[0123] CSeq: 1

[0124] Require: x-rtxsupport, x-unsupportedadaptationsupport, x-supportedadaptationsupport

[0125] The client uses the RTSP Require request header to signal the supported adaptation mechanisms or capabilities.

[0126] In order for the server to successfully tailor the SDP according to the adaptation mechanisms or capabilities supported by the client, the client signals the adaptation mechanisms or capabilities supported in an RTSP request prior to or at RTSP DESCRIBE method.

[0127] The server checks the RTSP request and sees that it can use x-rtpsupport and x-supportedadaptationsupport, but not use x-unsupportedadaptationsupport.

[0128] The server has two possible ways to respond:

[0129] Alternative 1:

[0130] Server sends RTSP 551 “Option Not Supported” Response, including the unsupported mechanisms or capabilities in the message body.

[0131] Server->Client

[0132] RTSP/1.0 551 Option not supported

[0133] CSeq: 1

[0134] Unsupported: x-unsupportedadaptationsupport

[0135] Client issues another DESCRIBE request with only the supported mechanisms or capabilities:

[0136] Client->Server:

[0137] DESCRIBE rtsp://foo/twister RTSP/1.0

[0138] CSeq: 2

[0139] Require: x-rtxsupport, x-supportedadaptationsupport

[0140] Server responds with RTSP 200 OK message, also containing an SDP description as shown in FIG. 7.

[0141] Alternative 2:

[0142] Server sends an RTSP DESCRIBE response, containing unsupported mechanism/capability information without RTSP 551 status response. The RTSP DESCRIBE response is shown in FIG. 8.

[0143] The server uses RTSP Unsupported response header to signal the unsupported mechanism or the adaptation mechanisms or capabilities that are not possible to use for the particular session, and uses the appropriate SDP attributes to signal the usage of the selected adaptation mechanisms or capabilities.

[0144] When client receives the DESCRIBE response with the SDP description, it knows which set of adaptation mechanisms or capabilities are selected for usage in this particular session.

[0145] In the case that the client receives the SDP description from another source, e.g. via MMS, the client analyzes the SDP description and find out the RTSP session URL. Then, it sends an RTSP DESCRIBE request to signal and negotiate the adaptation mechanisms or capabilities. The client can tailor the set of adaptation mechanisms or capabilities by analyzing the MMS retrieved SDP description beforehand. This solves the confusion on the server side, because the server does not exactly know the content of the SDP description in such a usage scenario.

[0146] III. SRTP Usage in a Particular 3G PSS Session

[0147] Let the attribute “SRTPSupport”be defined in the RDF Schema vocabulary to signal the support of SRTP defined in draft-srtp-05 for audio and video media.

[0148] Let the attribute “UnSupportedAdaptationSupport” be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is supported by the client, but not by the server.

[0149] Let the attribute “SupportedAdaptationSupport” be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.

[0150] Let “x-srtpsupport” be a well-defined SDP attribute which is included in the audio and video (or the session-level for usage in both media types) media section of the SDP when SRTP is supported.

[0151] Let “x-unsupportedadaptationsupport” be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.

[0152] Let “x-supportedadaptationsupport” be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.

[0153] A. Signalling and Negotiation via a Possible Capability Exchange Mechanism

[0154] The client sends an RTSP DESCRIBE request to the server with a URI pointing to the client capability information residing in a capability exchange server.

[0155] The server fetches the capability declaration of the client from the capability exchange server. The declaration includes a part for the client-side streaming capabilities, as shown in FIG. 9. The bold lines in the declaration represent the adaptation mechanism support capabilities of the client. SRTPSupport, when TRUE, declares that the client has the SRTP support for audio and video media components in a particular session.

[0156] Seeing this capability, the server tailors the SDP description to be sent to the client including the SRTP capability and the SupportedAdaptationSupport capability. The SDP description is shown in FIG. 10. The server does not include the SDP attributes based on the UnsupportedAdaptationSupport, because it does not have support for it.

[0157] The bold lines in the SDP description indicate the usage of the SRTP and the support for SupportedAdaptationSupport.

[0158] By receiving this SDP description, the client knows that SRTP will be used for video and audio components. Client also understands that UnsupportedadAptationSupport is not going to be used and SupportedAptationSupport mechanism or capability will be used for both audio and video media.

[0159] B. Signalling and Negotiation via a Possible Multimedia Streaming Control Protocol

[0160] In 3G PSS, RTSP protocol is used to control the multimedia session.

[0161] Let “x-srtpsupport” be a well-defined RTSP option tag, which indicates SRTP support on the client.

[0162] Let “x-unsupportedadaptationsupport” be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client. Assume that the mechanism or capability represented by this tag is not supported by the server.

[0163] Let “x-supportedadaptationsupport” be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.

[0164] The client is assumed to know the RTSP URL for the multimedia session.

[0165] The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:

[0166] Client->Server:

[0167] DESCRIBE rtsp://foo/twister RTSP/1.0

[0168] CSeq: 1

[0169] Require: x-srtpsupport, x-unsupportedadaptationsupport, x-supportedadaptationsupport

[0170] The client uses the RTSP Require request header to signal the supported mechanisms or capabilities.

[0171] In order for the server to successfully tailor the SDP according to the mechanisms or capabilities supported by the client, the client signals the mechanisms or capabilities supported in an RTSP request prior to or at RTSP DESCRIBE method.

[0172] The server checks the RTSP request and sees that it can use x-srtpsupport and x-supportedadaptationsupport, but not x-unsupportedadaptationsupport.

[0173] The server has two possible ways to respond:

[0174] Alternative 1:

[0175] Server sends RTSP 551 “Option Not Supported” Response, including the unsupported mechanisms or capabilities in the message body.

[0176] Server->Client

[0177] RTSP/1.0 551 Option not supported

[0178] CSeq: 1

[0179] Unsupported: x-unsupportedadaptationsupport

[0180] Client issues another DESCRIBE request with only the supported mechanisms or capabilities:

[0181] Client->Server:

[0182] DESCRIBE rtsp://foo/twister RTSP/1.0

[0183] CSeq: 2

[0184] Require: x-srtpsupport, x-supportedadaptationsupport

[0185] Server responds with RTSP 200 OK message, also containing an SDP description as shown in FIG. 11.

[0186] ALTERNATIVE 2:

[0187] Server sends an RTSP DESCRIBE response, containing unsupported mechanism/capability information without RTSP 551 status response. The RTSP DESCRIBE response is shown in FIG. 12.

[0188] The server uses RTSP Unsupported response header to signal the unsupported mechanism or the adaptation mechanisms or capabilities that are not possible to use for the particular session, and uses the appropriate SDP attributes to signal the usage of the selected adaptation mechanisms or capabilities.

[0189] When client receives the DESCRIBE response with the SDP description, it knows which set of adaptation mechanisms or capabilities are selected for usage in this particular session.

[0190] In the case that the client receives the SDP description from another source, e.g. via MMS, the client analyzes the SDP description and find out the RTSP session URL. Then, it sends an RTSP DESCRIBE request to signal and negotiate the adaptation mechanisms or capabilities. The client can tailor the set of adaptation mechanisms or capabilities by analysing the MMS retrieved SDP description beforehand. This solves the confusion on the server side, because the server does not exactly know the content of the SDP description in such a usage scenario.

[0191] In sum, the present invention provides a method of signaling and negotiation between a client and a server in a multimedia streaming service system regarding the adaptation of a data delivery process. The procedure for the signaling and negotiation can be illustrated by FIG. 13. As shown in the flowchart in FIG. 13, in order to negotiate an adaptation mechanism or capability, the client signals to the server a plurality of attributes to the client at step 110. These attributes are those of the adaptation mechanisms or capabilities implemented by the client. The attributes are included either in client's capability profile defined for a capability exchange mechanism, or in the multimedia streaming control protocol defined for the control of the streaming session. At step 120, the server obtains the attributes from the capability profile or the multimedia streaming control protocol, and selects a subset of these attributes. Based on the selected attributes, the server tailors a multimedia session description and sends the description to the client at step 130. Based on the session description, the client knows the attributes selected by the server. At step 140, the client accepts the adaptation mechanisms or capabilities defined by the selected attributes at default. The signaling and negotiation method, according to the present invention, can be implemented in an AVPT usage, an RTP Retransmission Payload Format usage or an SPTP usage in a particular 3G PSS session.

[0192] It should be noted that the method of signaling and negotiation, according to the present invention, can also be initiated by the server, as illustrated in the flowchart shown in FIG. 14. As shown, the server indicates to the client, at step 210, the adaptation mechanism or capability without client's initiation. In this case, there is no indication of the adaptation mechanism or capability from the client side, but from the server side. After obtaining the indication from the server, the client uses a well-defined attribute in the RSTP response to indicate, at step 220, its support for that capability to the server.

[0193] Thus, although the invention has been described with respect to a preferred embodiment thereof, it will be understood by those skilled in the art that the foregoing and various other changes, omissions and deviations in the form and detail thereof may be made without departing from the scope of this invention.

Claims

1. A method for signaling and negotiation between a client and a server in a multimedia streaming service, wherein a plurality of adaptation mechanisms or capabilities for use in the service for data delivery are supported by the client, each adaptation mechanism or capability having an attribute, said method comprising:

the client providing information indicative of the attributes defining the adaptation mechanisms or capabilities that are supported by the client;

the server selecting one or more of the attributes based on the provided information; and

the server providing further information indicative of the selected attributes so as to allow the client to know the one or more adaptation mechanisms or capabilities defined by the one or more attributes selected by the server.

2. The method of claim 1, wherein the client provides the information via a capability exchange mechanism.

3. The method of claim 1, wherein the client provides the information via a multimedia streaming control protocol.

4. The method of claim 1, further comprising

the server providing indication of a capability to the client prior to the client providing information.

5. A method for signaling and negotiation between two parties including a client and a server in a multimedia streaming service, wherein a plurality of adaptation mechanisms or capabilities for use in the server for data delivery are supported by the client, each adaptation mechanism or capability having an attribute, said method comprising:

providing by one of the two parties to the other of the two parties information indicative of one or more adaptation mechanisms or capabilities; and

conveying a message from said other party to said party, in response to the information, acknowledging supporting of said one or more adaptation mechanisms or capabilities.

6. The method of claim 5, wherein said one party is the server and the other party is the client, and wherein

the client acknowledges support by using the attributes defining said one or more adaptation mechanisms or capabilities in the responding message.

7. The method of claim 5, wherein said one party is the client and the other party if the server, and wherein

the client provides a plurality of attributes; and

the server selects one or more of the provided attributes based on the provided information for acknowledging the support.