Re: [rtcweb] JSEP: RTP demux algorithms

Hi,

I also want to point out that BUNDLE already have a section on how to demux RTP, so it’s not completely new functionality – it’s to make sure the existing functionality is correct.

Regards,

Christer

From: Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>>
Date: Wednesday 5 October 2016 at 00:58
To: Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>>
Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>, Colin Perkins <csp@csperkins.org<mailto:csp@csperkins.org>>, "rtcweb@ietf.org<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
Subject: 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<mailto: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<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb