Subject: [MMUSIC] comments on draft-ietf-mmusic-sdp-bundle-negotiation-01

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 4 Nov 2012 06:23:09 +0000

I have a few of comments on this draft, mostly in regard to the description of the offer/answer procedures.

1) Section 6.2 end as follows:

   If an SDP Offer, offering a "BUNDLE" group, and the SDP Offerer has
   reasons to believe that the rejection is due to the usage of a single
   port number value for multiple "m=" lines, the SDP Offerer SHOULD
   send a new SDP Offer, without a "BUNDLE" group, where a separate port
   number value is provide for each "m=" line of the SDP offer.

I think this was meant to be as follows:

   If an SDP Offer, offering a "BUNDLE" group, is rejected, and the SDP Offerer has
   reasons to believe that the rejection is due to the usage of a single
   port number value for multiple "m=" lines, the SDP Offerer SHOULD
   send a new SDP Offer, without a "BUNDLE" group, where a separate port
   number value is provide for each "m=" line of the SDP offer.

Additionally, on what basis would the offerer have "reasons to believe the rejection is due to the usage of a single port number value"? Perhaps if it is the initial INVITE, this assumption is made, whereas if this is a re-INVITE following a previously successful negotiation, it is assumed to be some other case? This seems strange to me. I think it is better to remove the "reasons to believe" qualifier.

2) Section 6.4.2, reads:

   The total proposed bandwidth is the sum of the proposed bandwidth for
   each "m=" line associated with a negotiated BUNDLE group.

I'm afraid this is an overly simplistic approach. For example, a typical video call with content sharing includes one audio m-line and 2 video m-lines. The bandwidth is declared at the session level as well as at the media level, but the sum of the media levels is typically greater than that of the session level. When content sharing occurs, it steals some bandwidth from the main video. In the case of BUNDLED m-lines, the proposed bandwidth should therefore be the lesser of the sum of the BUNDLE m-lines and the session bandwidth.

3) Section 7.2 reads,

   o  - A given SSRC SHOULD NOT transmit RTP packets using payload types
      that originates from different "m=" lines.

   NOTE: The last bullet above is to avoid sending multiple media types
   from the same SSRC.  If transmission of multiple media types are done
   with time overlap RTP and RTCP fails to function.  Even if done in
   proper sequence this causes RTP Timestamp rate switching issues [ref
   to draft-ietf-avtext-multiple-clock-rates].

Why not replace the text in the bullet point with the text from the note, i.e.

   o  - A given SSRC SHOULD NOT be used for sending multiple media types .
 
   NOTE: If transmission of multiple media types is done
   with time overlap, RTP and RTCP fail to function.  Even if done in
   proper sequence this causes RTP Timestamp rate switching issues [ref
   to draft-ietf-avtext-multiple-clock-rates].

Cheers,
Charles

---

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

> I'm afraid this is an overly simplistic approach. For example, a typical video call with content sharing includes one audio m-line and 2 video m-lines. The bandwidth is declared at the session leve…
I'm not sure this really matters; what we're trying to compute is the b= 
parameter for the "implied RTP session" in the BUNDLE group. What 
matters is that it's computed consistently, which argues for the 
simplest possible computation.

Last time I looked b=CT was scoped to a whole conference ("supplied for 
the session"), while b=AS was scoped to a single RTP session. But I may 
be misinterpreting RFC 4566 section 5.8.

But yes, that's one of the advantages of the MMT approach - the sender 
gets to specify instead of the receiver having to compute.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 5 Nov 2012 20:04:24 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Monday, November 05, 2012 10:45 AM
> To: [email-masked]
> Subject: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-
> ietf-mmusic-sdp-bundle-negotiation-01)
> 
> > I'm afraid this is an overly simplistic approach. For example, a typical video
> call with content sharing includes one audio m-line and 2 video m-lines. The
> bandwidth is declared at the session level as well as at the media level, but
> the sum of the media levels is typically greater than that of the session
> level. When content sharing occurs, it steals some bandwidth from the main
> video. In the case of BUNDLED m-lines, the proposed bandwidth should
> therefore be the lesser of the sum of the BUNDLE m-lines and the session
> bandwidth.
> >

I recommend using b=TIAS, as defined in RFC 3890. This parameter may be used at either the session or the media level, and it scope accordingly. 
What needs to be avoided is summing up the b=TIAS/AS values from the bundled media lines and using that as that bandwidth for the bundle even if it exceeds the b=TIAS/AS/CT value from the session level.

> gets to specify instead of the receiver having to compute.

The MMT approach has different challenges when it comes to bandwidth. That is being tracked in another thread (http://www.ietf.org/mail-archive/web/mmusic/current/msg09817.html).

Cheers,
Charles

> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

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

> What needs to be avoided is summing up the b=TIAS/AS values from the bundled media lines and using that as that bandwidth for the bundle even if it exceeds the b=TIAS/AS/CT value from the session l…
If one of the bundling approaches is chosen, would you recommend setting 
the RTP session (=media level) bandwidth as min(SDP session b= line, 
sum(media b= line))?

---

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

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Monday, November 05, 2012 4:19 PM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] BUNDLE: Session bandwidth (Re: comments on draft-
> > I recommend using b=TIAS, as defined in RFC 3890. This parameter may be
> used at either the session or the media level, and it scope accordingly.
> > What needs to be avoided is summing up the b=TIAS/AS values from the
> bundled media lines and using that as that bandwidth for the bundle even if
> it exceeds the b=TIAS/AS/CT value from the session level.

Yes.

Cheers,
Charles

> > The MMT approach has different challenges when it comes to bandwidth.
> That is being tracked in another thread (http://www.ietf.org/mail-
> archive/web/mmusic/current/msg09817.html).
> >
> > Cheers,
> > Charles
> >
> >>