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

Cullen Jennings <fluffy@cisco.com> Tue, 20 September 2011 20:04 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 293FA1F0C41 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 13:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.138
X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id r2nKRY7uf0-m for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 13:04:51 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id AE4971F0C40 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 13:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2109; q=dns/txt; s=iport; t=1316549238; x=1317758838; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ayc/wlm88z9fOToSB1Av2xq4hYPltolYbX4p5++ZBQ0=; b=QY/3Drcrg/ACsPQoQ9oKpIASNUW286IzDRWxS41EQFB6g/0cXugcPTpS US30kUKNFg09Rv1/JtSQ/anIyMwxNwQbfpOwBb15UdNCnrq9XTXsTzAMR IccAqEhue6qZ9zmW6L5EID0LyGXGqPkPQ8tDMlgz5vlRXPU9kf0H5j2kZ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANzxeE6rRDoG/2dsb2JhbABCp2J4gVMBAQEBAgESASc/BQtRVwY1h1WVBgGeK4YdYASHcItbhR6MMA
X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3267264"
Received: from mtv-core-1.cisco.com ([]) by mtv-iport-4.cisco.com with ESMTP; 20 Sep 2011 20:07:17 +0000
Received: from [] (sjc-fluffy-8914.cisco.com []) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8KK7Fi6021431; Tue, 20 Sep 2011 20:07:15 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: <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net>
Date: Tue, 20 Sep 2011 14:07:14 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <27019ED4-BE01-474C-886E-D237DBD6CD2C@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>
To: "Olle E. Johansson" <oej@edvina.net>
X-Mailer: Apple Mail (2.1084)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [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: Tue, 20 Sep 2011 20:04:52 -0000

On Sep 20, 2011, at 7:07 AM, Olle E. Johansson wrote:

> 20 sep 2011 kl. 15:00 skrev Harald Alvestrand:
>> Once we start requiring that the PeerConnection know the difference between "early" media and "late" media, it seems to me we're slipping down a slippery slope.
> The difference between early and late media is purely a billing decision in PSTN. I don't think we should separate these on the rtcweb side. It's a PSTN gateway issue, not something to be bothered with in rtcweb.
> "The campaign to simplify call states"

Simplification is good - just make sure that it is possible to gateway to a SIP call to 1-800-go-fedex. A simplification that broke that would, in my personal opinion, would not be acceptable. (and I think that early media is a bit more than just a billing artifact but that's a longer story). You agree?

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

What I'm trying to say is I agree that early media + forking is hard, and the way I would like to simplify that is not allow forking. Note that none of this has much to do with if the PeerConnection object knows if media is early or late - what it needs to deal with is receiving RTP regardless os if the SIP signaling GW had sent it any signaling that indicated what had been in the SIP answer of the SIP side of a signaling GW.