[clue] Boundary between SDP Offer/Answer and CLUE channel

<bruno.chatras@orange.com> Fri, 30 March 2012 08:54 UTC

Return-Path: <bruno.chatras@orange.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9521F889B for <clue@ietfa.amsl.com>; Fri, 30 Mar 2012 01:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level:
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVBO1GKprMCo for <clue@ietfa.amsl.com>; Fri, 30 Mar 2012 01:54:08 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id C48F521F888B for <clue@ietf.org>; Fri, 30 Mar 2012 01:54:07 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AAE93107406F for <clue@ietf.org>; Fri, 30 Mar 2012 10:55:40 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A31FB1074055 for <clue@ietf.org>; Fri, 30 Mar 2012 10:55:40 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 10:54:07 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0E52.A9F73316"
Date: Fri, 30 Mar 2012 10:54:06 +0200
Message-ID: <9ECCF01B52E7AB408A7EB8535264214103F3808B@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Boundary between SDP Offer/Answer and CLUE channel
Thread-Index: Ac0OUqm0hIhb19FEQn+Q6QxLFyLW+A==
From: bruno.chatras@orange.com
To: clue@ietf.org
X-OriginalArrivalTime: 30 Mar 2012 08:54:07.0199 (UTC) FILETIME=[AA5DBEF0:01CD0E52]
Subject: [clue] Boundary between SDP Offer/Answer and CLUE channel
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 08:54:10 -0000

As a follow-up to the discussion we had yesterday about the CLUE
protocol during the meeting, I would like to verify my understanding of
the differences between the proposals that were presented and/or
discussed. Does the following text provide an accurate summary of the
differences?

 

1) draft-wenger-clue-transport-02
<http://datatracker.ietf.org/doc/draft-wenger-clue-transport/>  and
draft-romanow-clue-sdp-usage-01
<http://datatracker.ietf.org/doc/draft-romanow-clue-sdp-usage/> 

Provider advertisement for encoding, consumer encoding configuration:
SDP O/A

Provider advertisement for media captures:  CLUE protocol

Consumer selection of media captures: CLUE protocol

 

2) draft-cazeaux-clue-sip-signaling-00
<http://datatracker.ietf.org/doc/draft-cazeaux-clue-sip-signaling/>  -
Solution #1

Provider advertisement for encoding, consumer encoding configuration:
SDP O/A

Provider advertisement for media captures:  SDP O/A

Consumer selection of media captures: SDP O/A

 

3) draft-cazeaux-clue-sip-signaling-00
<http://datatracker.ietf.org/doc/draft-cazeaux-clue-sip-signaling/>  -
Solution #2

Provider advertisement for encoding, consumer encoding configuration:
SDP O/A

Provider advertisement for media captures:  SDP O/A

Consumer selection of media captures: CLUE protocol

 

4) Alternative mentioned during the discussions

Provider advertisement for encoding, consumer encoding configuration:
CLUE protocol

Provider advertisement for media captures:  CLUE protocol

Consumer selection of media captures: CLUE protocol

SDP O/A used to establish the CLUE channel (if on the media plane) and
negotiating the bandwidth for a big pipe

 

I also understood that the above comparison is largely independent from
discussions about the pros and cons of the Unidirectional vs.
Bidirectional approaches and from the decision to be taken regarding the
transport of the CLUE protocol (i.e. signalling vs. media plane).

 

BC