Re: [MMUSIC] Feedback requested on requirements

[[e-mail] (Dale R. Worley)]

> From: Christer Holmberg <[e-mail]>
> 
> >Here are a few desiderata related to dealing with legacy devices, both
> >endpoints and intermediate devices:
> >
> >   DES C3  Avoid using media types in m= lines other than audio and
> >      video unless required for user media, as some SBCs reject SDP that
> >      uses other media types.
> >
> >   This desideratum was suggested by Hadriel Kaplan.
> 
> I am not sure I understand. Why would one use media types unless
> required for user media?

The MMT proposal (draft-holmberg-mmusic-sdp-mmt-negotiation-00) and
similar proposals add a separate media description (m= line section)
which describes the transport for the bundle as a whole.  The media
type specified by the m= line in such a media description is largely
arbitrary.  MMT specifies m=anymedia; m=multipart and m=application
have been proposed.

However, for compatibility with intermediate devices that remove media
descriptions other than m=audio and m=video, any "bundle" media
description should use either "audio" or "video" type.

> >   DES C4  Any additional m= lines prescribed by the bundle mechanism
> >      should be ordered after the constituent m= lines.
> 
> That is normal Offer/Answer procedure, isn't it?

If a "bundle" media description is to be added, it ought to be added
*after* the m= lines for the constituent media streams, so that the
"bundle" media description doesn't change which media description is
identified as "the first audio media description", "the second audio
media description", "the first video media description", etc.

> >   Many devices that have only one audio or video channel accept the
> >   first m= line with that media type and reject any further ones
> >
> >  non-DES C5  SBCs generally pass through attributes that they do not
> >      understand.  SBCs generally pass through codec specifications that
> >      they do not understand, even if they are configured to transcode
> >     certain specific codecs.
> >
> >   This non-desideratum was suggested by Hadriel Kaplan.
> 
> I don't understand this.

See my response to Martin Thompson.

I'm considering labeling this item "LATITUDE", meaning a range of
flexibility that the solution may exploit, as contrasted to
"DESIDERATUM", a constraint that we want the solution to obey.

Dale