Subject: [rtcweb] New version of -transport

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Feb 2015 15:31:25 +0100

I've shipped a new version of -transport, since I'll be away for most of
the time between now and the I-D deadline.

There's only one significant change, which resulted from reading the
JSEP draft and discussing the matter with the JSEP editors about the
meaning of the "balanced" mode.

OLD:

    it may therefore make sense for a sending application to
   choose any of the configurations:

   o  Each media stream carried on its own 5-tuple

   o  Media streams grouped by media type into 5-tuples (such as
      carrying all audio on one 5-tuple)

   o  All media sent over a single 5-tuple, with or without
      differentiation into 6-tuples based on DSCP code points

   In each of the configurations mentioned, data channels may be carried
   in its own 5-tuple, or multiplexed together with one of the media
   flows.

   More complex configurations, such as sending a high priority video
   stream on one 5-tuple and sending all other video streams multiplexed
   together over another 5-tuple, can also be envisioned.  More
   information on mapping media flows to 5-tuples can be found in
   [I-D.ietf-rtcweb-rtp-usage].

   A sending WebRTC endpoint MUST be able to support the following
   configurations:

   o  multiplex all media and data on a single 5-tuple (fully bundled)

   o  send each media stream on its own 5-tuple and data on its own
      5-tuple (fully unbundled)

   o  bundle each media type (audio, video or data) into its own 5-tuple
      (bundling by media type)

   It MAY choose to support other configurations.

NEW:

   it may therefore make sense for a sending application to
   choose any of the configurations:

   o  Each media stream carried on its own 5-tuple

   o  Media streams grouped by media type into 5-tuples (such as
      carrying all audio on one 5-tuple)

   o  All media sent over a single 5-tuple, with or without
      differentiation into 6-tuples based on DSCP code points

   In each of the configurations mentioned, data channels may be carried
   in its own 5-tuple, or multiplexed together with one of the media
   flows.

   More complex configurations, such as sending a high priority video
   stream on one 5-tuple and sending all other video streams multiplexed
   together over another 5-tuple, can also be envisioned.  More
   information on mapping media flows to 5-tuples can be found in
   [I-D.ietf-rtcweb-rtp-usage].

   A sending implementation MUST be able to support the following
   configurations:

   o  multiplex all media and data on a single 5-tuple (fully bundled)

   o  send each media stream on its own 5-tuple and data on its own
      5-tuple (fully unbundled)

   It MAY choose to support other configurations, such as bundling each
   media type (audio, video or data) into its own 5-tuple (bundling by
   media type).

Note that the draft is now on github:

https://github.com/rtcweb-wg/rtcweb-transport

If you wish to make sure I don't forget issues, filing an issue there is
a Good Ideal; if you feel that you can improve the text, don't hesitate
to post pull requests!

Harald

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Feb 2015 11:26:42 -0500

Harald,

In the below (both old and new) you identify an alternative that bundles 
all audio on one 5-tuple and all video on another 5-tuple.

AFAIK there is no way to tell JSEP to do that. (I once thought there 
was, but eventually learned it wasn't.) If not, does it make sense to 
list it as an alternative here? Or is that the reason you make that 
configuration optional for senders?

	Thanks,
	Paul

On 2/27/15 9:31 AM, Harald Alvestrand wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Feb 2015 22:33:02 +0100

> configuration optional for senders?

That is the reason I make that configuration optional for senders.

There's no sense in mandating it when there is consensus to not have a
control surface to choose it, but there's no sense in forbidding it
either - there will always be endpoints with extensions, and if this
particular extension makes sense, someone will eventually make it.