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

Cullen Jennings <fluffy@iii.ca> Thu, 10 May 2012 20:55 UTC

Return-Path: <fluffy@iii.ca>
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 A6E3211E8074 for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 13:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level:
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 hN3bZvyigDYJ for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 13:55:25 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BA84921F85D3 for <rtcweb@ietf.org>; Thu, 10 May 2012 13:55:24 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CFD2422E257; Thu, 10 May 2012 16:55:17 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAD5OKxvXstf7GOcZc7qdFB6GPvZyzBP8cv+JQcDK6rzbsmA6-Q@mail.gmail.com>
Date: Thu, 10 May 2012 14:55:16 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6B988EE-8847-4AC6-806C-A9B96A075BDB@iii.ca>
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> <CAD5OKxs3AqvbookWYPDgOuAkjPZGVUdSEhqz6P _p9E4h_ZHJGQ@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <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> <90DEBA9A-E8D2-4662-9A41-95B361FDAF05@iii.ca> <CAD5OKxvXstf7GOcZc7qdFB6GPvZyzBP8cv+JQcDK6rzbsmA6-Q@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.1084)
Cc: Randell Jesup <randell-ietf@jesup.org>, "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: Thu, 10 May 2012 20:55:25 -0000

On May 10, 2012, at 1:51 PM, Roman Shpount wrote:

> 
> On Thu, May 10, 2012 at 3:06 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> 
> Uh, I don't think we are ready to design anything yet - I am still 100% confused on what the use case we are trying to solve is. Is it forking on at the browser, in intermediate node, in SIP, parallel, sequential or what? I want to see the end user use cases we need to deal with. The example Randell gave seems reasonable but seem like it would best be handled with just multiple independent PeerConnection. The combination of requiring ICE and SIP parallel forking is very complicated - particularly without Reliable provisions responses and all the complexity that ensues.
> 
> So before we go down this path, lets get clearer on what we are trying to accomplish.
> 
> 
> One use case is interop with SIP with parallel forking, reliable provisioning responses, UPDATE, and ICE. The big question regarding this use case is availability of anything that supports parallel forking, reliable provisioning and UPDATE. I actually think ICE makes implementation of this use case easier, not harder.
> 
> The real end user use case is any type of service where calling destination is a small group of people. This allows to initiate a single offer and send it to all the members of the group. In most cases only one person will reply, but, in a smaller set of cases, several people from the group will answer. In the later case, you need a mechanism to clone the original peer connection (or to create additional peer connections based on the original offer) and deal with additional answers independently. 
> 
> This is a very common use case for any type of service where people use multiple devices. For instance if we add voice/video calling to a web mail program, I can be logged in from multiple devices. It can also be a shared account (like support@acme.com) where several different people are logged in to the same account. When someone places a call to a shared account, several people can answer at the same time.
> 
> I know this can be addressed by sending a separate message  and reversing the call setup direction (each accepting party creates an offer and sends it back), but this causes another set of issues related to slow call setup and media clipping.
> _____________
> Roman Shpount
> 

So let me try and make sure I understand this uses case. The web browser sends some signaling to a server that convert it to a sip call to the fork@example.com address. This sends it to the example.com sip server that parallel forks it to two SIP UASs  that are so two phones ring at the same time. Now both theses phones are going to negotiate ICE by using reliably provisional responses. 

What products actually do parallel forking like this and return provisional reliable responses with ICE. I'm sort of questioning this is a common use case. The Nortel, Cisco, Avaya, Siemens etc enterprises PBX systems I have seen that support ringing multiple phones at the same time don't seem to do this way. They manage to hide the parallel forking with a B2BUA model and make it look like sequential forking.