Return-Path: 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 9655E21F8CCA for ; Mon, 18 Feb 2013 12:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WOmoFr1zpAV for ; Mon, 18 Feb 2013 12:26:32 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 97DE821F8C56 for ; Mon, 18 Feb 2013 12:26:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ECC0339E0F3 for ; Mon, 18 Feb 2013 21:26:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7klWScB-r88z for ; Mon, 18 Feb 2013 21:26:22 +0100 (CET) Received: from [172.30.42.70] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 982D039E0E1 for ; Mon, 18 Feb 2013 21:26:22 +0100 (CET) Message-ID: <51228E6D.3010300@alvestrand.no> Date: Mon, 18 Feb 2013 21:26:21 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090504030808030001030906" Subject: Re: [rtcweb] JSEP and draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:26:36 -0000 This is a multi-part message in MIME format. --------------090504030808030001030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/18/2013 09:01 PM, Bernard Aboba wrote: > What are implications of this "new" approach on the SDP usage in the > JSEP API, if any? > > For example: do we expect the SDP output by createOffer() to support > this "different port" alternative by default? If this ends up being the one alternative that people think is best, I think createOffer() should (of course) create that format by default. > > Also, overall is there a goal of "optimizing for the common case"? I think the first focus is to have something that works; second focus is not failing in "interesting" ways in too many cases. The browser-to-browser case should be able to send data after the first offer/answer, just as we do in the fastest proposals now. The second offer/answer to regularize port pairings shouldn't add time to the setup phase. > > > From: christer.holmberg@ericsson.com > > To: mmusic@ietf.org > > Date: Mon, 18 Feb 2013 19:50:21 +0000 > > Subject: [MMUSIC] Draft new version: > draft-ietf-mmusic-sdp-bundle-negotiation-03 > > > > > > Hi, > > > > I've submitted a new version (-03) of BUNDLE. > > > > Based on discussions with Cullen, and exchange of the concerns we > had with the different port alternatives (different-ports vs > identical-port), this version now describes a mechanism where both > alternatives more or less are combined. When the first BUNDLE offer is > sent, and it is now known whether the answerer supports BUNDLE (or, > even identical ports), different ports are used (read: the one-rtp > alterntaive). Once BUNDLE answer has been received, a new offer, with > identical port numbers, is sent. > > > > We think that having to send a second offer is not going to increase > complexity and delay, because in many use-cases subsequent offer(s) > will be sent anyway. For example, RTCWEB entities will do it because > of ICE. > > > > Cullen has also been added as co-author. > > > > Now, we do realize that there are still issues that have to be > described, and hopefully we will be able to focus on those from now > on, but our wish is that this proposal will unite the different "port > camps" :) > > > > Regards, > > > > Christer > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------090504030808030001030906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/18/2013 09:01 PM, Bernard Aboba wrote:
What are implications of this "new" approach on the SDP usage in the JSEP API, if any?

For example: do we expect the SDP output by createOffer() to support this "different port" alternative by default?

If this ends up being the one alternative that people think is best, I think createOffer() should (of course) create that format by default.


Also, overall is there a goal of "optimizing for the common case"? 

I think the first focus is to have something that works; second focus is not failing in "interesting" ways in too many cases.

The browser-to-browser case should be able to send data after the first offer/answer, just as we do in the fastest proposals now. The second offer/answer to regularize port pairings shouldn't add time to the setup phase.


> From: christer.holmberg@ericsson.com
> To: mmusic@ietf.org
> Date: Mon, 18 Feb 2013 19:50:21 +0000
> Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03
>
>
> Hi,
>
> I've submitted a new version (-03) of BUNDLE.
>
> Based on discussions with Cullen, and exchange of the concerns we had with the different port alternatives (different-ports vs identical-port), this version now describes a mechanism where both alternatives more or less are combined. When the first BUNDLE offer is sent, and it is now known whether the answerer supports BUNDLE (or, even identical ports), different ports are used (read: the one-rtp alterntaive). Once BUNDLE answer has been received, a new offer, with identical port numbers, is sent.
>
> We think that having to send a second offer is not going to increase complexity and delay, because in many use-cases subsequent offer(s) will be sent anyway. For example, RTCWEB entities will do it because of ICE.
>
> Cullen has also been added as co-author.
>
> Now, we do realize that there are still issues that have to be described, and hopefully we will be able to focus on those from now on, but our wish is that this proposal will unite the different "port camps" :)
>
> Regards,
>
> Christer
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------090504030808030001030906--