<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6001.18542" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=772190020-20012011><FONT face=Arial
color=#0000ff size=2>Minor comment: I think all codecs that have been discussed
(except for G.711) are adaptive in the sense that their bitrate can be
adapted.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=772190020-20012011><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=772190020-20012011><FONT face=Arial
color=#0000ff size=2>Br,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=772190020-20012011><FONT face=Arial
color=#0000ff size=2>Stefan</FONT></SPAN></DIV><BR>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Stephen Botzko
[mailto:stephen.botzko@gmail.com] <BR><B>Sent:</B> den 20 januari 2011
16:45<BR><B>To:</B> Henry Sinnreich<BR><B>Cc:</B> Stefan Håkansson LK; Cullen
Jennings; DISPATCH list; rtc-web@alvestrand.no<BR><B>Subject:</B> Re:
[dispatch] The charter formerly know as RTC-WEB take 3<BR></FONT><BR></DIV>
<DIV></DIV>>>><BR> How does this fit with adaptive
codecs?<BR>>>><BR>Just because some codecs can adapt doesn't mean
rate adaptation/congestion control should be left out of the scope. I
think it needs to be considered.<BR><BR>>>><BR> Hint:
codec selection matters, is actually critical to this
effort.<BR>>>><BR>Codec selection does matter, but I am not convinced
that mandatory codecs need to be in the RFCs. I believe market forces
are sufficient - SIP itself is one proof point.<BR><BR>Stephen
Botzko<BR><BR><BR>
<DIV class=gmail_quote>On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <SPAN
dir=ltr><<A
href="mailto:henry.sinnreich@gmail.com">henry.sinnreich@gmail.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Hi
Stefan,<BR>
<DIV class=im><BR>> 2. The second one is about rate adaptation/congestion
control. It is not<BR>> mentioned at all. I don't know if it is needed,
perhaps it is enough that<BR>> RFC3550 (that is already pointed at) has a
section about it, but I wanted to<BR>> highlight it.<BR><BR></DIV>How
does this fit with adaptive codecs?<BR>Hint: codec selection matters, is
actually critical to this effort.<BR><BR>Thanks, Henry<BR><BR><BR>On 1/20/11
3:52 AM, "Stefan Håkansson LK" <<A
href="mailto:stefan.lk.hakansson@ericsson.com">stefan.lk.hakansson@ericsson.com</A>><BR>wrote:<BR>
<DIV>
<DIV></DIV>
<DIV class=h5><BR>> Hi Cullen,<BR>><BR>> two
comments:<BR>><BR>> 1. As requirements on the API are explicitly
described, I thinke that there<BR>> should be a comment that the API must
support media format negotiation.<BR>> Proposal: "The API must enable
media format negotiation and application<BR>> influence over media format
selection".<BR>><BR>> 2. The second one is about rate
adaptation/congestion control. It is not<BR>> mentioned at all. I don't
know if it is needed, perhaps it is enough that<BR>> RFC3550 (that is
already pointed at) has a section about it, but I wanted to<BR>>
highlight it.<BR>><BR>> Br,<BR>> Stefan<BR>><BR>>>
-----Original Message-----<BR>>> From: <A
href="mailto:dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</A><BR>>>
[mailto:<A
href="mailto:dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</A>] On
Behalf Of Cullen Jennings<BR>>> Sent: den 18 januari 2011
05:59<BR>>> To: DISPATCH list<BR>>> Cc: <A
href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</A><BR>>>
Subject: [dispatch] The charter formerly know as RTC-WEB take
3<BR>>><BR>>><BR>>> In my dispatch co-chair role, I tried
to take all the<BR>>> comments I had seen on the list about this
charter and see if<BR>>> I could address them in a new version of the
charter. I<BR>>> probably messed up in some places. There were
some<BR>>> conversation that did not seem to be converging so I did
not<BR>>> make any changes for theses. Have a read and if you
think<BR>>> something needs to be changed, propose text changes
along<BR>>> with the reasons why and we will keep the evolving this
charter.<BR>>><BR>>> Thanks<BR>>>
Cullen<BR>>><BR>>>
--------------------------------------------------------------<BR>>>
--------------------<BR>>><BR>>> Version:
3<BR>>><BR>>> Possible Names:<BR>>><BR>>>
RTCWEB<BR>>> WEBRTC<BR>>> STORM: Standardized Transport Oriented
for Realtime Media<BR>>> BURN: Browsers Using Realtime
Media<BR>>> WAVE: Web And Voice/Video Enablement<BR>>> WAVVE:
Web And Voice Video Enablement<BR>>> REALTIME<BR>>>
WEBCOMM<BR>>> WREALTIME<BR>>> WEBTIME<BR>>>
WEBFLOWS<BR>>> BRAVO Browser Realtime Audio and
VideO<BR>>> COBWEB COmmuication Between WEBclients<BR>>>
WHEELTIME<BR>>><BR>>><BR>>><BR>>>
Body:<BR>>><BR>>> Many implementations have been made that use a
Web browser to<BR>>> support direct, interactive communications,
including voice,<BR>>> video, collaboration, and gaming. In
these implementations,<BR>>> the web server acts as the signaling path
between these<BR>>> applications, using locally significant
identifiers to set up<BR>>> the association. Up till now, such
applications have<BR>>> typically required the installation of plugins
or<BR>>> non-standard browser extensions. There is a desire
to<BR>>> standardize this functionality, so that this type
of<BR>>> application can be run in any compatible browser and
allow<BR>>> for high-quality real-time communications experiences
within<BR>>> the browser.<BR>>><BR>>> Traditionally, the
W3C has defined API and markup languages<BR>>> such as HTML that work
in conjunction with with the IETF over<BR>>> the wire protocols such
as HTTP to allow web browsers to<BR>>> display media that does not
have real time interactive<BR>>> constraints with another
human.<BR>>><BR>>> The W3C and IETF plan to collaborate together
in their<BR>>> traditional way to meet the evolving needs of
browsers.<BR>>> Specifically the IETF will provide a set of on the
wire<BR>>> protocols, including RTP, to meet the needs on
interactive<BR>>> communications, and the W3C will define the API and
markup to<BR>>> allow web application developers to control the on the
wire<BR>>> protocols. This will allow application developers to
write<BR>>> applications that run in a browser and facilitate
interactive<BR>>> communications between users for voice and
video<BR>>> communications, collaboration, and
gaming.<BR>>><BR>>> This working group will select and define a
minimal set of<BR>>> protocols that will enable browsers
to:<BR>>><BR>>> * have interactive real time voice and video
pairwise between browsers<BR>>> or other devices using
RTP<BR>>><BR>>> * have interactive real time application data
for collaboration and<BR>>> gaming pairwise between
browsers<BR>>><BR>>> Fortunately very little development of new
protocol at IETF<BR>>> is required for this, only selection of
existing protocols<BR>>> and selection of minimum capabilities to
ensure<BR>>> interoperability. The following protocols are candidates
for<BR>>> including in the profile set:<BR>>><BR>>> 1)
RTP/ RTCP<BR>>><BR>>> 2) a baseline audio codec for high quality
interactive audio.<BR>>> Opus will<BR>>> be one of
the codecs considered<BR>>><BR>>> 3) a baseline audio codec for
PSTN interoperability. G.711<BR>>> and iLBC will<BR>>>
be some of the codecs considered<BR>>><BR>>> 4) a baseline
video codec. H.264 and VP8 will be some of the codecs<BR>>>
considered<BR>>><BR>>> 5) Diffserv based
QoS<BR>>><BR>>> 6) NAT traversal using
ICE<BR>>><BR>>> 7) media based DTMF<BR>>><BR>>> 8)
support for identifying streams purpose using semantics labels<BR>>>
mappable to the labels in RFC 4574<BR>>><BR>>> 9)
Secure RTP and keying<BR>>><BR>>> 10) support for IPv4, IPv6 and
dual stack browsers<BR>>><BR>>> Please note the above list is
only a set of candidates that<BR>>> the WG may consider and is not
list of things that will be in<BR>>> the profile the
set.<BR>>><BR>>> The working group will cooperate closely with
the W3C<BR>>> activity that specifies a semantic level API that allows
the<BR>>> control and manipulation of all the functionality above.
In<BR>>> addition, the API needs to communicate state information
and<BR>>> events about what is happening in the browser that
to<BR>>> applications running in the browser. These events and
state<BR>>> need to include information such as: receiving DTMF in
the<BR>>> RTP, RTP and RTCP statistics, and the state of
DTLS/SRTP<BR>>> handshakes. The output of this WG will form input to
the W3C<BR>>> group that specifies the API.<BR>>><BR>>>
The working group will follow BCP 79, and adhere to the<BR>>> spirit
of BCP 79. The working group cannot explicitly rule<BR>>> out the
possibility of adopting encumbered technologies;<BR>>> however, the
working group will try to avoid encumbered<BR>>> technologies that
require royalties or other encumbrances<BR>>> that would prevent such
technologies from being easy to use<BR>>> in web
browsers.<BR>>><BR>>> The following topics will be out of scope
for the initial<BR>>> phase of the WG but could be added after a
recharter: RTSP,<BR>>> RSVP, NSIS, LOST, Geolocation, IM &
Presence, NSIS, Resource<BR>>> Priority. RTP Payload formats will not
be done in this WG.<BR>>><BR>>>
Milestones:<BR>>><BR>>> May 2011 Main alternatives identified in
drafts<BR>>><BR>>> Aug 2011 WG draft with text reflecting
agreement of what the<BR>>> profile set<BR>>>
should be<BR>>><BR>>> Sept 2011 Scenarios
specification to IESG as Informational<BR>>><BR>>> Nov 2011
Documentation specifying mapping of protocol functionality to<BR>>>
W3C-specified API produced. This is an
input to W3C API work.<BR>>><BR>>> Dec 2011 Profile
specification to IESG as PS<BR>>><BR>>> Apr 2012 Mapping W3C
defied API to IETF protocols to IESG as<BR>>>
Informational. This depends on the W3C API
work.<BR>>><BR>>><BR>>><BR>>>
_______________________________________________<BR>>> dispatch mailing
list<BR>>> <A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A><BR>>> <A
href="https://www.ietf.org/mailman/listinfo/dispatch"
target=_blank>https://www.ietf.org/mailman/listinfo/dispatch</A><BR>>><BR>>
_______________________________________________<BR>> dispatch mailing
list<BR>> <A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A><BR>> <A
href="https://www.ietf.org/mailman/listinfo/dispatch"
target=_blank>https://www.ietf.org/mailman/listinfo/dispatch</A><BR><BR><BR>_______________________________________________<BR>dispatch
mailing list<BR><A
href="mailto:dispatch@ietf.org">dispatch@ietf.org</A><BR><A
href="https://www.ietf.org/mailman/listinfo/dispatch"
target=_blank>https://www.ietf.org/mailman/listinfo/dispatch</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>