Subject: [MMUSIC] "a=extmap" with BUNDLE

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 24 Mar 2017 10:19:00 -0700

Is there any document that defines the general semantics of "a=extmap" when
"m=" sections are bundled? I assumed there was a restriction that multiple
bundled "m=" sections must not use the same ID to refer to different header
extensions, but I haven't found this anywhere.

If it's needed, should it go in sdp-mux-attributes, with something similar
to "IDENTICAL-PER-PT"?

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 24 Mar 2017 18:00:10 +0000

Hi Taylor

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16#section-5.13

Mux attributes classifies it under SPECIAL category

Thanks
Suhas

On Fri, Mar 24, 2017 at 10:28 AM Taylor Brandstetter <[email-masked]>
wrote:

> Is there any document that defines the general semantics of "a=extmap"
> when "m=" sections are bundled? I assumed there was a restriction that
> multiple bundled "m=" sections must not use the same ID to refer to
> different header extensions, but I haven't found this anywhere.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 24 Mar 2017 11:28:45 -0700

I saw that. Which means that individual documents are responsible for
defining how their extensions work with BUNDLE.

But something still would need to define the *general* restrictions for
using "extmap" with BUNDLE, such as the ID restriction. Or is that just
something that's common sense and doesn't need to be specified?

On Fri, Mar 24, 2017 at 11:00 AM, Suhas Nandakumar <[email-masked]>
wrote:

>> If it's needed, should it go in sdp-mux-attributes, with something
>> similar to "IDENTICAL-PER-PT"?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 26 Mar 2017 03:35:54 +0200

2017-03-24 19:28 GMT+01:00 Taylor Brandstetter <[email-masked]>:
> saw that. Which means that individual documents are responsible for defining
> how their extensions work with BUNDLE.
>
> But something still would need to define the general restrictions for using
> "extmap" with BUNDLE, such as the ID restriction. Or is that just something
> that's common sense and doesn't need to be specified?

https://tools.ietf.org/html/rfc5285#section-6 just mandates that the
IDs must be unique within a m= section, but at the end, all the WebRC
implementations use unique ID values across the entire SDP.

There are some RTP extensions, such as
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01,
that work at *transport* level (rather than at m= section level), but
nothing prevents such a spec to work even if its ID is not unique
within the m= sections.

This is, IMHO we don't need a global behavior/requirement for the ID
values within bundled m= sections.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 27 Mar 2017 10:44:45 -0700

If extension IDs aren't unique across bundled m= sections, then on
receiving a packet, an implementation may need to determine which m=
section it's "associated" with before knowing how to interpret the
extension IDs. To do this, it may need to use the MID, which means that at
a minimum, the MID extension must be using a unique ID.

But this increases implementation complexity without much benefit (the
benefit being that by sharing IDs, you could more easily avoid running out
of spare IDs). So I'd be in favor of just requiring them to be unique.

---

From: Byron Campen <[email-masked]>
Date: Mon, 27 Mar 2017 12:55:27 -0500

Would it not be sufficient to specify that bundled m-sections not 
use the same identifier for _different_ extensions? There's no ambiguity 
if you use '3' for mid on every m-section, which is the kind of thing 
implementations do now anyway.

Best regards,
Byron Campen

On 3/27/17 12:44 PM, Taylor Brandstetter wrote:
> extension IDs. To do this, it may need to use the MID, which means 
> that at a minimum, the MID extension must be using a unique ID.
>
> benefit being that by sharing IDs, you could more easily avoid running 
> out of spare IDs). So I'd be in favor of just requiring them to be unique.
>
> On Sat, Mar 25, 2017 at 6:35 PM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2017-03-24 19:28 GMT+01:00 Taylor Brandstetter
>     <[email-masked] <mailto:[email-masked]>>:
>     https://tools.ietf.org/html/rfc5285#section-6
>     <https://tools.ietf.org/html/rfc5285#section-6> just mandates that the
>     http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
>     <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>,
>     <[email-masked] <mailto:[email-masked]>>
>
>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 27 Mar 2017 22:59:01 +0200

2017-03-27 19:44 GMT+02:00 Taylor Brandstetter <[email-masked]>:
> If extension IDs aren't unique across bundled m= sections, then on receiving
> a packet, an implementation may need to determine which m= section it's
> "associated" with before knowing how to interpret the extension IDs.

Yes.

> To do
> this, it may need to use the MID, which means that at a minimum, the MID
> extension must be using a unique ID.

