WebRTC 1.0: Unhandled RTP streams #163

Closed
aboba opened this Issue Dec 1, 2014 · 4 comments

Projects

None yet

2 participants

@aboba
Contributor
aboba commented Dec 1, 2014

The WebRTC 1.0 API now has a pull request relating to unhandled RTP media streams:
w3c/webrtc-pc#29

This involves definition of an RTCMediaDiscardedEvent.

@aboba
Contributor
aboba commented Dec 2, 2014

Here are some proposed changes to Section 8 in order to sync with the pull request:

  1. The RTCRtpListener Object

The RTCRtpListener listens to RTP packets received from the RTCDtlsTransport, determining whether an incoming RTP stream is configured to be processed by an existing RTCRtpReceiver object. If no match is found, the unhandledrtp event is fired. This can be due to packets having an unknown SSRC, payload type or any other error that makes it impossible to attribute an RTP packet to a specific RTCRtpReceiver object. The event is not fired once for each arriving packet; multiple discarded packets for the same SSRC should result in a single event.

Note that application handling of the unhandledrtp event may not be sufficient to enable the unhandled RTP stream to be rendered. The amount of buffering to be provided for unhandled RTP streams is not mandated by this specification and is recommended to be strictly limited to protect against denial of service attacks. Therefore an application attempting to create additional RTCRtpReceiver objects to handle the incoming RTP stream may find that portions of the incoming RTP stream were lost due to insufficient buffers, and therefore could not be rendered.

8.1 Overview

An RTCRtpListener instance is associated to an RTCDtlsTransport.

8.2 Operation

An RTCRtpListener instance is constructed from an RTCDtlsTransport object.

8.3 Matching rules

To determine whether an RTP stream is configured to be processed by an existing RTCRtpReceiver object, the RTCRtpListener attempts to match the values of an incoming RTP packet's Payload Type and SSRC fields as well as the value of the muxId (if present in the MID RTP header extension) against the RTCRtpReceiver.RTCRtpParameters.RTCRtpCodecParameters.payLoadType, RTCRtpReceiver.RTCRtpParameters.RTCRtpEncodingParameters.ssrc, and RTCRtpReceiver.RTCRtpParameters.muxId attributes of configured RTCRtpReceiver objects.

TODO: provide details of matching behavior, along with examples.

8.4 Interface Definition

[Constructor(RTCDtlsTransport transport)]
interface RTCRtpListener {
readonly attribute RTCDtlsTransport transport;
attribute EventHandler? onunhandledrtp;
};
8.4.1 Attributes

onunhandledrtp of type EventHandler, , nullable
The event handler which handles the RTCRtpUnhandledRtpEvent, which is fired when the RTCRtpListener detects an RTP stream that is not configured to be processed by an existing RTCRtpReceiver object.

transport of type RTCDtlsTransport, readonly
The RTP RTCDtlsTransport instance.

8.5 RTCRtpUnhandledEvent

The unhandledrtp event of the RTCRtpListener object uses the RTCRtpUnhandledEvent interface.

Firing an RTCRtpUnhandledEvent event named e means that an event with the name e, which does not bubble (except where otherwise stated) and is not cancelable (except where otherwise stated), and which uses the RTCRtpUnhandledEvent interface must be created and dispatched at the given target.

dictionary RTCRtpUnhandledEventInit : EventInit {
unsigned long ssrc;
payloadtype payloadType;
DOMString mid;
};

[Constructor(DOMString type, RTCRtpUnhandledEventInit eventInitDict)]
interface RTCRtpUnhandledEvent : Event {
readonly attribute unsigned long ssrc;
readonly attribute payloadtype payloadType;
readonly attribute DOMString mid;
};
8.5.1 Attributes

mid of type DOMString, readonly
The value of the MID RTP header extension [BUNDLE] in the RTP stream triggering the unhandledrtp event.

payloadType of type payloadtype, readonly
The Payload Type value in the RTP stream triggering the unhandledrtp event.

ssrc of type unsigned long, readonly
The SSRC in the RTP stream triggering the unhandledrtp event.

8.5.2 Dictionary RTCRtpUnhandledEventInit Members

mid of type DOMString
If present, the value of the MID RTP header extension [BUNDLE] in the RTP stream triggering the unhandledrtp event.

payloadType of type payloadtype
The Payload Type value in the RTP stream triggering the unhandledrtp event.

ssrc of type unsigned long
The SSRC in the RTP stream triggering the unhandledrtp event.

@aboba aboba added the 1.0 label Dec 2, 2014
@robin-raymond robin-raymond pushed a commit that referenced this issue Jan 22, 2015
Robin Raymond Updated Section 8.3 to reflect proposed matching rules, reflecting:
#48

Update to the Statistics API, reflecting:
#85

Update on 'automatic' use of scalable video coding, as noted in:
#156

Update to the H.264 parameters, as noted in:
#158

Update to the 'Big Picture', as noted in:
#159

Added support for maxptime, as noted in:
#160

Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in:
#161

Update to RTCRtpUnhandledEvent as noted in:
#163

Added support for RTCIceGatherer.state as noted in:
#164

Revised the text relating to RTCIceTransport.start() as noted in:
#166

Added text relating to DTLS interoperability with WebRTC 1.0, as noted in:
#167

Revised the text relating to RTCDtlsTransport.start() as noted in:
#168

Clarified handling of incoming connectivity checks by the RTCIceGatherer as noted in:
#170

Added a reference to the ICE consent specification, as noted in:
#171
a927ecf
@aboba
Contributor
aboba commented Jan 28, 2015

At the ORTC CG meeting on January 27, 2015 the question was raised about whether the WebRTC 1.0 RTCMediaDiscardedEvent was designed to deal with incoming RTP streams which were unsignaled, or whether this (or another event) was to deal with malformed packets that would have to be discarded. Sentiment was to stay with unhandledrtp event, but to investigate the need for a mediadiscarded event as well.

@robin-raymond
Contributor

What use cases where media would be discarded rather than unhandled?

@robin-raymond
Contributor

I think the discarded event is because media cannot be routed to an m line for decoding. In SDP world, there's no easy fix because you need to do an offer / answer exchange and by the time you complete O/A it's too late to fix so discarded is appropriate. But in ORTC we can fix this without any O/A so therefor it's unhandled since a new receiver object can quickly be setup.

@aboba aboba closed this Apr 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment