[RTW] [dispatch] The charter formerly know as RTC-WEB take 3

[Ted Hardie]

Howdy,

On Thu, Jan 20, 2011 at 1:52 AM, Stefan Håkansson LK
<stefan.lk.hakansson at ericsson.com> wrote:
> Hi Cullen,
>
> two comments:
>
> 1. As requirements on the API are explicitly described, I thinke that there should be a comment that the API must support media format negotiation. Proposal: "The API must enable media format negotiation and application influence over media format selection".
>

Are you thinking that the API should allow for something like SIP's
use of the CONNEG framework
(that is, allow the overall system to use a set intersection model,
with the API acting on the set
membership?)

regards,

Ted Hardie


> 2. The second one is about rate adaptation/congestion control. It is not mentioned at all. I don't know if it is needed, perhaps it is enough that RFC3550 (that is already pointed at) has a section about it, but I wanted to highlight it.
>
> Br,
> Stefan
>
>> -----Original Message-----
>> From: dispatch-bounces at ietf.org
>> [mailto:dispatch-bounces at ietf.org] On Behalf Of Cullen Jennings
>> Sent: den 18 januari 2011 05:59
>> To: DISPATCH list
>> Cc: rtc-web at alvestrand.no
>> Subject: [dispatch] The charter formerly know as RTC-WEB take 3
>>
>>
>> In my dispatch co-chair role, I tried to take all the
>> comments I had seen on the list about this charter and see if
>> I could address them in a new version of the charter. I
>> probably messed up in some places. There were some
>> conversation that did not seem to be converging so I did not
>> make any changes for theses. Have a read and if you think
>> something needs to be changed, propose text changes along
>> with the reasons why and we will keep the evolving this charter.
>>
>> Thanks
>> Cullen
>>
>> --------------------------------------------------------------
>> --------------------
>>
>> Version: 3
>>
>> Possible Names:
>>
>> RTCWEB
>> WEBRTC
>> STORM: Standardized Transport Oriented for Realtime Media
>> BURN: Browsers Using Realtime Media
>> WAVE: Web And Voice/Video Enablement
>> WAVVE: Web And Voice Video Enablement
>> REALTIME
>> WEBCOMM
>> WREALTIME
>> WEBTIME
>> WEBFLOWS
>> BRAVO  Browser Realtime Audio and VideO
>> COBWEB COmmuication Between WEBclients
>> WHEELTIME
>>
>>
>>
>> Body:
>>
>> Many implementations have been made that use a Web browser to
>> support direct, interactive communications, including voice,
>> video, collaboration, and gaming.  In these implementations,
>> the web server acts as the signaling path between these
>> applications, using locally significant identifiers to set up
>> the association.  Up till now, such applications have
>> typically required the installation of plugins or
>> non-standard browser extensions.  There is a desire to
>> standardize this functionality, so that this type of
>> application can be run in any compatible browser and allow
>> for high-quality real-time communications experiences within
>> the browser.
>>
>> Traditionally, the W3C has defined API and markup languages
>> such as HTML that work in conjunction with with the IETF over
>> the wire protocols such as HTTP to allow web browsers to
>> display media that does not have real time interactive
>> constraints with another human.
>>
>> The W3C and IETF plan to collaborate together in their
>> traditional way to meet the evolving needs of browsers.
>> Specifically the IETF will provide a set of on the wire
>> protocols, including RTP, to meet the needs on interactive
>> communications, and the W3C will define the API and markup to
>> allow web application developers to control the on the wire
>> protocols. This will allow application developers to write
>> applications that run in a browser and facilitate interactive
>> communications between users for voice and video
>> communications, collaboration, and gaming.
>>
>> This working group will select and define a minimal set of
>> protocols that will enable browsers to:
>>
>> * have interactive real time voice and video pairwise between browsers
>>   or other devices using RTP
>>
>> * have interactive real time application data for collaboration and
>>   gaming pairwise between browsers
>>
>> Fortunately very little development of new protocol at IETF
>> is required for this, only selection of existing protocols
>> and selection of minimum capabilities to ensure
>> interoperability. The following protocols are candidates for
>> including in the profile set:
>>
>> 1) RTP/ RTCP
>>
>> 2) a baseline audio codec for high quality interactive audio.
>> Opus will
>>    be one of the codecs considered
>>
>> 3) a baseline audio codec for PSTN interoperability. G.711
>> and iLBC will
>>    be some of the codecs considered
>>
>> 4) a baseline video codec. H.264 and VP8 will be some of the codecs
>>    considered
>>
>> 5) Diffserv based QoS
>>
>> 6) NAT traversal using ICE
>>
>> 7) media based DTMF
>>
>> 8) support for identifying streams purpose using semantics labels
>>    mappable to the labels in RFC 4574
>>
>> 9) Secure RTP and keying
>>
>> 10) support for IPv4, IPv6 and dual stack browsers
>>
>> Please note the above list is only a set of candidates that
>> the WG may consider and is not list of things that will be in
>> the profile the set.
>>
>> The working group will cooperate closely with the W3C
>> activity that specifies a semantic level API that allows the
>> control and manipulation of all the functionality above. In
>> addition, the API needs to communicate state information and
>> events about what is happening in the browser that to
>> applications running in the browser. These events and state
>> need to include information such as: receiving DTMF in the
>> RTP, RTP and RTCP statistics, and the state of DTLS/SRTP
>> handshakes. The output of this WG will form input to the W3C
>> group that specifies the API.
>>
>> The working group will follow BCP 79, and adhere to the
>> spirit of BCP 79. The working group cannot explicitly rule
>> out the possibility of adopting encumbered technologies;
>> however, the working group will try to avoid encumbered
>> technologies that require royalties or other encumbrances
>> that would prevent such technologies from being easy to use
>> in web browsers.
>>
>> The following topics will be out of scope for the initial
>> phase of the WG but could be added after a recharter: RTSP,
>> RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource
>> Priority. RTP Payload formats will not be done in this WG.
>>
>> Milestones:
>>
>> May 2011 Main alternatives identified in drafts
>>
>> Aug 2011 WG draft with text reflecting agreement of what the
>> profile set
>>          should be
>>
>> Sept 2011 Scenarios specification to IESG as Informational
>>
>> Nov 2011 Documentation specifying mapping of protocol functionality to
>>          W3C-specified API produced. This is an input to W3C API work.
>>
>> Dec 2011 Profile specification to IESG as PS
>>
>> Apr 2012 Mapping W3C defied API to IETF protocols to IESG as
>>          Informational. This depends on the W3C API work.
>>
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch at ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>