Subject: Re: [rtcweb] JSEP: RTP demux algorithms

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Oct 2016 12:41:09 +0100

> On 26 Sep 2016, at 10:35, Harald Alvestrand <[email-masked]> wrote:
> 
> Den 26. sep. 2016 11:14, skrev Magnus Westerlund:
>> Den 2016-09-26 kl. 10:48, skrev Harald Alvestrand:
>>> Den 23. sep. 2016 10:56, skrev Magnus Westerlund:
>>>> Hi,
>>>> 
>>>> I think the use cases looks fairly covering.
>>>> 
>>>> I want to add an alternative way of thinking on how the SDES item (MID,
>>>> RID) related demultiplexing part is handled. So the RID and MID in RTP
>>>> header extensions or in RTSP SDES packets results in these values being
>>>> bound to the SSRC until further notice. So packets arriving without
>>>> actual RTP header extensions can still be handled according to the SSRCs
>>>> associated SDES items. From my perspective all the cases with MID and
>>>> RID can be handled on a per packet basis rules without latching the SSRC
>>>> to a specific receiver. Instead what is "latched" is the SDES values to
>>>> the SSRC. Still at the point of change there needs to take the
>>>> combination of SSRC and Seq into account to avoid miss routing packets.
>>>> 
>>>> So my general handling algorithm would be this sequence:
>>>> 
>>>> 1. Check if RTP header extensions update any SDES item for the SSRC.
>>>>   a. If they do, mark the Sequence number and keep the old SDES item as
>>>> valid prior to this extended sequence number.
>>>> 
>>>> 2. Determine the set of relevant SDES items that applies for this
>>>> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and
>>>> RID.
>>>> 
>>>> 3. Perform the demuxing algorithm
>>> 
>>> I don't understand this as written.
>>> When an RTP packet arrives before the RTCP packet containing SDES, we
>>> can't latch to the content of the RTCP packet; we haven't seen it yet.
>> 
>> So if neither RTP header extension nor RTCP SDES item with RID/MID for
>> that SSRC has been received, then you don't have that information and
>> you will have to either queue or drop that packet if the relation isn't
>> otherwise clear through PT or SSRC signalling in SDP.
>> 
>>> 
>>> You can, in theory, latch RID and MID for the SSRC to the values in the
>>> SDES packet you haven't seen yet, but that seems somewhat backwards.
>>> 
>>> The problematic sequence is:
>>> 
>>> 1) RTP packet(s) with header extensions
>>> 2) RTP packet(s) without header extensions
>>> 3) SDES RTCP packet
>> 
>> I don't see why the above is problematic. Step one gives you the SDES
>> item for that SSRC. Thus in step 2 one knows that the SSRC has the
>> MID/RID value that you need.
>> 
>> I don't understand why you are not binding the SDES info from the RTP
>> header extension to the SSRC.
> 
> OK, I had missed the change of the RID header extension from being its
> own header extension to being a component of the SDES header extension only.
> 
> Then it all makes sense! Thanks!

I think I agree with Magnus. RTP flows are based around SSRCs, so the key to demultiplexing is that RTP packets are grouped by SSRC, then that SSRC is mapped to some higher level role based on some combination of signalled SSRC, MID, RID, etc. 

I’d suggest that the right way to write Section 7 of JSEP is not “how to route RTP packets”, as RTP packets are always grouped by SSRC, but rather how to map SSRCs to higher-level roles, based on updates of the mapping received in SDP, RTCP SDES, and RTP header extensions.

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 12:00:38 +0000

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?

Regards,

Christer

On 04/10/16 14:41, "rtcweb on behalf of Colin Perkins"
<[email-masked] on behalf of [email-masked]> wrote:

>I think I agree with Magnus. RTP flows are based around SSRCs, so the key
>to demultiplexing is that RTP packets are grouped by SSRC, then that SSRC
>is mapped to some higher level role based on some combination of
>signalled SSRC, MID, RID, etc.
>
>I¹d suggest that the right way to write Section 7 of JSEP is not ³how to
>route RTP packets², as RTP packets are always grouped by SSRC, but rather
>how to map SSRCs to higher-level roles, based on updates of the mapping
>received in SDP, RTCP SDES, and RTP header extensions.
>
>-- 
>Colin Perkins
>https://csperkins.org/
>
>
>
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Oct 2016 13:09:14 +0100

> On 4 Oct 2016, at 13:00, Christer Holmberg <[email-masked]> wrote:
> 

Don’t you need both? 

BUNDLE would specify how to map an RTP SSRC onto something described in SDP, using the combination of a=ssrc: lines, and the information carried in RTCP and RTP header extensions (MID, RID, etc.). That is, it maps SSRC -> “role”.

JSEP would specify how to map that “role” onto the concepts visible in the Javascript API.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 12:18:09 +0000

Hi,

>Don¹t you need both?

Yes.

>BUNDLE would specify how to map an RTP SSRC onto something described in
>SDP, using the combination of a=ssrc: lines, and the information carried
>in RTCP and RTP header extensions (MID, RID, etc.). That is, it maps SSRC
>-> ³role².

Yes.

>JSEP would specify how to map that ³role² onto the concepts visible in
>the Javascript API.

Yes. But, based on the discussions it seems like JSEP would define what
you suggest should be done in BUNDLE.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 4 Oct 2016 14:23:30 +0200

> still think we want the RTP demuxing to be done in the same way?

Does BUNDLE say how to handle RID?

Seriously, please get BUNDLE out the door and don't tangle it in any
more new stuff.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 12:29:07 +0000

Hi,

>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

If that was meant to me, I will pretend I didn¹t see itŠ

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 4 Oct 2016 15:05:38 +0200

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 13:43:43 +0000

Hi,

>If we can segregate new requests for functionality into other documents,

It’s not the addition of new functionality that has caused the delay.
Whenever we’ve decided to add some new functionality, the process has been
rather fast and smooth - thanks to everyone who have provided text and
input.

What is causing the delay is the never-ending requests for editorial
changes (many of which are not done using a simple search/replace - they
often require wider re-writing/structuring). Whenever person X has
provided comments, and I’ve updated the document, person Y wants something
else. It would have been much easier if person Y would have given his/her
comments when person X did, and then we could have discussed and tried to
find something that both X and Y are happy with.

Note that I AM very thankful that people DO review the document (we need
more of that), and most of the comments are really good, but by using the
current “process” we’ll never be ready. Anyway, I think that discussion
belongs to MMUSIC.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2016 14:58:14 -0700

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.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Oct 2016 08:18:08 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 5 October 2016 at 00:58
To: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Colin Perkins <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] JSEP: RTP demux algorithms

Harald said:

[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 <[email-masked]<mailto:[email-masked]>> wrote:

Harald

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb