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

["Miguel A. Garcia" <[e-mail]>]

Hi Krishna:

Your example got lost in the jungle of Audio-Video Profiles. And I didn't 
succeed even myself in trying to give you an example where one can 
indicate two mutually exclusive media streams, where only the port number 
changes. I am not sure how to encode it.

But let me give you another example for which I am more familiar with. 
Assume I can offer you two audio streams, one is narrow bandwidth over 
the PSTN (with codec number 3 (GSM low bandwidth) and the other is 
wideband stereo over IP (codec 10, L16 2 channels). I want to describe 
these options in clear written language (icap line). The potential 
configuration 1 selects the narrowband channel whereas the potential 
configuration 2 selects the wideband channel. This would be the SDP 
(relevant lines).

    m=audio 49170 RTP/AVP 3
    c=IN IP4 192.0.2.1
    a=creq:med-v0,pstn-v0
    a=mcap:1 GSM/8000/1
    a=mcap:2 L16/48000/2
    a=tcap:1 RTP/AVP PSTN
    a=ccap:1 IN IP4 192.0.2.1
    a=ccap:2 PSTN E164 [phone]
    a=icap:1 telephony quality audio
    a=icap:2 high quality stereo audio
    a=pcfg:1 t=1 m=1 c=1 i=1
    a=pcfg:2 t=2 m=2 c=2 i=2



/Miguel


Krishna Prasad Kalluri wrote:
> 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

-- 
Miguel A. Garcia
[phone]
Ericsson Spain
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic