Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-negotiation-00

Hi Flemming,

You may very well be right, and I think Christer agrees with your assessment as well. I do not necessarily disagree, but I am not sure that I agree either.
The bandwidth attribute is one example for which I think BUNDLE works better than MMT. However, bandwidth may be the exception and it may be that the majority of SDP attributes are more straightforward with MMT.
An example or two would probably help convince me, or maybe a beer :)

Cheers,
Charles

> -----Original Message-----
> From: Flemming Andreasen (fandreas)
> Sent: Monday, November 05, 2012 2:00 PM
> To: Charles Eckel (eckelcu)
> Cc: Christer Holmberg; mmusic@ietf.org
> Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-
> negotiation-00
> 
> Taking a step back, the big issue I have with the various "bundle"-like
> proposals is how we deal with parameters/attributes that have to be
> reconciled across multiple media descriptions. I have yet to see
> solutions for how to deal with that in a generic manner.
> 
> What I like about the "mmt"-style proposal is that we avoid that issue
> by treating the multiplexed media stream as a single media description
> and hence we explicitly provide the parameters/attributes we want to use
> for that multiplexed media description. As you note, we lose some
> expressiveness in the process of doing that. Use of source-specific
> media attributes (RFC 5576) brings some of that back, but not
> everything. We have other parameters and, as you note, a potential need
> to specify things at the "stream"-level (which could consist of more
> than one SSRC), however you could probably come up with a solution
> similar to RFC 5576 for those (level of indirection for the actual
> parameter/attribute). It's a more verbose solution than the
> "bundle"-like approaches, but it also provides a clearer and cleaner
> solution IMO (of course the middlebox guys will probably tell us shortly
> that this will never make it through their boxes)
> 
> Thanks
> 
> -- Flemming (as Individual)
> 
> 
> On 11/4/12 10:29 PM, Charles Eckel (eckelcu) wrote:
> >> -----Original Message-----
> >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> >> Sent: Sunday, November 04, 2012 8:00 PM
> >> To: Charles Eckel (eckelcu); mmusic@ietf.org
> >> Subject: RE: comments on draft-holmberg-mmusic-sdp-mmt-negotiation-
> 00
> >>
> >>
> >> Hi Charles,
> >>
> >>> I read the draft, and I have some concerns it with. It seems that in
> general
> >> one needs to duplicate much of the information from each individual
> media
> >> description in the anymedia media description. I think I could live with
> that;
> >>> however, the bigger problem is in regard to figuring out what needs to
> be
> >> specified in the anymedia media description. In the good cases, you
> merely
> >> duplicate the SDP attributes from each individual media description in
> the
> >> anymedia
> >>> media description. In the bad case, you need to define new SDP
> attributes.
> >>> Here are some related comments in regard to specific section of the
> >> existing draft.
> >>> 1) Section 5.2.2.2 seems to imply that accepting/rejecting an anymedia
> >> media description is always an all of nothing matter. If it contains 2 audio
> >> lines and 2 video lines, I need to accept all of them or none of them. It
> that
> >> is the
> >>> intent, it seems pretty limiting to me.
> >> That is not the intent.
> >>
> >> However, it is related to a more general (not specific to muliplexing)
> >> question that needs to be clarified - how individual sources/streams
> within
> >> an SDP m- line are rejected.
> > Okay, that is true; but the need for such a mechanism is more common
> needed if all media is in a single description rather than in multiple media
> descriptions that are then bundled. The anymedia syntax really forces the
> issue for even relatively simple use cases.
> >
> >>> 2) Section 6.3 says directionality of anymedia applies to all media lines.
> >> This seems limiting as well. I may want to temporarily stop a video
> stream
> >> (i.e. make inactive or recvonly), but continue to have the audio be
> sendrecv.
> >>
> >> You can use the ssrc attribute to set the directionality for individual
> >> sources/streams.
> >>
> >>> 3) Section 6.4, I think you need to be able to specify the bandwidth for
> >> each media stream in the anymedia group, so new syntax will be needed
> to
> >> deal with the bandwidth attribute.
> >>
> >> Yes.
> >>
> >> But, again, it is a generic thing for when you have multiple
> sources/streams
> >> per m- line.
> > In the case of multiple m-lines, you can assign a bandwidth per m-line and
> have the session bandwidth cap the total bandwidth for the session. With
> anymedia and a single m-line, you lose the granularity you previously had at
> the m-line level and are left with specifying the bandwidth for the
> anymedia line as a whole.
> > For example, today I might offer the following for a video call with content
> sharing:
> >
> > v=0
> > o=anonymous 1240218157 1240218157 IN IP4 10.193.128.35
> > s=-
> > i=myUserAgent
> > c=IN IP4 10.193.128.35
> > b=TIAS:512000
> > t=0 0
> > m=audio 6000 RTP/AVP 0 18 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:18 G729/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-15
> > m=video 6002 RTP/AVP 96
> > b=TIAS:512000
> > a=rtpmap:96 H264/90000
> > a=fmtp:96 profile-level-id=428014
> > a=content:main
> > m=video 6002 RTP/AVP 96
> > b=TIAS:256000
> > a=rtpmap:96 H264/90000
> > a=fmtp:96 profile-level-id=428014
> > a=content:slides
> >
> > In this case, depending on the answer, the audio will take between 8k and
> 64k, the main video can take the remainder of the 512k until content sharing
> starts, and once content sharing starts, the main video could drop down a bit
> to free some bandwidth for the content .
> > With mmt, all I can specify is 512k for the total. I cannot subdivide it per
> media stream as above. To do so, I would need to specify some new SDP
> and/or encode the SSRC values I plan to use in SDP.
> >
> > Cheers,
> > Charles
> >
> >
> >> Regards,
> >>
> >> Christer
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> > .
> >