WO2012175227A1 - Procédés et appareil pour identifier des flux multimédias rtp contenant des données multimédias associées - Google Patents

Procédés et appareil pour identifier des flux multimédias rtp contenant des données multimédias associées Download PDF

Info

Publication number
WO2012175227A1
WO2012175227A1 PCT/EP2012/053860 EP2012053860W WO2012175227A1 WO 2012175227 A1 WO2012175227 A1 WO 2012175227A1 EP 2012053860 W EP2012053860 W EP 2012053860W WO 2012175227 A1 WO2012175227 A1 WO 2012175227A1
Authority
WO
WIPO (PCT)
Prior art keywords
endpoint device
media streams
media
rtp
receiver
Prior art date
Application number
PCT/EP2012/053860
Other languages
English (en)
Inventor
Bo Burman
Magnus Westerlund
Original Assignee
Telefonaktiebolaget L M Ericsson (Publ)
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget L M Ericsson (Publ) filed Critical Telefonaktiebolaget L M Ericsson (Publ)
Publication of WO2012175227A1 publication Critical patent/WO2012175227A1/fr

Links

Classifications

    • 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/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H04L65/4015—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference where at least one of the additional parallel sessions is real time or time sensitive, e.g. white board sharing, collaboration or spawning of a subconference
    • 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/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

Definitions

  • the present invention relates to communications networks. More particularly, and not by way of limitation, the present invention is directed to systems and methods of establishing and controlling Real Time Transport Protocol (RTP) media streams through a communications network between endpoint devices.
  • RTP Real Time Transport Protocol
  • RTP protocol supports multiple endpoint device participants each sending their own media streams.
  • VoIP Voice over IP
  • client system implementations providing video conference functionality typically require the use of a central mixer that only delivers a single media stream per media type.
  • any application that wants to allow for more advanced usage where multiple media streams are sent and received by an endpoint device would have an incompatibility problem with legacy systems.
  • Some embodiments of the present invention are directed to a method of operating a sender endpoint device that communicates with a receiver endpoint device.
  • the method includes communicating a plurality of media streams simultaneously in time toward the receiver endpoint device.
  • the method further includes communicating information toward the receiver endpoint device that identifies which of the media streams contain related media data.
  • the communicated information identifies which of the media streams contain different encoded types of the same media content, which of the media streams contain different spatial sampled versions, temporal sampled versions, and/or lossy quality versions of a same media source, and/or which of the media streams of a same media source.
  • Some other embodiments of the present invention are directed to a method of operating a receiver endpoint device that communicates with a sender endpoint device.
  • the method includes receiving a plurality of media streams simultaneously in time from the sender endpoint device, and receiving information from the sender endpoint device that identifies which of the media streams contain related media data.
  • the method further includes selecting among the media streams responsive to the received information.
  • Some other embodiments of the present invention are directed to a sender endpoint device that includes a network interface and a processor.
  • the network interface is configured to communicate over a network with a receiver endpoint device.
  • the processor is coupled to the network interface, and is configured to simultaneously communicate a plurality of media streams through at least one RTP session toward the receiver endpoint device, and to communicate information toward the receiver endpoint device that identifies which of the media streams contain related media data.
  • Some other embodiments of the present invention are directed to a receiver endpoint device that includes a network interface and a processor.
  • the network interface is configured to communicate over a network with a sender endpoint device.
  • the processor is coupled to the network interface, and is configured to simultaneously receive a plurality of media streams from the sender endpoint device, receive information from the sender endpoint device that identifies which of the media streams contain related media data, and select among the media streams responsive to the received information.
  • Figure 1 is a block diagram of a communication system that is configured according to some embodiments
  • Figures 2 and 3 are block diagrams of a UE and a base station, respectively, configured according to some embodiments;
  • FIGS 4-9 are flow charts that illustrate operations and methods that can be performed by sender endpoint devices to identify simultaneously communicated media streams as having related media data in accordance with some embodiments;
  • Figures 11-20 are flow charts that illustrate operations and methods that can be performed by receiver endpoint devices to simultaneously receive media streams and identify which media streams have related media data in accordance to some embodiments;
  • Figures 21-32 are flow charts that illustrate operations and methods that can be performed by receiver endpoint devices to advertise their capability for simultaneously receiving media streams in accordance with some embodiments.
  • Figures 33-41 are flow charts that illustrate operations and methods that can be performed by sender endpoint devices to advertise their capability for simultaneously communicating media streams in accordance with some embodiments.
  • Various embodiments are directed to sender endpoint devices and receiver endpoint devices, and associated methods, that simultaneously send and receive, respectively, a plurality of media streams through at least one RTP session.
  • the media streams are communicated through Real Time Transport Protocol (RTP), where there are multiple media streams that are sent over an RTP session.
  • RTP Real Time Transport Protocol
  • a sender endpoint device may establish a RTP session with a receiver endpoint device and may then simultaneously communicate a plurality of media streams through the RTP session.
  • the sender endpoint device may establish a plurality of RTP sessions with the receiver endpoint device and communicate a plurality of media streams through one or more of the plurality of RTP sessions.
  • the receiver endpoint device uses that information to, for example, select among the simultaneously received media streams to output/use a selected media stream and/or may combine two or more of the selected media streams to output/use a combined media stream.
  • a sender endpoint device can communicate the information identifying the related media stream through additional uses of existing signaling provided by RTP and/or Real-time Transport Control Protocol (RTCP), and/or by generating signaling extensions to RTP and/or RTCP.
  • the sender endpoint device can communicate the information directly to a receiver endpoint device and/or can communicate information to a central node for forwarding to the receiver endpoint device.
  • the related media data information can be used to provide improved handling of simulcasted media streams, such as when multiple encodings or representations of the same media source are sent from a same sender endpoint device to a receiver endpoint device.
  • RTCP is a sister protocol of Real-time Transport Protocol (RTP) which is widely used for real time data transport.
  • media stream refers to a stream of data
  • endpoint device (e.g., video data stream and/or audio data stream) that is sent from one endpoint device (such as a microphone for audio data stream and/or a video camera for video data stream).
  • endpoint device also referred to as an endpoint refers to a communication device that handles media by originating one or more media streams (e.g., originating audio and/or video streams using a microphone and/or video camera) and/or terminating one or more media streams (e.g., generating audio and/or video data stream output) received from one or more other endpoint devices.
  • each endpoint device of a RTP session may be both a sender endpoint device generating one or more media data streams for communication to other endpoint devices (acting as receiver endpoint devices), and a receiver endpoint device receiving media data streams as input.
  • an RTP Mixer may be considered as an endpoint.
  • FIG. 1 is a block diagram of a communication system that is configured according to some embodiments.
  • the communication system includes a plurality of endpoint devices 111-1 to 111-n that are communicatively connected through one or more networks 101 (e.g., public networks, such as the Internet, and/or private networks).
  • networks 101 e.g., public networks, such as the Internet, and/or private networks.
  • One or more of the endpoint devices may operate as a sender that simultaneously communicates a plurality of media streams (such as audio data and/or video data) toward a receiver endpoint device participating in a streaming communication session (such as a video conferencing session) through network 101 (e.g., the Internet) according to some embodiments.
  • a streaming communication session such as a video conferencing session
  • network 101 e.g., the Internet
  • at least five endpoint devices 111 are shown in Figure 1 by way of example, embodiments of the present invention may be implemented using any number of two or more endpoint devices.
  • One or more RTP sessions are established between two or more of endpoint devices 111.
  • Each endpoint device 111 included in the RTP session(s) may act as a sender endpoint device to generate a plurality of media streams that can be communicated directly to a receiver endpoint device or may be communicated to a central node 112 (e.g., a RTP mixer node) for possible forwarding to the receiver endpoint device.
  • Each endpoint device 111 may also act as a receiver endpoint device to receive a plurality of media streams.
  • the central node 112 may select among a plurality of received media streams for forwarding to a receiver endpoint device and/or it may combine or otherwise manipulate (e.g., perform transcoding between defined data encoding formats) one or more received media streams before forwarding to the receiver endpoint device. More particularly, the central node 112 may select a media stream to be sent to a receiver endpoint device 111 responsive to input from the receiver endpoint device 111. For example, each endpoint device 111 of a conference session may select a media stream or a plurality of media streams of the conference session to be presented at that endpoint device 111. Two endpoint devices in a peer to peer embodiment, for example, may each send and receive a plurality of media streams, and each of the endpoint devices may use functionality of embodiments described herein to control which of the streams are received from the other endpoint device.
  • FIG 2 is a block diagram illustrating an endpoint device 111 of Figure 1 according to some embodiments.
  • Endpoint device 111 may include a processor 131 coupled to a display 121 (e.g., a liquid crystal display screen providing a video output) or display output, a user input interface 129 (e.g., including a keypad, a touch sensitive surface of display 121, etc.), a speaker 123 or speaker output, one or more video cameras 125 or video camera input(s), and one or more microphones 127 or microphone input(s).
  • a display 121 e.g., a liquid crystal display screen providing a video output
  • a user input interface 129 e.g., including a keypad, a touch sensitive surface of display 121, etc.
  • speaker 123 or speaker output e.g., including a keypad, a touch sensitive surface of display 121, etc.
  • one or more video cameras 125 or video camera input(s) e.g., a microphones 127 or
  • Inputs/outputs discussed above may be interfaces (e.g., couplings, jacks, etc.) for wired inputs/outputs and/or wireless interfaces (e.g., Bluetooth, WiFi, etc.).
  • a network interface 133 may provide a data/communications coupling between processor 131 and network 101.
  • the coupling between network interface 133 and network 101 may be provided over a wired coupling (e.g., using a digital subscriber line modem, a cable modem, etc.), over a wireless coupling (e.g., over a 3G/4G wireless network, over a WiFi link, etc.), or over a combination thereof.
  • Endpoint device 111 may be a smartphone, a tablet computer, a netbook computer, a laptop computer, a desktop computer, a video camera, a digital microphone, a hub that combines audio/video streams from a plurality of video cameras and/or digital microphones.
  • the processor 131 may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor), which may be collocated or distributed across a communication network.
  • the processor 131 is configured to execute computer program instructions from memory device(s) (e.g., internal or external memory), described below as a computer readable medium, to perform at least some of the operations and methods described herein as being performed by an endpoint device in accordance with one or more embodiments of the present invention.
  • the endpoint device 111 is used for video conferencing and is configured to receive audio/video streams from a plurality of external cameras and associated microphones that may be positioned around a room (e.g., for video conferencing) or positioned in a plurality of rooms (e.g., for security monitoring) and coupled to the processor 131 through video/microphone inputs 125/127.
  • the processor 131 may encode data carried by the media streams, and may be configured to simultaneously output a plurality of different encoded types of a same input media content.
  • the processor 131 may receive a video or audio stream from a camera or microphone, and apply different spatial sampling and/or temporal sampling to the media stream to simultaneously output a plurality of different versions of the media stream.
  • the processor 131 may output a full resolution video/audio stream and one or more reduced resolution video/audio streams for communication toward a receiver endpoint device 111.
  • the processor 131 may, in another embodiment, output different bitrate streams using variable lossy coding, such as by controllably discarding different rates of bits from an input media stream to output different quality lossy quality versions (e.g., different levels of video coarseness) of the input media stream.
  • a sender endpoint device 111 may thus simultaneously output a plurality of media streams that contain related media data (such as different spatial samplings, temporal samplings, and/or data encodings of a same media content stream).
  • FIG 4 is a flowchart of operations and methods that can be performed by a sender endpoint device 111-1 to simultaneously communicate a plurality of media streams toward a receiver endpoint device 111-2 through a session, in accordance with some embodiments which will be explained in further detail below.
  • the sender endpoint device 111-1 can be configured to communicate (block 400) a plurality of media streams, simultaneously in time, for a session (e.g., a RTP session) toward a receiver endpoint device 111-2.
  • the sender endpoint device 111-1 also communicates (block 402) information toward the receiver endpoint device 111-2 that identifies which of the media streams contain related media data (content).
  • the receiver endpoint device 111-2 can use the information to identify which of the media streams contain related media data, and may further identify, using the information, differences between the media data (e.g., which media streams have been coded using which algorithms, which media streams have been sampled using which rates, which media streams have which video pixel/line resolutions, etc.).
  • FIG 3 is a block diagram illustrating the central node 112 of Figure 1 according to some embodiments.
  • central node 112 may include a processor 231 and a network interface 233, with a network interface 233 providing a data/communications coupling between the processor 231 and the network 101.
  • the processor 231 may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor), which may be collocated or distributed across a communication network.
  • the processor 231 is configured to execute computer program instructions from memory device(s) (e.g., internal or external memory), described below as a computer readable medium, to perform at least some of the operations and methods described herein as being performed by a central node (e.g., RTP mixer node) in accordance with one or more embodiments of the present invention.
  • memory device(s) e.g., internal or external memory
  • a central node e.g., RTP mixer node
  • Processor 231 may receive one or more media streams and associated information from each sender endpoint device 111-1, and may select among received media streams for forwarding to a receiver endpoint device 111-2 and/or it may combine or otherwise manipulate (e.g., perform transcoding between defined data encoding formats) one or more received media streams before forwarding to the receiver endpoint device 111-2.
  • the central node 112 may communicate to the receiver endpoint device 111-2 information identifying characteristics of each of the media streams to enable the receiver endpoint device to select one or more the available media streams for communication from the central node 112 to the receiver endpoint device 111-2.
  • the processor 231 may select among the received media streams for forwarding to the receiver endpoint device 111-2 and/or combine or otherwise manipulate one or more received media streams responsive to an instruction received from the receiver endpoint device 111-2.
  • RTP sessions are a fundamental part of a Synchronization Source identifier
  • the SSRC uniquely identifies real time media streams within a
  • the SSRC space can encompass a number of network nodes and interconnecting transport flows between these nodes.
  • Each node may have zero, one or more source identifiers SSRCs used to either source a real media source such as a camera or a microphone, a conceptual source, like the most active speaker selected by a RTP mixer that switches between incoming media streams based on the media stream or additional information, or simple as an identifier for a receiver that provides feedback and reports on reception.
  • RTP nodes like translators that are manipulating, data, transport or session state without making their presence aware to the other session participants.
  • RTP was designed with multiple participants in a session from the beginning.
  • a single endpoint device may have multiple media sources of the same media type, like cameras or microphones.
  • SDP Session Initiation Protocol
  • an endpoint device can be configured to advertise its capabilities to another session participant s), so that endpoint device limitations are exposed and can be compensated for by the other session participant s) (e.g., sender endpoint device).
  • an endpoint device is configured to signal whether it intends to produce one or more media stream.
  • convention SDP signaling is limited to communicating a directionality attribute which indicates whether an endpoint device intends to send media or not. No indication of how many media streams an endpoint device intends to send is communicated by conventional SDP signaling, and which is now addressed by some embodiments of the present invention.
  • invention is not limited thereto and may be used for any communication devices either simultaneously receiving sending and/or simultaneously receiving a plurality of media streams.
  • Simulcast is the act of simultaneously sending multiple different versions of source media content. This can be done in several ways and for different purposes. Various example embodiments are described herein the context of the case where an endpoint device 111 will provide multiple different encodings towards a central node device 112
  • Bit-rate The primary difference is the amount of bits used to encode source media content into a media stream, and thus primarily affects the media Signal to Noise Ratio (SNR);
  • Codec Different media codecs are used, for example, to ensure that different receivers that do not have a common set of decoders can decode at least one of the versions of the encoded source media content. This includes codec configuration options that aren't compatible, like video encoder profiles, or the capability of receiving the transport packetization; and
  • Different sampling of the source media content, in the spatial domain and/or in the temporal domain, may be used to suit different rendering capabilities or needs at receiving endpoint devices, as well as a method to achieve different bit-rates.
  • spatial sampling affects image resolution
  • temporal sampling affects video frame rate.
  • audio spatial sampling relates to the number of audio channels
  • temporal sampling affects audio bandwidth.
  • different lossy quality versions of the input media stream may be generated by discarding a controllable rate of bits of the input media stream to provide, for example, output different levels of video coarseness.
  • Different applications in one or more endpoint devices can have different reasons for simulcasting a plurality of different versions of media content from a media source.
  • the need for simulcasting different versions of a media stream can arise even when media codecs used by a sending/receiving endpoint device have scalability features that enable them to solve a set of coding variations.
  • encoding refers to a media encoder (codec) that has been used to compress a media stream and/or the fidelity of encoding that has been used to encode a media stream through the choice of sampling, bit-rate, and/or other configuration parameters.
  • codec media encoder
  • the phrase "different encodings" refers to the use of one or more different parameters that characterize the encoding of a particular media source. Such changes can include, but are not limited to, one or more of the following parameters: codec; codec configuration; bit-rate; and/or sampling.
  • Some embodiments are directed to a multi-party session that is communicated through one or more RTP Mixers 112 to facilitate the media transport between the session participants (endpoint devices 111-1...111-n).
  • the RTP topology can include that defined in [RFC5117] of RTP Mixer (Section 3.4: Topo-Mixer).
  • an RTP mixer 112 can be controlled to select the most active speaker (e.g., endpoint device 111- 1) and sends that participant's (e.g., selected) media stream as a high resolution stream to a receiver (e.g., endpoint device 111-2) and in addition can simultaneously send a number of small resolution video streams of any additional participants (e.g., non-selected, such as endpoint devices 111-3...
  • Simulcast For example, the client endpoint device 111 sends one stream for the low resolution and another for the high resolution.
  • Scalable Video Coding For example, the client endpoint device 111 uses a video encoder that can provide one media stream that is both providing the high resolution and enables the RTP mixer 112 to extract a lower bit-rate than the full stream version, for the low resolution.
  • Transcoding in the Mixer For example, the client endpoint device 111 sends a high resolution stream to the RTP Mixer 112, which performs a transcoding to a lower resolution version of the video stream that is forwarded to other endpoint devices that need it.
  • the transcoding alternative may require that the RTP Mixer 112 has sufficient amounts of transcoding resources to produce the number of low resolution versions that are required.
  • the worst case loading for resources may correspond to when all participants streams needs transcoding. If the resources are not available, a different solution needs to be chosen.
  • the RTP mixer 112 can advertise its resource capabilities to the sender endpoint device 111 and/or to the receiver endpoint device 111. The sender endpoint device 111 and to the receiver endpoint device 111 can then consider the resource capabilities of the RTP mixer 112 when configuring a session and/or one or more media streams that will be communicated through the RTP mixer 112.
  • the scalable video encoding alternative may necessitate a more complex encoder compared to non-scalable encoding.
  • the scalable codec may be only marginally more bandwidth efficient, between the encoding client endpoint device 111 and the RTP mixer 112, than a simulcast that send the resolutions in separate streams, assuming equivalent video quality.
  • the transmission of all but the lowest resolution will consume more bandwidth from the RTP mixer 112 to the other participant endpoint devices 111 than a non- scalable encoding, again assuming equivalent video quality.
  • Simulcasting has the benefit that it is conceptually simple. It enables use of any media codec that the participants 111/112 agree on, allowing the RTP mixer 112 to be codec-agnostic. Considering today's video encoders, it is less bit-rate efficient in the path from the sending client endpoint device 111 to the RTP mixer 112 but more efficient in the RTP mixer 112 to receiver path compared to Scalable Video Coding.
  • Topo-Trn-Translator [RFC5117], which may be included within the central node 112.
  • the transport translator functions as a relay and transmits all the streams received from one participant endpoint device 111-1 to selected other participant endpoint devices 111-2... 111- n.
  • All receiver endpoint devices may be configured to receive all media stream versions of a same source media content through simulcast thereof. However, this approach increases the bit-rate consumed on the paths to the receiver endpoint devices.
  • a benefit for the receiver client endpoint devices is reduced decoding complexity when there is a need to only display a low resolution version. Otherwise a single stream application which only transmits the high resolution stream would allow the receiver endpoint device 111 to decode it and the scale it down to the needed resolution.
  • simulcast is where one encoding is sent to multiple receiver endpoint devices 111. This may be supported in RTP by copying all outgoing RTP and RTCP traffic to several transport destinations as long as the intention is to create a common RTP session. As long as all participants do the same, a full mesh is constructed and everyone in the multi party session have a similar view of the joint RTP session. This is similar to an Any Source Multicast (ASM) session but without the traffic optimization as multiple copies of the same content is likely to have to pass over the same link.
  • ASM Any Source Multicast
  • simulcast Another alternative implementation of simulcast is where multiple destination endpoint devices 111 each receive a specifically tailored version, but where the destination endpoint devices 111 are independent.
  • a typical example for this would be a streaming server (e.g., source endpoint device 111) distributing the same live session to a number of receiver endpoint devices 111, while adapting the quality and resolution of the multi-media session to each receiver endpoint devices' 111 capability and available bit-rate.
  • multiple independent RTP sessions are established between the sender endpoint device 111 and the receiver endpoint devices 111.
  • RTP extension mechanism has made the RTP stacks requiring to handle additional SSRCs, like SSRC multiplexed RTP retransmission [RFC4588]. However, that still has only required handling a single media decoding chain.
  • the receiving client needs to be configured to handle receiving more than one stream simultaneously rather than replacing the already existing stream with the new one.
  • the receiving client needs to be configured to decode multiple streams
  • the receiving client needs to be configured to render multiple streams
  • An endpoint device 111/ central node 1 12 that intends to process the media in an RTP session needs to have sufficient resources to receive and process all the incoming streams. It is extremely likely that no receiver endpoint device 111/central node 112 is capable of handling the theoretical upper limit of an RTP session when it comes to more than 4 billion media sources. Instead, one or more limitations will exist for the endpoint device 111/central node 112 resource capabilities to handle simultaneous media streams. These resource limitations can include, for example memory, processing, network bandwidth, memory bandwidth, or rendering estate.
  • Non-actively media sending SSRCs may not result in significant resource consumption and, therefore, may not need to be limited.
  • a potential issue that is noted is where a limited set of simultaneously active sources varies within a larger set of session members. As each media decoding chain may contain state, it is important that this type of usage ensures that a receiver endpoint device 111/central node 112 can flush a decoding state for an inactive source and if that source becomes active again it does not assume that this previous state exists.
  • signaling is provided that allows a receiver endpoint device 111/central node 112 to indicate its upper limit in terms of capability to handle simultaneous media streams.
  • Applications may need to be configured to consideration how they use codecs.
  • an endpoint device 111 may either be legacy or has an explicit upper limit in the number of simultaneous streams, one will encounter situations where the endpoint device 111 will not receive all simultaneous active streams in the session. Instead the endpoint device 111 or central nodes 112, like RTP mixers, will be configured to provide the endpoint device 111 with a selected set of streams based on various metrics, such as most active, most interesting, or user selected. In addition, the central node 112 may combine multiple media streams using mixing or composition into a new media stream to enable an endpoint device 111 to get a sufficient source coverage in the session, despite existing limitations.
  • RTCP issues and related embodiments for supporting multiple streams.
  • An existing issue with SDP is that the bandwidth parameters aren't specified to take asymmetric conditions into account. This becomes especially evident when using multiple streams in an RTP session. Such use case can result in an endpoint receiver receiving, for example, five streams of Full High Definition (HD) video but only sending one Standard Definition (SD) video stream, which can result in a 10: 1 asymmetry in bit-rate.
  • HD Full High Definition
  • SD Standard Definition
  • an endpoint device 111 may conclude that it can't support the bit-rate despite it being capable of actually receiving the media streams being sent.
  • RTCP bandwidth may be derived from the session bandwidth. It is important that all endpoint devices have a common view on what the RTCP bandwidth is. Otherwise if the bandwidth values are more than 5 times different, an endpoint device with the high bandwidth value may time out an endpoint device that has a low value as it's minimal reporting interval can become more than 5 times longer than for the other nodes.
  • a multi-stream capable RTP sender endpoint device is able to adapt the number of streams that it will output responsive to the known capabilities of the RTP receiver endpoint device.
  • max-send-ssrc and max-recv-ssrc are defined, which can be used independently to establish a limit to the number of simultaneously active SSRCs for the send and receive directions, respectively.
  • Active SSRCs are the ones counted as senders according to RFC3550, i.e. they have sent RTP packets during the last two regular RTCP reporting intervals.
  • a payload-agnostic upper limit to the total number of simultaneous SSRC that can be sent or received in this RTP session is signaled with a * payload type. A value of 0 may be used as maximum number of SSRC, but it is then recommended that this is also reflected using the sendonly or recvonly attribute. There should also be at most one payload- agnostic limit specified in each direction.
  • a payload-specific upper limit to the total number of simultaneous SSRC in the RTP session with that specific payload type is signaled with a defined payload type (static, or dynamic through rtpmap). Multiple lines with max-send-ssrc or max-recv-ssrc attributes specifying a single payload type may be used, each line providing a limitation for that specific payload type. Payload types that are not defined in the media block should be ignored.
  • the sender or receiver endpoint devices 111 should be able to handle any combination of the SSRCs with different payload types that fulfill all of the payload specific limitations, with a total number of SSRCs up to the payload-agnostic limit.
  • max-send-ssrc or max-recv-ssrc are not included in the SDP, it can be interpreted by an endpoint device as equivalent to a limit of one, unless sendonly or recvonly attributes are specified, in which case the limit is implicitly zero for the corresponding unused direction.
  • the specified limit in max-send- ssrc indicates the maximum number of simultaneous streams of the specified payload types that the configured endpoint device 111 may send at any single point in time.
  • max-recv-ssrc indicates the maximum number of simultaneous streams of the specified payload types that may be sent to the configured endpoint endpoint device 111.
  • Payload- agnostic limits can be used with or without additional payload-specific limits.
  • the specified limits indicates the agent endpoint device's 111 intent of sending and/or capability of receiving that number of simultaneous SSRC.
  • the answerer can cause a decrease in the offered limit in the answer to suit the answering client endpoint device's 111 capability.
  • a sender endpoint device 111 can responds by not sending more simultaneous streams of the specified payload type than the receiver endpoint device 111 has indicated ability to receive, taking into account also any payload-agnostic limit.
  • the agent endpoint device 111 is then known to only be capable of supporting a single stream in the direction for which attributes are missing. If the offer lacks attributes it must be assumed that the offerer only supports a single stream in each direction.
  • SDP bandwidth attribute can be used that supports directionality, possibility for payload specific values and clear semantics.
  • a common problem for current SDP bandwidth modifiers is that they use a single bandwidth value without a clear specification. Uncertainty in how the bandwidth value is derived creates uncertainty on how bursty a media source can be.
  • the functionality that can be provided by the new bandwidth attribute can include the following:
  • the SDP bandwidth attribute can indicate different sets of attribute values depending on direction;
  • Bandwidth specification method To indicate what bit-rate values mean, an endpoint device can communicate Token bucket parameters that indicate, for example, bucket depth and bucket fill rate. If single values are to be specified, a clear definition on how one derive that value must be specified, including averaging intervals etc.
  • This attribute is structured as follows, in accordance with some embodiments. After the attribute name there is a directionality parameter, a scope parameter, and a semantics. The semantics provides an indication that is useful for interpreting the parameter values.
  • the attribute is designed so that multiple instances of the line will be necessary to express the various bandwidth related configurations that are desired.
  • a required-prefix indicator (“ ! ) can be added prior to any scope or semantics parameter.
  • scope payloadType / scope-ext
  • PT-value-list PT-value *(";" PT-Value)
  • SDP Offer/ Answer agent e.g., endpoint device
  • SDP Offer/ Answer agent e.g., endpoint device
  • sendrecv The provided bandwidth values applies equally in send and recv direction, i.e. the values configures the directions symmetrically.
  • Scope indicates what is being configured by the bandwidth semantics of this attribute line. This parameter is extensible and we begin with defining two different scopes based on payload type:
  • Payload Type The bandwidth configuration applies to one or more specific payload type values.
  • This specification defines two semantics which are related.
  • the token bucket values are the Token bucket rate and the token bucket size and represented as two floating-point numbers.
  • SMT The maximum intended or allowed bandwidth usage for each individual source (SSRC) in an RTP session as specified by a token bucket.
  • AMT The maximum intended or allowed bandwidth usage for sum of all sources (SSRC) in an RTP session according to the specified directionality as specified by a token bucket.
  • the token bucket values are the token rate in bits per second and the bucket size in bytes.
  • a agent responding to an offer will need to consider the directionality and reverse them when responding for media streams using unicast. If the transport is multicast the directionality is not affected.
  • the answerer e.g., receiver and point device 111
  • the answerer will reverse the directionality and may only reduce the bandwidth when producing the answer indicating the answerer intended maximum.
  • the SDP attribute is interpreted from the perspective of the endpoint device being configured by the particular SDP.
  • the outgoing single stream is limited to bucket rate of 1.2 Mbps and bucket size of 16384 bytes.
  • the up to 5 incoming streams can in aggregate use maximum 8 Mbps bucket rate and with a bucket size of 65535 bytes.
  • the individual streams maximum rate is depending on payload type.
  • Payload type 96 (H.264) is limited to 1.5 Mbps with a bucket size of 16384 bytes
  • the Payload type 97 (H.263) may use up to 2.5 Mbps with a bucket size of 16384 bytes.
  • Simulcast is the act of sending multiple alternative encodings of the same underlying media source.
  • the below sub-sections describe potential ways of achieving flow de-multiplexing and identification of which streams are alternative encodings of the same source.
  • multiple SSRCs may occur for various reasons such as multiple participant endpoint devices in multipoint topologies such as multicast, transport relays or full mesh transport simulcasting, multiple source devices, such as multiple cameras or microphones at one endpoint, or RTP mechanisms in use, such as RTP Retransmission [RFC4588].
  • Payload multiplexing uses only the RTP payload type to identify the different alternatives. Thus all streams would be sent in the same RTP session using only a single SSRC per actual media source. So when having multiple SSRCs, each SSRC would be unique media sources or RTP mechanism-related SSRC. Each RTP payload type would then need to both indicate the particular encoding and its configuration in addition to being a stream identifier. When considering mechanism like RTP retransmission using SSRC multiplexing then an SSRC may either be a media source with multiple encodings as provided by the payload type, or a retransmission packet as identified also by the payload type.
  • a sender endpoint device 111 of a payload type multiplexed simulcast will need to send multiple different packets with one version in each packet or sequence of packets.
  • the SSRC multiplexing idea is based on using a unique SSRC for each alternative encoding of one actual media source within the same RTP session.
  • the identification of how flows are considered to be alternative needs an additional mechanism, for example using SSRC grouping [RFC5576] with a semantics that indicate them as alternatives.
  • each media source will use a number of SSRCs to represent the different alternatives it produces. For example, if all actual media sources are similar and produce the same number of simulcast versions, one will have n*m SSRCs in use in the RTP session, where n is the number of actual media sources and m the number of simulcast versions they can produce.
  • Each SSRC can use any of the configured payload types for this RTP session.
  • Session multiplexing means that each different version of an actual media source is transmitted in a different RTP session, using whatever session identifier to demultiplex the different versions. This solution can then use the same SSRC in all the different sessions to indicate that they are alternatives, or it can use explicit session grouping
  • the simulcast solution should ensure that any negative impact on RTP/RTCP is minimal and that all the features of RTP/RTCP and its extensions can be used.
  • Payload type multiplexing for purposes like simulcast has well known negative effects on RTP.
  • the basic issue is that all the different versions are being sent on the same SSRC, thus using the same timestamp and sequence number space. This has many effects:
  • Some media formats require uninterrupted sequence number space between media parts. These are media formats where any missing RTP sequence number will result in decoding failure or invoking of a repair mechanism within a single media context.
  • the text/ T140 payload format [RFC4103] is an example of such a format. These formats may not be possible to simulcast using payload multiplexing.
  • the current RTCP feedback mechanisms are built around providing feedback on media streams based on stream ID (SSRC), packets (sequence number) and time interval (RTP Timestamps). There is almost never a field for indicating which payload type one is reporting on. Thus giving version specific feedback is difficult.
  • SSRC stream ID
  • RTP Timestamps time interval
  • the current RTCP media control messages [RFC5104] is oriented around controlling particular media flows, i.e. requests are done on RTCP level. Thus such mechanism needs to be redefined to support payload type multiplexing.
  • the SSRC multiplexing of simulcast version may require a receiver endpoint device to know that one is expected to only decode one of the versions and need not decode all of them simultaneously. This is currently a missing functionality as SDES CNAME cannot be used.
  • the same CNAME has to be used for all flows connected to the same endpoint and location. A clear example of this could be video conference where an endpoint has 3 video cameras plus an audio mix being captured in the same room. As the media has a common timeline, it is important to be able to indicate that through the CNAME. Thus an endpoint device cannot use CNAME to indicate that multiple SSRCs with the same CNAME are different versions of the same source.
  • session multiplexing does not have any of the negative effects that payload type multiplexing has (Section 7.1.1). As each flow is uniquely identified by RTP Session and SSRC, one can control and report on each flow explicitly.
  • the method of multiplexing has significant impact on signaling functionality and how to perform it, especially if SDP [RFC4566] and SDP Offer/ Answer [RFC3264] is used.
  • SSRC multiplexing will likely use a standalone attribute to indicate the usage of simulcast.
  • the first part is non-controversial.
  • the second one has significant impact on the signaling load in sessions with dynamic session participation.
  • SIP and SDP offer answer As each new participant endpoint device joins a multiparty session, the existing participant endpoint devices that need to know the binding will need to receive an updated list of bindings. If that is done in SIP and SDP offer answer, a SIP re-Invite is required for each such transaction.
  • SIP re-Invite is required for each such transaction.
  • the signaling channel may introduce additional delay before the receiver endpoint device can decode the media.
  • Session multiplexing results in one media description per version. It will be necessary to indicate which RTP sessions are in fact simulcast versions. For example, using a Media grouping semantics specific for this. Each of these sessions will be focused on the particular version they intended to transport.
  • Legacy fallback also needs to be considered, the impact on an endpoint that isn't simulcast enabled.
  • a legacy endpoint that doesn't understand the indication that different RTP payload types are for different purpose may be slightly confused by the large amount of possibly overlapping or identical RTP payload types.
  • a legacy endpoint device will not understand the grouping semantic. It might either understand the grouping framework and thus determine that they are grouped for some purpose or not understand grouping at all as the offer simply looks like several different media sessions.
  • the payload type multiplexed session cannot negotiate bandwidth for the individual versions without extensions.
  • the regular SDP bandwidth attributes can only negotiate the overall bandwidth that all versions will consume. This makes it difficult to determine that one should drop one or more versions due to lack of bandwidth between the peers.
  • SSRC multiplexing suffers the same issues as payload type multiplexing, unless additional signaling (SSRC level attributes) is added.
  • Session multiplexing can negotiate bandwidth for each individual version and determine to exclude a particular version, and have the full knowledge on what it excludes to avoid consuming a certain amount of bandwidth.
  • each version For the negotiation and setting of the media codec, e.g., the codec parameters and RTP payload parameters for the payload type multiplexing, it is possible for each version to be individually negotiated and set, by communications between the sender endpoint device and receiver endpoint device, because each version has unique payload types. The same is true for the session multiplexing where each version is negotiated by setting the parameters in the context of each RTP session. In endpoint device can be configured to provide additional signaling for the SSRC multiplexed version to enable a binding between the payload types and for which versions they are used. Otherwise, the RTP payload types are negotiated without any context of which version intends to use which payload type.
  • an endpoint device When an endpoint device negotiates or configures RTP and RTCP extensions, they can be done on either session level, in direct relation to one or several RTP payload types. They are not negotiated in the context of an SSRC. Thus payload type multiplexing will need to negotiate any session level extensions for all the versions without version specific consideration, unless extensions are deployed. It can also negotiate payload specific versions at a version individual level. SSRC multiplexing cannot negotiate any extension related to a certain version without extensions. Session multiplexing will have the full freedom of negotiating extensions for each version individually without any additional extensions.
  • Quality of Service When it comes to Quality of Service mechanisms (e.g., signaling between sender and receiver endpoint devices), they are either flow based or marking based. RSVP [RFC2205] is an example of a flow based mechanism, while Diff-Serv [RFC2474] is an example of a Marking based one. If an endpoint device uses a marking based scheme, the associated operations and methods of multiplexing will not affect the possibility to use QoS. However, if an endpoint device uses flow based scheme, there is a clear difference between these operations and methods and those of the marking based scheme.
  • Both the payload and SSRC multiplexing will have only one RTP session, not introducing any additional NAT traversal complexities compared to not using simulcast and only have a single version.
  • the session multiplexing is using one RTP session per simulcast version.
  • additional NAT/FW pinholes will be required.
  • sessions using simulcast will use multiple media, there will already be more than a single (pair) of pinholes needed anyway.
  • the additional pinhole will result in some extra delay in traversal mechanism such as ICE, however for mechanism that perform explicit control uPnP, NAT- PNP or PCP, such requests is expected to be possible to parallelize. Establishing additional pinholes will result in a slightly higher risk of NAT/FW traversal failure.
  • endpoint devices 111 To enable the usage of simulcast using session multiplexing some minimal signaling support are required to be provided by endpoint devices 111. That support is discussed in this section. First of all there is need for a mechanism performed by endpoint devices 111 to identify the RTP sessions carrying simulcast alternatives to each other.
  • a receiver endpoint device needs to be able to identify the SSRC in the different sessions that are of the same media source but in different encodings.
  • a sender endpoint device 111-1 When a sender endpoint device 111-1 performs simulcast, it will, for each actual media source, have one SSRC in each session for which it currently provides an encoding alternative in. As a receiver endpoint device 111-2 or a mixer 112 will receive one or more of these, it is important that any RTP session participant beyond the sender endpoint device 111-1 can explicitly identify which SSRCs in the set of RTP sessions providing a simulcast service that are the same media source. Two extensions to RTP are explained below for how to accomplish this in accordance with some embodiments.
  • Source Descriptions are an approach that should work with all RTP topologies (assuming that any intermediary node (e.g., Central node 112) is supporting this item) and existing RTP extensions. Thus we propose one defines a new SDES item called the
  • SRCNAME which identifies with an unique identifier a single media source, like a camera. That way even if multiple encodings or representations are produced, any endpoint device receiving the SDES information from a set of interlinked RTP sessions can determine which are the same source.
  • the SRCNAME may commonly be per-session unique random identifiers generated identifiers according to "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC6222].
  • This SRCNAME' s relation to CNAME is the following.
  • CNAME represents an endpoint device 111 and a synchronization context, if the different
  • representations should be played out synchronized and without overlap if switching between them, then need to be in the same synchronization context. Thus in almost all cases all SSRCs with the same SRCNAME will have the same CNAME.
  • a given CNAME may also contain multiple sets of sources using different SRCNAMEs.
  • Source-Specific Media Attributes in the Session Description Protocol defines a way of declaring attributes for SSRC in each session in SDP.
  • SDES Session Description Protocol
  • Such a mechanism should thus be optional to use, but as there is likely a general interest in such a mechanism.
  • Session multiplexing may have some additional overhead in the key-management but also provide the flexibility to exclude certain users from certain versions by using session specific keys and not allow all users access in the key-management. But this may have minimal benefit.
  • the multi-stream signaling has as other SDP based signaling issues with man in the middles that may modify the SDP as an attack on either the service in general or a particular endpoint. This can as usual be resolved by a security mechanism that provides integrity and source authentication between the signaling peers.
  • Figures 4-9 are flow charts that illustrate operations and methods that can be performed by sender endpoint devices to identify simultaneously communicated media streams as having related media data in accordance with some embodiments.
  • Figures 11-21 are flow charts that illustrate corresponding operations and methods that can be performed by receiver endpoint devices to identify and use the related media streams in accordance with some embodiments
  • Figure 4 illustrates operations and methods that can be performed by a sender endpoint device 111-1 to communicate (block 400) a plurality of media streams, simultaneously in time, for a session (e.g., a RTP session) toward a receiver endpoint device 111-2.
  • the sender endpoint device 111-1 also communicates (block 402) information toward the receiver endpoint device 111-2 that identifies which of the media streams contain related media data (content).
  • the sender endpoint device 111-1 can communicate (block 500) the media streams of simulcast media streams.
  • the sender endpoint device 111-1 can also communicate (block 502) information identifying which of the media streams contain different encoded versions of the same media content.
  • the sender endpoint device 111-1 can communicate (block 600) the media streams of simulcast media streams.
  • the sender endpoint device 111-1 can also communicate (block 602) information identifying which of the media streams contain different spatial sampled versions, temporal sampled versions, and/or lossy quality versions of a same media source.
  • the sender endpoint device 111-1 can communicate (block 700) the media streams of simulcast media streams.
  • the sender endpoint device 111-1 can also communicate (block 702) information identifying which of the media streams are from the sender endpoint device 111-1.
  • SSRCs and stream identifiers can be communicated to the receiver endpoint device 111-2 to identify groups of the media streams containing related media data across a plurality of RTP sessions.
  • the sender endpoint device 111-1 can communicate (block 800) the media streams toward the receiver endpoint device 111-2 through a plurality of different RTP sessions.
  • the sender endpoint device 111- 1 also communicates (block 802) information, using RTCP, including a plurality of SSRCs that each uniquely identify a different one of the RTP sessions, and further including at least one stream identifier defined to uniquely identify each group of the media streams containing related media content.
  • the SSRCs can be communicated through RTCP and the stream identifiers can be communicated through RTP as part of the media streams.
  • the sender endpoint device 111-1 can communicate (block 900) the media streams toward the receiver endpoint device 111-2 through a plurality of RTP sessions.
  • the SSRCs are communicated (block 902) via RTCP toward the receiver endpoint device 111-2.
  • Information including at least one stream identifier defined to uniquely identify each group of the media streams containing related media content is communicated (block 904) toward the receiver endpoint device (111-2).
  • the SSRCs and stream identifiers are communicated through SDP communications during setup of RTP sessions.
  • the sender endpoint device 111-1 can communicate (block 1000) the media streams toward the receiver endpoint device 111-2 through a plurality of RTP sessions.
  • Information can be communicated (block 1002) through SDP during setup of the RTP sessions, where the information includes a plurality of SSRCs that each uniquely identify a different one of the RTP sessions, and further includes at least one stream identifier defined to uniquely identify each group of the media streams containing related media content.
  • a receiver endpoint device 111-2 can perform the corresponding operations and methods of Figure 11 to receive, identify, and use the related media streams.
  • the receiver endpoint device 111-2 may be a RTP mixer or other endpoint device.
  • the receiver endpoint device 111-2 receives (block 1100) a plurality of media streams, simultaneously in time, from the sender endpoint device 111-1.
  • Information is also received (block 1102) from the sender endpoint device 111-1 that identifies which of the media streams contain related media data.
  • the receiver endpoint device 111-2 selects (block 1104) among the media streams responsive to the received information.
  • the receiver endpoint device 111-2 operates as a RTP mixer (central node) 112 that selectively forwards a media stream(s), such as described above in section 3.1.
  • the RTP mixer 112 selects (block 1200) at least one of the media streams responsive to the received information, and forwards (block 1202) the selected at least one media stream to another receiver endpoint device 111- 3.
  • the RTP mixer 112 may select among received media streams for output to the receiver endpoint device 111-3 responsive to user input that is received, for example, from a
  • Graphical User Interface associate with the receiver endpoint device 111-3. For example, when a user selects a video display window or deselects (e.g., hides) a video display widow on a display device, a responsive message can be communicated to the RTP mixer 112 that causes the RTP mixer to start sending a media stream to a newly displayed video window, stop sending a media stream to a newly hidden video window, and/or perform other operations which select among the received media streams for forwarding to the receiver endpoint device.
  • the receiver endpoint device 111-2 may perform the operations and methods of Figure 12.
  • the receiver endpoint device 111-2 selects (block 1200) at least one of the media streams responsive to the received information, and forwards (block 1202) the selected at least one media stream to the other receiver endpoint device 111-3.
  • the receiver endpoint device 111-2 may perform the operations and methods of Figure 13.
  • the sender endpoint device 111-1 may be configured to operate a scalable encoder to output a media stream, which may be sent as a single SSRC, to the receiver endpoint device 111-2.
  • the receiver endpoint device 111-2 may, in one embodiment, control what scalable coding is used by the sender endpoint device 111-1 to output the media stream.
  • he receiver endpoint device 111-2 is configured to select the media stream from the sender endpoint device 111-1 responsive to the received information, and to perform (block 1300) scalable video coding and/or transcoding on the media stream to generate at least one media stream, and forward (block 1302) the generated at least one media stream to the other receiver endpoint device 111-3.
  • the receiver endpoint device 111-2 operates as a RTP mixer (central node) 112 that combines at media content from at least two of the media streams, such as described above in section 3.1.
  • the receiver endpoint device 111-2 may perform the operations and methods of Figure 14.
  • the receiver endpoint device 111-2 selects (block 1400) at least two of the media streams responsive to the received information.
  • the selected at least two media streams are combined (block 1402) to generate a combined media stream.
  • the receiver endpoint device 111-2 forwards (block 1404) the combined media stream to the other receiver endpoint device 111-3.
  • the receiver endpoint device 111-2 can be configured to perform the operations and methods of Figures 15-17 which correspond to the sender endpoint device operations and methods of Figures 4-6.
  • the receiver endpoint device 111-2 receives (block 1500) the media streams as simulcast media streams from the sender endpoint device 111-1.
  • the receiver endpoint device 111-2 uses the received information to identify (block 1502) which of the media streams contain different encoded types of the same media content.
  • the receiver endpoint device 111-2 receives (block 1600) the media streams as simulcast media streams from the sender endpoint device 111-1, and uses the received information to identify (block 1602) which of the media streams contain different spatial sampled versions, temporal sampled versions, and/or lossy quality versions of a same media source.
  • the receiver endpoint device 111-2 receives (block 1700) the media streams as simulcast media streams from the sender endpoint device 111-1, and uses the received information to identify (block 1702) which of the media streams are from the sender endpoint device.
  • the SSRCs and stream identifiers may be used by a receiver endpoint device to identify groups of the media streams containing related media data across a plurality of RTP sessions.
  • a receiver endpoint device 111-2 simultaneously receives (block 1800) the media streams through a plurality of RTP sessions.
  • the received information includes a plurality of SSRCs that are each used by the receiver endpoint device 111-2 to uniquely identify (block 1802) a different one of the RTP sessions.
  • the received information further includes at least one stream identifier that is defined to enable the receiver endpoint device 111-2 to uniquely identify (block 1802) each group of the media streams containing related media content.
  • the SSRCs can be received through RTCP and the stream identifiers can be communicated through RTP as part of the media streams.
  • the receiver endpoint device 111-2 receives (block 1900) the media streams as simulcast media streams from the sender endpoint device 111-1.
  • the receiver endpoint device 111-2 also receives (block 1902) information, using RTCP, that includes a plurality of SSRCs that are each used to uniquely identify a different one of the RTP sessions.
  • the receiver endpoint device 111-2 also receives (block 1904) information, using RTP, that includes at least one stream identifier that is used to uniquely identify each group of the media streams containing related media content.
  • the SSRCs and stream identifiers can be received through SDP
  • the receiver endpoint device 111-2 receives (block 2000) the media streams as simulcast media streams from the sender endpoint device 111-1.
  • the receiver endpoint device 111-2 also receives (block 2002) information through SDP during setup of the RTP sessions, where the information includes a plurality of SSRCs that are each used to uniquely identify a different one of the RTP sessions, and further includes at least one stream identifier that is used to uniquely identify each group of the media streams containing related media content.
  • the endpoint device 111 of Figure 2 can be configured to perform the operations and methods of one or more of the embodiments of the sender endpoint device 111-1 of Figures 4-20. Accordingly, the network interface 133 of the sender endpoint device 111-1 can be configured to communicate over the network 101 with a receiver endpoint device 111-2.
  • the processor 131 of the endpoint device 111-1 can be configured to simultaneously communicate a plurality of media streams through at least one RTP session toward the receiver endpoint device 111-2, and to communicate information toward the receiver endpoint device 111-2 that identifies which of the media streams contain related media data.
  • the processor 131 of the sender endpoint device 111- 1 is further configured to communicate the plurality of media streams as simulcast media streams toward the receiver endpoint device 111-2, and the communicated information identifies which of the media streams contain different encoded types of the same media content and/or identifies which of the media streams contain different spatial sampled versions, temporal sampled versions, and/or lossy quality versions of a same media source.
  • the processor 131 of the sender endpoint device 111- 1 is further configured to communicate the plurality of media streams toward the receiver endpoint device 111-2 through a plurality of RTP sessions, and the information
  • the communicated toward the receiver endpoint device 111-2 includes a plurality of SSRCs that each uniquely identify a different one of the RTP sessions, and the information further includes at least one stream identifier defined to uniquely identify each group of the media streams containing related media content.
  • the processor 131 of the sender endpoint device 111- 1 is further configured to communicate the plurality of media streams toward the receiver endpoint device 111-2 through a plurality of RTP sessions, and the information
  • the communicated toward the receiver endpoint device 111-2 includes a plurality of SSRCs that each uniquely identify a different one of the RTP sessions, and the information further includes at least one stream identifier defined to uniquely identify each group of the media streams containing related media content.
  • the endpoint device 111 of Figure 2 can be alternatively or additionally be configured to perform the operations and methods of one or more of the embodiments of the receiver endpoint device 111-2 of Figures 4-20.
  • the network interface 133 of a receiver endpoint device 111-2 can be configured to communicate over the network 101 with a sender endpoint device 111-1.
  • the processor 131 of the receiver endpoint device 111-2 can be configured to simultaneously receive a plurality of media streams for at least one RTP session from the sender endpoint device 111-1, receive information from the sender endpoint device 111-1 that identifies which of the media streams contain related media data, and select among the media streams responsive to the received information.
  • the processor 131 of the receiver endpoint device 111-2 is further configured to receive the plurality of media streams as simulcast media streams from the sender endpoint device 111-1, and the received information identifies which of the media streams contain different encoded types of the same media content and/or identifies which of the media streams contain different spatial sampled versions, temporal sampled versions, and/or lossy quality versions of a same media source.
  • the processor 131 of the receiver endpoint device 111-2 is further configured to receive the plurality of media streams through a plurality of RTP sessions, and the received information includes a plurality of Synchronization Source Identifiers, SSRCs, that each uniquely identify a different one of the RTP sessions, and the received information further includes at least one stream identifier defined to uniquely identify each group of the media streams containing related media content. 14. Additional Receiver Endpoint Device Operations and Methods for Advertising its Capabilities for Simultaneously Receiving a Plurality of Media Streams During Negotiations with a Sender Endpoint Device
  • a receiver endpoint device 111-2 can advertises its capabilities for simultaneously receiving a plurality of media streams.
  • the receiver endpoint device 111-2 advertises (block 2100) its capability information to a sender endpoint device 111-1 that defines a capability of the receiver endpoint device 111-2 to simultaneously receive media streams.
  • the receiver endpoint device 111-2 receives (2102) the media streams at a same time (simultaneously) from the sender endpoint device 111-1 during the communication session based on the advertised capability information.
  • the receiver endpoint device 111-2 exchanges (block 2200) session negotiation information with the sender endpoint device 111- 1 to setup the communication session prior to receiving the plurality of media streams.
  • the receiver endpoint device 111-2 communicates the capability information to the sender endpoint device 111-1 as part of the session negotiation information.
  • the receiver endpoint device 111-2 communicates (2300) the capability information to the sender endpoint device 111-1 using SDP as part of re-negotiation communications with the sender endpoint device 111-1 to renegotiate the communication session.
  • the receiver endpoint device 111-2 waits (block 2400) for receipt of an acknowledgement message from the sender endpoint device 111-1 indicating agreement to constrain its communication of the media streams to the receiver endpoint device 111-2 according to the session negotiation information offered by the receiver endpoint device 111-2.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 advertises (block 2500) a maximum number of media streams that the receiver endpoint device 111-2 is presently capable of simultaneously receiving, and which is dependent upon the sender endpoint device 111-1 using a defined coding to encode data carried by the media streams.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 advertises (block 2600) a maximum combined bandwidth for all of the media streams and/or a maximum per-stream bandwidth that the receiver endpoint device 111-2 is presently capable of simultaneously receiving from the sender endpoint device 111- 1.
  • the maximum combined bandwidth for all of the media streams and/or the maximum per- stream bandwidth can be dependent upon the sender endpoint device 111-1 using a defined coding to encode data carried by the media streams.
  • the receiver endpoint device 111-2 can advertise (block 2700) which of a plurality of defined coding parameters that the sender endpoint device 111-1 should use to encode data carried by particular ones of the media streams to be communicated to the receiver endpoint device 111- 2.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 can advertise (block 2800) a token rate and a bucket size for a token bucket algorithm that will be performed by the receiver endpoint device 111-2 to constrain a data rate of media streams that will be simultaneously received from the sender endpoint device 111-1.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 can advertise (block 2900) a number of media streams containing related media data that can be simultaneously received by the receiver endpoint device 111-2.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 can advertise (block 3000) a number of media streams containing different encoded types of the same media content that can be simultaneously received.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 can advertise (block 3100) a number of media streams containing different spatial sampling versions, temporal sampling versions, and/or lossy quality versions of a same media source that can be simultaneously received.
  • the receiver endpoint device 111-2 when advertising (block 2100 of Figure 21) its capability information to the sender endpoint device 111-1, the receiver endpoint device 111-2 can advertise (block 3200) which of a plurality of different defined spatial sampled versions, temporal sampled versions, and/or lossy quality versions of a same media source that the sender endpoint device 111-1 should communicate as particular ones of the media streams to the receiver endpoint device 111-2.
  • a sender endpoint device 111-1 can advertises its capabilities for
  • the sender endpoint device 111-1 advertises (block 3300) its capability information to a receiver endpoint device 111-2 that defines a capability of the sender endpoint device 111-1 to simultaneously communicate a plurality of media streams.
  • the sender endpoint device 111-1 also communicates (block 3302) the plurality of media streams at a same time toward the receiver endpoint device (111-2) during the communication session based on the advertised capability information.
  • the sender endpoint device 111-1 exchanges (block 3400) session negotiation information with the receiver endpoint device 111-2 to setup the communication session prior to communicating the plurality of media streams.
  • the sender endpoint device 111-1 communicates the capability information to the receiver endpoint device 111-2 as part of the session negotiation information.
  • the sender endpoint device 111-1 communicates (block 3500) the capability information to the receiver endpoint device 111-2 using SDP as part of re-negotiation communications with the receiver endpoint device 111-2 to re-negotiate the communication session.
  • the sender endpoint device 111- 1 when advertising (block 3300) its capability information to the receiver endpoint device 111-2, the sender endpoint device 111- 1 can advertise (block 3600) a maximum number of media streams that the sender endpoint device 111-1 is presently capable of simultaneously communicating to the receiver endpoint device 111-2.
  • the sender endpoint device 111-1 may advertise (block 3600) that the maximum number of media streams is dependent upon the receiver endpoint device 111-2 being capable of using a defined coding to decode data carried by the media streams.
  • the sender endpoint device 111- 1 when advertising (block 3300) its capability information to the receiver endpoint device 111-2, the sender endpoint device 111- 1 can advertise (block 3700) a maximum per-stream bandwidth that the sender endpoint device 111-1 is presently capable of simultaneously sending to the receiver endpoint device 111-2.
  • the sender endpoint device 111-1 may advertise (block 3700) that the maximum per- stream bandwidth is dependent upon the receiver endpoint device 111-2 being capable of using a defined coding to decode data carried by the media streams.
  • the sender endpoint device 111-1 when advertising (block 3300) its capability information to the receiver endpoint device 111-2, the sender endpoint device 111-1 can advertise (block 3800) which of a plurality of defined coding parameters that the sender endpoint device 111-1 will use to encode data carried by particular ones of the media streams to be communicated to the receiver endpoint device 111-2.
  • the sender endpoint device 111-1 before communicating (block 3302) the plurality of media streams at a same time toward the receiver endpoint device 111-2, the sender endpoint device 111-1 can receive (block 3900) an advertised token rate and an advertised bucket size for a token bucket algorithm that will be performed by the receiver endpoint device 111-2 to receive the media streams. The sender endpoint device 111-1 can then constrain (block 3902) a data rate of the media streams that it simultaneously communicates to the receiver endpoint device (111-2) in response to the advertised token rate and the advertised bucket size.
  • the sender endpoint device 111-1 when advertising (block 3300) its capability information to the receiver endpoint device 111-2, the sender endpoint device 111-1 can advertise (block 4000) a number of media streams containing different spatial sampling versions, temporal sampling versions, and/or lossy quality versions of a same media source that are available to be simultaneously communicated to the receiver endpoint device 111-2.
  • the sender endpoint device 111- 1 when advertising (block 3300) its capability information to the receiver endpoint device 111-2, the sender endpoint device 111- 1 can advertise (block 4100) which of a plurality of different defined spatial sampling versions, temporal sampling versions, and/or lossy quality versions of a same media source that are available for communication from the sender endpoint device 111-1 as particular ones of the media streams to the receiver endpoint device 111-2.
  • node When a node is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another node, it can be directly connected, coupled, or responsive to the other node or intervening nodes may be present. In contrast, when an node is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another node, there are no intervening nodes present. Like numbers refer to like nodes throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.
  • the common abbreviation “e.g.” which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item.
  • Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits.
  • These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).
  • These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer- readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks.
  • a tangible, non-transitory computer-readable medium may include an electronic, magnetic, optical, electromagnetic, or semiconductor data storage system, apparatus, or device. More specific examples of the computer-readable medium would include the following: a portable computer diskette, a random access memory (RAM) circuit, a read-only memory (ROM) circuit, an erasable programmable read-only memory (EPROM or Flash memory) circuit, a portable compact disc read-only memory (CD-ROM), and a portable digital video disc read-only memory (DVD/BlueRay).
  • RAM random access memory
  • ROM read-only memory
  • EPROM or Flash memory erasable programmable read-only memory
  • CD-ROM compact disc read-only memory
  • DVD/BlueRay portable digital video disc read-only memory
  • the computer program instructions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus to produce a computer- implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.
  • embodiments of the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module” or variants thereof.
  • SDP Session Description Protocol
  • [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention se rapporte à des procédés adaptés pour commander un dispositif de point d'extrémité transmetteur (111-1) qui communique avec un dispositif de point d'extrémité récepteur (111-2). Le procédé selon l'invention consiste à transmettre (400) une pluralité de flux multimédias simultanément dans le temps, en direction du dispositif de point d'extrémité récepteur. Le procédé consiste par ailleurs à transmettre (402) des informations en direction du dispositif de point d'extrémité récepteur pouvant identifier les flux multimédias qui contiennent des données multimédias associées. La présente invention se rapporte d'autre part à des procédés adaptés pour commander un dispositif de point d'extrémité récepteur. L'invention se rapporte également à des dispositifs de point d'extrémité transmetteurs associés et à des dispositifs de point d'extrémité récepteurs associés.
PCT/EP2012/053860 2011-06-23 2012-03-07 Procédés et appareil pour identifier des flux multimédias rtp contenant des données multimédias associées WO2012175227A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161500333P 2011-06-23 2011-06-23
US61/500,333 2011-06-23

Publications (1)

Publication Number Publication Date
WO2012175227A1 true WO2012175227A1 (fr) 2012-12-27

Family

ID=45815536

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/EP2012/053861 WO2012175228A1 (fr) 2011-06-23 2012-03-07 Procédés et appareil pour informer de la capacité d'un dispositif de point d'extrémité à transmettre et à recevoir des flux multimédias simultanés
PCT/EP2012/053860 WO2012175227A1 (fr) 2011-06-23 2012-03-07 Procédés et appareil pour identifier des flux multimédias rtp contenant des données multimédias associées

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/053861 WO2012175228A1 (fr) 2011-06-23 2012-03-07 Procédés et appareil pour informer de la capacité d'un dispositif de point d'extrémité à transmettre et à recevoir des flux multimédias simultanés

Country Status (1)

Country Link
WO (2) WO2012175228A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2785001A1 (fr) * 2013-03-27 2014-10-01 Unify GmbH & Co. KG Procédé de négociation de médias entre un dispositif de communication source et un dispositif de communication de destination de multiplexage de multiples types de média sur une adresse de transport IP, produit de programme informatique pour exécuter le procédé et dispositif de communication source pour négocier des médias entre le dispositif de communication source et un dispositif de communication de destination
WO2015078220A1 (fr) * 2013-11-27 2015-06-04 华为技术有限公司 Procédé et dispositif destinés à la négociation de multiplexage de supports
WO2015153593A1 (fr) * 2014-03-31 2015-10-08 Polycom, Inc. Système et procédé associés à un système de conférence multimédia à topologie hybride
CN116980657A (zh) * 2023-09-25 2023-10-31 北京数盾信息科技有限公司 一种视频数据传输处理方法、装置及设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005002264A1 (fr) * 2003-06-27 2005-01-06 Nokia Corporation Procede et systeme de reservation de ressources dans un reseau de communications sans fil
US20100142413A1 (en) * 2007-03-29 2010-06-10 Anders Eriksson Media Stream Setup in a Group Communication System
US20100183000A1 (en) * 2009-01-22 2010-07-22 Hitachi, Ltd. Video delivering system, video delivering device, and synchronization correcting device

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1758334A1 (fr) * 2005-08-26 2007-02-28 Matsushita Electric Industrial Co., Ltd. Établissement des sessions média avec adaptation de média
WO2008081130A2 (fr) * 2006-12-22 2008-07-10 France Telecom Pont de conference mixte
US8892149B2 (en) * 2008-05-27 2014-11-18 Cisco Technology, Inc. Interoperability and communications system dynamic media proxy based on capability negotiation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005002264A1 (fr) * 2003-06-27 2005-01-06 Nokia Corporation Procede et systeme de reservation de ressources dans un reseau de communications sans fil
US20100142413A1 (en) * 2007-03-29 2010-06-10 Anders Eriksson Media Stream Setup in a Group Communication System
US20100183000A1 (en) * 2009-01-22 2010-07-22 Hitachi, Ltd. Video delivering system, video delivering device, and synchronization correcting device

Non-Patent Citations (18)

* Cited by examiner, † Cited by third party
Title
BEGEN, A.; PERKINS, C.; D. WING: "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs", RFC 6222, April 2011 (2011-04-01)
BRADEN, B.; ZHANG, L.; BERSON, S.; HERZOG, S.; S. JAMIN: "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997 (1997-09-01)
BRADNER, S.: "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (1997-03-01)
CAMARILLO G ERIKSSON J HOLLER ERICSSON H SCHULZRINNE COLUMBIA UNIVERSITY G: "Grouping of Media Lines in the Session Description Protocol (SDP); rfc3388.txt", 20021201, 1 December 2002 (2002-12-01), XP015009199, ISSN: 0000-0003 *
CAMARILLO, G.; H. SCHULZRINNE: "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010 (2010-06-01)
CROCKER, D.; P. OVERELL: "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008 (2008-01-01)
HANDLEY, M.; JACOBSON, V.; C. PERKINS: "SDP: Session Description Protocol", RFC 4566, July 2006 (2006-07-01)
HELLSTROM, G.; P. JONES: "RTP Payload for Text Conversation", RFC 4103, June 2005 (2005-06-01)
LENNOX VIDYO J OTT HELSINKI UNIVERSITY OF TECHNOLOGY T SCHIERL FRAUNHOFER HHI J: "Source-Specific Media Attributes in the Session Description Protocol (SDP); rfc5576.txt", SOURCE-SPECIFIC MEDIA ATTRIBUTES IN THE SESSION DESCRIPTION PROTOCOL (SDP); RFC5576.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 1 June 2009 (2009-06-01), XP015065612 *
LENNOX, J.; OTT, J.; T. SCHIERL: "Source-Specific Media Attributes in the Session Description Protocol (SDP", RFC 5576, June 2009 (2009-06-01)
NICHOLS, K.; BLAKE, S.; BAKER, F.; D. BLACK: "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998 (1998-12-01)
PANASONIC ET AL: "Proposal for RTP retransmission in PSS Release 6", 3GPP DRAFT; S4-030783, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG4, no. Tampere, Finland; 20031119, 19 November 2003 (2003-11-19), XP050286416 *
PERKINS, C.; M. WESTERLUND: "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010 (2010-04-01)
REY, J.; LEON, D.; MIYAZAKI, A.; VARSA, V.; R. HAKENBERG: "RTP Retransmission Payload Format", RFC 4588, July 2006 (2006-07-01)
ROSENBERG, J.; H. SCHULZRINNE: "An Offer/Answer Model with Session Description Protocol (SDP", RFC 3264, June 2002 (2002-06-01)
SCHULZRINNE, H.; CASNER, S.; FREDERICK, R.; V. JACOBSON: "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003 (2003-07-01)
WENGER, S.; CHANDRA, U.; WESTERLUND, M.; B. BURMAN: "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF", RFC 5104, February 2008 (2008-02-01)
WESTERLUND, M.; S. WENGER: "RTP Topologies", RFC 5117, January 2008 (2008-01-01)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2785001A1 (fr) * 2013-03-27 2014-10-01 Unify GmbH & Co. KG Procédé de négociation de médias entre un dispositif de communication source et un dispositif de communication de destination de multiplexage de multiples types de média sur une adresse de transport IP, produit de programme informatique pour exécuter le procédé et dispositif de communication source pour négocier des médias entre le dispositif de communication source et un dispositif de communication de destination
US10027732B2 (en) 2013-03-27 2018-07-17 Unify Gmbh & Co. Kg Method and system for negotiation of media between communication devices for multiplexing multiple media types
US10375138B2 (en) 2013-03-27 2019-08-06 Unify Gmbh & Co. Kg Method and system for negotiation of media between communication devices for multiplexing multiple media types
US10819765B2 (en) 2013-03-27 2020-10-27 Ringcentral, Inc. Method and system for negotiation of media between communication devices for multiplexing multiple media types
WO2015078220A1 (fr) * 2013-11-27 2015-06-04 华为技术有限公司 Procédé et dispositif destinés à la négociation de multiplexage de supports
WO2015153593A1 (fr) * 2014-03-31 2015-10-08 Polycom, Inc. Système et procédé associés à un système de conférence multimédia à topologie hybride
US9338401B2 (en) 2014-03-31 2016-05-10 Polycom, Inc. System and method for a hybrid topology media conferencing system
CN106464842A (zh) * 2014-03-31 2017-02-22 宝利通公司 用于混合式拓扑媒体会议系统的方法和系统
US9596433B2 (en) 2014-03-31 2017-03-14 Polycom, Inc. System and method for a hybrid topology media conferencing system
CN106464842B (zh) * 2014-03-31 2018-03-02 宝利通公司 用于混合式拓扑媒体会议系统的方法和系统
CN116980657A (zh) * 2023-09-25 2023-10-31 北京数盾信息科技有限公司 一种视频数据传输处理方法、装置及设备
CN116980657B (zh) * 2023-09-25 2023-12-26 北京数盾信息科技有限公司 一种视频数据传输处理方法、装置及设备

Also Published As

Publication number Publication date
WO2012175228A1 (fr) 2012-12-27

Similar Documents

Publication Publication Date Title
Westerlund et al. Rtp topologies
US10778731B2 (en) Communications methods, apparatus and systems for conserving media resource function resources
US20170034224A1 (en) Relaying multimedia conferencing utilizing software defined networking architecture
US10523730B2 (en) Real-time transport protocol (RTP) media conference server routing engine
US20150032857A1 (en) Mixer for providing media streams towards a plurality of endpoints whereby the media streams originating from one or more media source and method therefore
US10063643B2 (en) Media stream grouping in multimedia communication networks
WO2012175227A1 (fr) Procédés et appareil pour identifier des flux multimédias rtp contenant des données multimédias associées
Perkins et al. Media transport and use of RTP in webrtc
Westerlund et al. Guidelines for using the multiplexing features of RTP to support multiple media streams
Burman et al. RFC 8853: Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
Perkins et al. RFC 8834: Media Transport and Use of RTP in WebRTC
Stephens et al. SIP and H. 323—interworking VoIP networks
Alvestrand et al. Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams draft-ietf-avtcore-multiplex-guidelines-05
Westerlund et al. RFC 7667: RTP Topologies
Alvestrand Guidelines for using the Multiplexing Features of RTP draft-westerlund-avtcore-multiplex-architecture-03
Alvestrand Guidelines for using the Multiplexing Features of RTP draft-ietf-avtcore-multiplex-guidelines-00
WO2013057547A1 (fr) Procédés de communication fournissant une sélection de flux de contenu multimédia et système associé
Ott Network Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Informational M. Westerlund Expires: December 7, 2011 Ericsson
Audinate et al. RTP Clock Source Signalling draft-ietf-avtcore-clksrc-05
Ott RTCWEB Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: November 30, 2015 Ericsson
Ott RTCWEB Working Group CS Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: January 24, 2015 Ericsson
Ott RTCWEB Working Group CS Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: August 13, 2015 Ericsson
Ott RTCWEB Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: November 17, 2014 Ericsson
Ott RTCWEB Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: November 29, 2014 Ericsson
Ott RTCWEB Working Group CS Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund Expires: October 01, 2015 Ericsson

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12708807

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12708807

Country of ref document: EP

Kind code of ref document: A1