IETF Logo Mail Archive

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

Justin Uberti <juberti@google.com> Thu, 10 May 2012 20:56 UTC

Return-Path: <juberti@google.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 DF5B121F85D3 for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 13:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.561
X-Spam-Level:
X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Tui108V8yQRC for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 13:56:28 -0700 (PDT)
Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC021F85CF for <rtcweb@ietf.org>; Thu, 10 May 2012 13:56:27 -0700 (PDT)
Received: by qabj40 with SMTP id j40so1073005qab.15 for <rtcweb@ietf.org>; Thu, 10 May 2012 13:56:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=RWW6QX03lS/qyvW0v1S19WA01DwNt13DZYTzv9QmFX4=; b=UFMJPFS38ej8jO8FhRYdDx1BGjQOXsfxCOS50odIJUW3EnyeDwepvg/6kkDo6b/DI9 PqYGxFw94k5A6oxIDZRdUh+c3lkj49S0xy3X7gAN+GtUPC0uPr7a9MNhS4X+G2gOQNf3 94pUJoSUiUbt/1Opkdu4CD8v2ySoFmB7qc4Hgj6imZBOGLPoaTjNCW28551WWEwNarQI 8SQg2j5YtY5kMMpf40BlJ4QLHmTm8vrsOBriUK2SVC89HA/gl9JZbEc3Ak7ztCtrTLz8 TOHXAeDa6sVhRPxAZIVCoqeGrXuq2rzK9QiFsgIH9kcauypbPMnsyPE7CqJZ63RGhKuZ uaHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=RWW6QX03lS/qyvW0v1S19WA01DwNt13DZYTzv9QmFX4=; b=RTCxah3qsx15xj+T1/3lXtg2ppO+PT0xlvP8k6beuvW61hLbdSH0vDezfVTrgLdOcL 2q0h1w8mDoYEfNZ2opvDoxDHAueutoLpPSJxUFatSyRx63H8QVapDr/pREnJChU1X4gj yZB+NkRJwa54nGxYHCyxcwHIw/X0m/iIv4odvByDhs9yrlXuxTifXbRlobFwlebmxqwR bCJjLHmIj1Wbi1L+BVyPVrFE5Fyt7EXIq3O0nZ6vFfcPR/7TgPYZeRp14zlrw0gn4xdh EyckgknPgkDvMeULKHNMrQxiOzOf/TCOn+buS1OgKo8u6hO3t7P/y5foRvW0tc7YPzSn kEQw==
Received: by 10.229.114.203 with SMTP id f11mr3001468qcq.10.1336683387505; Thu, 10 May 2012 13:56:27 -0700 (PDT)
Received: by 10.229.114.203 with SMTP id f11mr3001453qcq.10.1336683387267; Thu, 10 May 2012 13:56:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.217.129 with HTTP; Thu, 10 May 2012 13:56:07 -0700 (PDT)
In-Reply-To: <CABkgnnVO5UyhHjiWVPsLYAoXSKPsfn6Fnb10hQr_6-kgq0FC3g@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> <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> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <CABkgnnVO5UyhHjiWVPsLYAoXSKPsfn6Fnb10hQr_6-kgq0FC3g@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 10 May 2012 16:56:07 -0400
Message-ID: <CAOJ7v-1Rguh4vSDqdXQx=+SoSoE8ze+97gjXSFPDNMWNF=daZg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="00235429db9079ac4c04bfb4da15"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmmgLspk0tXUgtSzHs0NfDlYuhgA+bETr637rAMjBE2SssXB8mptzGRtX3hrrIAqFOnqDpmXF0qL1rNOgGb94hXgKOTtUjE513CQlphP7tHHvh0p1nXBUNKCymz+xKBCxZCAmyR
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:56:29 -0000

The other use case is the one Partha originally mentioned, and recently
resurfaced:

Issue 2)  UPDATE support within SIP early dialog in the non-forking
scenario. Here, the cloning will not solve issue as the answerer originated
the new offer during SDP_PRANSWER state . Issue 2 is the title of this mail
thread.

which I think expands to:
1. local PC1 sends offer, forks to remote PC1 and PC2
2. remote PC1 receives offer, sends pranswer
3. local PC1 applies this pranswer
4. remote PC2 receives offer, sends pranswer
5. local PC1 applies this pranswer
6. remote PC1 sends update (i.e. new offer)
7. local PC1 does ???

Richard mentioned that this could be solved by cloning, and I think I agree.
local PC1 can clone at step 5, and create local PC2. local PC2 stays in the
pranswer state; local PC1 applies the previous pranswer as final, and then
handles the new offer (update).


On Thu, May 10, 2012 at 3:53 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 10 May 2012 12:05, Cullen Jennings <fluffy@iii.ca> wrote:
> > I'm a very confused on what type of forking (with ICE) use case people
> want to satisfy.
>
> Here's the use case as I understand it:
>
> create offer and send to some thing
> the offer actually hits multiple things
> multiple answers arrive
> want to establish sessions with all of them
>
> That's the use case.  Adding it to the use cases draft (or not) is
> probably something that needs to be debated more.
>
> --Martin
>
> p.s. How the offer reaches multiple things doesn't matter much.  I see
> too many emails on these lists that include the letters S, I and P
> together.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email