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

Jozsef Vass <jovass@adobe.com> Mon, 26 September 2011 17:15 UTC

Return-Path: <jovass@adobe.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 C159C21F8CD7 for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 10:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 H9eOdsFgNwi6 for <rtcweb@ietfa.amsl.com>; Mon, 26 Sep 2011 10:15:33 -0700 (PDT)
Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 554E521F8C86 for <rtcweb@ietf.org>; Mon, 26 Sep 2011 10:15:32 -0700 (PDT)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKToCzxof+AE+rivsC6ETd9SbGPuZi+B43@postini.com; Mon, 26 Sep 2011 10:18:16 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8QHGQdI011133; Mon, 26 Sep 2011 10:16:27 -0700 (PDT)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8QHCeHS011865; Mon, 26 Sep 2011 10:17:39 -0700 (PDT)
Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 26 Sep 2011 10:17:08 -0700
From: Jozsef Vass <jovass@adobe.com>
To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
Date: Mon, 26 Sep 2011 10:17:07 -0700
Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])
Thread-Index: Acx8G3BT5l/1JIY9S9Cv+fBuNGuWNgAUlZ3A
Message-ID: <0FEA137C08A9DF4781EEF745038C969430A51F67F2@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@alvestran d.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com>
In-Reply-To: <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 17:15:34 -0000

Look at it from a game developer's perspective. I do not want to build a softphone phone with advanced features, just to add voice chat to the game. Online registered players should be able to chat with each other, but really no need to interoperate with anything else (and preferred not to).  Quite often, it is a group of people who are playing together, so multiparty chat is highly desirable.  As I game developer, I do not event know what is SIP, Jingle or SDP and probably do not even care about it.

If you want to communicate behind NATs, firewalls, you need to run a service to determine the reflexive address (in addition to your web server) at least.

Jozsef

-----Original Message-----
From: Saúl Ibarra Corretgé [mailto:saul@ag-projects.com] 
Sent: Monday, September 26, 2011 12:11 AM
To: Jozsef Vass
Cc: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)])


On Sep 23, 2011, at 2:58 AM, Jozsef Vass wrote:

> I am in support of having some basic mechanism in the browser as part of rtcweb to enable developers to quickly and easily setup media between participants. Furthermore, if an API is too complex or too hard to use, people will not use it or misuse it. I can only see a handful of companies developing advanced calling feature on top of rtcweb, most people just want to have something simple to work without caring too much about the details.
> 
> Maybe it would be advantages to specify such a very basic use case, e.g., targeting gaming. It must work behind NATs using peer-to-peer media transport (but fallback to media relay may not be required). Since it is targeting closed community, 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.
> 

This is a no go. What "closed community" are you talking about? Interoperability is a MUST here, even if I'm in favor of not having any default signaling protocol specified. We need to be able to communicate with other protocols without building gateways. This can be achieved with both SIP and XMPP, so I see no need for reinventing the wheel. Lets let developers use whatever protocol they like and just use RTCweb for the media part.

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

What service? Who would host a server?

--
Saúl Ibarra Corretgé
AG Projects