Re: [clue] IETF#89: CLUE Data Channel - Next Step
Christer Holmberg <christer.holmberg@ericsson.com> Fri, 07 March 2014 05:46 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996811A01ED for <clue@ietfa.amsl.com>; Thu, 6 Mar 2014 21:46:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level:
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-kpWKagsMdg for <clue@ietfa.amsl.com>; Thu, 6 Mar 2014 21:46:42 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6671A01E5 for <clue@ietf.org>; Thu, 6 Mar 2014 21:46:41 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-86-53195d3c65b8
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BE.09.10875.C3D59135; Fri, 7 Mar 2014 06:46:37 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 06:46:36 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "clue@ietf.org" <clue@ietf.org>
Thread-Topic: [clue] IETF#89: CLUE Data Channel - Next Step
Thread-Index: Ac84stqWg0jHh/1aTnG2LUuaAasKJwAuO2YAABc0cAA=
Date: Fri, 07 Mar 2014 05:46:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1D7934@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D1CFD69@ESESSMB209.ericsson.se>, <5318CF92.2080003@alum.mit.edu>
In-Reply-To: <5318CF92.2080003@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1D7934ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja5trGSwwflPzBb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxa2tKQUtIxftfj1kaGK+6djFyckgImEj8 ffqJHcIWk7hwbz1bFyMXh5DAIUaJpS+3M0M4ixklpm9qBnI4ONgELCS6/2mDNIgIeErs+DiF GcQWFrCS2DxxJztE3Fpi+v5pULaVxM+pU1lBbBYBFYkfa7vBbF4BX4lJE06B1QgJ5Ep0rl4O NodTQEei+/VPFhCbEeig76fWMIHYzALiEk1fVrJCHCogsWTPeWYIW1Ti5eN/rBA1+RIrLs1n hpgvKHFy5hOWCYzCs5C0z0JSNgtJGUTcQOLL+9tQtrbEsoWvmSFsfYnu96eZkMUXMLKvYmTP TczMSS833MQIjJCDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhjNt2WHRymW3zv0iYvT0UX9iea9SWHf4xzta3dWvE9fl7t5kk/aXX+huqu9WlUif7R/ /7mewr3JNX1d3XL7yDftUxZn18kHOIr/vs+zws9Q6rGUXc0V8f7FwguMTdbyGOvO/7ReK1xV dmFPi8su17tT5e0Oae7+H/snm3PTZYuPbYvCRQIdmJVYijMSDbWYi4oTAXWrfgJeAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lQBxv_FhoB_FvdrUl_9I8z2YW4E
Subject: Re: [clue] IETF#89: CLUE Data Channel - Next Step
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Mar 2014 05:46:45 -0000
Hi Paul, Perhaps it would be tricky for an rtcweb app to figure out its DTLS role, but it WOULD know whether it is offerer or answerer. Regards, Christer Sent from Windows Mail From: Paul Kyzivat<mailto:pkyzivat@alum.mit.edu> Sent: Thursday, 6 March 2014 21:44 To: clue@ietf.org<mailto:clue@ietf.org> Comment at end On 3/5/14 8:38 PM, Christer Holmberg wrote: > Hi data channel lovers, > > Today we agreed to adopt DECP for the CLUE Data Channel (CDC). > > (Note that we did NOT prevent usage of draft-eyzak, if the mechanism > gets done in MMUSIC). > > (We also agreed that there needs to be A way to identity that a call can > use CLUE, but that is NOT the topic of this e-mail - please start a > separate thread if you want to discuss that). > > As time has been allocated for the CDC also on Friday, I intend to use > that time to discuss the issue regarding who is responsible for sending > DATA_CHANNEL_OPEN. > > > First we need to decide if we want to specify who is responsible, or > whether we’ll specify procedures when both endpoints send DCO. > > My suggestion is that we do specify that one of the endpoints is > responsible. > > Second, if we agree to the suggestion above, we need to decide which > endpoint is responsible for sending DCO. Alternatives are e.g. offerer, > answerer, DTLS client and DTLS server. Note that this is separate from > which endpoint establishes the SCTP association, and how the DTLS roles > are determined - those procedures are defined in the sctp-sdp draft. > > Also, we do need to describe what happens if both endpoint still sends > DCO. It would be considered an error case, and we could e.g. say that > the endpoint responsible for sending DCO would have to reset the > stream/channel created by the other endpoint. Some (maybe all) of these algorithms for determining which end does the open may be difficult for applications to apply. In particular I'm thinking about an RTCWEB browser app. It *may* have access to info about whether it is the "even" or "odd" end, but maybe not. It could figure that out by doing an experiment - opening a channel and then discovering its stream id. But that is silly. I doubt it will have access to whether it is DTLS client or server. It *might* be able to determine if it is offerer or answerer (of the first O/A in which the SCTP m-line appears. But this also seems tricky to figure out. (It will likely have to scan every SDP sent or received, looking for the SCTP m-line.) Another alternative I'll try again is for each end to send an open *if* it wants to be an advertiser. Then it will use that channel to send advertisements and receive configurations. In the normal case, each will then receive an open. It would use that channel to receive advertisements and send configure messages. Or, we could just let each side send an open. If one side receives and open before sending one, then it won't send its own - both will use that one. If an endpoint receives an open after sending its own, it will ack that. At that point it has two CLUE channels. Both sides agree that if they have two clue channels, then they only use the one with the smaller stream ID, and send a reset on the one with the larger stream id. This does mean that any messages sent on the stream that is reset will be ignored. (That can happen if messages are sent immediately after the open, before the ack is received.) Either of these symmetric ones are easy to implement in any environment. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue
- Re: [clue] IETF#89: CLUE Data Channel - Next Step Paul Kyzivat
- [clue] IETF#89: CLUE Data Channel - Next Step Christer Holmberg
- Re: [clue] IETF#89: CLUE Data Channel - Next Step Mary Barnes
- Re: [clue] IETF#89: CLUE Data Channel - Next Step Christer Holmberg