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

[Justin Uberti <[e-mail]>]

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 <
[e-mail]> 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).
>
> Is there any similar limit for RID values?
>
> Best regards
> Sergio
>
>
>
> El jue., 4 mar. 2021 18:07, Paul Kyzivat <[e-mail]> escribió:
>
>> On 3/4/21 12:40 AM, Nils Ohlmeier wrote:
>> > 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.
>>
>> 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
>>
>> > Best
>> >    Nils
>> >
>> >> On 3Mar, 2021, at 14:43, Martin Thomson <[e-mail]> wrote:
>> >>
>> >> What Justin said.
>> >>
>> >> Does anyone *need* more than 16 bytes?
>> >>
>> >> On Thu, Mar 4, 2021, at 08:55, Justin Uberti wrote:
>> >>> 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).
>> >>>
>> >>> On Wed, Mar 3, 2021 at 1:43 PM Sergio Garcia Murillo
>> >>> <[e-mail]> 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 <[e-mail]>
>> escribió:
>> >>>>>
>> >>>>> On 3/3/21 4:06 PM, Nils Ohlmeier wrote:
>> >>>>>>> Am 3/3/21 um 06:31 schrieb Paul Kyzivat <[e-mail]>:
>> >>>>>>>
>> >>>>>>> On 3/3/21 3:51 AM, Harald Alvestrand wrote:
>> >>>>>>>> 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.)
>> >>>>>>> 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.
>> >>>>>> 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?
>> >>>>>
>> >>>>> 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
>> >>>>>> [e-mail]
>> >>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> mmusic mailing list
>> >>>>> [e-mail]
>> >>>>> https://www.ietf.org/mailman/listinfo/mmusic
>> >>>> _______________________________________________
>> >>>> mmusic mailing list
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/mmusic
>> >>> _______________________________________________
>> >>> mmusic mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/mmusic
>> >>>
>> >>
>> >> _______________________________________________
>> >> mmusic mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/mmusic
>> >
>> > _______________________________________________
>> > mmusic mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mmusic
>> >
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>