Re: [rtcweb] Minimal SDP negotiation mechanism

"Olle E. Johansson" <oej@edvina.net> Tue, 20 September 2011 13:38 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 6062621F8C71 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 06:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level:
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 4RykThuD+zZR for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 06:38:28 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B588421F8C5D for <rtcweb@ietf.org>; Tue, 20 Sep 2011 06:38:28 -0700 (PDT)
Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 76849754BCE4; Tue, 20 Sep 2011 13:40:10 +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: <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se>
Date: Tue, 20 Sep 2011 15:40:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A61D589-1C23-4364-AA4A-60338D8C5859@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> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1244.3)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] 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 13:38:29 -0000

20 sep 2011 kl. 15:15 skrev Christer Holmberg:

> 
> Hi, 
> 
>>> 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.
> 
> It's not about knowing the difference between "early" and "late" media - it's about whether the API and browser need to support multiple SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will always, at any given time, only provide ONE SDP answer to the API and browser.

I just wanted to get rid of the early/late media discussion. As you state, the forking issue with getting multiple responses is a separate issue.

Do we have any use cases using forking? Is forking a desired feature or something that SIP brought in?

To give an example to those of you with no SIP history:

In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from different devices. This means that you actually have multiple calls and need to hang up all of those that you do not want, or just mix them somehow and live with it. 

With early media, it gets even more confusing, because you will get an SDP answer before the call is in up state (in 180/183 response) then another SDP answer from another device at 200 OK. In this case you have an early dialog with early media with the device sending the first answer, a dialog that terminates at 200 OK. 

Supporting this behaviour adds complexity. And not all SIP devices support these situations properly, as we've proven at SIPit testing. 

Which leads to an unshameful plug: SIPit in Monaco is now open for registration - for all SIP developers to attend :-)

/O