Re: [rtcweb] Checkpointing decisions in RTCWEB

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 08 March 2013 17:08 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4821F8767 for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 09:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.782
X-Spam-Level:
X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 MNwQrsLMk33k for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 09:08:15 -0800 (PST)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 103CC21F84FF for <rtcweb@ietf.org>; Fri, 8 Mar 2013 09:08:14 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id b12so641919qca.32 for <rtcweb@ietf.org>; Fri, 08 Mar 2013 09:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TZ5HcYBxUtaG+4Ij1DxjlChA25N91Qf1W0Kwb/BQ1f4=; b=GlIpBwzW2PRaPGcU+sFNwLs86o01ZUoHIE4hJ6oCaJH+vu8FImzhmyGc7mSnY4tQr9 kZ2Y5wM/s0DQLHFtz5jXxdeUGlaR3b6CYHPbLMUjIYHzzVInfpwg1n267aKwQt3AWfkF NOqy1txJb/rNp/lrm/D6avWUqooTaGQ1me2H6gpmCK5DEu3n9sUiiXaTJH+Xpv2SjRzp e7z9y2k3s84qZpIjo3OWZYWGqvfXks5XN5ecLWyau9wCcthLRq2QKnBvydDRtDM28eFw qNdFyPe41zKugzq37iGz6pgxVF0OlprvOuLxms+AplaJa/3RJuIPFpsUbyUE9GlQTbIx 7E/A==
MIME-Version: 1.0
X-Received: by 10.49.85.34 with SMTP id e2mr5097470qez.1.1362762493876; Fri, 08 Mar 2013 09:08:13 -0800 (PST)
Received: by 10.49.24.130 with HTTP; Fri, 8 Mar 2013 09:08:13 -0800 (PST)
In-Reply-To: <513A159E.4030800@nostrum.com>
References: <CA+9kkMAtTOAw4hy5yRhdgW5=Ca9a9LjX9paZrR=+ABJGnJAU=w@mail.gmail.com> <CAHBDyN75PncyA1euiZ-9rr=parAGnM43oAL0JQHykxnJ+3YWww@mail.gmail.com> <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com> <CAHBDyN7+DoJcbgT3pYqSX7qycYFPtTVZC3CC-okyDep8NYwddg@mail.gmail.com> <513A159E.4030800@nostrum.com>
Date: Fri, 08 Mar 2013 11:08:13 -0600
Message-ID: <CAHBDyN4GnoYFKY4Jwiz_0RHX7LXH5AjE+5frDYmE5+TJ2w2Y5w@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2013 17:08:15 -0000

On Fri, Mar 8, 2013 at 10:45 AM, Adam Roach <adam@nostrum.com> wrote:
> On 3/8/13 10:36, Mary Barnes wrote:
>>
>> [MB]  My concern is extrapolated a bit beyond just RTCWEB to the
>> extensions that are being proposed for SDP to support RTCWEB -
>> independent of whether RTCWEB uses it over the wire.  In cases where
>> folks want interop with "legacy" SIP some form of the SDP needs to go
>> over the wire.  In an ideal world, that would be the same SDP blob,
>> but it doesn't appear that would be the case where RTCWEB is now.
>> [/MB]
>
>
> Much to my surprise, we actually saw exactly this mostly work at the SIPit
> in Boston. The places we fell down were ICE support and DTLS-SRTP, both of
> which are in the process of being adopted in SIP products at the moment.
[MB2] Right, but that wasn't doing any of the multistream stuff was
it?   Or, did I miss something in the SIPit report?  Again, I don't
debate you wizards can make things work.  [/MB2]
>
>
>> [MB] Are you saying that there are things that we need that SDP cannot
>> express (or cannot be extended to express)?
>> [MB] Right now, there are things you need in SDP that there is no
>> agreement as to how they should be expressed.  I agree that the group
>> could certainly pick a way and then try to live with it.  However,
>> some of these things overlap with what CLUE needs.  If CLUE wants to
>> use the same building blocks (and not create yet another way to do
>> multi-stream), then CLUE would reuse some of what is being driven to
>> meet RTCWEB requirements.  A CLUE application/endpoint will be using
>> the SDP over the wire.
>
>
> Given that most of the extensions under discussion are driven in equal
> measures by RTCWEB and CLUE, are you about to propose that CLUE move away
> from SDP as well? We could well charter a new WG for SDPNGNG.
[MB2]  My personal opinion is that CLUE would do much better to
minimize its dependency on SDP.  We will use SIP for basic session
setup.  We are in the process of figuring out exactly what from the
CLUE data (see the FW and data model in CLUE) can or should be carried
in SDP.   I'm (as an individual) of the opinion that we should do bare
minimum in SDP - e.g., just what it takes to get a CLUE client
endpoint connected  to a non-CLUE endpoint.  I believe that the more
we put in SDP, the less extensible CLUE will be. I don't think that's
a good thing when we are defining a new application.  There are those
that believe we can signal lots of stuff in the SDP - that introduces
a tighter coupling between the CLUE data and SDP.  As I said for the
RTCWEB folks, I don't doubt that the CLUE folks can eventually get it
specified and made to work putting as much as possible in SDP.  I will
note that there are already deployed and interoperable telepresence
applications out there that do rely entirely on SIP and SDP, so I am
not suggesting it isn't possible, but the reason for chartering CLUE
was that the implementations are not standards based (despite there
being a specification that defines the interfaces) and not easily
extended.  That was the motivation for chartering CLUE.  Note, we will
be having this discussion in CLUE WG on Monday morning.

And, no I don't think we need SDPNGNG.  I think we need to decouple
our applications from the underlying session setup protocols.  [/MB2]
>
> /a