[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] draft-garcia-mmusic-sdp-misc-cap-00. About "icap"
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 +15551234
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: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] 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
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic