Re: [rtcweb] Checkpointing decisions in RTCWEB

Jim Barnett <Jim.Barnett@genesyslab.com> Fri, 08 March 2013 19:33 UTC

Return-Path: <jim.barnett@genesyslab.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 6AC3A21F88EE for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 11:33:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Sbyy1Rm5Y-0F for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 11:33:20 -0800 (PST)
Received: from service108-us.mimecast.com (service108-us.mimecast.com [205.139.110.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC1221F88E8 for <rtcweb@ietf.org>; Fri, 8 Mar 2013 11:33:18 -0800 (PST)
Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service108-us.mimecast.com; Fri, 08 Mar 2013 14:33:17 -0500
Received: from GENSJZMBX03.msg.int.genesyslab.com ([fe80::fc31:8268:eb4c:f8af]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 11:33:13 -0800
From: Jim Barnett <Jim.Barnett@genesyslab.com>
To: Robin Raymond <robin@hookflash.com>
Thread-Topic: [rtcweb] Checkpointing decisions in RTCWEB
Thread-Index: AQHOG4X1bqeXKKMkOkGn8rQENJxOWZicZ2SA//96ejCAAMzeAP//fcBQ
Date: Fri, 08 Mar 2013 19:33:13 +0000
Message-ID: <57A15FAF9E58F841B2B1651FFE16D281026B8A@GENSJZMBX03.msg.int.genesyslab.com>
References: <CA+9kkMAtTOAw4hy5yRhdgW5=Ca9a9LjX9paZrR=+ABJGnJAU=w@mail.gmail.com> <CAHBDyN75PncyA1euiZ-9rr=parAGnM43oAL0JQHykxnJ+3YWww@mail.gmail.com> <57A15FAF9E58F841B2B1651FFE16D281026A26@GENSJZMBX03.msg.int.genesyslab.com> <CAADs5MoWo6Nd+S7ndLDn784hTtCBxzu-kR0=9PkwJRQFZ5bp7Q@mail.gmail.com>
In-Reply-To: <CAADs5MoWo6Nd+S7ndLDn784hTtCBxzu-kR0=9PkwJRQFZ5bp7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [98.110.233.90]
MIME-Version: 1.0
X-MC-Unique: 113030814331709502
Content-Type: multipart/alternative; boundary="_000_57A15FAF9E58F841B2B1651FFE16D281026B8AGENSJZMBX03msgint_"
Cc: "rtcweb@ietf.org" <rtcweb@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 19:33:22 -0000

My understanding is that SDP is an API surface _only_.  So, yes, the application developer can send whatever he wants over the wire.   (I imagine that a lot of implementations, including ours, will send the SDP to the other side, but it's not required.)

I tend to agree with a previous poster who suggests that we separate problems with the offer/answer state machine from problems with the SDP API surface.  We could keep the state machine but change the API surface, or change the API language and keep the state machine.


-          Jim

From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Friday, March 08, 2013 2:05 PM
To: Jim Barnett
Cc: Mary Barnes; Ted Hardie; rtcweb@ietf.org
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB



On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
Mary,
  How can there be interoperability issues if no one is required to use SDP over the wire?  Are you saying that there are things that we need that SDP cannot express (or cannot be extended to express)?

- Jim


I just want to clarify something. Is the expectation that an application developer can (if they so choose) take the SDP, parse it, extract the data, send in an alternative format and then reassemble the SDP at the remote side an accepted practice and an expected use case?

Regardless if it is or not, I'm positive that this extraction/assembly process will be done but I want to make sure the expectation/use case is absolutely clear. From what I've been reading, the expectation is the browser generates "blob" and "blob" gets given to other party 'as is' but perhaps I'm mistaken.

Further, the issue with SDP is also offer/answer. SDP isn't just a arcane/obtuse format. It's a state machine and a media signalling protocol. That causes a great deal of pain (breaks or messy hybrids) for other models even if we can "disassemble and reassemble" SDP.