Subject: [MMUSIC] Finding a max length of "a=mid" attribute

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Mar 2021 09:51:59 +0100

I'm searching for the source of a max length limit on the "a=mid" attribute.

I couldn't find it in RFC 5888 (grouping framework) or RFC 8843 (BUNDLE).

Does anyone remember where it's supposed to be?

(I have code that will insist that it should be 16 bytes or less, but 
I'm trying to verify that this is the correct limit.)

Harald

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 3 Mar 2021 09:31:51 -0500

> I'm trying to verify that this is the correct limit.)

Its defined as a token (from RFC4566/8866). And that is:

   token = 1*(token-char)

There is no upper limit on the length. You can't impose a limit for 
implementation convenience. But practically speaking it is limited by 
the length of the message body that contains it, so you could code using 
an offset+length into the message buffer.

	Thanks,
	Paul

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 3 Mar 2021 07:06:59 -0800

> Am 3/3/21 um 06:31 schrieb Paul Kyzivat <[email-masked]>:
>
>> (I have code that will insist that it should be 16 bytes or less, but I'm trying to verify that this is the correct limit.)
>
> There is no upper limit on the length. You can't impose a limit for implementation convenience. But practically speaking it is limited by the length of the message body that contains it, so you could code using an offset+length into the message buffer.

While the SDP side might be able to handle really long MID values I
doubt the RTP header extension allow or support that. Maybe your 16
byte length limitation comes from the RTP side?

Best
  Nils

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Mar 2021 22:39:51 +0100

> byte length limitation comes from the RTP side?

I found that it is impossible to encode an 1-byte RTP header extension 
longer than 16 bytes (the length is a 4-bit field with a bias value of 
1). So in practice, it's an RTP restriction.

I think Postel once advised that one should always have length limits - 
"if you don't have a length limit, you just have an implementation 
defined limit, and that's worse".

So the next question (now that we've settled that the standards don't 
impose one) is: Should the standards specify a limit?

And the third question: if asked to handle a BUNDLEd connection where 
the MID is > 16 bytes, is it reasonable to just ignore the over-long MID 
value?

>
> Best
>    Nils
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 3 Mar 2021 22:43:31 +0100

If length is >16, shouldn't the 2 byte header extension be used instead?
that would allow mid values up to 256 bytes.

Best regards
Sergio

El mié., 3 mar. 2021 22:40, Harald Alvestrand <[email-masked]>
escribió:

> implementation convenience. But practically speaking it is limited by the
> length of the message body that contains it, so you could code using an
> offset+length into the message buffer.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 3 Mar 2021 13:55:49 -0800

We have limits on a lot of values for exactly this reason - UDP packets
have a finite length, and therefore when it comes to RTP packetization,
overly long values make things screech to halt.

So I think defining such a limit would be a good idea, but I think you'd
have to reject it rather than ignore it to get deterministic behavior
(which seems like another upside to me).

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 04 Mar 2021 09:43:21 +1100

What Justin said.

Does anyone *need* more than 16 bytes?

On Thu, Mar 4, 2021, at 08:55, Justin Uberti wrote:
> So I think defining such a limit would be a good idea, but I think 
> you'd have to reject it rather than ignore it to get deterministic 
> behavior (which seems like another upside to me).
> 
> On Wed, Mar 3, 2021 at 1:43 PM Sergio Garcia Murillo 
> <[email-masked]> wrote:
> > If length is >16, shouldn't the 2 byte header extension be used instead? that would allow mid values up to 256 bytes.
> > 
> > Best regards 
> > Sergio
> > 
> > 
> > El mié., 3 mar. 2021 22:40, Harald Alvestrand <[email-masked]> escribió:
> >>

---

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 3 Mar 2021 21:40:06 -0800

When Firefox started putting its original MID values of ‘mid0’, ‘mid1’ etc into the RTP header extension we received several complaints about wasting bytes on the wire. Because of that we switched to ‘0’, ‘1’, … to save bytes. So it seems everyone is interested in using as little bytes as possible for this.

In other words: I believe 16 bytes should be enough.

Best
  Nils

> On 3Mar, 2021, at 14:43, Martin Thomson <[email-masked]> wrote:
> 
> What Justin said.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 4 Mar 2021 12:06:29 -0500

> In other words: I believe 16 bytes should be enough.

I don't see any conceptual problem with imposing a limit. But when 
imposing a limit retroactively there is the potential for breaking some 
existing implementations in the wild. I think that is unlikely, but hard 
to verify.

	Thanks,
	Paul

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 4 Mar 2021 18:14:53 +0100

A limit of 16bytes is more than enough (1 or 2 bytes is the max you should
use).

However IMHO implementations should be ready to receive up to the maximum
of the 2 header bytes header extensions (there is always crazy people out
there).

Is there any similar limit for RID values?

Best regards
Sergio

El jue., 4 mar. 2021 18:07, Paul Kyzivat <[email-masked]> escribió:

> > When Firefox started putting its original MID values of ‘mid0’, ‘mid1’
> etc into the RTP header extension we received several complaints about
> wasting bytes on the wire. Because of that we switched to ‘0’, ‘1’, … to
> save bytes. So it seems everyone is interested in using as little bytes as
> possible for this.
> >
> >>>> If length is >16, shouldn't the 2 byte header extension be used
> instead? that would allow mid values up to 256 bytes.
> >>>>
> >>>> Best regards
> >>>> Sergio
> >>>>
> >>>>
> >>>>>>>> (I have code that will insist that it should be 16 bytes or less,
> but I'm trying to verify that this is the correct limit.)
> >>>>>>> There is no upper limit on the length. You can't impose a limit
> for implementation convenience. But practically speaking it is limited by
> the length of the message body that contains it, so you could code using an

---

From: Justin Uberti <[email-masked]>
Date: Thu, 4 Mar 2021 13:26:29 -0800

I would argue that even without an enforced limit, things are
already breaking out there silently as packets exceed some link MTU. So
having a deterministic failure seems like
an improvement.

That said, I agree it would be prudent to add some counter to Chrome first
to ensure enforcing a 16 limit would be safe, and this should be performed
for all SDP-defined values carried in RTP header extensions.

On Thu, Mar 4, 2021 at 9:15 AM Sergio Garcia Murillo <
[email-masked]> wrote:

>> >>>>>>>> (I have code that will insist that it should be 16 bytes or
>> less, but I'm trying to verify that this is the correct limit.)

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 8 Mar 2021 08:18:21 +0100

Please note - we *know* that no 17-byte MID is being used with WebRTC in 
Chrome today, because there is code that causes a disruptive failure 
when a MID or RID longer than 16 bytes occurs in the SDP.

WebRTC's BUNDLE is, however, not the only user of the grouping 
framework, so this doesn't guarantee that there isn't such an usage in 
some other place - but this can't be checked by Chrome counters.

The choices available to me as an implementor (short term) are:

A - Return an error on set*Description that attempts to set a MID > 16 
bytes (my preference, needs to be a standard change)

B - Silently ignore attempts to set MIDs > 16 bytes (less disruptive 
than current behavior)

C - Do B, but add a comment to the code saying "TODO() - implement 
support for 256 byte MIDs (low priority bug)"

D - Leave the current behavior

I do agree that new restrictions should be preceded with counters 
(except where there is a security issue) - but this isn't a new 
restriction, it's trying to document an existing one.

On 3/4/21 10:26 PM, Justin Uberti wrote:
> already breaking out there silently as packets exceed some link MTU. 
> So having a deterministic failure seems like
> an improvement.
>
> That said, I agree it would be prudent to add some counter to Chrome 
> first to ensure enforcing a 16 limit would be safe, and this should be 
> performed for all SDP-defined values carried in RTP header extensions.
>
> On Thu, Mar 4, 2021 at 9:15 AM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     A limit of 16bytes is more than enough (1 or 2 bytes is the max
>     you should use).
>
>     However IMHO implementations should be ready to receive up to the
>     maximum of the 2 header bytes header extensions (there is always
>     crazy people out there).
>
>     El jue., 4 mar. 2021 18:07, Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>> escribió:
>
>         > When Firefox started putting its original MID values of
>         ‘mid0’, ‘mid1’ etc into the RTP header extension we received
>         several complaints about wasting bytes on the wire. Because of
>         that we switched to ‘0’, ‘1’, … to save bytes. So it seems
>         everyone is interested in using as little bytes as possible
>         for this.
>         >
>         >> On 3Mar, 2021, at 14:43, Martin Thomson <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         >>
>         >> What Justin said.
>         >>
>         >>> <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         >>>> If length is >16, shouldn't the 2 byte header extension
>         be used instead? that would allow mid values up to 256 bytes.
>         >>>>
>         >>>> Best regards
>         >>>> Sergio
>         >>>>
>         >>>>
>         >>>> El mié., 3 mar. 2021 22:40, Harald Alvestrand
>         <[email-masked] <mailto:[email-masked]>> escribió:
>         >>>>>
>         >>>>>>> Am 3/3/21 um 06:31 schrieb Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>>:
>         >>>>>>>
>         >>>>>>>> (I have code that will insist that it should be 16
>         bytes or less, but I'm trying to verify that this is the
>         correct limit.)
>         >>>>>>> There is no upper limit on the length. You can't
>         impose a limit for implementation convenience. But practically
>         speaking it is limited by the length of the message body that
>         contains it, so you could code using an offset+length into the
>         message buffer.
>         >>>>>> [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>>>>
>         >>>>> [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>>> [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>> [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>>
>         >>
>         >> [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >
>         > [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>