Re: [rtcweb] Current state of signaling discussion

Eric Rescorla <ekr@rtfm.com> Tue, 18 October 2011 21:19 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 6081921F8C19 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 14:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.952
X-Spam-Level:
X-Spam-Status: No, score=-102.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 tki2-I6-VZeW for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 14:19:28 -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 D39D521F8C17 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 14:19:27 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1137374vcb.31 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 14:19:27 -0700 (PDT)
Received: by 10.52.99.195 with SMTP id es3mr4361062vdb.63.1318972767096; Tue, 18 Oct 2011 14:19:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.161.20 with HTTP; Tue, 18 Oct 2011 14:18:47 -0700 (PDT)
In-Reply-To: <F89E752A-820B-4C41-BE14-15B358BFA267@acmepacket.com>
References: <4E9D773A.4010705@ericsson.com> <E7E0C331-9943-444F-9D42-782DAD6A7FF3@acmepacket.com> <CABcZeBP0v=q7sH4G4Ehvx7x5b_tyoukS1N0EOm1Ji8URNOeDUw@mail.gmail.com> <F89E752A-820B-4C41-BE14-15B358BFA267@acmepacket.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 18 Oct 2011 14:18:47 -0700
Message-ID: <CABcZeBMmB=Lgo3eRXR6VdUwxndGcquije1wVfOcYWwOF+y5gOg@mail.gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [rtcweb] Current state of signaling discussion
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: Tue, 18 Oct 2011 21:19:28 -0000

On Tue, Oct 18, 2011 at 2:05 PM, Hadriel Kaplan <HKaplan@acmepacket.com>; wrote:
>
> In the abstract it states:
> "The protocol focuses solely on media negotiation and does not handle call control, call processing, or other functions."
>
> Ignoring esoteric stuff like session transfer, forwarding, etc. (ie, ignoring "phone" stuff) is fine.
>
> BUT, for an actual session protocol to work for even a gaming app, you need to do the following:
> 1) determine a target for the ROAP message (ie, who's this OFFER going to in the end?)
> 2) define how that target identity is conveyed (ie, how does the web server know which browser to give this ROAP OFFER to?)
> 3) define a source identity model, possibly with authentication (ie, who are you?)
> 4) define how the source identity is conveyed (ie, how does the server/far-end-browser know who's calling?)

One might already have much of this stuff in your application to support
whatever person-to-person communications (E.g., IM) you already
have. When I heard "20 lines of code" I always assumed that it excluded that
sort of routing-type stuff.


> 5) define a end-of-session indication
> 6) define a keep-alive mechanism, for when the far end goes away silently and (5) doesn't apply

Do these involve a lot of code?

-Ekr