CA2515952A1 - Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming - Google Patents
Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming Download PDFInfo
- Publication number
- CA2515952A1 CA2515952A1 CA002515952A CA2515952A CA2515952A1 CA 2515952 A1 CA2515952 A1 CA 2515952A1 CA 002515952 A CA002515952 A CA 002515952A CA 2515952 A CA2515952 A CA 2515952A CA 2515952 A1 CA2515952 A1 CA 2515952A1
- Authority
- CA
- Canada
- Prior art keywords
- client
- server
- adaptation
- capabilities
- capability
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
- H04L47/263—Rate modification at the source after receiving feedback
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
- H04L47/6255—Queue scheduling characterised by scheduling criteria for service slots or service orders queue load conditions, e.g. longest queue first
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9063—Intermediate storage in different physical parts of a node or terminal
- H04L49/9078—Intermediate storage in different physical parts of a node or terminal using an external memory or storage device
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/752—Media network packet handling adapting media to network capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/756—Media network packet handling adapting media to device capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
- H04N21/2401—Monitoring of the client buffer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
- H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/633—Control signals issued by server directed to the network components or client
- H04N21/6332—Control signals issued by server directed to the network components or client directed to client
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/6437—Real-time Transport Protocol [RTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
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.
Retransmission Playload Format usage, and an SPTP usage in a particular 3G PSS
session.
Description
METHOD FOR SIGNALING STREAMING QUALITY ADAPTATION AND
CONTROL MECHANISMS IN MULTIMEDIA STREAMING
Field of the Invention The present invention relates generally to multimedia streaming and, more particularly, to signaling of streaming quality adaptation and control mechanism.
Background of the Invention In a multimedia streaming service, there are three participants involved: a streaming server, a streaming client and an underlying network which provides the comiectivity 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 netv,~ork 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.
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 3GhP
TS 26.234 V5.1.0, 'Transparent End-to-End Packet Switched Streaming Service (PSS)9 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 cleliverw ~~azta~~l mechanisms in the service must also be well-defined. Such mechanisms are used to aelcz~t the data delivery process in order to cause the changes of behavior in the underlying network characteristics.
Three possible adaptation processes based on the ~leeisive a~aata°o~
l~eati~fa of the adaptation mechanisms or capabilities are as follows:
Client-Driven Adaptation 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.
Server-Driven Adaptation CONFIRMATION COPY
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.
Cooperative Adaptation 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.
Within the service context, there may be more than one adaptation naechanisrra oY
capability defined within the context of each of the above-mentioned adaptati~n py~~cesses. It may be the case that each of these adaptation naeclaanisnas oa° capabilities is standardized within the service, but kept ~pti~raal for a server or client to implement.
Therefore, there is a certain need for a capability identification mechanism to identify the supported adaptation mechanisms or capabilities and an adaptati~fa capability si~nalin.~ and net-~tiati~n 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.
In prior art, Annex G of 3G PSS (Rel.S) defines a signaling mechanism, which can be used to signal the usage and support parameters, but this is not a complete solution.
Surmnary of the Invention 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.
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-knomn between the server and the client.
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:
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.
According to the present invention, the client provides the information via a capability exchange mechanism, or via a multimedia streaming control protocol.
Alternatively, the method comprises:
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 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.
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 Figure 1 shows a declaration by a client as part of the signaling and negotiation process, according to the present invention.
Figure 2 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the present invention.
Figure 3 shows the SDP description in an RTSP message sent by the server.
Figure 4 shows an RTSP DESCRIBE response sent by the server.
Figure 5 shows a declaration by the client as part of the signaling and negotiation process, according to another embodiment of the present invention.
Figure 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.
Figure 7 shows the SDP description in an RTSP message sent by the server.
Figure g shows an RTSP DESCRIBE response sent by the server.
Figure 9 shows a declaration by the client as part of the signaling and negotiation process, according to yet another embodiment of the present invention.
Figure 10 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the present invention.
Figure 11 shows the SDP description in an RTSP message sent by the server.
Figure 12 shows an RTSP DESCRIBE response sent by the server.
Figure 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.
Figure 14. is a flowchart illustrating the method of signaling and negotiation wherein the 8ertyer lnltlates the negotiate~n.
Detailed Descripti~n of the Invention 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.
When the signaling and negotiation is carried out via a capability exchange mechanism, the procedure is described as follows:
- 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;
- The server obtains the capability profile;
- 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 - Based on the session description, the client knows the adaptation mechanism or capability selection carned 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.
When the signaling and negotiation is carried out via a multimedia streaming control protocol, the procedure is described as follows:
- The client includes the attributes of the adaptation mechanism or capability implemented by the client in the IVlultimedia Streaming Control Protocol defined for the control of the streaming session;
- 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 - 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.
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:
- 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);
- an RTP Retransmission Payload Format usage in a particular 3G PSS session (see, for example, IETF dradt-ietf avt-rpt-retransmission-O5: "RTP
Retransmission Payload Format", Rey et al., 2002, hereafter referred to as df-aft-retransmission-OS); and - an SPTP usage in a particular 3G PSS session (see, for example, IETF draft-ietf avt-srtp-O5: "The Secure Real-time Transport Protocol", Eaugher et al., 2002, hereafter referred to as dr°aft-srtp-OS).
I. AVPF usage in a particular 3G PSS session 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 draf °t-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.
Let the attribute "AI~PFSupport" be defined in the RDF (Resource Description Framework) Schema vocabulary to signal the support of AVPF defined in da°aft-eavpf 04 for audio and video media.
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.
Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.
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.
Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute, which is included in the SDP (session or media level) when supported.
Let "x-supportedadaptationsupport" be a well-defined SDP attribute, which is included in the SDP (session or media level) when supported.
A. Signalling and negotiation via a possible capacity exchange mechanism:
- 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.
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 Figure 1.
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 AVPFSupp~rt is TRUE, it declares that the client has the AVPF
support for audio and video media components in a particular session.
Seeing this capability, the server tailors the SDP description to be sent to the client including the AVPF capability and the ~~app~rted~daptati~n~~app~rt capability.
The SDP
description is shown in Figure 2. The server does not include the SDP
attributes based on the Uns~app~rted~daptati~n~~app~rt, 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 ~~app~rted~d~ptati~n~~app~rt.
By receiving this SDP description, the client l~nows 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=~z-avpfsupp~rt"
~5 would be a session-level SDP attribute. Client also understands that Unsupp~rtedAptati~n~upp~rt will not be used aald Suapp~rted~dapfati~nSu~pp~rt mechanism or capability will be used for both audio and video media.
B. Signalling and negotiation via a possible Multimedia Streaming Control Protocol:
In 3G PSS, RTSP protocol is used to control the multimedia session.
Let "x-avpfsupport" be a well-defined RTSP option tag, which indicates AVPF
support on the client.
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.
Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.
The client is assumed to know the RTSP URL for the multimedia session.
- The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:
Client->Server:
DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 Require: x-avpfsupport, x-unsupportedadaptationsupport, ~e-supportedadaptationsupport - The client uses the R7f~P Reqtaia-e request header to signal the supported meehezyaisnzs ~~ capabilites.
- In order for the server to successfully tailor the SDP according to the mechanisms or capabilities supported by the client9 the client signals the mechanisms or capabilities supported in an RTSP request prior to or at RTSP DESCRIES method.
- The server checks the RTSP request and sees that it can use x-avpfisupport and x-supportedadaptaiionsupport, but not x-unsupportedadaptationsupport.
The server has two possible ways to respond:
ALTERNATIVE 1:
- Server sends an RTSP 551 "~ption Not Supported" Response, including the unsupported mechanisms and capabilities in the message body:
Server->Client RTSP/1.0 551 Option not supported CSeq: 1 Unsupported: x-unsupportedadaptationsupport - Client issues another DESCRIBE request with only the supported mechanisms or capabilities:
Client->Server DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 2 Require: x-avpfsupport, x-supportedadaptationsupport - Semer responds with an RTSP 200 OK message, also containing SDP description as shown in Figure 3.
ALTERNATIVE 2:
- Server sends a RTSP DESCRIBE response, containing unsupported mechanism/capability information without an RTSP 551 status response. The RTSP
DESCRIDE response is shown in Figure 4..
- Server uses RTSP ITr~supp0a Eed 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.
- 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.
In the case that the client receives the SDP description from another source, e.g.
via I~IIliIS9 the client can analyze the SDP description and find out the RTSP
session LTRI,.
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 S 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.
II. RTP Retransmission Payload Format usa a in a particular 3G PSS session 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.
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.
Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.
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 fornlat is supported.
Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.
Let "x-supportedadaptationsupport" be a well-defined SDP attribute which is included in the SDP (session or media level) when suppouted.
A. Signalling and Negotiation via a Possible Capability Exchange leilechanism 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.
The server fetches the capability declaration of the client from the capability exchange server. The declaration includes a pant for the client-side streaming capabilities, as shown in Figure 5.
The bold lines in the declaration represent the adaptation mechanism support capabilities of the client. Rt~Support, when TRUE, declares that the client has the RTP
retransmission payload format support for audio and video media components in a particular session.
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 Figure 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.
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.
B. Signalling and Negotiation via a possible Multimedia Streaming Control Protocol In 3G PSS, RTSP protocol is used to control the multimedia session.
Let "x-rtxsupport" be a well-defined RTSP option tag, which indicates RTP
retransmission payload format is supported by the client.
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.
Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.
The client is assumed to lcnow the RTSP LJRL for the multimedia session.
The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:
?0 Client->Server ~ESGRIEE rasp://fioo/twister RTSP/~ .0 CSeq: 1 f~equire: s~-rt~~support, ~;-unsupportedadaptationsupport, ~;-supportedadaptationsupport The client uses the RTSP Require request header to signal the supported adalatati~ya naeelcaraisms oy~ capezbilities.
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.
The server checks the RTSP request and sees that it can use x-rtpsupport and x-supportedadaptationsupport, but not use x-unsupportedadaptationsupport.
The server has two possible ways to respond:
ALTERNATIVE 1:
- Server sends RTSP 551 "Option Not Supported" Response, including the unsupported mechanisms or capabilities in the message body.
Server->Client RTSP/1.0 551 Option not supported CSeq: 1 Unsupported: x-unsupportedadaptationsupport - Client issues another DESCRIBE request with only the supported mechanisms or capabilities:
Client->Server DESCRIES rtsp://foo/twister RTSP/1.0 CSeq: ~
I~e~uire: x-rtxsupport, gs-supportedadaptationsupport - Server responds with RTSP 200 ~I~ lrlessage, also contamlng an SDP
description as shown in Figure 7.
ALTERNATIVE 2:
- Server sends an RTSP DESCRIBE response, containing unsupported mechanism/capability information without RTSP 551 status response. The RTSP
DESCRIBE response is shown in Figure ~.
- 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.
- When client receives the DESCR1BE response with the SDP description, it knows which set of adaptation mechanisms or capabilities are selected for usage in this particular session.
In the case that the client receives the SDP description from another source, e.g.
via M1VIS, 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.
III. SRTP usa e~particular 3G PSS session Let the attribute "SRTPSupport" be defined in the RDF Schema vocabulary to signal the support of SRTP defined in daft-sf°tp-OS for audio and video media.
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.
Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.
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.
Let "ac-unsupportedadaptationsupport" be a well-defined SDP attribute wl2ich is included in the SDP (session or media level) when supported.
Let "~-supportedadaptationsupport" be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.
A. Signalling and Negotiation via a Possible Capability Exchange l~Iechanism - The client sends an RTSP DESCRIBE request to the server with a ZTRI pointing to the client capability information residing in a capability exchange server.
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 Figure 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.
- 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 Figure 10. 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 SRTP and the support for SupportedAdaptationSupport.
- 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.
B. Signalling and Negotiation via a possible Multimedia Streaming Control Protocol In 3G PSS, RTSP protocol is used to control the multimedia session.
Let "x-srtpsupport" be a well-defined RTSP option tag, which indicates SRTP
support on the client.
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.
Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.
The client is assumed to know the RTSP LTRL for the multimedia session.
- The client sends a DESCRIBE request with the selection ~f preferred adaptation mechanisms or capabilities:
Client->Server ~ESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 Require: x-srtpsuppori;, x-unsupportedadaptationsupport, ~-supportedadaptationsupport - The client uses the RTSP Require request header to signal the supported mechanisms or capabilities.
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.
- The server checks the RTSP request and sees that it can use x-srtpsupport and x-supportedadaptationsupport, but not x-unsupportedadaptationsupport.
The server has two possible ways to respond:
ALTERNATIVE 1:
- Server sends RTSP 551 "Option Not Supported" Response, including the unsupported mechanisms or capabilities in the message body.
Server->Client RTSP/1.0 551 Option not supported GSeq: 1 Unsupported: ac-unsupportedadaptationsupport - Client issues another DESCRIBE request with only the supported mechanisms or capabilities:
Client->Server :
~ESCRIBE rtsp://foo/twisier RTSP/1.0 Cseq: 2 I~equir~: x-srtpsupport, 5~-support~dadaptationsupport - Server responds with RTSP 200 ~I~ message also containing an SDP descuiption as shown in Figurc 11.
ALTERNATIVE 2:
- Server sends an RTSP DESCRIBE response, containing unsupported mechanism/capabilitiy information without RTSP 551 status response. The RTSP
DESCRIBE response is shown in Figure 12.
- 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.
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.
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.
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 Figure 13. As shown in the flowchart in Figure 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 sheaming 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.
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 Figure 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.
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.
CONTROL MECHANISMS IN MULTIMEDIA STREAMING
Field of the Invention The present invention relates generally to multimedia streaming and, more particularly, to signaling of streaming quality adaptation and control mechanism.
Background of the Invention In a multimedia streaming service, there are three participants involved: a streaming server, a streaming client and an underlying network which provides the comiectivity 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 netv,~ork 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.
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 3GhP
TS 26.234 V5.1.0, 'Transparent End-to-End Packet Switched Streaming Service (PSS)9 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 cleliverw ~~azta~~l mechanisms in the service must also be well-defined. Such mechanisms are used to aelcz~t the data delivery process in order to cause the changes of behavior in the underlying network characteristics.
Three possible adaptation processes based on the ~leeisive a~aata°o~
l~eati~fa of the adaptation mechanisms or capabilities are as follows:
Client-Driven Adaptation 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.
Server-Driven Adaptation CONFIRMATION COPY
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.
Cooperative Adaptation 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.
Within the service context, there may be more than one adaptation naechanisrra oY
capability defined within the context of each of the above-mentioned adaptati~n py~~cesses. It may be the case that each of these adaptation naeclaanisnas oa° capabilities is standardized within the service, but kept ~pti~raal for a server or client to implement.
Therefore, there is a certain need for a capability identification mechanism to identify the supported adaptation mechanisms or capabilities and an adaptati~fa capability si~nalin.~ and net-~tiati~n 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.
In prior art, Annex G of 3G PSS (Rel.S) defines a signaling mechanism, which can be used to signal the usage and support parameters, but this is not a complete solution.
Surmnary of the Invention 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.
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-knomn between the server and the client.
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:
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.
According to the present invention, the client provides the information via a capability exchange mechanism, or via a multimedia streaming control protocol.
Alternatively, the method comprises:
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 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.
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 Figure 1 shows a declaration by a client as part of the signaling and negotiation process, according to the present invention.
Figure 2 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the present invention.
Figure 3 shows the SDP description in an RTSP message sent by the server.
Figure 4 shows an RTSP DESCRIBE response sent by the server.
Figure 5 shows a declaration by the client as part of the signaling and negotiation process, according to another embodiment of the present invention.
Figure 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.
Figure 7 shows the SDP description in an RTSP message sent by the server.
Figure g shows an RTSP DESCRIBE response sent by the server.
Figure 9 shows a declaration by the client as part of the signaling and negotiation process, according to yet another embodiment of the present invention.
Figure 10 shows the SDP description sent by the server to indicate the selected attributes to the client, according to the present invention.
Figure 11 shows the SDP description in an RTSP message sent by the server.
Figure 12 shows an RTSP DESCRIBE response sent by the server.
Figure 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.
Figure 14. is a flowchart illustrating the method of signaling and negotiation wherein the 8ertyer lnltlates the negotiate~n.
Detailed Descripti~n of the Invention 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.
When the signaling and negotiation is carried out via a capability exchange mechanism, the procedure is described as follows:
- 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;
- The server obtains the capability profile;
- 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 - Based on the session description, the client knows the adaptation mechanism or capability selection carned 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.
When the signaling and negotiation is carried out via a multimedia streaming control protocol, the procedure is described as follows:
- The client includes the attributes of the adaptation mechanism or capability implemented by the client in the IVlultimedia Streaming Control Protocol defined for the control of the streaming session;
- 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 - 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.
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:
- 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);
- an RTP Retransmission Payload Format usage in a particular 3G PSS session (see, for example, IETF dradt-ietf avt-rpt-retransmission-O5: "RTP
Retransmission Payload Format", Rey et al., 2002, hereafter referred to as df-aft-retransmission-OS); and - an SPTP usage in a particular 3G PSS session (see, for example, IETF draft-ietf avt-srtp-O5: "The Secure Real-time Transport Protocol", Eaugher et al., 2002, hereafter referred to as dr°aft-srtp-OS).
I. AVPF usage in a particular 3G PSS session 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 draf °t-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.
Let the attribute "AI~PFSupport" be defined in the RDF (Resource Description Framework) Schema vocabulary to signal the support of AVPF defined in da°aft-eavpf 04 for audio and video media.
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.
Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.
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.
Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute, which is included in the SDP (session or media level) when supported.
Let "x-supportedadaptationsupport" be a well-defined SDP attribute, which is included in the SDP (session or media level) when supported.
A. Signalling and negotiation via a possible capacity exchange mechanism:
- 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.
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 Figure 1.
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 AVPFSupp~rt is TRUE, it declares that the client has the AVPF
support for audio and video media components in a particular session.
Seeing this capability, the server tailors the SDP description to be sent to the client including the AVPF capability and the ~~app~rted~daptati~n~~app~rt capability.
The SDP
description is shown in Figure 2. The server does not include the SDP
attributes based on the Uns~app~rted~daptati~n~~app~rt, 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 ~~app~rted~d~ptati~n~~app~rt.
By receiving this SDP description, the client l~nows 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=~z-avpfsupp~rt"
~5 would be a session-level SDP attribute. Client also understands that Unsupp~rtedAptati~n~upp~rt will not be used aald Suapp~rted~dapfati~nSu~pp~rt mechanism or capability will be used for both audio and video media.
B. Signalling and negotiation via a possible Multimedia Streaming Control Protocol:
In 3G PSS, RTSP protocol is used to control the multimedia session.
Let "x-avpfsupport" be a well-defined RTSP option tag, which indicates AVPF
support on the client.
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.
Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.
The client is assumed to know the RTSP URL for the multimedia session.
- The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:
Client->Server:
DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 Require: x-avpfsupport, x-unsupportedadaptationsupport, ~e-supportedadaptationsupport - The client uses the R7f~P Reqtaia-e request header to signal the supported meehezyaisnzs ~~ capabilites.
- In order for the server to successfully tailor the SDP according to the mechanisms or capabilities supported by the client9 the client signals the mechanisms or capabilities supported in an RTSP request prior to or at RTSP DESCRIES method.
- The server checks the RTSP request and sees that it can use x-avpfisupport and x-supportedadaptaiionsupport, but not x-unsupportedadaptationsupport.
The server has two possible ways to respond:
ALTERNATIVE 1:
- Server sends an RTSP 551 "~ption Not Supported" Response, including the unsupported mechanisms and capabilities in the message body:
Server->Client RTSP/1.0 551 Option not supported CSeq: 1 Unsupported: x-unsupportedadaptationsupport - Client issues another DESCRIBE request with only the supported mechanisms or capabilities:
Client->Server DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 2 Require: x-avpfsupport, x-supportedadaptationsupport - Semer responds with an RTSP 200 OK message, also containing SDP description as shown in Figure 3.
ALTERNATIVE 2:
- Server sends a RTSP DESCRIBE response, containing unsupported mechanism/capability information without an RTSP 551 status response. The RTSP
DESCRIDE response is shown in Figure 4..
- Server uses RTSP ITr~supp0a Eed 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.
- 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.
In the case that the client receives the SDP description from another source, e.g.
via I~IIliIS9 the client can analyze the SDP description and find out the RTSP
session LTRI,.
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 S 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.
II. RTP Retransmission Payload Format usa a in a particular 3G PSS session 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.
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.
Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.
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 fornlat is supported.
Let "x-unsupportedadaptationsupport" be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.
Let "x-supportedadaptationsupport" be a well-defined SDP attribute which is included in the SDP (session or media level) when suppouted.
A. Signalling and Negotiation via a Possible Capability Exchange leilechanism 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.
The server fetches the capability declaration of the client from the capability exchange server. The declaration includes a pant for the client-side streaming capabilities, as shown in Figure 5.
The bold lines in the declaration represent the adaptation mechanism support capabilities of the client. Rt~Support, when TRUE, declares that the client has the RTP
retransmission payload format support for audio and video media components in a particular session.
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 Figure 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.
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.
B. Signalling and Negotiation via a possible Multimedia Streaming Control Protocol In 3G PSS, RTSP protocol is used to control the multimedia session.
Let "x-rtxsupport" be a well-defined RTSP option tag, which indicates RTP
retransmission payload format is supported by the client.
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.
Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.
The client is assumed to lcnow the RTSP LJRL for the multimedia session.
The client sends a DESCRIBE request with the selection of preferred adaptation mechanisms or capabilities:
?0 Client->Server ~ESGRIEE rasp://fioo/twister RTSP/~ .0 CSeq: 1 f~equire: s~-rt~~support, ~;-unsupportedadaptationsupport, ~;-supportedadaptationsupport The client uses the RTSP Require request header to signal the supported adalatati~ya naeelcaraisms oy~ capezbilities.
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.
The server checks the RTSP request and sees that it can use x-rtpsupport and x-supportedadaptationsupport, but not use x-unsupportedadaptationsupport.
The server has two possible ways to respond:
ALTERNATIVE 1:
- Server sends RTSP 551 "Option Not Supported" Response, including the unsupported mechanisms or capabilities in the message body.
Server->Client RTSP/1.0 551 Option not supported CSeq: 1 Unsupported: x-unsupportedadaptationsupport - Client issues another DESCRIBE request with only the supported mechanisms or capabilities:
Client->Server DESCRIES rtsp://foo/twister RTSP/1.0 CSeq: ~
I~e~uire: x-rtxsupport, gs-supportedadaptationsupport - Server responds with RTSP 200 ~I~ lrlessage, also contamlng an SDP
description as shown in Figure 7.
ALTERNATIVE 2:
- Server sends an RTSP DESCRIBE response, containing unsupported mechanism/capability information without RTSP 551 status response. The RTSP
DESCRIBE response is shown in Figure ~.
- 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.
- When client receives the DESCR1BE response with the SDP description, it knows which set of adaptation mechanisms or capabilities are selected for usage in this particular session.
In the case that the client receives the SDP description from another source, e.g.
via M1VIS, 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.
III. SRTP usa e~particular 3G PSS session Let the attribute "SRTPSupport" be defined in the RDF Schema vocabulary to signal the support of SRTP defined in daft-sf°tp-OS for audio and video media.
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.
Let the attribute "SupportedAdaptationSupport" be defined in the RDF Schema vocabulary as an adaptation mechanism or capability, which is also supported by the server.
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.
Let "ac-unsupportedadaptationsupport" be a well-defined SDP attribute wl2ich is included in the SDP (session or media level) when supported.
Let "~-supportedadaptationsupport" be a well-defined SDP attribute which is included in the SDP (session or media level) when supported.
A. Signalling and Negotiation via a Possible Capability Exchange l~Iechanism - The client sends an RTSP DESCRIBE request to the server with a ZTRI pointing to the client capability information residing in a capability exchange server.
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 Figure 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.
- 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 Figure 10. 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 SRTP and the support for SupportedAdaptationSupport.
- 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.
B. Signalling and Negotiation via a possible Multimedia Streaming Control Protocol In 3G PSS, RTSP protocol is used to control the multimedia session.
Let "x-srtpsupport" be a well-defined RTSP option tag, which indicates SRTP
support on the client.
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.
Let "x-supportedadaptationsupport" be a well-defined RTSP option tag, which is signalled in the RTSP message when supported by the client.
The client is assumed to know the RTSP LTRL for the multimedia session.
- The client sends a DESCRIBE request with the selection ~f preferred adaptation mechanisms or capabilities:
Client->Server ~ESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 Require: x-srtpsuppori;, x-unsupportedadaptationsupport, ~-supportedadaptationsupport - The client uses the RTSP Require request header to signal the supported mechanisms or capabilities.
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.
- The server checks the RTSP request and sees that it can use x-srtpsupport and x-supportedadaptationsupport, but not x-unsupportedadaptationsupport.
The server has two possible ways to respond:
ALTERNATIVE 1:
- Server sends RTSP 551 "Option Not Supported" Response, including the unsupported mechanisms or capabilities in the message body.
Server->Client RTSP/1.0 551 Option not supported GSeq: 1 Unsupported: ac-unsupportedadaptationsupport - Client issues another DESCRIBE request with only the supported mechanisms or capabilities:
Client->Server :
~ESCRIBE rtsp://foo/twisier RTSP/1.0 Cseq: 2 I~equir~: x-srtpsupport, 5~-support~dadaptationsupport - Server responds with RTSP 200 ~I~ message also containing an SDP descuiption as shown in Figurc 11.
ALTERNATIVE 2:
- Server sends an RTSP DESCRIBE response, containing unsupported mechanism/capabilitiy information without RTSP 551 status response. The RTSP
DESCRIBE response is shown in Figure 12.
- 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.
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.
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.
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 Figure 13. As shown in the flowchart in Figure 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 sheaming 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.
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 Figure 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.
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 (7)
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 characterized by:
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.
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, characterized in that the client provides the information via a capability exchange mechanism.
3. The method of claim 1, characterized in that the client provides the information via a multimedia streaming control protocol.
4. The method of claim 1, further characterized by 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 characterized by:
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.
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, characterized in that said one party is the server and the other party is the client, and that 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, characterized in that said one party is the client and the other party if the server, and that 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.
Applications Claiming Priority (9)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US44726403P | 2003-02-13 | 2003-02-13 | |
US60/447,264 | 2003-02-13 | ||
US44830903P | 2003-02-14 | 2003-02-14 | |
US44828403P | 2003-02-14 | 2003-02-14 | |
US44829903P | 2003-02-14 | 2003-02-14 | |
US60/448,299 | 2003-02-14 | ||
US60/448,309 | 2003-02-14 | ||
US60/448,284 | 2003-02-14 | ||
PCT/IB2004/000374 WO2004072765A2 (en) | 2003-02-13 | 2004-02-13 | Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2515952A1 true CA2515952A1 (en) | 2004-08-26 |
Family
ID=32872992
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002515952A Abandoned CA2515952A1 (en) | 2003-02-13 | 2004-02-13 | Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming |
Country Status (6)
Country | Link |
---|---|
US (3) | US7558869B2 (en) |
EP (3) | EP1593047A4 (en) |
JP (2) | JP2006525693A (en) |
KR (1) | KR100759954B1 (en) |
CA (1) | CA2515952A1 (en) |
WO (3) | WO2004072764A2 (en) |
Families Citing this family (154)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2849733A1 (en) * | 2003-01-02 | 2004-07-09 | Thomson Licensing Sa | DEVICE AND METHOD FOR ADJUSTING THE FLOW OF A CONTENT FLOW AND RELATED PRODUCTS |
WO2004072764A2 (en) * | 2003-02-13 | 2004-08-26 | Nokia Corporation | Method for signaling client rate capacity in multimedia streaming |
JP3825007B2 (en) * | 2003-03-11 | 2006-09-20 | 沖電気工業株式会社 | Jitter buffer control method |
GB0306973D0 (en) * | 2003-03-26 | 2003-04-30 | British Telecomm | Transmitting video |
US7054774B2 (en) * | 2003-06-27 | 2006-05-30 | Microsoft Corporation | Midstream determination of varying bandwidth availability |
US20050091395A1 (en) * | 2003-10-08 | 2005-04-28 | Jason Harris | Method and system for transferring data files |
JP2005244525A (en) * | 2004-02-25 | 2005-09-08 | Fujitsu Ltd | Communication system |
GB0406901D0 (en) * | 2004-03-26 | 2004-04-28 | British Telecomm | Transmitting recorded material |
FI117313B (en) * | 2004-04-05 | 2006-08-31 | Nokia Corp | Message handling method in telecommunication system, involves obtaining capability data relating to client terminal and checking whether obtained data comprises upper-level application that is supported by client terminal |
US7616587B1 (en) | 2004-04-14 | 2009-11-10 | Marvell International Ltd. | Methods and apparatus for performing reverse auto-negotiation in network communication |
US7162533B2 (en) * | 2004-04-30 | 2007-01-09 | Microsoft Corporation | Session description message extensions |
US8868772B2 (en) * | 2004-04-30 | 2014-10-21 | Echostar Technologies L.L.C. | Apparatus, system, and method for adaptive-rate shifting of streaming content |
US7818444B2 (en) | 2004-04-30 | 2010-10-19 | Move Networks, Inc. | Apparatus, system, and method for multi-bitrate content streaming |
US7542435B2 (en) * | 2004-05-12 | 2009-06-02 | Nokia Corporation | Buffer level signaling for rate adaptation in multimedia streaming |
EP1745609B1 (en) * | 2004-05-12 | 2013-06-26 | Nokia Corporation | Buffer level signaling for rate adaptation in multimedia streaming |
US7839844B2 (en) * | 2004-07-30 | 2010-11-23 | Sony Corporation | System and method for dynamically determining retransmit buffer time |
US7643503B2 (en) * | 2004-07-30 | 2010-01-05 | Sony Corporation | System and method for dynamically determining retransmit buffer time |
US7433319B2 (en) * | 2004-10-27 | 2008-10-07 | At&T Intellectual Property I, L.P. | System and method for collecting and presenting service level agreement metrics in a switched metro ethernet network |
US20060184697A1 (en) * | 2005-02-11 | 2006-08-17 | Microsoft Corporation | Detecting clock drift in networked devices through monitoring client buffer fullness |
US8370514B2 (en) | 2005-04-28 | 2013-02-05 | DISH Digital L.L.C. | System and method of minimizing network bandwidth retrieved from an external network |
US8683066B2 (en) | 2007-08-06 | 2014-03-25 | DISH Digital L.L.C. | Apparatus, system, and method for multi-bitrate content streaming |
JP4274149B2 (en) * | 2005-05-19 | 2009-06-03 | ソニー株式会社 | Content playback apparatus and content playback method |
US7743183B2 (en) | 2005-05-23 | 2010-06-22 | Microsoft Corporation | Flow control for media streaming |
EP1900118B1 (en) * | 2005-06-21 | 2014-04-09 | LG Electronics Inc. | Terminal, method and system for performing combination service using terminal capability version |
CN101218579B (en) | 2005-07-11 | 2012-12-19 | 派克维迪奥公司 | System and method for transferring data |
US7676591B2 (en) * | 2005-09-22 | 2010-03-09 | Packet Video Corporation | System and method for transferring multiple data channels |
US7720970B2 (en) * | 2005-09-30 | 2010-05-18 | Microsoft Corporation | Method for processing received networking traffic while playing audio/video or other media |
US20070156770A1 (en) * | 2005-10-18 | 2007-07-05 | Joel Espelien | System and method for controlling and/or managing metadata of multimedia |
US7900818B2 (en) * | 2005-11-14 | 2011-03-08 | Packetvideo Corp. | System and method for accessing electronic program guide information and media content from multiple locations using mobile devices |
US8214516B2 (en) * | 2006-01-06 | 2012-07-03 | Google Inc. | Dynamic media serving infrastructure |
US8234397B2 (en) * | 2006-01-06 | 2012-07-31 | Google Inc. | Media article adaptation to client device |
US9432729B2 (en) * | 2006-02-08 | 2016-08-30 | Thomson Licensing | Method and apparatus for adaptive transport injection for playback |
EP3641239B1 (en) * | 2006-02-10 | 2022-08-03 | III Holdings 2, LLC | System and method for connecting mobile devices |
US7965771B2 (en) | 2006-02-27 | 2011-06-21 | Cisco Technology, Inc. | Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network |
US8218654B2 (en) | 2006-03-08 | 2012-07-10 | Cisco Technology, Inc. | Method for reducing channel change startup delays for multicast digital video streams |
US8874645B2 (en) * | 2006-03-28 | 2014-10-28 | Packetvideo Corp. | System and method for sharing an experience with media content between multiple devices |
WO2007112111A2 (en) * | 2006-03-29 | 2007-10-04 | Packetvideo Corp. | System and method for securing content ratings |
CN101047705B (en) * | 2006-03-31 | 2013-01-30 | 华为技术有限公司 | Report process method, server for customer agent file information and its customer terminal |
US20070258418A1 (en) * | 2006-05-03 | 2007-11-08 | Sprint Spectrum L.P. | Method and system for controlling streaming of media to wireless communication devices |
DE102006021846A1 (en) * | 2006-05-10 | 2007-11-22 | Benq Mobile Gmbh & Co. Ohg | Receive device for block-based reception of files, transmission device for block-based transfer of files, system for data transmission, method for block-based reception of a file and method for block-based transmission of a file |
US8139566B2 (en) * | 2006-07-21 | 2012-03-20 | Cisco Technology, Inc. | System and method for establishing a communication session between two endpoints that do not both support secure media |
US20080037489A1 (en) * | 2006-08-10 | 2008-02-14 | Ahmed Adil Yitiz | System and method for intelligent media recording and playback on a mobile device |
WO2008021091A2 (en) * | 2006-08-11 | 2008-02-21 | Packetvideo Corp. | 'system and method for delivering interactive audiovisual experiences to portable devices' |
US7680099B2 (en) * | 2006-08-22 | 2010-03-16 | Nokia Corporation | Jitter buffer adjustment |
US8031701B2 (en) * | 2006-09-11 | 2011-10-04 | Cisco Technology, Inc. | Retransmission-based stream repair and stream join |
US7733773B2 (en) * | 2006-10-18 | 2010-06-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Playout based delay scheduler |
US7962637B2 (en) * | 2006-11-03 | 2011-06-14 | Apple Computer, Inc. | Dynamic adjustments of video streams |
US20080107108A1 (en) * | 2006-11-03 | 2008-05-08 | Nokia Corporation | System and method for enabling fast switching between psse channels |
US8959239B2 (en) * | 2006-12-29 | 2015-02-17 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for reporting streaming media quality |
JP4701189B2 (en) * | 2007-01-19 | 2011-06-15 | 富士通株式会社 | Data processing apparatus, data processing method, and data processing program |
US7937531B2 (en) * | 2007-02-01 | 2011-05-03 | Cisco Technology, Inc. | Regularly occurring write back scheme for cache soft error reduction |
US8769591B2 (en) | 2007-02-12 | 2014-07-01 | Cisco Technology, Inc. | Fast channel change on a bandwidth constrained network |
KR100860076B1 (en) | 2007-02-22 | 2008-09-24 | 한국전자통신연구원 | Apparatus and method for the replacement of cache for streaming service in the proxy server |
US7940644B2 (en) * | 2007-03-14 | 2011-05-10 | Cisco Technology, Inc. | Unified transmission scheme for media stream redundancy |
US20080253369A1 (en) | 2007-04-16 | 2008-10-16 | Cisco Technology, Inc. | Monitoring and correcting upstream packet loss |
JP4325697B2 (en) * | 2007-04-17 | 2009-09-02 | ソニー株式会社 | Image processing system, image processing apparatus, image processing method, and program |
EP2160906B1 (en) * | 2007-06-19 | 2015-07-22 | Nokia Technologies Oy | System and method for an MBMS to PSS handover |
WO2009025747A1 (en) * | 2007-08-21 | 2009-02-26 | Packetvideo Corp. | Mobile media router and method for using same |
US8190750B2 (en) * | 2007-08-24 | 2012-05-29 | Alcatel Lucent | Content rate selection for media servers with proxy-feedback-controlled frame transmission |
US8238900B2 (en) * | 2007-08-30 | 2012-08-07 | Motorola Mobility Llc | Management of anticipated data outages in a Push-to-X communication system |
US8464053B2 (en) * | 2007-09-05 | 2013-06-11 | Radvision Ltd | Systems, methods, and media for retransmitting data using the secure real-time transport protocol |
WO2009035578A1 (en) * | 2007-09-11 | 2009-03-19 | Packetvideo Corp. | System and method for virtual storage for media service on a portable device |
US8346959B2 (en) | 2007-09-28 | 2013-01-01 | Sharp Laboratories Of America, Inc. | Client-controlled adaptive streaming |
FR2922401B1 (en) * | 2007-10-10 | 2010-04-16 | Sagem Comm | DEVICE FOR CONTINUOUSLY RECEIVING AUDIO AND / OR VIDEO DATA PACKETS |
CA2703676A1 (en) * | 2007-10-25 | 2009-04-30 | Nokia Corporation | System and method for re-synchronization of a pss session to an mbms session |
US7895629B1 (en) * | 2007-11-07 | 2011-02-22 | At&T Mobility Ii Llc | Video service buffer management in a mobile rate control enabled network |
US8065325B2 (en) * | 2007-12-12 | 2011-11-22 | Packet Video Corp. | System and method for creating metadata |
EP3503008A1 (en) * | 2007-12-12 | 2019-06-26 | III Holdings 2, LLC | System and method for generating a recommendation on a mobile device |
US9497583B2 (en) | 2007-12-12 | 2016-11-15 | Iii Holdings 2, Llc | System and method for generating a recommendation on a mobile device |
WO2009078150A1 (en) * | 2007-12-14 | 2009-06-25 | Panasonic Corporation | Dynamic image encoding device, method, program, and integrated circuit |
US8787153B2 (en) | 2008-02-10 | 2014-07-22 | Cisco Technology, Inc. | Forward error correction based data recovery with path diversity |
EP2101503A1 (en) * | 2008-03-11 | 2009-09-16 | British Telecommunications Public Limited Company | Video coding |
WO2009114111A2 (en) | 2008-03-12 | 2009-09-17 | Packetvideo Corp. | System and method for reformatting digital broadcast multimedia for a mobile device |
JP2011523727A (en) * | 2008-03-31 | 2011-08-18 | パケットビデオ コーポレーション | System and method for managing, controlling and / or rendering media over a network |
US8578056B1 (en) * | 2008-03-31 | 2013-11-05 | Symantec Corporation | Optimized application streaming for just in time compiled components |
US20090259756A1 (en) * | 2008-04-11 | 2009-10-15 | Mobitv, Inc. | Transmitting media stream bursts |
CN101282339B (en) * | 2008-05-16 | 2012-12-12 | 华为技术有限公司 | Capability negotiation method for flow medium system, data transmission method as well as related equipment |
CN101296184B (en) * | 2008-05-30 | 2011-04-13 | 华为技术有限公司 | Method, system and device for data transmission |
US8107438B1 (en) | 2008-06-18 | 2012-01-31 | Sprint Spectrum L.P. | Method for initiating handoff of a wireless access terminal based on the reverse activity bit |
KR101519903B1 (en) * | 2008-07-28 | 2015-05-14 | 밴트릭스 코오퍼레이션 | Flow-rate adaptation for a connection of time-varying capacity |
US8001260B2 (en) | 2008-07-28 | 2011-08-16 | Vantrix Corporation | Flow-rate adaptation for a connection of time-varying capacity |
US7844725B2 (en) | 2008-07-28 | 2010-11-30 | Vantrix Corporation | Data streaming through time-varying transport media |
US8544046B2 (en) * | 2008-10-09 | 2013-09-24 | Packetvideo Corporation | System and method for controlling media rendering in a network using a mobile device |
EP2200319A1 (en) | 2008-12-10 | 2010-06-23 | BRITISH TELECOMMUNICATIONS public limited company | Multiplexed video streaming |
TWI396443B (en) | 2008-12-22 | 2013-05-11 | Ind Tech Res Inst | Method for audio and video control response and bandwidth adaptation based on network streaming application and server using the same |
EP2219342A1 (en) | 2009-02-12 | 2010-08-18 | BRITISH TELECOMMUNICATIONS public limited company | Bandwidth allocation control in multiple video streaming |
US8254930B1 (en) * | 2009-02-18 | 2012-08-28 | Sprint Spectrum L.P. | Method and system for changing a media session codec before handoff in a wireless network |
US9374306B1 (en) | 2009-03-04 | 2016-06-21 | Sprint Spectrum L.P. | Using packet-transport metrics for setting DRCLocks |
CA2759880C (en) | 2009-03-23 | 2013-09-24 | Azuki Systems, Inc. | Method and system for efficient streaming video dynamic rate adaptation |
US9467938B1 (en) | 2009-04-29 | 2016-10-11 | Sprint Spectrum L.P. | Using DRCLocks for conducting call admission control |
US7975063B2 (en) | 2009-05-10 | 2011-07-05 | Vantrix Corporation | Informative data streaming server |
US8310929B1 (en) | 2009-06-04 | 2012-11-13 | Sprint Spectrum L.P. | Method and system for controlling data rates based on backhaul capacity |
US9195775B2 (en) | 2009-06-26 | 2015-11-24 | Iii Holdings 2, Llc | System and method for managing and/or rendering internet multimedia content in a network |
US11647243B2 (en) | 2009-06-26 | 2023-05-09 | Seagate Technology Llc | System and method for using an application on a mobile device to transfer internet media content |
US8245088B1 (en) | 2009-06-30 | 2012-08-14 | Sprint Spectrum L.P. | Implementing quality of service (QoS) by using hybrid ARQ (HARQ) response for triggering the EV-DO reverse activity bit (RAB) |
US8204000B1 (en) | 2009-07-23 | 2012-06-19 | Sprint Spectrum L.P. | Achieving quality of service (QoS) by using the reverse activity bit (RAB) in creation of neighbor lists for selected access terminals |
US8848548B2 (en) * | 2009-08-04 | 2014-09-30 | Qualcomm Incorporated | Internet radio broadcast using cellular |
JP2011041018A (en) * | 2009-08-11 | 2011-02-24 | Sony Corp | Information processing apparatus, information processing method, program and communication terminal |
CN102025760B (en) | 2009-09-21 | 2015-11-25 | 华为技术有限公司 | The media transmission method of HTTP and device |
ES2627521T3 (en) | 2010-01-18 | 2017-07-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and arrangement to support content reproduction |
US20110183651A1 (en) * | 2010-01-28 | 2011-07-28 | Packetvideo Corp. | System and method for requesting, retrieving and/or associating contact images on a mobile device |
US8516063B2 (en) | 2010-02-12 | 2013-08-20 | Mary Anne Fletcher | Mobile device streaming media application |
US8644176B1 (en) | 2010-03-11 | 2014-02-04 | Sprint Spectrum L.P. | Methods and systems for supporting enhanced non-real-time services for real-time applications |
US9168946B2 (en) * | 2010-03-19 | 2015-10-27 | Javad Gnss, Inc. | Method for generating offset paths for ground vehicles |
US8363564B1 (en) | 2010-03-25 | 2013-01-29 | Sprint Spectrum L.P. | EVDO coverage modification based on backhaul capacity |
US8515434B1 (en) | 2010-04-08 | 2013-08-20 | Sprint Spectrum L.P. | Methods and devices for limiting access to femtocell radio access networks |
EP2395668B1 (en) * | 2010-06-10 | 2016-08-17 | Nxp B.V. | Reconfigurable interleaver comprising reconfigurable counters |
US8472952B1 (en) | 2010-11-30 | 2013-06-25 | Sprint Spectrum L.P. | Discovering a frequency of a wireless access point |
US8619674B1 (en) | 2010-11-30 | 2013-12-31 | Sprint Spectrum L.P. | Delivery of wireless access point information |
WO2012089671A1 (en) * | 2010-12-29 | 2012-07-05 | Skype | Dynamical adaptation of data encoding dependent on cpu load |
US10135900B2 (en) | 2011-01-21 | 2018-11-20 | Qualcomm Incorporated | User input back channel for wireless displays |
US9413803B2 (en) | 2011-01-21 | 2016-08-09 | Qualcomm Incorporated | User input back channel for wireless displays |
US8677029B2 (en) * | 2011-01-21 | 2014-03-18 | Qualcomm Incorporated | User input back channel for wireless displays |
US9582239B2 (en) | 2011-01-21 | 2017-02-28 | Qualcomm Incorporated | User input back channel for wireless displays |
US9787725B2 (en) | 2011-01-21 | 2017-10-10 | Qualcomm Incorporated | User input back channel for wireless displays |
US9130746B1 (en) | 2011-01-27 | 2015-09-08 | Marvell International Ltd. | Single pair PHY with auto-negotiation |
WO2012109568A1 (en) | 2011-02-11 | 2012-08-16 | Packetvideo Corporation | System and method for using an application on a mobile device to transfer internet media content |
EP2490447A1 (en) * | 2011-02-16 | 2012-08-22 | British Telecommunications Public Limited Company | Compact cumulative bit curves |
US8798777B2 (en) | 2011-03-08 | 2014-08-05 | Packetvideo Corporation | System and method for using a list of audio media to create a list of audiovisual media |
FR2975555A1 (en) * | 2011-05-18 | 2012-11-23 | Thomson Licensing | METHOD OF DYNAMIC ADAPTATION OF RECEPTION RATE AND RECEPTOR |
FR2977101A1 (en) * | 2011-06-24 | 2012-12-28 | France Telecom | RETRANSMISSION OF DATA LOST BETWEEN A TRANSMITTER AND A RECEIVER |
US9137551B2 (en) | 2011-08-16 | 2015-09-15 | Vantrix Corporation | Dynamic bit rate adaptation over bandwidth varying connection |
CN104040992B (en) * | 2011-11-14 | 2018-06-29 | 瑞典爱立信有限公司 | There is the Media Stream of improved efficiency in mobile network |
KR101397592B1 (en) | 2012-03-21 | 2014-05-20 | 삼성전자주식회사 | Method and apparatus for receving multimedia contents |
US9276989B2 (en) * | 2012-03-30 | 2016-03-01 | Adobe Systems Incorporated | Buffering in HTTP streaming client |
KR101394884B1 (en) * | 2012-06-18 | 2014-05-13 | 현대모비스 주식회사 | Congestion Control Device and Method for Inter-Vehicle Communication |
US9439100B2 (en) * | 2012-06-27 | 2016-09-06 | Aruba Networks, Inc. | System and method for dynamic rate adaptation based on real-time call quality metrics |
CN104521241A (en) | 2012-07-03 | 2015-04-15 | 汤姆逊许可公司 | Data recording device and method relating to a time shifting function on a recording medium |
US9357272B2 (en) | 2012-08-03 | 2016-05-31 | Intel Corporation | Device orientation capability exchange signaling and server adaptation of multimedia content in response to device orientation |
US9100698B2 (en) * | 2012-10-26 | 2015-08-04 | Motorola Solutions, Inc. | Systems and methods for sharing bandwidth across multiple video streams |
US9356981B2 (en) * | 2012-11-29 | 2016-05-31 | Broadcom Corporation | Streaming content over a network |
JP5998923B2 (en) * | 2012-12-28 | 2016-09-28 | 富士通株式会社 | Program, information processing apparatus, and communication method |
US9819604B2 (en) * | 2013-07-31 | 2017-11-14 | Nvidia Corporation | Real time network adaptive low latency transport stream muxing of audio/video streams for miracast |
CN103401930B (en) * | 2013-08-05 | 2016-08-10 | 北京邮电大学 | A kind of industrial monitoring method and device of sing on web Service |
EP3579520B1 (en) * | 2013-11-06 | 2021-09-22 | Telefonaktiebolaget LM Ericsson (publ) | Exchanging service capabilities between two devices supported by a network node |
CN103594103B (en) * | 2013-11-15 | 2017-04-05 | 腾讯科技(成都)有限公司 | Audio-frequency processing method and relevant apparatus |
US9495312B2 (en) * | 2013-12-20 | 2016-11-15 | International Business Machines Corporation | Determining command rate based on dropped commands |
US10142259B2 (en) | 2014-03-03 | 2018-11-27 | Ericsson Ab | Conflict detection and resolution in an ABR network |
US9455932B2 (en) * | 2014-03-03 | 2016-09-27 | Ericsson Ab | Conflict detection and resolution in an ABR network using client interactivity |
GB2521883B (en) * | 2014-05-02 | 2016-03-30 | Imagination Tech Ltd | Media controller |
DE102014012355A1 (en) * | 2014-08-25 | 2016-02-25 | Unify Gmbh & Co. Kg | Method for controlling a multimedia application, software product and device |
US10306182B2 (en) * | 2015-06-26 | 2019-05-28 | Intel Corporation | Method and system for improving video quality during call handover |
WO2017063189A1 (en) * | 2015-10-16 | 2017-04-20 | Qualcomm Incorporated | Deadline signaling for streaming of media data |
US9928844B2 (en) * | 2015-10-30 | 2018-03-27 | Intel Corporation | Method and system of audio quality and latency adjustment for audio processing by using audio feedback |
CN106953834B (en) * | 2016-01-07 | 2020-01-24 | 中国移动通信集团公司 | Method, terminal and network equipment for realizing terminal media capability negotiation |
KR102532645B1 (en) * | 2016-09-20 | 2023-05-15 | 삼성전자 주식회사 | Method and apparatus for providing data to streaming application in adaptive streaming service |
CN107035348B (en) * | 2017-05-08 | 2019-05-07 | 中国石油天然气股份有限公司 | A kind of oil field profile control multiplicity well choosing method and device |
US10616304B2 (en) * | 2018-05-30 | 2020-04-07 | Qualcomm Incorporated | Audio dejittering using delay standard deviation |
US11575958B2 (en) | 2018-08-31 | 2023-02-07 | International Business Machines Corporation | Progressive increase in multimedia streaming quality |
CN109565718B (en) * | 2018-11-15 | 2023-11-17 | 北京小米移动软件有限公司 | Method and device for transmitting message |
US10701124B1 (en) | 2018-12-11 | 2020-06-30 | Microsoft Technology Licensing, Llc | Handling timestamp inaccuracies for streaming network protocols |
CN112771828B (en) * | 2018-12-25 | 2022-10-18 | 华为技术有限公司 | Audio data communication method and electronic equipment |
CN111246284B (en) * | 2020-03-09 | 2021-05-25 | 深圳创维-Rgb电子有限公司 | Video stream playing method, system, terminal and storage medium |
US20210281618A1 (en) * | 2020-11-12 | 2021-09-09 | Intel Corporation | System, apparatus, and method for streaming input/output data |
Family Cites Families (50)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6217234B1 (en) * | 1994-07-29 | 2001-04-17 | Discovision Associates | Apparatus and method for processing data with an arithmetic unit |
US5543853A (en) * | 1995-01-19 | 1996-08-06 | At&T Corp. | Encoder/decoder buffer control for variable bit-rate channel |
US5854898A (en) * | 1995-02-24 | 1998-12-29 | Apple Computer, Inc. | System for automatically adding additional data stream to existing media connection between two end points upon exchange of notifying and confirmation messages therebetween |
CN1097912C (en) * | 1995-03-08 | 2003-01-01 | 英国电讯公司 | Broadband switching system |
US5640388A (en) * | 1995-12-21 | 1997-06-17 | Scientific-Atlanta, Inc. | Method and apparatus for removing jitter and correcting timestamps in a packet stream |
KR0176806B1 (en) * | 1995-12-29 | 1999-05-01 | 구자홍 | 2-picture of television |
EP0800294B1 (en) * | 1996-03-20 | 2004-08-04 | Alcatel | Method to control data flow rate, queuing network node and packet switching network |
US5881245A (en) * | 1996-09-10 | 1999-03-09 | Digital Video Systems, Inc. | Method and apparatus for transmitting MPEG data at an adaptive data rate |
US6175856B1 (en) * | 1996-09-30 | 2001-01-16 | Apple Computer, Inc. | Method and apparatus for dynamic selection of compression processing during teleconference call initiation |
US6292834B1 (en) * | 1997-03-14 | 2001-09-18 | Microsoft Corporation | Dynamic bandwidth selection for efficient transmission of multimedia streams in a computer network |
US6154768A (en) * | 1998-03-30 | 2000-11-28 | International Business Machines Corporation | System and method for negotiating functions and features |
CN1150765C (en) * | 1998-07-10 | 2004-05-19 | 皇家菲利浦电子有限公司 | Bit-rate modification |
US6212194B1 (en) * | 1998-08-05 | 2001-04-03 | I-Cube, Inc. | Network routing switch with non-blocking arbitration system |
US6453336B1 (en) * | 1998-09-14 | 2002-09-17 | Siemens Information And Communication Networks, Inc. | Video conferencing with adaptive client-controlled resource utilization |
US6570872B1 (en) * | 1999-04-06 | 2003-05-27 | Nortel Networks Limited | Self-configuring distributed switch |
US6330286B1 (en) * | 1999-06-09 | 2001-12-11 | Sarnoff Corporation | Flow control, latency control, and bitrate conversions in a timing correction and frame synchronization apparatus |
US6466980B1 (en) * | 1999-06-17 | 2002-10-15 | International Business Machines Corporation | System and method for capacity shaping in an internet environment |
US6904045B1 (en) * | 2000-06-02 | 2005-06-07 | Agere Systems Inc. | Method and apparatus for guaranteeing data transfer rates and delays in asynchronous transfer mode networks using pivot sessions |
EP1182875A3 (en) * | 2000-07-06 | 2003-11-26 | Matsushita Electric Industrial Co., Ltd. | Streaming method and corresponding system |
US6904054B1 (en) * | 2000-08-10 | 2005-06-07 | Verizon Communications Inc. | Support for quality of service and vertical services in digital subscriber line domain |
US6763392B1 (en) * | 2000-09-29 | 2004-07-13 | Microsoft Corporation | Media streaming methods and arrangements |
US6901429B2 (en) * | 2000-10-27 | 2005-05-31 | Eric Morgan Dowling | Negotiated wireless peripheral security systems |
US6937770B1 (en) * | 2000-12-28 | 2005-08-30 | Emc Corporation | Adaptive bit rate control for rate reduction of MPEG coded video |
US20020131496A1 (en) * | 2001-01-18 | 2002-09-19 | Vinod Vasudevan | System and method for adjusting bit rate and cost of delivery of digital data |
JP4524724B2 (en) * | 2001-01-19 | 2010-08-18 | ルネサスエレクトロニクス株式会社 | I / O device |
FI118830B (en) * | 2001-02-08 | 2008-03-31 | Nokia Corp | Streaming playback |
US7631037B2 (en) * | 2001-02-08 | 2009-12-08 | Nokia Corporation | Data transmission |
EP1237332B1 (en) * | 2001-03-02 | 2003-11-05 | Hewlett-Packard Company | Provision of services to portable information devices via an information technology network |
EP1248431B1 (en) * | 2001-03-27 | 2007-10-31 | Sony Deutschland GmbH | Method for achieving end-to-end quality of service negotiation for distributed multimedia applications |
US6909702B2 (en) * | 2001-03-28 | 2005-06-21 | Qualcomm, Incorporated | Method and apparatus for out-of-band transmission of broadcast service option in a wireless communication system |
US6600931B2 (en) * | 2001-03-30 | 2003-07-29 | Nokia Corporation | Antenna switch assembly, and associated method, for a radio communication station |
US7161902B2 (en) * | 2001-08-08 | 2007-01-09 | Nortel Networks Limited | Reducing network traffic congestion |
US6885861B2 (en) * | 2001-08-24 | 2005-04-26 | Nokia Corporation | Service mobility and recovery in communication networks |
EP1311102A1 (en) * | 2001-11-08 | 2003-05-14 | Hewlett-Packard Company | Streaming audio under voice control |
JP2003158543A (en) * | 2001-11-22 | 2003-05-30 | Anritsu Corp | Relaying device and relaying method |
ATE443970T1 (en) * | 2001-12-11 | 2009-10-15 | Ericsson Telefon Ab L M | METHOD OF LEGAL MANAGEMENT FOR STREAMING MEDIA |
US20030193619A1 (en) * | 2002-04-11 | 2003-10-16 | Toby Farrand | System and method for speculative tuning |
US20030221014A1 (en) * | 2002-05-24 | 2003-11-27 | David Kosiba | Method for guaranteed delivery of multimedia content based on terminal capabilities |
US7451229B2 (en) * | 2002-06-24 | 2008-11-11 | Microsoft Corporation | System and method for embedding a streaming media format header within a session description message |
FI116498B (en) * | 2002-09-23 | 2005-11-30 | Nokia Corp | Bandwidth adjustment |
US8161158B2 (en) * | 2002-09-25 | 2012-04-17 | Nokia Corporation | Method in a communication system, a communication system and a communication device |
US7134143B2 (en) * | 2003-02-04 | 2006-11-07 | Stellenberg Gerald S | Method and apparatus for data packet pattern matching |
SG111978A1 (en) * | 2002-11-20 | 2005-06-29 | Victor Company Of Japan | An mpeg-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control |
US7526420B2 (en) * | 2002-11-27 | 2009-04-28 | Opcoast Llc | Method and system for virtual injection of network application codes into network simulation |
EP1573979A1 (en) * | 2002-12-12 | 2005-09-14 | Koninklijke Philips Electronics N.V. | A system and method for adapting transmission rate of a multimedia streaming server using a "virtual clock" |
WO2004072764A2 (en) * | 2003-02-13 | 2004-08-26 | Nokia Corporation | Method for signaling client rate capacity in multimedia streaming |
US7844727B2 (en) * | 2003-04-24 | 2010-11-30 | Nokia Corporation | Method and device for proactive rate adaptation signaling |
US7542435B2 (en) * | 2004-05-12 | 2009-06-02 | Nokia Corporation | Buffer level signaling for rate adaptation in multimedia streaming |
EP1675343A1 (en) * | 2004-12-23 | 2006-06-28 | Siemens S.p.A. | Method and system to minimize the switching delay between two RTP multimedia streaming sessions |
US7720096B2 (en) * | 2005-10-13 | 2010-05-18 | Microsoft Corporation | RTP payload format for VC-1 |
-
2004
- 2004-02-13 WO PCT/IB2004/000370 patent/WO2004072764A2/en active Search and Examination
- 2004-02-13 KR KR1020057015011A patent/KR100759954B1/en not_active IP Right Cessation
- 2004-02-13 EP EP04710942A patent/EP1593047A4/en not_active Withdrawn
- 2004-02-13 CA CA002515952A patent/CA2515952A1/en not_active Abandoned
- 2004-02-13 JP JP2006500320A patent/JP2006525693A/en active Pending
- 2004-02-13 EP EP04710939A patent/EP1593107A4/en not_active Withdrawn
- 2004-02-13 US US10/778,899 patent/US7558869B2/en active Active
- 2004-02-13 WO PCT/IB2004/000374 patent/WO2004072765A2/en active Application Filing
- 2004-02-13 EP EP04710940A patent/EP1593046A2/en not_active Withdrawn
- 2004-02-13 US US10/779,318 patent/US20040196849A1/en not_active Abandoned
- 2004-02-13 US US10/778,941 patent/US20040196852A1/en not_active Abandoned
- 2004-02-13 JP JP2006500321A patent/JP2006518948A/en active Pending
- 2004-02-13 WO PCT/IB2004/000380 patent/WO2004072766A2/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
EP1593047A4 (en) | 2010-06-09 |
EP1593047A2 (en) | 2005-11-09 |
US7558869B2 (en) | 2009-07-07 |
KR20050106592A (en) | 2005-11-10 |
EP1593107A2 (en) | 2005-11-09 |
JP2006518948A (en) | 2006-08-17 |
WO2004072766A3 (en) | 2004-11-25 |
US20040196849A1 (en) | 2004-10-07 |
KR100759954B1 (en) | 2007-09-19 |
EP1593046A2 (en) | 2005-11-09 |
JP2006525693A (en) | 2006-11-09 |
US20040193762A1 (en) | 2004-09-30 |
US20040196852A1 (en) | 2004-10-07 |
WO2004072765A3 (en) | 2005-06-02 |
WO2004072764A2 (en) | 2004-08-26 |
EP1593107A4 (en) | 2010-08-18 |
WO2004072766A2 (en) | 2004-08-26 |
WO2004072764A3 (en) | 2007-08-16 |
WO2004072765A2 (en) | 2004-08-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2515952A1 (en) | Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming | |
US10277651B2 (en) | Session control for media stream transmission | |
US10728318B2 (en) | Methods and apparatus for selection of content delivery network (CDN) based on user location | |
US9300696B2 (en) | Method of sharing one or more media in a session between terminals | |
EP2044747B1 (en) | Technique for providing access to a media resource attached to a network-registered device | |
US10778731B2 (en) | Communications methods, apparatus and systems for conserving media resource function resources | |
US20060256748A1 (en) | System and method for interworking between IMS network and H.323 network | |
WO2016210109A1 (en) | Mechanisms to support adaptive constrained application protocol (coap) streaming for internet of things (iot) systems | |
CN102215276A (en) | Video monitoring system and method of media traverse of network address translation equipment | |
ZA200506682B (en) | Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming | |
US20150264103A1 (en) | Real-Time Transport Protocol (RTP) Media Conference Server Routing Engine | |
US9912623B2 (en) | Systems and methods for adaptive context-aware control of multimedia communication sessions | |
JP2007524167A (en) | Send asset information in streaming services | |
CN101094159B (en) | Method for penetrating through private network of media stream | |
KR20140001477A (en) | Apparatus and method for efficient session negotiation for video telephony system | |
KR20060038296A (en) | Apparatus and method for multiplexing the packet in mobile communication network | |
CN101919216A (en) | Gateway device, system, and communication method | |
KR101528268B1 (en) | System and method for streaming content to remote locations | |
WO2023071656A1 (en) | Information transmission method and apparatus | |
JP7009509B2 (en) | Network device management | |
RU2367003C2 (en) | Method of reporting on transfer rate of data from client during transmission of multimedia stream |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued |