New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebRTC 1.0: Unhandled RTP streams #163
Comments
Here are some proposed changes to Section 8 in order to sync with the pull request:
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)] onunhandledrtp of type EventHandler, , nullable transport of type RTCDtlsTransport, readonly 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 { [Constructor(DOMString type, RTCRtpUnhandledEventInit eventInitDict)] mid of type DOMString, readonly payloadType of type payloadtype, readonly ssrc of type unsigned long, readonly 8.5.2 Dictionary RTCRtpUnhandledEventInit Members mid of type DOMString payloadType of type payloadtype ssrc of type unsigned long |
#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
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. |
What use cases where media would be discarded rather than unhandled? |
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. |
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.
The text was updated successfully, but these errors were encountered: