IETF Logo Mail Archive

Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 23 September 2011 05:06 UTC

Return-Path: <christer.holmberg@ericsson.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 2D02B21F8573 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 22:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.53
X-Spam-Level:
X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 H0447wVxQJJi for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 22:06:56 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 691F721F8569 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 22:06:56 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-a2-4e7c148866fc
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.F5.20773.8841C7E4; Fri, 23 Sep 2011 07:09:29 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 23 Sep 2011 07:09:28 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Hadriel Kaplan <HKaplan@acmepacket.com>
Date: Fri, 23 Sep 2011 07:09:27 +0200
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: Acx5fs23NM/h1Wl4R+WqaPUYYR5+DQAL+Ohg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233FB6BAA@ESESSCMS0356.eemea.ericsson.se>
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> <CAD5OKxt26UfWLz8duPvinhOpHUqGy8M7FDx7v5jFkZ68Gcsj7g@mail.gmail.com>
In-Reply-To: <CAD5OKxt26UfWLz8duPvinhOpHUqGy8M7FDx7v5jFkZ68Gcsj7g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
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: Fri, 23 Sep 2011 05:06:57 -0000

 
Hi,	

>> That's not the whole problem though.  Suppose it only forked to two agents: Robert and Bob.  Robert sent a 18x with SDP first and then Bob.  So the rtcweb browser starts off using 
>>>Robert's, does ICE with Robert, etc., and then get's Bob's and starts using Bob's because it's fresher.  Now Robert accepts the connection and/or Bob rejects it; how does the rtcweb 
>>browser revert to using Robert?
>	
>The rtc browser will update the connection with the answer it got in SIP 200 OK when Robert accepts the connection. There is nothing that prevents RTC from doing update to the final accepted 
>party. This is not ideal but works most of the time. 

The 200 OK may not contain the answer, so the JS app would need to store it somewhere. But, the browser doesn't need to do it (unless the application is built into the browser, of course).

Regards,

Christer

v2.23.0 | Report a Bug | By Email