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

From: "Roni Even" <[email-masked]>
Date: Tue, 22 May 2012 12:34:30 +0300

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
<http://tools.ietf.org/html/draft-wenger-clue-transport-02%20was%20presented
%20in%20IETF83>  (Paris) but the issue is still open.

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

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 22 May 2012 09:26:05 -0400

On Tue, May 22, 2012 at 5:34 AM, Roni Even <[email-masked]> wrote:
> 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

> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Tue, 22 May 2012 15:37:24 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Marshall Eubanks
Sent: 22. mai 2012 06:26
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] My view if CLUE status and topics for Interim
meeting

On Tue, May 22, 2012 at 5:34 AM, Roni Even <[email-masked]>
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.

> 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.

> 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

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

> 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
>
> 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.
> 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.

> 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.
> 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.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 22 May 2012 10:16:55 -0400

> 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

---

From: "Roni Even" <[email-masked]>
Date: Tue, 22 May 2012 18:03:35 +0300

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

> From: Marshall Eubanks [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2012 4:26 PM
> To: Roni Even
> Cc: [email-masked]