Re: [clue] My view if CLUE status and topics for Interim meeting

On Tue, May 22, 2012 at 9:37 AM, Espen Berger (espeberg)
<espeberg@cisco.com> wrote:
> Marshal, did you mean sctp?
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00

No, I did not, I meant SRTP.

http://www.ietf.org/mail-archive/web/rtcweb/current/msg04264.html

(I was in the rough on this one.)

http://www.ietf.org/rfc/rfc3711.txt

Regards
Marshall

>
> For CLUE message transport I think a reliable transport channel is a
> good option. Especially if it's used by other IETF protocols that also
> benefits from reliable and in-order message delivery.
>
> As I remember SRTP is used for media encryption.
>
> Cheers
>
> -Espen
>
> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Marshall Eubanks
> Sent: 22. mai 2012 06:26
> To: Roni Even
> Cc: clue@ietf.org
> Subject: Re: [clue] My view if CLUE status and topics for Interim
> meeting
>
> On Tue, May 22, 2012 at 5:34 AM, Roni Even <ron.even.tlv@gmail.com>
> wrote:
>>
>>
>> Hi Guys,
>>
>> I think that we are in a good shape in the framework and think that in
>
>> order to expedite the work we need to address the following topic and
>> I think it will be good use of our time to do it in the Interim
> meeting.
>>
>> These are the topics as I see them. Please feel free to comment.
>>
>>
>>
>> Data model
>>
>> At the last Interim meeting in February Andy presented an initial data
>
>> structure in
>>
> http://www.ietf.org/proceedings/interim/2012/02/15/clue/slides/clue-5.do
> c .
>> This is an XML schema that has the outline of the data but it is very
>> basic and need more work. There was a discussion if the encoding group
>
>> information can be described using SDP and
>> http://tools.ietf.org/html/draft-romanow-clue-sdp-usage-01 is an
>> attempt to describe the encoding groups in SDP. It was presented in
>> IETF83 (Paris) but there was no real progress or discussion since
> then.
>>
>> CLUE transport.
>>
>> The group is still evaluating what is the right transport for the CLUE
>
>> protocol. The major options are using a second MIME body in offer
>> answer (similar to the approach taken in SIPREC
>> http://tools.ietf.org/html/draft-ietf-siprec-protocol-03 ) or using
>> RFC3264 offer answer to negotiate an end to end channel that will
>> carry the CLUE protocol (maybe something like BFCP). The draft
>> http://tools.ietf.org/html/draft-wenger-clue-transport-02 was
>> presented in
>> IETF83 (Paris) but the issue is still open.
>>
>
> Given that rtcweb has firmly decided to use SRTP, and only SRTP, for
> transport, shouldn't SRTP be added to the mix here ?
>
> Regards
> Marshall
>
>
>> Some other work on the topic is in
>> http://tools.ietf.org/html/draft-cazeaux-clue-sip-signaling-01 which
>> suggests using SDP with offer answer.
>>
>> http://tools.ietf.org/html/draft-hansen-clue-protocol-choices-evaluati
>> on-00 is trying to evaluate both transport options.
>>
>> The solution should take into account the call flow which is still an
>> open issue.
>>
>> CLUE call flow
>>
>> The framework talks about 3 messages (consumer capabilities, provider
>> advertisement and consumer configuration). There is an ongoing
>> discussion if we need all three and how they fit with the offer answer
>
>> exchange. The more general question is how many messages it take to
>> establish a TP call. While the provider advertisement and consumer
>> configuration are used to negotiate the media captures that will be
>> used in the call it is not clear why we need the consumer capability.
>> The justification for the consumer capabilities may be to allow the
>> provider to advertise the relevant capture scene entries, for example
>> a 3 camera system sending an advertisement to a 2 screen system may
> offer only capture scene entries relevant to two screens system.
>>
>> This subject is relevant to the CLUE transport work which will include
>
>> the call flows.
>>
>>
>>
>> Mapping of CLUE media captures to RTP payload (SSRC and payload type
>> number)
>>
>> The media captures provide information about constrains of the streams
>
>> and the spatial relation between them. The streams themselves are
>> described in SIP using SDP and they can be identified by their SSRC
>> numbers. The mapping between these two is important to allow the
>> receiver of the RTP stream to know where to display them.
>> http://tools.ietf.org/html/draft-even-clue-rtp-mapping-01 is trying to
>
>> propose a solution but need more work. There is a similar requirement
>> in RTCweb and
>> http://tools.ietf.org/html/draft-alvestrand-rtcweb-msid-01 tries a
>> different approach. In IETF83 the author of the RTCweb draft was asked
>
>> to look at using grouping and SSRC for this mapping. This may require
> new attribute to the SSRC SDP attribute.
>>
>>
>>
>> RTP usage in CLUE
>>
>> This topic is about multiplexing RTP streams in CLUE. In RTCweb the
>> direction is to multiple the audio and video in one UDP session and
>> work is now in progress in AVTcore and MMUSIC to address this
>> requirement. In CLUE it is desirable to multiplex all the video
> streams in one UDP connection.
>> http://tools.ietf.org/html/draft-lennox-clue-rtp-usage-03 present and
>> recommends the RTP multiplexing mechanism.
>>
>> Thanks
>>
>> Roni
>>
>>
>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue