IETF Logo Mail Archive

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

Cullen Jennings <fluffy@iii.ca> Thu, 10 May 2012 22:29 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 8594B21F85F2 for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 15:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 0cSG-7sPyBMt for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 15:29:30 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id AF46D21F85F0 for <rtcweb@ietf.org>; Thu, 10 May 2012 15:29:30 -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 D578422E25B; Thu, 10 May 2012 18:29:23 -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: <CAD5OKxsw+mJ5Ou7_p+nJU55iwuh1xnNrF0YEeST_sBUFWLwLHA@mail.gmail.com>
Date: Thu, 10 May 2012 16:29:21 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <865D30F8-A632-4D2C-97B4-693854F03210@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> <7F2072F1E0DE894DA4B517B93C6A05852C44001 338@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> <F6B988EE-8847-4AC6-806C-A9B96A075BDB@iii.ca> <CAD5OKxsw+mJ5Ou7_p+nJU55iwuh1xnNrF0YEeST_sBUFWLwLHA@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 22:29:31 -0000

On May 10, 2012, at 3:23 PM, Roman Shpount wrote:

> 
> On Thu, May 10, 2012 at 4:55 PM, Cullen Jennings <fluffy@iii.ca> wrote:
> > 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.
> 
> 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 theexample.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.
> 
> 
> Let's say a standard SIP proxy (call it opensips for specificity) placing a forked call to two ICE enabled IP phones. Both phones answer with 200 OK.

With a standard SIP proxy, only one of the 200 would be sent back to the web browser.

v2.23.0 | Report a Bug | By Email