[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] draft-garcia-mmusic-sdp-misc-cap-00. About "icap"
Yesterday we had a discussion about the Miscellaneous Capabilities draft,
and there was a question about the "icap" capability. I was listening to
the audio stream and posted some comments on the chat room, but let me
try to clarify the issue.
The "icap" capability allows to express media "i" lines as capabilities.
Bear in mind that the "i" line is intended for human consumption, so,
there are no semantics added to it, other than provide a human readable
description of the media stream. If we wanted to get a user agent to
consume the information, we should be using the "label" attribute
specified in RFC 4574.
So, considering that the i line is for human consumption, people would
ask whether there is a need for expressing it as a capability. The
authors discussed this issue and came up with a use case where a user
would offer several alternative media streams and could indicate in the
i/icap line some information about what is in that media stream. For
example, one could indicate that a video stream contains a close-up of
the presenter versus a general room, or an audio stream could contain the
original movie audio track versus the director's commentary. This could
help the answerer to select the appropriate alternative media stream.
Obviously this require the endpoint to be able to present this
information to the end user. Honestly, I don't know of any endpoint that
allows the user to write an i line, or which displays it to the end user.
That might be the weakest selling point of this idea. But technically
it makes sense.
What do people think? What should we do in the next revision of the
document, should we keep the icap line (and add the use case
description), or should we remove it?
Thanks,
Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic