IETF Logo Mail Archive

Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])

Iñaki Baz Castillo <ibc@aliax.net> Mon, 26 September 2011 07:52 UTC

Return-Path: <ibc@aliax.net>
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 EF61221F8AD9 for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 00:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.415
X-Spam-Level:
X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3, 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 ijLNvnHDGi0X for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 00:52:40 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC821F8569 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 00:52:40 -0700 (PDT)
Received: by vcbfo11 with SMTP id fo11so3608734vcb.31 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 00:55:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.69.18 with SMTP id a18mr5478742vdu.430.1317023721966; Mon, 26 Sep 2011 00:55:21 -0700 (PDT)
Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 00:55:21 -0700 (PDT)
In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com> <4E77C3EC.9060801@jesup.org> <CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com> <DB86C19C-781C-4FD2-ADE2-D6E1C0EE1D61@ag-projects.com> <4E79A964.2050007@alvestrand.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com>
Date: Mon, 26 Sep 2011 09:55:21 +0200
Message-ID: <CALiegf=XwxfEnraDFNy2tQjQcQagbyhZaO30ce10Ny4YahZtjg@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Jozsef Vass <jovass@adobe.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
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, 26 Sep 2011 07:52:41 -0000

2011/9/23 Jozsef Vass <jovass@adobe.com>:
> there is no need for interoperability, there is no need for SIP, Jingle, etc. At the minimum, this would require a simple service for ip address lookup and to aid NAT and firewall traversal.
> For example, when a user registers with this service, he/she is assigned an identifier or blob. In order to communicate with another party, all they need to do is to exchange this information (this can be done using websocket, etc.) and setup media channel. There should be no need for parsing SDP, etc.


...and when you need more features (like adding video within an
existing audio session, or putting the session on hold, or negotiating
codecs and encryption parameters) you will realize that you are
reinventing SDP.





-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email