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

Hi Christer,

Thanks for your comments!  See below.

Richard

> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> 
> 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.

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

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.

This isn't particularly elegant, but it applies the definition consistently and I think it works in all cases.

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