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

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