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

Randell Jesup <randell-ietf@jesup.org> Tue, 15 May 2012 04:42 UTC

Return-Path: <randell-ietf@jesup.org>
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 E6CCF9E8016 for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 21:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599]
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 HJoOuk5Z2po0 for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 21:42:13 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E2BAE9E8006 for <rtcweb@ietf.org>; Mon, 14 May 2012 21:42:12 -0700 (PDT)
Received: from pool-108-16-41-249.phlapa.fios.verizon.net ([108.16.41.249] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1SU9aN-0004WQ-Ca for rtcweb@ietf.org; Mon, 14 May 2012 23:42:11 -0500
Message-ID: <4FB1DE4F.5010701@jesup.org>
Date: Tue, 15 May 2012 00:40:47 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.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 >
In-Reply-To: <CABkgnnWDqnYho+KEOFe+N2TjQvPQa6BYoCLKAR6n79Da9bqwrQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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: Tue, 15 May 2012 04:42:15 -0000

On 5/14/2012 4:31 PM, Martin Thomson 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.

That isn't the point of cloning (getting notified).  It's the server in 
this case that knows about the multiple endpoints.  (For that matter, 
one could be a WebRTC client, and another could be a WebRTC gateway to 
PSTN, and a third could be a network-based answering service where a 
pickup from an actual endpoint would abort the playback/recording - 
another case of a forked ANSWER after a final ANSWER where cloning is 
useful.)

-- 
Randell Jesup
randell-ietf@jesup.org