Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Thu, 21 February 2013 14:06 UTC
Return-Path: <richard.ejzak@alcatel-lucent.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 52DAD21F8AB6; Thu, 21 Feb 2013 06:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.055
X-Spam-Level:
X-Spam-Status: No, score=-9.055 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Z=0.259]
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 9if3yheRM5mO; Thu, 21 Feb 2013 06:06:26 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3017321F8ABC; Thu, 21 Feb 2013 06:06:26 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1LE4fvW003127 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Feb 2013 15:06:23 +0100
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 21 Feb 2013 15:05:15 +0100
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.105]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 21 Feb 2013 09:05:13 -0500
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
Thread-Index: AQHOD2W+toYseWtIxEKEwtE+xBCEiZiCxbWggAHMggD//8Z4EA==
Date: Thu, 21 Feb 2013 14:05:12 +0000
Message-ID: <03FBA798AC24E3498B74F47FD082A92F36EA6C8F@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <03FBA798AC24E3498B74F47FD082A92F36EA6762@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FC32F@ESESSMB209.ericsson.se>, <03FBA798AC24E3498B74F47FD082A92F36EA6AA6@US70UWXCHMBA04.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0FEDDE@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
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, 21 Feb 2013 14:06:27 -0000
Hi Christer, My proposal never has a zero port on a valid m line, in either offer or answer. I only use unspecified address (with valid port number) for subsequent m lines in answers. I'm not sure how you got this from the description. Let's discuss this on the call today. I hope you are available. Richard > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, February 21, 2013 6:26 AM > To: Ejzak, Richard P (Richard); mmusic@ietf.org; rtcweb@ietf.org > Subject: RE: [MMUSIC] FW: New Version Notification for draft-ejzak- > mmusic-bundle-alternatives-00.txt > > > Hi, > > >> First, as you will now have a single non-zero m- line, you still > >> assume that entities (including intermediaries) will take > information > >> (media types, payload type mappings etc etc etc - even protocol, if > >> we decide to also allow the data channel in the bundle) from all m- > >> lines. Or, do you intend to put all that information into a single > m- > >> line? If so, in my opinion MMT is a much better approach. > > > > The intent is to reuse all of the existing information in the > subsequent m lines except the connection, candidate and non-zero port > information. That excludes the crypto info as well. > > And how do you expect intermediaries to understand that, when the ports > are zero? > > And, even if we don't consider intermediaries, I think it's BAD DESIGN > to assume that we use a stream, and associated data, from m- lines with > port zero. Port zero means that the stream associated with the m- line > is DISABLED. > > >> Second, what if a user wants the disable, or reject, a specific > >> stream, using port zero? How is it done in case the stream is > already > >> represented by a zero m- line? How is it done in case the stream is > >> represented by the non-zero m- line which contains the port number > >> value used for the whole bundle? > > > > A zero port value would retain its original semantic of > >disabling/rejecting an individual m line. In my proposal all > subsequent m lines in the SDP answer that are accepted would have valid > and unique non-zero port values that are different from the port value > in the first m line of the bundle group. > > >I admit that I did not think through how to disable the first m line > in the group, but let me propose the following: > > > >Let's specify that we get the connection and port information for the > >bundle from the first valid (non-zero port) m line in the bundle group > >of the SDP answer (not offer). If the answerer wants to disable the > >first valid m line(s) of the bundle group in the first SDP offer, both > >ends use the connection and port information from the next valid m > line > >in the SDP answer (and its corresponding m line in the SDP offer). > The offerer had valid information for each m line in the SDP offer so > it doesn't matter which set we use after the first offer/answer > transaction. But we don't want to change the 5-tuple or crypto info > for the bundle with any subsequent offer/answer. > > > >If the offerer wants to disable the first valid m line(s) of a bundle > >group in a subsequent offer, it places the connection and port > >information for the bundle group in the next valid m line of the > bundle > >group in the SDP offer (it would actually move this information from > the previous first valid m line to the new one to avoid restarting > crypto or changing ports). > >In response to the new offer disabling the initial valid m line(s), > the > >answerer similarly places the connection and port information for the > bundle group in the corresponding m line of the SDP answer. > > I think that's very hacky, moving information from one m- line to > another... > > >The answerer is not allowed to disable the first valid m line of a > >bundle group in the SDP answer it sends in response to a subsequent > >offer. If the answerer needs to disable the first valid m line(s), it > >must instead accept the m line(s) in response to the latest pending > offer (if there is one) and immediately send a new SDP offer disabling > the line by following the SDP offerer rule above. > > I don't think we should have a solution where the answerer is not > allowed to reject an m- line. > > >The only other rule to add is that the SDP offerer will never re- > enable > >(set port to a non-zero value) a disabled m line before the first > valid > >m line in a bundle group but will instead create a new m line and add > >it to the group. This makes it unlikely that the answerer will reject > the first valid m line of the bundle group in a subsequent SDP offer > since it had previously accepted it and did not initiate the new > transaction due to any changes in the configuration of local resources. > > What if you have a session where a stream is enabled/disabled many > times. If, every time you re-enable, is going to add a new m- line, you > may end up with a very large SDP... > > >This isn't particularly elegant, but it applies the definition > consistently and I think it works in all cases. > > I think it's very hacky, and I don't see how you think that > intermediaries (which your draft focues on) would be able to handle > this... > > Regards, > > Christer > > > > > > > > > > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > > Behalf Of Ejzak, Richard P (Richard) > > Sent: 19. helmikuuta 2013 0:09 > > To: mmusic@ietf.org; rtcweb@ietf.org > > Subject: [MMUSIC] FW: New Version Notification for draft-ejzak- > mmusic- > > bundle-alternatives-00.txt > > > > Please note that I have also submitted a draft on how to fix BUNDLE. > > This doc is based on the modified BUNDLE proposal with different port > > information for each m line and compares several different additional > > modifications to BUNDLE. The doc ends up recommending the use of the > > unspecified address for subsequent m lines in a bundle group in the > > SDP answer (not offer). Please see the doc for details. > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, February 18, 2013 3:57 PM > > To: Ejzak, Richard P (Richard) > > Subject: New Version Notification for draft-ejzak-mmusic-bundle- > > alternatives-00.txt > > > > > > A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt > > has been successfully submitted by Richard Ejzak and posted to the > > IETF repository. > > > > Filename: draft-ejzak-mmusic-bundle-alternatives > > Revision: 00 > > Title: Alternatives to BUNDLE > > Creation date: 2013-02-18 > > Group: Individual Submission > > Number of pages: 7 > > URL: http://www.ietf.org/internet-drafts/draft-ejzak- > > mmusic-bundle-alternatives-00.txt > > Status: http://datatracker.ietf.org/doc/draft-ejzak-mmusic- > > bundle-alternatives > > Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic- > bundle- > > alternatives-00 > > > > > > Abstract: > > This paper discusses some potential modifications to the BUNDLE > > proposal for multiplexing of multiple media types within a single > > 5-tuple to address limitations of the current proposal and > > alternatives already considered by MMUSIC. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic
- [rtcweb] FW: New Version Notification for draft-e… Ejzak, Richard P (Richard)
- Re: [rtcweb] [MMUSIC] FW: New Version Notificatio… Christer Holmberg
- Re: [rtcweb] [MMUSIC] FW: New Version Notificatio… Ejzak, Richard P (Richard)
- Re: [rtcweb] [MMUSIC] FW: New Version Notificatio… Christer Holmberg
- Re: [rtcweb] [MMUSIC] FW: New Version Notificatio… Ejzak, Richard P (Richard)
- Re: [rtcweb] [MMUSIC] FW: New Version Notificatio… Christer Holmberg
- Re: [rtcweb] [MMUSIC] FW: New Version Notificatio… Ejzak, Richard P (Richard)