Re: [rtcweb] Review request for RTCWeb standard signaling protocol

samuel <samu60@gmail.com> Fri, 07 October 2011 10:27 UTC

Return-Path: <samu60@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 B8B7F21F8A6C for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 03:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 3My8FSHrN88E for <rtcweb@ietfa.amsl.com>; Fri, 7 Oct 2011 03:27:34 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B84A421F88B6 for <rtcweb@ietf.org>; Fri, 7 Oct 2011 03:27:33 -0700 (PDT)
Received: by qyk32 with SMTP id 32so346961qyk.10 for <rtcweb@ietf.org>; Fri, 07 Oct 2011 03:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GjZ/9kyY24ZHSjQV7eKoe+xwfpX9HqX8ivzDTr9QNYc=; b=YGgYA0gqwTIp04NgK20c+4aUfBdvn2rcbGB8eQuOs24ElcEwFluQOvmhclmfV7wKvk eFky4sMRJUoB5Tzav9+U9ombgJJtBg+n8GfvnLM5lTa5awOrNWHa6lz0x0EHH1MQdXVT DzAj/w4BuUcYL6hq9oTj6pyUQTkLLyl9D0rDM=
MIME-Version: 1.0
Received: by 10.229.241.135 with SMTP id le7mr1388669qcb.149.1317983444981; Fri, 07 Oct 2011 03:30:44 -0700 (PDT)
Received: by 10.229.40.68 with HTTP; Fri, 7 Oct 2011 03:30:44 -0700 (PDT)
In-Reply-To: <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com>
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com> <4E8AC222.4050308@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com> <CALiegf=ejF2kUC1m=74o9eprF1M8wYtgE-Crwa1x14rzDOf+gQ@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com> <393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com>
Date: Fri, 07 Oct 2011 12:30:44 +0200
Message-ID: <CAOg=WDcC9t2KhQUg0gDJ60gO_2mNyMv9HKt=otCdPDfj4TnoTg@mail.gmail.com>
From: samuel <samu60@gmail.com>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: multipart/alternative; boundary="001485ea86b60ed67a04aeb2efc8"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
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, 07 Oct 2011 10:27:34 -0000

Hi all,

The point Iñaki is pushing forward is crucial, as Tim also stated, because
it will save us the burden of implementing another protocol, the marketing
fight between protocols (do you want another SIP vs. H323 "war"?) Please,
don't reinvent the wheel, keep it simple.

Best regards,

Samuel

On 7 October 2011 12:23, Tim Panton <tim@phonefromhere.com> wrote:

>
> On 7 Oct 2011, at 07:05, Ravindran Parthasarathi wrote:
>
> > Inaki,
> >
> > I understand that you don't want any signaling protocol for RTCWeb  to be
> standardized. I'm strong believer of "something is better than nothing".
> Also, My standard signaling protocol proposal is never a hindrance to your
> innovative custom-build signaling protocol (SIP over websocket) development
> and the standard signaling protocol is not meant for you in case you are
> building custom-build signaling protocol.
> >
> > From the RTCweb client programmer perspective, there will be an set of
> API for building custom build signaling and another top level API which is
> based on proposed standard signaling. I could not understand why are you so
> against the standardization of the signaling protocol.
>
> Because it is a distraction. It is unnecessary, the advantages don't
> outweigh the disadvantages.
>
> It isn't essential to the success of this effort and would slow us down by
> _years_ debating the details.
>
> Even if we could magically all instantly agree to use (say) RFC 5456 as the
> standard (*) , it would then immediately impact the
> core effort, the temptation to add features and helper methods to the core
> media API that suited the 'standard' signalling protocol
> would be irresistible. Pretty soon we'd find we had a media layer that
> could _only_ work well through the standard signalling protocol.
>
> Tim.
>
> (*) In my view no one of the currently available signalling protocols are
> suitable for this effort. They were all designed with
> a totally different set of constraints to the ones faced by rtcweb.
>
> T.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>