Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Roman Shpount <roman@telurix.com> Mon, 14 May 2012 20:40 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 1B14921F88C1 for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 13:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Level:
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 XPPdjwfHnT3i for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 13:40:47 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54E7221F88BF for <rtcweb@ietf.org>; Mon, 14 May 2012 13:40:47 -0700 (PDT)
Received: by dacx6 with SMTP id x6so6607104dac.31 for <rtcweb@ietf.org>; Mon, 14 May 2012 13:40:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=0eWoHnz3QV7+pyDX6Rv4ViHgBWyNSnPzgM3mnTqu9Lw=; b=HoX/WlzsEadv/UKt4Y5IZyRjdyhKSd/Q59tFPY7HYcEmCJYI1elD9HG1dO70Ffm2Ky Uz1b9ymnqtNZKTbkttX5XmzUkWNHe0/iGQ6uXD99qwn/D9EC80AXeCoPlZ1q66NSJSVc i0if6OCR3KiELH3LEASXvsd3UIVgtv63MskaNkdjLhzIctMQ9DQbC82l5hOaOR6z7LnD EsEJwOI+ztjnLdjeqF4jDsC+mjn1LKv8fELxU8lyGBv55ZGBTxjESemqLq82U1HkYUNe 55aU45nv6TDHupQ8ACeUgWUMUsBQmk9AUkXJQCieFoEyfuEAetBFh00TqdZLXUYNHt+I cZpA==
Received: by 10.68.193.233 with SMTP id hr9mr26077756pbc.99.1337028046984; Mon, 14 May 2012 13:40:46 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id jv6sm15555709pbc.40.2012.05.14.13.40.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 13:40:46 -0700 (PDT)
Received: by dacx6 with SMTP id x6so6607079dac.31 for <rtcweb@ietf.org>; Mon, 14 May 2012 13:40:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.131.38 with SMTP id oj6mr4033850pbb.39.1337028045251; Mon, 14 May 2012 13:40:45 -0700 (PDT)
Received: by 10.68.74.133 with HTTP; Mon, 14 May 2012 13:40:45 -0700 (PDT)
In-Reply-To: <CABkgnnWDqnYho+KEOFe+N2TjQvPQa6BYoCLKAR6n79Da9bqwrQ@mail.gmail.com>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <CAD5OKxsOAeTRdCgj2g4BY8maeG1n9nzCv29g8kaFPVZ4tf8C5w@mail.gmail.com> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxsbTSpMPg30P4DSN6UasCx6na43tpZ5yT2ct6SLMpd9xQ@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuy8_Ras3X-8tcY1qaLRTVJ-z-JuXQaf0NKaRwN_dU18Q@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuv7T6YrEXEeVECKbGtRg4feoRYTgvC57yqWXTBK43ypg@mail.gmail.com> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <CAD5OKxuq14_DfSJuFEHq_ZEubbOYt7NFTcXWpLND8ggAr37QhA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxvFYy-9XAE5GG0n58xX2HKRX3o5qkTZ2o6rugakaM77Ew@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <CAOJ7v-1Ue=q4MAh0csiDLvRFfMGaJ4vWrDxhir-S-OjSTsymaw@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <CABkgnnVO5UyhHjiWVPsLYAoXSKPsfn6Fnb10hQr_6-kgq0FC3g@mail.gmail.com> <F0D1114C-0B6C-4AED-BDD3-4E3D6A219485@iii.ca> <CABkgnnWNLOb_xLUfOoZ5d7sKVsJDvjmNhmRqFcupO4S4p8Nrfw@mail.gmail.com> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <BDEE1968-C29C-45D1-9D88-59723C63125C@phonefromhere.com> <CAD5OKxsQqVPL1OVn=BjasFWaeyHCB1A3WwFuix99KpXd9CQWEQ@mail.gmail.com> <CABkgnnWDqnYho+KEOFe+N2TjQvPQa6BYoCLKAR6n79Da9bqwrQ@mail.gmail.com>
Date: Mon, 14 May 2012 16:40:45 -0400
Message-ID: <CAD5OKxumK66RDX3zr59jxA1Mwvn7ZqNhP6=wnhC2e+drCRZg+w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b15b017b124f704c00519e0
X-Gm-Message-State: ALoCoQnYVy89gyItuu5AKcBmrrZW5250deVcffUBWqIsCDWxobLAM3Jj5AS5RfHhSCu7e33/TfTd
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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, 14 May 2012 20:40:48 -0000

On Mon, May 14, 2012 at 4:31 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 14 May 2012 11:45, Roman Shpount <roman@telurix.com> wrote:
> > It is possible to resolve this identity to end
> > point mapping using some sort of HTTP signaling
>
> I think that this was the point.  Your application has some concept of
> identity that maps to one or more registered endpoints.  It can work
> out the signaling such that all devices get notified of a session
> request without the need for this complex cloning mess.
>

I am not sure the cloning is a "complex mess". If ICE is the requirement
(so you know remote IP/port of each party) you can map each remote party to
the source IP/port. Then all you need to do is reference counting for local
sockets/TURN allocations, and you are done implementing it. PRANSWER would
probably require as much coding but would not solve all the problems that
cloning will.
_____________
Roman Shpount