Proposal: RtpListener for unsignalled ssrcs #32

Closed
aboba opened this Issue Feb 15, 2014 · 4 comments

Projects

None yet

2 participants

@aboba
Contributor
aboba commented Feb 15, 2014

From: Peter Thatcher pthatcher@google.com
Date: Thu, 13 Feb 2014 11:23:56 -0800
To: "public-orca@w3.org" public-orca@w3.org
URL: http://lists.w3.org/Archives/Public/public-orca/2014Feb/0022.html

With the move to RtpSender/RtpReceiver, we have one thing we're missing
from RTP that can't be put in either of them: an event for unsignalled
ssrcs. We want such an event, but right now we don't have a clear place to
put it. I propose we add a class called RtpListener which, like
RtpReceiver, wraps a DtlsTransport, and fires events for RTP received.
Unlike RtpReceiver, which handles the RTP for a given set of ssrcs, the
RtpListener can listen to all RTP and fire an event if a packet is already
process by an existing RtpReceiver. Here's how I propose RtpListener
should look:

[Constructor(RTCDtlsTransport)]
interface RTCRtpListener {
readonly attribute RTCDtlsTransport transport;
// fires RTCRtpUnhandledRtpEvent;
attribute EventHandler? onunhandledrtp;
}

interface RTCRtpUnhandledRtpEvent : Event {
readonly attribute unsigned int ssrc;
readonly attribute unsigned byte payloadType;
// AKA "AppID" header extension
readonly attribute DOMString? receiverId;
}

That's it :). It's simple, but it grants a lot more flexibility to the
application to signal things (or not signal things) how it wants.

@martinthomson
Member

I assume that you only want to fire this once for a given stream, but what are the uniqueness properties that you want to key on? Just SSRC? SSRC + PT? All three attributes on the event?

I found that it helps to buffer a couple of packets, particularly if this is video inbound. Since this event isn't synchronous, the time it takes to fire and process the event is all you need to cover. Might want to recommend that a tiny number of packets or small number of bytes be kept.

@aboba
Contributor
aboba commented Feb 26, 2014

I would suggest that the event be fired once for a given stream if no matching active RtpReceiver object is found. The search for a match would be based on tuples of Payload Type, (nullable) SSRC and (nullable) receiverId, If the SSRC and receiverId are not configured, then the match would occur based on the Payload Type, which would be useful for audio scenarios (where only one stream at a time is expected) as well as receiving simulcast (where the mixer may change from one stream to another without signaling). If the SSRC is configured, then both the Payload Type and SSRC need to match.

@aboba
Contributor
aboba commented Mar 7, 2014

Consensus seems to be to go with option #2. Behavior of appId/SSRC latching is still undefined, but that is an issue in draft-even-mmusic-application-token, not an ORTC API issue per se.

@aboba
Contributor
aboba commented Apr 4, 2014

We will file another issue for the matching behavior, but looks like this one is resolved.

@aboba aboba closed this Apr 4, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 12, 2014
Robin Raymond Support for contributing source information added, as described in w3…
…c#27

Support for control of quality, resolution, framerate and layering added, as described inhttps://github.com/openpeer/ortc/issues/31
RTCRtpListener object added and figure in Section 1 updated, as described in w3c#32
More complete support for RTP and Codec Parameters added, as described in w3c#33
Data Channel transport problem fixed, as described in w3c#34
Various NITs fixed, as described in w3c#37
Section 2.2 and 2.3 issues fixed, as described in w3c#38
Default values of some dictionary attributes added, to partially address the issue described in w3c#39
Support for ICE TCP added, as described in w3c#41
Fixed issue with sequences as attributes, as described in w3c#43
Fix for issues with onlocalcandidate, as described in w3c#44
Initial stab at a Stats API, as requested in w3c#46
Added support for ICE gather policy, as described in w3c#47
b536737
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment