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

[Flemming Andreasen <[e-mail]>]

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:[e-mail]]
>> Sent: Sunday, November 04, 2012 8:00 PM
>> To: Charles Eckel (eckelcu); [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>