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

Marshal, did you mean sctp? 
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00

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