Scribd
Upload
42 views11 pages

Webrtc Media Transport and Use of RTP

This document discusses the open issues regarding the use of RTP for media transport in WebRTC. It outlines several remaining topics to address, such as signaling coding capability, topologies, simulcast, forwarding media, differentiated services, mapping to the W3C API, and correlating media streams. The draft seeks feedback on resolving these issues to complete the specification.

Uploaded by

sitaram_1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
42 views11 pages

Webrtc Media Transport and Use of RTP

This document discusses the open issues regarding the use of RTP for media transport in WebRTC. It outlines several remaining topics to address, such as signaling coding capability, topologies, simulcast, forwarding media, differentiated services, mapping to the W3C API, and correlating media streams. The draft seeks feedback on resolving these issues to complete the specification.

Uploaded by

sitaram_1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

WebRTC Media Transport and Use of RTP

draft-ietf-rtcweb-rtp-usage-10
Colin Perkins University of Glasgow
Magnus Westerlund Ericsson
Jrg Ott Aalto University
Changes Since Last Meeting

Changes in -08:

Rewrote Section 12 (RTP Implementation Considerations)

Removed most of the Appendix (Supported RTP Topologies), moving


the remainder into Section 12

Changes in -09:

Updated references

Changes in -10:

Clarified that keying for RTP/SAVPF profile specified in security-arch draft

Clarified that an endpoint can have multiple RTCP CNAMEs if it sends


streams synchronised to multiple clocks

Clarified that the RTP circuit breaker is a boundary condition, and that
applications also need to implement congestion control

Clarified that RTP/AVPF + DTLS-SRTP keying is mandatory to implement


2
Open Issues

Several open issues remain to discuss:

Signalling coding capability

Signalling RTP topologies

Simulcast

Forwarding media

Use of differentiated services

Mapping to W3C API

Correlating media streams

Would like to resolve most of these this week

Some might be resolved by moving the discussion to separate drafts


3
Open Issue: Signalling Coding Capability

Do endpoints need to signal limitations in their


capability to encode or decode some number of
simultaneous streams?

One possible proposal is in draft-westerlund-mmusic-max-ssrc-02

Defines media-level a=max-send-ssrc: and a=max-recv-ssrc: SDP attributes

Are media-level attributes sufficient when using the SDP bundle extensions?

Currently just require support for use of multiple simultaneous SSRC


values in a single RTP session with no limit on the number of SSRCs or
flows that can be encoded/decoded

Affects Section 4.1 and Section 12.1.1


4
Open Issue: Signalling RTP Topologies

WebRTC endpoints use one or more RTP sessions


in the context of a PeerConnection

Each RTP session can convey several RTP media streams, possibly from
several capture devices, representing layered coding, or for FEC

Each RTP session can extend beyond the scope of single PeerConnection
if the remote endpoint is an RTP mixer or other middlebox

The draft mandates support for multiple SSRCs per RTP session, but not
for multiple synchronisation contexts (CNAMEs) or for multiple endpoints;
should it?

Do we need to add discussion of SDP signalling for


the different scenarios?

If so, should it be a separate draft? (JSEP?)


5
Open Issue: Simulcast

Broad agreement that simulcast is in scope, but the


method for achieving simulcast has to be decided

Will be discussed in AVTEXT on Tuesday and MMUSIC on Thursday

Does simulcast require RTP-level mechanisms


beyond those specified?

If so, what? draft-westerlund-avtcore-rtp-simulcast-03 is one proposal

If not, do we need to specify signalling for simulcast in this draft, or does it


go elsewhere? May relate to the W3C API to RTP mapping (later slide!)
6
Open Issue: Forwarding Media

Endpoints can participate in multiple RTP sessions

This potentially lets them forward RTP media data


between peers

Directly relay RTP packets, acting as an RTP translator

Decode then re-encode and transmit the media data

Should media forwarding be allowed?

May be natural to support in the W3C API

Requires forwarding browser be aware of congestion state on both paths

Two implementation choices exist: browser supports multiple disjoint RTP


sessions with media transcoding or browser acts as an RTP translator
between sessions, forwarding media and translating/forwarding RTCP
feedback
7
Open Issue: Differentiated Services

Differentiated services possible on a transport flow


basis using existing mechanisms

Details omitted from this draft they require no RTP-level mechanisms

Sufficient complexity in passing markings between domains, and with the


API to mark packets

Various early proposals to give per-packet marking

Use differentiated services field on a per-packet basis

Use RTP header extension with deep-packet inspection or middleboxes

Proposals are not finished; interaction with congestion control algorithms


and AQM is unclear

Recommendation: this draft outlines the issues, but


makes no concrete recommendation
8
Open Issue: Mapping to W3C API

The mapping between the W3C API and RTP level


concepts has to be agreed and documented

Does this go into Section 11 of this draft, or is it part of the W3C API
specification?

Magnus has a detailed presentation of the issues propose an ad-hoc


discussion meeting later this week to discuss
9
Open Issue: Correlating Media Streams

How can we correlate RTP media streams with the


signalling? How do we correlate related RTP media
streams?

Signalled SSRC values or unique payload types per m= line can provide
static correlation between SDP m= lines and RTP media flows

Limited functionality, but the mechanisms exist to do this already

Section 5.2.4: do we need to mandate an RTP header extension that can


be used for dynamic correlation of RTP media streams with signalling?

RTCP SDES SRCNAME (draft-westerlund-avtext-rtcp-sdes-srcname-03) with RTP header


extension for RTCP SDES (draft-westerlund-avtext-sdes-hdr-ext-01) discuss in AVTEXT

Application ID header extension & RTCP SDES item (draft-even-mmusic-application-token-01)


was discussed in MMUSIC this morning

Media stream ID (draft-ietf-mmusic-msid-01)

May depend on details of the mapping between W3C API and RTP

Section 12.2.4: does this draft need to say anything about the signalling
for the unified plan? If so, what?
10
Next Steps

Resolve these open issues feedback is needed!

Submit updated draft and go to WG last call


11

You might also like