Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt

Christer Holmberg <> Thu, 21 February 2013 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74D7C21F8CB2; Thu, 21 Feb 2013 04:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.144
X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4ZYrKj2z-hQf; Thu, 21 Feb 2013 04:25:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C408E21F8C9E; Thu, 21 Feb 2013 04:25:58 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-cb-5126125564aa
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 07.29.32353.55216215; Thu, 21 Feb 2013 13:25:57 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 13:25:57 +0100
From: Christer Holmberg <>
To: "Ejzak, Richard P (Richard)" <>, "" <>, "" <>
Thread-Topic: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
Thread-Index: AQHOD35vMbWFu2fEI0efKvWAcqBYapiDLdGQ
Date: Thu, 21 Feb 2013 12:25:56 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvjW6okFqgQctqU4upyx+zWPQ2hFus /dfO7sDs0fpsL6vHkiU/mQKYorhsUlJzMstSi/TtErgyGg9+YinYYVrxb0o7cwPjfq0uRk4O CQETiVe/W9khbDGJC/fWs4HYQgKHGCXOrTWFsBczSjzpEeti5OBgE7CQ6P6n3cXIxSEi0M8o 0f1tMSNIjbBAmsTMSU1gvSIC6RKvLj6Aso0krkx9wQpiswioSqxZ9B2snlfAW2LXurlMIIOE BN4zSqz6NJ8JJMEpECuxcNM1sIMYgQ76fmoNWJxZQFzi1hOIGgkBAYkle84zQ9iiEi8f/2OF sBUlrk5fDlWvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzs uYmZOenl5psYgTFxcMtvgx2Mm+6LHWKU5mBREucNd70QICSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoHRIGzr8XWdfdYuhVnbmqZ5CIYt5b3VPe9sqO7fyJqzQupnwiw/rk5Rn15wzzRY1Nro zO857k7mLUUyZfcXse2+8nBfxSvpz93OV3Suv3Gc4i60P431oPsp5R8T3FcGFa+7o5eQkO81 SST79Zajn2efd176QT9tm/K2eW5vb2oo3zv+zv72evEnSizFGYmGWsxFxYkAljYaC1cCAAA=
Subject: Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt
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: Thu, 21 Feb 2013 12:26:00 -0000


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



> -----Original Message-----
> From: [] On
> Behalf Of Ejzak, Richard P (Richard)
> Sent: 19. helmikuuta 2013 0:09
> To:;
> 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: []
> 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:   
> mmusic-bundle-alternatives-00.txt
> Status:
> bundle-alternatives
> Htmlized:
> 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