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

Cullen Jennings <fluffy@cisco.com> Thu, 22 September 2011 13:14 UTC

Return-Path: <fluffy@cisco.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 25CB121F8C70 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 06:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.115
X-Spam-Level:
X-Spam-Status: No, score=-103.115 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, 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 nAP2HRKiXTPz for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 06:14:52 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E8E7121F8C56 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 06:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1368; q=dns/txt; s=iport; t=1316697444; x=1317907044; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UNfn66p8HKBbKKs1C/c5DCA9sVv7WjuaGbkDZY+Igys=; b=akOoGPYe3Hz2Iwfkm6WE50GoCzpNFDJ/ts0kM1CyJEEF0OA92UFYmm+H oTKjfMRxHwjSF3XLgUQZvkJFZ82W8nuezsjDVDxShh64eG+bCOFaW0Z// qw/Is2fwkyPD1We1YoAxhbclBtW+1+WUD/N1spuGZL5a/+F6cqBas5F4P w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAMQ0e06rRDoI/2dsb2JhbABCqAB4gVMBAQEBAxIBJzIKAxALDjhXBiwJni4BnjaGHWAEh3GLX4UfjC8
X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="3660140"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Sep 2011 13:17:24 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8MDHNuo029665; Thu, 22 Sep 2011 13:17:23 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com>
Date: Thu, 22 Sep 2011 07:17:23 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A175754-2318-4512-98C5-F8742A82067E@cisco.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>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1084)
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 13:14:54 -0000

On Sep 20, 2011, at 4:36 PM, Hadriel Kaplan wrote:

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

I'll note that Cary and my draft has been putting serious limitation on SIP since the beginning and we have yet to receive a comment on that. You do realize the outcome of this decision would be that you needed an SBC between the SIP to WEB Gateway and any SIP network that forked so that SBC could isolate the other side from the forks. As full disclosure, really, I don't own any ACME stock :-) 

Clearly one could support forking in the browsers and equally obviously, that complicates things fairly significantly. The question will be if the complexity is worth the end user gain in functionality.