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

Roman Shpount <roman@telurix.com> Thu, 22 September 2011 23:22 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 DB27B21F8C11 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 16:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.225, 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 KOtTYM2J-WiI for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 16:22:04 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB3A621F8BF3 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 16:22:03 -0700 (PDT)
Received: by ywa6 with SMTP id 6so2865276ywa.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 16:24:36 -0700 (PDT)
Received: by 10.100.82.6 with SMTP id f6mr2622079anb.52.1316733876211; Thu, 22 Sep 2011 16:24:36 -0700 (PDT)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by mx.google.com with ESMTPS id z6sm34983991anf.22.2011.09.22.16.24.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 16:24:35 -0700 (PDT)
Received: by gwj16 with SMTP id 16so2892368gwj.15 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 16:24:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.4.170 with SMTP id l10mr6513267pbl.3.1316733874578; Thu, 22 Sep 2011 16:24:34 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 16:24:34 -0700 (PDT)
In-Reply-To: <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com>
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>
Date: Thu, 22 Sep 2011 19:24:34 -0400
Message-ID: <CAD5OKxt26UfWLz8duPvinhOpHUqGy8M7FDx7v5jFkZ68Gcsj7g@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary=bcaec5215f35dba64304ad8ffebe
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: Thu, 22 Sep 2011 23:22:05 -0000

> 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.

Alternative is when the second answer is received, update the stream with
hold and start playing ring back locally. Once call is connected, update to
the final answer.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 6:55 PM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote;wrote:

>
> On Sep 22, 2011, at 3:41 PM, Christer Holmberg wrote:
>
> >> The really hard part is knowing which stream to use/render/send-to,
> imho.  And putting that decision in the gateway isn't good - the best
> decider of that is probably the JS in the browser.
> >
> > I am not sure whether the JS app would be able to make better decisions
> than the gateway - and I've never seen a SIP client which would allow the
> user to choose which early media to listen to.
>
>
> But these aren't phone-call SIP clients - they're browsers.  They can show
> the multiple video streams in separate windows, for example.  They can show
> multiple chat sessions per fork too.  Or they may just pick the most recent
> one and only display it.  That's the nice thing about JS: the JS developer
> decides what the user experience model is like, based on what type of
> application/service they're providing; as opposed to the IETF/W3C choosing
> for them.
>
>
> > In my opinion the best thing would be if we could come up with some
> common BCP, e.g. saying that media associated with the early dialog on which
> the latest SDP answer was received is considered "active", and will be
> presented to the user etc.
>
> 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?
>
> If the answer is "well the rtcweb browser had to keep state information
> about Robert's SDP/media info as well as about Bob's", then we're back to
> the tricky part about PeerConnection having multiple media peers when it
> only expected one; if we can solve that, then we've solved the basic issue
> at hand. (I think... or I need more coffee)
>
> -hadriel
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>