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

[Christer Holmberg <[e-mail]>]

Hi,

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

Sorry, I mixed up terminology.

But, still, if you want to disable/reject the m- line which contains the bundle ADDRESS, you will have to move the address to another m- line.

And, still, you expect intermediaries to retrieve media types, protocols, payload types etc from the m- lines, which addresses are unspecified - but at the same time you say that no resources will be reserved for the m- lines with unspecified addresses...

Regards,

Christer




> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Thursday, February 21, 2013 6:26 AM
> To: Ejzak, Richard P (Richard); [e-mail]; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Ejzak, Richard P (Richard)
> > Sent: 19. helmikuuta 2013 0:09
> > To: [e-mail]; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic