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

[Sergio Garcia Murillo <[e-mail]>]

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
>