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

"Olle E. Johansson" <oej@edvina.net> Wed, 21 September 2011 06:16 UTC

Return-Path: <oej@edvina.net>
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 8DED621F8B6D for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 23:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_52=0.6]
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 ShzBXeuNQGpL for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 23:16:16 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8977021F8B59 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 23:16:16 -0700 (PDT)
Received: from [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d] (unknown [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d]) by smtp7.webway.se (Postfix) with ESMTPA id D9769754BCE4; Wed, 21 Sep 2011 06:18:39 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com>
Date: Wed, 21 Sep 2011 08:18:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F6A723B-8386-40F6-8ABC-4935F42B7D36@edvina.net>
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>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1244.3)
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: Wed, 21 Sep 2011 06:16:17 -0000

21 sep 2011 kl. 00:36 skrev Hadriel Kaplan:

> 
> On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:
> 
>> That said, I think that doing both forking and early media is hard. Lets assume we are using a signaling gateway that is not a media gateway to translate between a SIP call on one side and whatever is happening over on the browser side. The basic issue is the browser initiating the communications needs to be able to start receiving multiple RTP streams before it even has signaling information to tell it how many it might receive.
> 
> Not really - there will be signaling, because there has to be SDP answers even just to get ICE to work before the media starts flowing in many NAT cases.  And even in practice in SIP there're usually SDP answers in 18x to open "gates", and to get upstream DTMF.  So if the concern is just that there's no signaling to tell the browser there are multiple RTP streams coming, I think that can be allayed.  
> 
> 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.
Food for thought.
> 
> 
>> To simplify this problem, Cary and my draft proposes not allowing forking on the SIP side of the signaling gateway but still allowing early media. If you wanted to do do forking in this case, one would need a SBC that processed media and turned the forked medial legs into one media leg. 
> 
> Obviously you can request that a request not be forked, using caller-prefs, but you can't "not allow" forking on the SIP side.  That would make it not SIP.  I know forking is hard, but that's life.  It's not appropriate for this WG to make fundamental changes/limitations to the SIP protocol, just because some of it's "hard" for a browser. 

But it will be appropriate to avoid SIP as a requirement within the RTCweb architecture because of that. I'm not saying that a new SIP dialect can't be built - but I think it's another WG's task. 

/O