Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

Eric Rescorla <ekr@rtfm.com> Wed, 03 July 2013 21:37 UTC

Return-Path: <ekr@rtfm.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 8167411E80F7 for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2013 14:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.192
X-Spam-Level:
X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 LGrI3-SaPO-N for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2013 14:37:17 -0700 (PDT)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 77FB911E80EA for <rtcweb@ietf.org>; Wed, 3 Jul 2013 14:37:17 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id c11so411703qcv.23 for <rtcweb@ietf.org>; Wed, 03 Jul 2013 14:37:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=YSIW81SEkHRuXVI7EAnYqQq8UmmeiTrr6XM9TCR+KLs=; b=LGX9fwR2MTZgfNrU9GKNfcynX6ufTJAOTuuo/+IFpHJiXeW2kDtjhj2535t/z64OqM fAQAgi/XZ6LqD0EOjSxseMIpEYDA3UvPqfGd9BuIb+ILfaNzkp5Ug7S2FQf/DH3+KL2m GyBGL9GRzAiIONJz3Z0IvV2k/OEMR7udbBCFKvsz4SNYSRXN8UFwbFkH5ZTzkzYoZRD3 gMsZ5WkvpMEg5Vmn1u2pZ99qy4QJdsAYKkfzUhO2ebxxz3MbqliLIdtbhhRqtrEXX5Pp WjByXTvclkThTWGm9MqrIe91NcgJWB0KCUe34BSeuTrO2gJ3OlV0zDdc+rf4u8MSlOJi iKDQ==
X-Received: by 10.224.115.5 with SMTP id g5mr6275088qaq.53.1372887437001; Wed, 03 Jul 2013 14:37:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.48.234 with HTTP; Wed, 3 Jul 2013 14:36:36 -0700 (PDT)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 3 Jul 2013 14:36:36 -0700
Message-ID: <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: multipart/alternative; boundary=047d7bdc9514ffd74204e0a243ca
X-Gm-Message-State: ALoCoQlM0EFdi68E32/9RVefDx/2NwvWyq8NblAeUwVcNyGEeDaI/KOlmYYus+ltmH6Om6C13lP3
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
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: Wed, 03 Jul 2013 21:37:23 -0000

On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <pthatcher@google.com>; wrote:

> On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
>
>> On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <pthatcher@google.com>wrote:
>>
>>> Camp #0:  I've used SDP for years and I'm very comfortable with it.
>>>  Using SDP as the control surface really helps my use case, which is legacy
>>> interop.  Defining an API without SDP would be too much work, and probably
>>> fail.  Look at what happened with SDPng!  Supporting all these advanced use
>>> cases doesn't seem worth it.   If developers are doing that much advanced
>>> stuff, they can learn to munge SDP.  It isn't that bad.
>>>
>>
>> Hmm... That's not my understanding of the situation at all.
>>
>> Rather, I believe the expectation is that you shouldn't have to modify the
>> SDP but rather there should be API points to cover most of the use cases
>> that people want. This isn't to say that all those API points exist or
>> that
>> they work or whatever.
>>
>> -Ekr
>>
>>
> I'm glad to be wrong here.  Is the phrase "you shouldn't have to modify
> the SDP but rather there should be API points to cover most of the use
> cases"  the consensus of the working group?
>

I thought it was, but I'm not the chair, so maybe you could ask Harald or
Stefan.


 Along with that, is "use Jingle for signalling" included in your set of
> "most of the use cases"?
>

No, I don't think it is, since it's not SDP.

Maybe I could phrase this differently: It was my understanding that you
should have
API points to get the PC to emit SDP that would express the policies,
preferences,
actions, etc. that the application wants. If you want something that's not
SDP you would
need to gateway.

This may or may not be a satisfactory state of affairs, but it was the rule
I was using
(based on what I thought the WG expected) for when use cases needed new API
points.

-Ekr