Subject: [MMUSIC] Simulcast worries: What bitrate? (from the WEBRTC list)

From: Harald Alvestrand <[email-masked]>
Date: Wed, 21 Oct 2015 15:42:16 +0200

Hi,

I had some worries about simulcast in the thread called "Towards
Simulcast" - Adam Roach asked me to post them here so that they can be
discussed in the right forum.

I became a little less worried after reading version -01 of the RID
draft, but I'm still worried. Uncomfortably many loose ends.

I'll raise a simple one in this message, and another message on my more
complex worry.

In -00, bitrate was undefined. In -01, bitrate (max-br) is defined as:

   o  max-br, for bit rate in bits per second.  The restriction applies
      to the media payload only, and does not include overhead
      introduced by other layers (e.g., RTP, UDP, IP, or Ethernet).  The
      exact means of keeping within this limit are left up to the
      implementation, and instantaneous excursions outside the limit are
      permissible.  For any given one-second sliding window, however,
      the total number of bits in the payload portion of RTP SHOULD NOT
      exceed the value specified in "max-br."

Question: Is this definition compatible with any of our other bitrate
definitions?
(I like it - it's more actionable than other bitrate definitions that
don't specify the measurement interval for conformance)

I'd be happier if we could say "this is the same bitrate as b=TEAS" or
something like that - if an implementation has to stick to multiple
definitions of bitrate for the same media flow, which will happen with
a=rid .. max-br and b= in the same message, it would be nice to be able
to use the same counters.

Harald

---

From: Adam Roach <[email-masked]>
Date: Thu, 22 Oct 2015 09:56:38 -0500

> to use the same counters.

I'm good either way. We can keep this as-is, or add a reference to 
RFC3890. Anyone want to speak for or against moving over to the RFC3890 
definition of bandwidth?

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Oct 2015 15:37:00 +0200

Hi,

I am of the opinion (having authored RFC 3890) that we should use a more 
well defined bit-rate definition than what is in TIAS.
In fact the current definition is well matching that of TIAS, with the 
additional constraints of a measuring interval. I think this is the 
minimal improvement we should do.

I can argue for an even more specific bandwidth definitions. My personal 
position is that the stream specific ones (SMT and SLT) in our SDP 
bandwidth proposal (now expired) actually makes sense to be used with RID:
https://www.ietf.org/archive/id/draft-westerlund-mmusic-sdp-bw-attribute-02.txt

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------