Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

Roman Shpount <roman@telurix.com> Thu, 13 October 2011 04:48 UTC

Return-Path: <roman@telurix.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 EDF7A21F8B16 for <rtcweb@ietfa.amsl.com>; Wed, 12 Oct 2011 21:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level:
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, 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 VqUkb-d4Nuyk for <rtcweb@ietfa.amsl.com>; Wed, 12 Oct 2011 21:48:25 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06321F8A55 for <rtcweb@ietf.org>; Wed, 12 Oct 2011 21:48:25 -0700 (PDT)
Received: by vws5 with SMTP id 5so1466543vws.31 for <rtcweb@ietf.org>; Wed, 12 Oct 2011 21:48:24 -0700 (PDT)
Received: by 10.52.36.197 with SMTP id s5mr2187005vdj.36.1318481304393; Wed, 12 Oct 2011 21:48:24 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id jo8sm2699945vdb.20.2011.10.12.21.48.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Oct 2011 21:48:23 -0700 (PDT)
Received: by ggnk3 with SMTP id k3so1694079ggn.31 for <rtcweb@ietf.org>; Wed, 12 Oct 2011 21:48:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.8.233 with SMTP id u9mr6059770pba.30.1318481302251; Wed, 12 Oct 2011 21:48:22 -0700 (PDT)
Received: by 10.68.47.40 with HTTP; Wed, 12 Oct 2011 21:48:22 -0700 (PDT)
In-Reply-To: <4E966928.1020100@jesup.org>
References: <CA+9kkMBi9BzDu=WOq3RG-o5nbfnUTftDg3LRBU3DFh=Kc4W5ZQ@mail.gmail.com> <CALiegfms2bt-WPtMeosFQz3-aSf2L6mfX+i68tw45sSgix561Q@mail.gmail.com> <4E8D6507.8000707@ericsson.com> <CALiegf=VyViX2arp0gr0dK4WN_jv=bjwP0LUAxRf=quTxrYrUQ@mail.gmail.com> <CALiegfn15szv-2yXeWptWjsQC2CwVODg_X90gD4odZkCR0LzvA@mail.gmail.com> <4E955775.10206@alvestrand.no> <CABRok6n6UA_nFfLzQ4K+H0+idspEsymW29OZH0J5q1ewF3PpRw@mail.gmail.com> <4E956526.2090604@alvestrand.no> <380E325E-A7EF-489A-AA24-0270224FC87A@phonefromhere.com> <4E957C55.9020706@alvestrand.no> <13C2526B-E7B1-408C-BD1D-EC5E8C8F6472@phonefromhere.com> <4E95871F.9010605@alvestrand.no> <E21755ED-205F-4D80-BB97-CF32E989EB3F@phonefromhere.com> <4E959D48.3090401@mozilla.com> <9E790044-DE19-46DD-89D8-C4F2973F8D65@phonefromhere.com> <CAD5OKxvORBxJk=5oAeWjUdMgq9pr7eePOnKana4VtwVEHFNGNg@mail.gmail.com> <4E9612D3.2040207@jesup.org> <CAD5OKxu_dL_K1N-H=Cz2Lcyvv8426SXACp1GvCeOLyFpdiyOHw@mail.gmail.com> <4E966928.1020100@jesup.org>
Date: Thu, 13 Oct 2011 00:48:22 -0400
Message-ID: <CAD5OKxvUEXOepL4OyDDy+bS1GPxwK=cy=UbVSUD6=0JiZrkzuA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=bcaec5215a59a9e87b04af26d948
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)
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: Thu, 13 Oct 2011 04:48:26 -0000

On Thu, Oct 13, 2011 at 12:29 AM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:

> It did cover that case - it was up to the app what to do when the first
> ACCEPT was processed.  I didn't go into the JS-level mechanisms used.


I guess I might be missing something, but how, using ACCEPT, RTC can
generate a single offer, get two answers back, and create two media streams?
Creating a second media stream does not mean that this is a last answer for
this stream (corresponds to new SIP dialog created by provisional response)
and accepting a stream does not mean it cannot be cloned (corresponds to new
SIP dialog created by new final response). So essentially we need four
operations: create offer, create media stream based on an answer, update
existing stream based on a new answer for the same dialog, and finalize the
media stream. Or alternatively we can achieve the same with create offer and
stream together, process answer, accept (finalize the stream) and clone the
stream. Either way we need four methods and we achieve the same
functionality.

Do not assume that remote IP == source - this is easily provably false,
> though if you used remote IP+port AND local IP+port I think it would be ok.
>  However, for each remote connection we should have a DTLS connection
> instance, so that's probably simplest.
>

Yes, I do agree we should disambiguate on local/remote IP+port pair. I did
not realize we are requiring DTLS/SRTP in RTC. I don't think I've seen a
single implementation of this in the wild, and I do not see any harm in
supporting SRTP and (with user confirmation) of plain RTP.
_____________
Roman Shpount