Re: [rtcweb] Checkpointing decisions in RTCWEB

Adam Roach <adam@nostrum.com> Fri, 08 March 2013 16:45 UTC

Return-Path: <adam@nostrum.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 63A0221F869B for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 08:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level:
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, SPF_PASS=-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 DWyZP70lRdpp for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 08:45:25 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C1F9721F8644 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 08:45:25 -0800 (PST)
Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r28GjKPr024996 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 8 Mar 2013 10:45:21 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <513A159E.4030800@nostrum.com>
Date: Fri, 08 Mar 2013 10:45:18 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.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>
In-Reply-To: <CAHBDyN7+DoJcbgT3pYqSX7qycYFPtTVZC3CC-okyDep8NYwddg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
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 16:45:26 -0000

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.

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

/a