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

[Marshall Eubanks <[e-mail]>]

On Tue, May 22, 2012 at 5:34 AM, Roni Even <[e-mail]> 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.doc .
> 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-evaluation-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>