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

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

Hi Miguel,

OK Thanks for the clarification. Now I see the usage. Minor issue with
the example I guess the correct pcfgs are 


   a=pcfg:1 t=1 m=2 c=1 i=2
   a=pcfg:2 t=2 m=1 c=2 i=1

I think the document can be improved with examples and it will be easy
to grasp the concept.

Regards
Krishna

-----Original Message-----
From: Miguel Garcia A 
Sent: den 18 november 2008 15:35
To: Krishna Prasad Kalluri
Cc: mmusic; Joerg Ott
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-misc-cap-00. About "icap"

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