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

["Roni Even" <[e-mail]>]

Marshal,
We are talking about how to transport the CLUE message and not the media in
this item.
Maybe SRTP should be part of RTP usage in CLUE and I can agree that it will
make sense to  discuss the issue of key exchange in SRTP for CLUE
Roni

> -----Original Message-----
> From: Marshall Eubanks [mailto:[e-mail]]
> Sent: Tuesday, May 22, 2012 4:26 PM
> To: Roni Even
> Cc: [e-mail]
> Subject: Re: [clue] My view if CLUE status and topics for Interim
> meeting
> 
> 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-
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/clue
> >