Oh no, not at all. It's just about getting the appropriate RtpReceiver
associated to the current RTP packet (this can be done by MID, RID,
SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define).
Once we have the proper RtpReceiver, pass the packet to it so it can
set the corresponding RTP extension ID mappings (because those params
belong to each RtpReceiver), and later, let the transport get
transport related IDs (such as REMB or transport-cc) from the RTP
packet.

Well, I implemented it yesterday so... :)

https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/Transport.cpp
https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/RtpStreamRecv.cpp#L57

> of spare IDs). So I'd be in favor of just requiring them to be unique.

Me too.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 27 Mar 2017 23:00:33 +0200

2017-03-27 19:55 GMT+02:00 Byron Campen <[email-masked]>:
>   Would it not be sufficient to specify that bundled m-sections not use the
> same identifier for _different_ extensions? There's no ambiguity if you use
> '3' for mid on every m-section, which is the kind of thing implementations
> do now anyway.

Still one may use '3' for MID within a m=audio line and '4' for MID
within a m=video line. And that's legal.
Anyhow, current browsers use unique IDs across the whole SDP.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 27 Mar 2017 15:24:22 -0700

> same identifier for _different_ extensions?

Yes, that's what I meant to describe.

It's just about getting the appropriate RtpReceiver
> SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define).

Right. So, if you *can't* get the appropriate RtpReceiver with RID, SSRC or
PT, then you must do it with MID. And if the MID extension shares an ID
with another extension, it becomes impossible to know the MID. For example:

m=audio ...
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:foo
m=video ...
a=extmap:1 urn:bar
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid

I know it would be crazy to generate SDP like that, but there's nothing
I've found that disallows it.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 28 Mar 2017 01:08:35 +0200

2017-03-28 0:24 GMT+02:00 Taylor Brandstetter <[email-masked]>:
> Right. So, if you can't get the appropriate RtpReceiver with RID, SSRC or
> PT, then you must do it with MID. And if the MID extension shares an ID with
> another extension, it becomes impossible to know the MID. For example:
>
> m=audio ...
> I know it would be crazy to generate SDP like that, but there's nothing I've
> found that disallows it.

And you are 100% right here. MID ID must be unique across all the m=
lines, otherwise it is useless.

To make things even uglier, the RFC 5285 states:

   The mapping may be provided per media stream (in the media-level
   section(s) of SDP, i.e., after an "m=" line) or globally for all
   streams (i.e., before the first "m=" line, at session level).  The
   definitions MUST be either all session level or all media level; it
   is not permitted to mix the two styles.  In addition, as noted above,
   the IDs used MUST be unique for each stream type for a given media,
   or for the session for session-level declarations.

So a solution may be using just global a=extmap lines at SDP session
level. That would work, but it's a hack, because not all the IDs are
to be used within all the m= lines, not even across all the m= lines
of the same kind (audio, video).

Anyhow, the key of your argument is the "just MID for m=line
identification". It clearly requires the MID ID to be unique across
all the m= lines. One "solution" would be for the BUNDLE spec [*] to
mandate having a single MID ID, but it does not. I still prefer to
mandate that the same ID always references the same extension URI, and
that the same extension URI is just referenced by a single and unique
ID in the entire SDP, but that "breaks" RFC 5285...

So IMHO, the immediate issue is in BUNDLE spec [*] which defines the
MID stuff but does not mandate the MID ID to be unique in the whole
SDP.

[*] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-36

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Mar 2017 23:38:29 -0400

> MID stuff but does not mandate the MID ID to be unique in the whole

This is already required by section 4 of RFC5888:

    The identification-tag MUST be unique within an SDP session
    description.

	Thanks,
	Paul

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 28 Mar 2017 06:20:36 +0000

The issue is uniqueness of the extmap id for mid not the mid value itself (identification-tag). 

Mo

On Mar 27, 2017, at 10:38 PM, Paul Kyzivat <[email-masked]> wrote:

   Thanks,
   Paul

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 28 Mar 2017 01:43:21 -0500

Since extmap is currently categorized under category of SPECIAL, at the
minimum we need BUNDLE draft to describe its behavior for MID RTP Header
extension under multiplexing, if it is not already doing so

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 28 Mar 2017 15:37:19 +0200

> extension under multiplexing, if it is not already doing so

It does not do it. I mean, BUNDLE draft does not state that the ID for
MID must be unique across all the m= sections. And it MUST be
(otherwise it does not make sense at all).

-- 
Iñaki Baz Castillo
<[email-masked]>