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

Peter Thatcher <pthatcher@google.com> Mon, 08 July 2013 14:51 UTC

Return-Path: <pthatcher@google.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 03A4221F9C06 for <rtcweb@ietfa.amsl.com>; Mon, 8 Jul 2013 07:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.813
X-Spam-Level:
X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 3rJV-6NCMQwl for <rtcweb@ietfa.amsl.com>; Mon, 8 Jul 2013 07:51:53 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91C21F9AA4 for <rtcweb@ietf.org>; Mon, 8 Jul 2013 07:51:53 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id xb12so4351612pbc.40 for <rtcweb@ietf.org>; Mon, 08 Jul 2013 07:51:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xOukynzRt9DJpE6XRhuAl6Om2WTAN9tE9ZQxh1of5R8=; b=PFIm/zNYQqw7PBcz0NrEeBwLJsHS53VeFjXVuB7JXRhHCvslC7gpI+O4fvps0mcmHR RL1eo3cGIuyXRd3AvdEx8huMysJHvdaDRwon1+hILWYoq2/PHeFjKSuMlYRTv4FxUJsC 3yuJMVCd2nGc3BRrqaAsti5ih+9e/Wd0hDmQJgxChEEfRly1e3hGrAFWQ2X1ABEvJUY6 TBbY1BR+RwUZECv74Bemw+B9DlBbW26QvALj8lP2bUhV88JgujYNaFlmOqX21wn00e3s 433EGrbiGhZkuOHgTlhMwoIAwWegMz3hG9Lx+scEJ7DxzfBX4FFhVkO2j2lBxymq8Bi7 ezgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xOukynzRt9DJpE6XRhuAl6Om2WTAN9tE9ZQxh1of5R8=; b=pfbEbgJU6b/grO00NgPFgHkSUmT2J06i/622pnLJKstjllwhucHJKoyKJUhh6m+zHS Zk7QMLq4JrzGAR2uvNIqgkLVfL77NfwjItJ+ADlNNnSjqu1eQN6ZbKKuik/Vtoe8C4hX 0AzPcARxrb/r4881ml+zAazCEEfLYnFm1Ov5EUFu/8w+JAif5H2Ce6PkEjlgs6V7ThqA qyyQjXJEDnystb3c96lAyXC2/eiTGdOADTaGtTYRJztp0sEbi8z+sJw5Z0Mt8Ll/KiJu GJqWnFRnDEFR5z3D+ZCdLTiSwtQfreRcSnl9AMr3EM3zHqCVvSY1kYfWIudcF9o4sX/e agRA==
X-Received: by 10.66.25.10 with SMTP id y10mr23059589paf.96.1373295112634; Mon, 08 Jul 2013 07:51:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 07:51:12 -0700 (PDT)
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com> <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se>
From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 08 Jul 2013 07:51:12 -0700
Message-ID: <CAJrXDUHfjjZ9f2fRq=kPb-vmydQrLF=GP=wTsMq=oGEbCrf=ew@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Content-Type: multipart/alternative; boundary="bcaec52bec175cb2ef04e1012f51"
X-Gm-Message-State: ALoCoQm3hsauhnimkmQT/SGsnJrTFc2vuAUCC8jwCXIzkH8UcS5eETWtzsU7QNfe/X5a1I4heeoEPDYWwI31VoOSqfHzGCSXE1Q7FXLATqIze9KUYCise4Dc+ub9tcnv5BdnSjLoU7OqRBGKOKDZrErOm4pH5VjbsFS8RhEoUk8Xpsck1HeyVikBbfDY8QkibxWipspEYvIx
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: Mon, 08 Jul 2013 14:51:54 -0000

On Fri, Jul 5, 2013 at 11:33 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 7/3/13 11:37 PM, Eric Rescorla wrote:
> > On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <pthatcher@google.com
> > <mailto:pthatcher@google.com>> wrote:
> >
> >     On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <ekr@rtfm.com
> >     <mailto:ekr@rtfm.com>> wrote:
> >
> >         On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher
> >         <pthatcher@google.com <mailto: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.
>
> I definitely think this is the consensus of the working group.
>
> I think the exception would be when interoperating with other systems
> that use another dialect of SDP - I don't think we could cover such
> translations with API points.
>

Are you trying to say "API points couldn't cover uses cases where different
dialects of SDP go over the wire"?  Because I would have to disagree with
that.  I think we could very easily support such uses cases with rather
minor changes to the API.  In fact, the proposal I made for adding just 3
methods (the NoPlan JS API) allows for either Plan A or Plan B (or even
Jingle, mostly), which would make things a lot easier for such use cases.

Now, my design might not be the optimal.  Perhaps we could do better.  But
I think it is possible to serve all these uses cases with a pleasant API.


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