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

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 5 Nov 2012 00:42:53 +0000

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.

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.

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.

Cheers,
Charles

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Nov 2012 01:00:12 +0000

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.

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.

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

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.

Regards,

Christer

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 5 Nov 2012 03:29:14 +0000

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Sunday, November 04, 2012 8:00 PM
> To: Charles Eckel (eckelcu); [email-masked]
> 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
> >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.
> 
> >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.
> 

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 Nov 2012 13:59:37 -0500

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:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Nov 2012 22:23:55 +0100

> 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.
I'm curious - if I send this in an offer, is there any part of the SDP 
description that says that the respondent, when sending, should cut down 
on his video bandwidth if video + audio would otherwise be > 512K?

I don't see any "priority" flags in there.

(another thing that confuses me a bit is how b= represents bandwidth in 
the 2 directions for a point-to-point session - if A sends an offer with 
session b=TIAS:512K, and B sends A an answer with session b=TIAS:512K, 
and they both start sending video at 300K, are they below the cap or 
above the cap?

Again, it's probably clear to those who've been around here for a while)

                 Harald

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 5 Nov 2012 23:58:29 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Monday, November 05, 2012 4:24 PM
> To: [email-masked]
> Subject: [MMUSIC] MMT bandwidth limits (Re: comments on draft-
> holmberg-mmusic-sdp-mmt-negotiation-00)
> 
> > 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.
> > 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.

There is no explicit priority. It is up to the application to decide. RFC 3890 does say:

   At the SDP session level, the TIAS value is the maximal amount of
   bandwidth needed when all declared media streams are used.  This MAY
   be less than the sum of all the individual media streams values.
   This is due to the possibility that not all streams have their
   maximum at the same point in time. 

> and they both start sending video at 300K, are they below the cap or

That is fine. This is just a statement of the maximum bandwidth the implementation is willing to receive. The values can be asymmetric, and this is just a maximum. It does not indicate anything about how much the implementation will send.

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 6 Nov 2012 00:06:23 +0000

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

> From: Flemming Andreasen (fandreas)
> Sent: Monday, November 05, 2012 2:00 PM
> To: Charles Eckel (eckelcu)
> Cc: Christer Holmberg; [email-masked]
> Subject: Re: [MMUSIC] comments on draft-holmberg-mmusic-sdp-mmt-
> negotiation-00
> 
> > 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.
> >
> >> But, again, it is a generic thing for when you have multiple
> sources/streams
> >> per m- line.