Re: [rtcweb] JSEP: RTP demux algorithms

Peter Thatcher <pthatcher@google.com> Fri, 16 September 2016 18:48 UTC

MIME-Version: 1.0
In-Reply-To: <CAJrXDUHAc9Gi=sqtFdZ4F-HjY-8w1m=6pJ2VjfkFAhrt_ja9rw@mail.gmail.com>
References: <CAOW+2dtN-tfmnsep8FjOFD2R2uZbUwZxHfDGBwx3N13Ue9Nb2w@mail.gmail.com> <CAJrXDUHAc9Gi=sqtFdZ4F-HjY-8w1m=6pJ2VjfkFAhrt_ja9rw@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 16 Sep 2016 11:47:33 -0700
Message-ID: <CAJrXDUG=AaYvEeV-U=nGEcS1M=E+ihO63K0tsqWkubwaAqnoRA@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: multipart/alternative; boundary="001a1141d9c49eae8a053ca467a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/UBLO4YkOxefSXGsxiI1x2nCc4sY>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, Robin R <robin@myjoe.com>
Subject: Re: [rtcweb] JSEP: RTP demux algorithms
Precedence: list

By the way, as I mentioned elsewhere, I think we should not use RIDs for
demux between RtpReceivers, and only use them within an RtpReceiver.  Demux
between RtpReceivers should be done with MID.

On Fri, Sep 16, 2016 at 11:45 AM, Peter Thatcher <pthatcher@google.com>
wrote:

> I agree 100% that having a set of unit tests for the demux alogirthm.  I
> found it very difficult to write the algorithm in a way that covered all
> the known cases by just keeping all the cases in my head.  Any tweak (like
> swapping step 2 and step 3) can break something that you forget about.
> Having a set of unit tests would help a lot.
>
> I think we would need to formulate a unit test like this.  Each test is a
> series of 3 operations:
>
> 1.  Add an RtpReceiver with MID A, SSRCs 1, 2, 3, and PTs 4, 5, 6.
> 2.  Route a packet with MID X (or unset), SSRC 1, PT 2.
> 3.  Remove an RtpReceiver
>
>
> Then we have tests like:
>
> 1.  Add X
> 2.  Add Y
> 3.  Route Z
>
> Or:
>
> 1.  Add X
> 2.  Route Y
> 3.  Add Y
> 4.  Remove X
> 4.  Route Z
>
>
> Then I could write a little python to check these things.
>
>
>
> On Wed, Sep 14, 2016 at 10:49 AM, Bernard Aboba <bernard.aboba@gmail.com>
> wrote:
>
>> There is now a JSEP PR relating to RTP demux algorithms:
>> https://github.com/rtcweb-wg/jsep/pull/320
>>
>> Rather than commenting in detail on that PR in this post, I would like to
>> prove some thoughts on how we evaluate proposed RTP demux algorithms.
>>
>> The goal of an RTP demux algorithm is to determine whether an incoming
>> RTP packet received on a DtlsTransport can be forwarded to one of the
>> RtpReceivers attached to that DtlsTransport.  If none of the RtpReceivers
>> qualify, then the packet is either dropped (WebRTC 1.0) or generates an RTP
>> unhandled event (ORTC).
>>
>> In principle, RTP demux algorithms do not seem complicated, since they
>> often can be expressed in less than half a dozen steps, typically with less
>> than a page of text.
>>
>> However, in practice the difficulty has turned out to be not in stating
>> an algorithm, but in evaluating whether it is correct. This challenges
>> include:
>>
>> 1. Agreement on a set of use cases and desired outcomes that a proposed
>> algorithm must satisfy.  Think of this as a set of regression tests that
>> insure that a proposed algorithm behaves as we expect, as well as ensuring
>> that changes to that algorithm do not result in unintended consequences.
>>
>> 2. Agreement on all the inputs that the algorithm takes into account.
>> This includes fields within the RTP packet (e.g. SSRC, PT, RID, MID, etc.)
>> as well as methods within the API (e.g. setLocalDescription,
>> setRemoteDescription, setParameters, etc.).
>>
>> With respect to Issue #1, some of the trickiest use cases involve both PT
>> and SSRC signaling, SSRC "latching" and handling FEC and RTX.  Examples
>> include:
>>     a. Change of SSRCs (e.g. due to conflict).
>>     b. Codec switching (e.g. changing PT but same SSRC, or changing both
>> PT and SSRC).
>>     c. Use of both FEC and RTX (and perhaps RTX of FEC).
>>
>> IMHO it would be useful to come up a few (less than half a dozen) use
>> cases with agreed-upon outcomes.
>>
>> With respect to Issue #2, the proposed algorithms so far look at the SSRC
>> & PT fields in the RTP header as well as the MID RTP extension.  However, I
>> have not seen algorithms which take into account the role of the RID RTP
>> extension.  So agreement on whether the RID needs to be considered or not
>> would be helpful.
>>
>> Also, for WebRTC 1.0 it would appear to me that the algorithm will depend
>> on the inputs to the setLocalDescription/setRemoteDescription methods,
>> so that there is a potential dependency on the signaling state of the
>> PeerConnection.
>>
>> Overall, I believe that the discussion of RTP demux algorithms is likely
>> to go more smoothly (and conclude more quickly) if we get agreement on
>> these meta-issues upfront.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

[rtcweb] JSEP: RTP demux algorithms Bernard Aboba
Re: [rtcweb] JSEP: RTP demux algorithms Cullen Jennings
Re: [rtcweb] JSEP: RTP demux algorithms Bernard Aboba
Re: [rtcweb] JSEP: RTP demux algorithms Cullen Jennings
Re: [rtcweb] JSEP: RTP demux algorithms Cullen Jennings
Re: [rtcweb] JSEP: RTP demux algorithms Peter Thatcher
Re: [rtcweb] JSEP: RTP demux algorithms Peter Thatcher
Re: [rtcweb] JSEP: RTP demux algorithms Jonathan Lennox
Re: [rtcweb] JSEP: RTP demux algorithms Cullen Jennings
Re: [rtcweb] JSEP: RTP demux algorithms Jonathan Lennox
Re: [rtcweb] JSEP: RTP demux algorithms Magnus Westerlund
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg
Re: [rtcweb] JSEP: RTP demux algorithms Magnus Westerlund
Re: [rtcweb] JSEP: RTP demux algorithms Bernard Aboba
Re: [rtcweb] JSEP: RTP demux algorithms Bernard Aboba
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg
Re: [rtcweb] JSEP: RTP demux algorithms Harald Alvestrand
Re: [rtcweb] JSEP: RTP demux algorithms Magnus Westerlund
Re: [rtcweb] JSEP: RTP demux algorithms Harald Alvestrand
Re: [rtcweb] JSEP: RTP demux algorithms Iñaki Baz Castillo
Re: [rtcweb] JSEP: RTP demux algorithms Bernard Aboba
Re: [rtcweb] JSEP: RTP demux algorithms Iñaki Baz Castillo
Re: [rtcweb] JSEP: RTP demux algorithms Colin Perkins
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg
Re: [rtcweb] JSEP: RTP demux algorithms Colin Perkins
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg
Re: [rtcweb] JSEP: RTP demux algorithms Harald Alvestrand
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg
Re: [rtcweb] JSEP: RTP demux algorithms Harald Alvestrand
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg
Re: [rtcweb] JSEP: RTP demux algorithms Bernard Aboba
Re: [rtcweb] JSEP: RTP demux algorithms Christer Holmberg