U.S. patent application number 10/779318 was filed with the patent office on 2004-10-07 for method for signaling streaming quality adaptation and control mechanisms in multimedia streaming.
This patent application is currently assigned to Nokia Corporation. Invention is credited to Aksu, Emre Baris, Curcio, Igor Danilo Diego, Leon, David, Varsa, Viktor, Wang, Ru-Shang.
Application Number | 20040196849 10/779318 |
Document ID | / |
Family ID | 32872992 |
Filed Date | 2004-10-07 |
United States Patent
Application |
20040196849 |
Kind Code |
A1 |
Aksu, Emre Baris ; et
al. |
October 7, 2004 |
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.
Inventors: |
Aksu, Emre Baris; (Tampere,
FI) ; Curcio, Igor Danilo Diego; (Tampere, FI)
; Leon, David; (Irving, TX) ; Varsa, Viktor;
(Irving, TX) ; Wang, Ru-Shang; (Coppell,
TX) |
Correspondence
Address: |
WARE FRESSOLA VAN DER SLUYS &
ADOLPHSON, LLP
BRADFORD GREEN BUILDING 5
755 MAIN STREET, P O BOX 224
MONROE
CT
06468
US
|
Assignee: |
Nokia Corporation
|
Family ID: |
32872992 |
Appl. No.: |
10/779318 |
Filed: |
February 13, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60447264 |
Feb 13, 2003 |
|
|
|
60448309 |
Feb 14, 2003 |
|
|
|
60448284 |
Feb 14, 2003 |
|
|
|
60448299 |
Feb 14, 2003 |
|
|
|
Current U.S.
Class: |
370/395.2 ;
709/231 |
Current CPC
Class: |
H04L 65/608 20130101;
H04N 21/6125 20130101; H04L 65/80 20130101; H04L 69/24 20130101;
H04L 67/322 20130101; H04L 47/263 20130101; H04N 21/6437 20130101;
H04N 21/6375 20130101; H04L 49/9078 20130101; H04L 65/607 20130101;
H04N 21/44004 20130101; H04L 67/42 20130101; H04N 21/643 20130101;
H04N 21/2401 20130101; H04L 69/329 20130101; H04L 47/6255 20130101;
H04L 29/06027 20130101; H04N 21/658 20130101; H04N 21/6373
20130101; H04L 65/4092 20130101; H04N 21/6332 20130101; H04L 47/10
20130101; H04N 21/6131 20130101; H04N 21/41407 20130101; H04L
65/4084 20130101; H04N 21/6377 20130101; H04N 21/2662 20130101 |
Class at
Publication: |
370/395.2 ;
709/231 |
International
Class: |
H04L 012/28; G06F
015/16; H04L 012/56 |
Claims
What is claimed is:
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.
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
SupportedAdaptationSupp- ort.
[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.
* * * * *