Re: [rtcweb] JSEP: RTP demux algorithms

Harald said:

"If we can segregate new requests for functionality into other documents,
I think that is a win."

[BA] In general, I agree with Harald.  However, there is one issue that I
do think that BUNDLE needs to address, which is what happens when there are
non-unique PTs.  JSEP Section 7 says:

      "If any payload type could map to more than one RtpReceiver, map to
      the RtpReceiver whose m= section appears earliest in the local
description."

While this is one way of handling it, there are implementations that
have solved the problem in a different way.  For example, I believe
that ORTC Lib maps to the RtpReceiver whose m= section contains no
specified SSRCs.

At this point, I do not feel strongly about *which* solution is
chosen, but since we have multiple non-interoperable BUNDLE
implementations, I would like the BUNDLE draft to add a sentence
choosing one approach, which can be referenced in JSEP Section 7.

On Tue, Oct 4, 2016 at 6:05 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 04. okt. 2016 14:29, skrev Christer Holmberg:
> > Hi,
> >
> >>> I still question why the low-level RTP demuxing shall be described in
> >>> JSEP, instead of e.g., BUNDLE.
> >>>
> >>> Keep in mind that all BUNDLE implementations may not implement JSEP,
> >>> but I
> >>> still think we want the RTP demuxing to be done in the same way?
> >>
> >> Does BUNDLE say how to handle RID?
> >
> > No. Cullen wanted more text, though, but I am not sure whether that
> > covered RID.
> >
> >> Seriously, please get BUNDLE out the door and don't tangle it in any
> >> more new stuff.
> >
> > If that was meant to me, I will pretend I didn¹t see itŠ
>
> It's actually a grave concern of mine - more addressed to the chairs of
> the relevant WGs than to anyone else.
>
> Any open document is a magnet for new functionality, and any new
> functionality delays the document's publication.
>
> The bundle document, with its associated changes in registration
> procedures for SDP attributes (the mux category), needs to be seen as
> stable. RFC publication is the best way to make it so.
>
> Datatracker says we've been working on this document since 2011. It's
> now at version -32, and was in state "Minor updates needed to address
> WGLC comments" in May.
>
> If we can segregate new requests for functionality into other documents,
> I think that is a win.
>
> Harald
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>