Re: [MMUSIC] draft-garcia-mmusic-sdp-misc-cap-00. About "icap"

["Krishna Prasad Kalluri" <[e-mail]>]

Hi Miguel,

I have difficulties to understand icap. I just try to illustrate with an
example. You can correct me or provide a better example to understand
this. May be you can give an example to show how it looks with just i=
(media title) and the same example with 'icap'

m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/90000

a=icap:1 video
a=icap:2 video close-up

a=tcap:1 RTP/SAVPF RTP/SAVP RTP/AVPF

a=acap:1 key-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAyO...
a=acap:2 crypto:1 AES_CM_128_HMAC_SHA1_32
         inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=acap:3 crypto:1 AES_CM_128_HMAC_SHA1_80
         inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32
a=acap:4 rtcp-fb:* nack

a=pcfg:1 t=1 a=1,4|3,4 i=1|2
a=pcfg:2 t=2 a=1|3 i=1
a=pcfg:3 t=3 a=4  i=2

>From sdp-misc-cap-00 section 3.1.3.1, Each potential capability
configuration contains a single information capability attribute number.
So this can as well be expressed with just i= xyz at the media stream
level. If you have multiple m lines you can write an 'i' line for each
'm' line and express multiple labels. May be I miss understood :(

Regards
Krishna

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Miguel A. Garcia
Sent: den 18 november 2008 10:06
To: mmusic
Cc: Joerg Ott
Subject: [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
[phone]
Ericsson Spain
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic