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

Roman Shpount <roman@telurix.com> Mon, 14 May 2012 18:45 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 1147B21F88A3 for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 11:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.884
X-Spam-Level:
X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, 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 pjJXd5s3PtuT for <rtcweb@ietfa.amsl.com>; Mon, 14 May 2012 11:45:30 -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 6C43F21F88A7 for <rtcweb@ietf.org>; Mon, 14 May 2012 11:45:30 -0700 (PDT)
Received: by dacx6 with SMTP id x6so6481041dac.31 for <rtcweb@ietf.org>; Mon, 14 May 2012 11:45:30 -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=NJaDgNUJBddL/nwIkzno7SJ6Qs2jtk2LdJlKtVYN5uQ=; b=Vc/KzUOqNJcXRf6q9TZtIVot4nn03cm8+vvU3iTDd6HNCa79RKNqjyQ1ZxjOHQPWU6 +FBT1rUzhtqMqt3Zg6QTfccJr00HAL7z7Y2UO0ak7ivFn+ObtcG5rxEfKG4Q7hfrq/B5 N5o9zPUbfD5ISiL3WN1YnKgixnPq5Ix2gxk0knQFz+BqsIskV9sdt/WdZeulOn62ghEN wHcfTHAupfuU7DOmlGC1OwKV0h/Fqy1TWtIgWGgVkwZJj6bf1lnVevUlfn+iwPI71RR6 9q3/7mgLuC2R90h668QM6qLW6/pE69vMQuYU1SnIF4nN5f9+dmWTQbl+Rlym3ia1uk1Q PWLQ==
Received: by 10.68.132.34 with SMTP id or2mr25647737pbb.118.1337021130271; Mon, 14 May 2012 11:45:30 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id jv6sm15314383pbc.40.2012.05.14.11.45.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 11:45:26 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so6675577pbc.31 for <rtcweb@ietf.org>; Mon, 14 May 2012 11:45:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.227.33 with SMTP id rx1mr25192796pbc.102.1337021125392; Mon, 14 May 2012 11:45:25 -0700 (PDT)
Received: by 10.68.74.133 with HTTP; Mon, 14 May 2012 11:45:25 -0700 (PDT)
In-Reply-To: <BDEE1968-C29C-45D1-9D88-59723C63125C@phonefromhere.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>
Date: Mon, 14 May 2012 14:45:25 -0400
Message-ID: <CAD5OKxsQqVPL1OVn=BjasFWaeyHCB1A3WwFuix99KpXd9CQWEQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: multipart/alternative; boundary=047d7b1631bf3c779c04c0037d32
X-Gm-Message-State: ALoCoQnXiNfy9C2LvjlYtWRvqSKZMpmcupQ74rq/yuBZ+K05EhUtQvuYf0UTy1vXpc+fGNQBQbj8
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 18:45:31 -0000

On Mon, May 14, 2012 at 5:25 AM, Tim Panton <tim@phonefromhere.com> wrote:

>
> On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote:
>
> > Support for multiple registered contacts and (parallel) forking are
> pretty fundamental to SIP.  This has little to do with conferencing.  Some
> systems (not all) may support only serial forking or may serialize media
> interactions associated with parallel forking, but forking remains widely
> deployed and useful.
>
>
> I have a feeling that it is mostly useful because SIP is managing both the
> signalling and the identity.
> In most WebRTC cases, the real identity of the user will be established
> with a web protocol (perhaps OAuth).
> The identity used in any browser based legacy signalling (e.g. SIP) will
> be a second-order derived or temporary identity.
>
> In that case there is no need for SIP to use the same  temporary identity
> for both my phones, which (I think)
> renders the forking case significantly less useful.
>
>
I strongly disagree with this. I can still be calling somebody via, let's
say, their email address and end up talking to two people using two
different devices. I think there is always going to be the situation where
one identity (email address, support link on the web site) will map to
multiple physical end points. It is possible to resolve this identity to
end point mapping using some sort of HTTP signaling before media connection
is setup and then to generate offers for each end point, but this would
make signaling more complex, and would slow down the call connect process
by at least half the round trip time.
_____________
Roman Shpount