> 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".
>
> 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@ietf.org>>
[mailto:
dispatch-bounces@ietf.org] On
Behalf Of Cullen Jennings
>> Sent: den 18 januari 2011
05:59
>> To: DISPATCH list
>> Cc:
rtc-web@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@ietf.org>>
https://www.ietf.org/mailman/listinfo/dispatch>>
>
_______________________________________________
> dispatch mailing
list
>
dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch_______________________________________________
dispatch
mailing list
dispatch@ietf.orghttps://www.ietf.org/mailman/listinfo/dispatch