Subject: [rtcweb] Minutes from 6 Feb joint interim session

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 06 Feb 2013 14:42:25 -0800

BUNDLE, ONE-RTP, MMT:

* Note - If we proceed with MMT, we should use m=application instead of 
m=anymedia

* Decision - Are you generally okay with any of the approaches that 
reduce the number of long-lived flows to this level OR is there some 
other feature in one of the proposals you must have before this meets 
your needs?

6 for the former, 17 for the latter

Cullen's plan to dig us out of this hole:

* Proposed Superset of Requirement 2 - Should be able to interop with 
legacy without the JS doing anything special.

* Proposed Relaxation of Requirement 2 - Should be able to interop with 
legacy, but not necessarily in one O/A exchange within a single dialog 
(without relying on failure cases).

* Requirement 3 - Change video flows to media flows

* Proposed Requirement - When we have a large conference with 1000's of 
people, we don't have to send new signaling to every participant of the 
conference.

* Proposed Requirement - Must be able to configure a set of similar 
flows such that once established, the endpoints can add or remove flows 
without having to do an O/A cycle (i.e., without having to exchange SDP).

* Proposed Requirement - Have this process terminate in some finite 
period of time.

* Point of Discussion - Plan A: same port on each m-line or different 
candidate sets?

* Action - Plan B: Write the drafts to extend SDP to explicitly describe 
multiple cameras with multiple streams from each camera under a single 
m-line.

* Decision - Should we come up with a set of requirements and proceed 
with Plan A and Plan B with the timelines outlined here?

24 for, 5 against

* Note - Mary Barnes refuses to go back to work until she gets her mini 
candy bars.

DataChannel SDP

* Action - Justin to draft API for SDP-only channel open

* Decision (rtcweb hats) -
   2a) In-band only - 6
   2b) SDP & in-band - 10
   2c) SDP-only - 15
   Work on both will continue until a decision is reached.

* Action - Martin believes he can send a proposal to the list which will 
change some minds.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 7 Feb 2013 14:41:43 +0200

Hi,
On Action - Plan B: Write the drafts to extend SDP to explicitly describe
multiple cameras with multiple streams from each camera under a single
m-line.

We did it in CLUE look at
http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04  examples is
section 6.1 and 6.2. (6.2 was taken out in the 05 version since we agreed in
CLUE that simulcast is out of scope for CLUE)

Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Timothy B. Terriberry
Sent: 07 February, 2013 12:42 AM
To: [email-masked]; [email-masked]
Subject: [MMUSIC] Minutes from 6 Feb joint interim session

BUNDLE, ONE-RTP, MMT:

* Decision - Are you generally okay with any of the approaches that reduce
the number of long-lived flows to this level OR is there some other feature
in one of the proposals you must have before this meets your needs?

* Proposed Superset of Requirement 2 - Should be able to interop with legacy
without the JS doing anything special.

* Proposed Requirement - Must be able to configure a set of similar flows
such that once established, the endpoints can add or remove flows without
having to do an O/A cycle (i.e., without having to exchange SDP).

* Proposed Requirement - Have this process terminate in some finite period
of time.

* Decision - Should we come up with a set of requirements and proceed with
Plan A and Plan B with the timelines outlined here?

24 for, 5 against

DataChannel SDP

* Action - Martin believes he can send a proposal to the list which will
change some minds.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic