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

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 <
sergio.garcia.murillo@gmail.com> 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 <harald@alvestrand.no>
> escribió:
>
>>
>> On 3/3/21 4:06 PM, Nils Ohlmeier wrote:
>> >> Am 3/3/21 um 06:31 schrieb Paul Kyzivat <pkyzivat@alum.mit.edu>du>:
>> >>
>> >> 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
>> > mmusic@ietf.org
>> > https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>