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

Thu Jan 27 06:44:38 CET 2011

+1
I also don't think people will agree on either SIP or Jingle no matter how
long the discussion may be. Humming is not a good metric here, since it will
favor those who can attend the meeting.

For what it is worth, please see our _outline_ for a SIP API targeted for
compatibility with existing SIP VoIP networks.

http://tools.ietf.org/html/draft-sinnreich-sip-web-apis-01.html

Though the I-D focuses on the most basic 2-party call model, the API can be
extended by developers familiar with SIP.

Other parts of the I-D relating to SDP, RTP and NAT traversal have already
been addressed here on the list, so please disregard. Maybe we should post a
new version, if of interest.

Thanks, Henry

On 1/26/11 8:04 PM, "Cullen Jennings" <fluffy at cisco.com> wrote:

> 
> Clearly you could put a SIP and/or Jingle stack in a browser and have it
> control the RTP. Ignore any SIP vs Jingle issues for a second and just assume
> we had agreement on one or both of them. Some people think this is a good
> idea, some people think it is a bad idea. The charters were constructed such
> that the charter would not determine this and the working group could have
> that argument inside the working group. I really doubt that we could get
> consensus at this point in time to either rule it out of scope or say that the
> solutions had to do this. As people develop proposal around the details of the
> API and how this will all work, I think consensus could start to gather around
> if this is a good idea or not.
> 
> Perhaps the charter should explicitly say this but that is why it seems so
> mute on this topic, it is.
> 
> Cullen
> 
> On Jan 21, 2011, at 7:58 , Xavier Marjou wrote:
> 
>> Hi,
>> 
>> Something strikes me. So far RTC-Web is known as "an effort to achieve
>> a standardized infrastructure in Web browsers on which real-time
>> interactive communication between users of the World Wide Web can be
>> achieved."
>> So what about the selection or definition of a protocol mechanism to
>> establish a media session and negotiate media properties? Are they in
>> scope or out of scope? (nothing is mentioned about it in the last
>> proposal)
>> 
>> Cheers,
>> Xavier
>> 
>> On Tue, Jan 18, 2011 at 5:58 AM, Cullen Jennings <fluffy at cisco.com> wrote:
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> RTC-Web mailing list
>>> RTC-Web at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
>> 
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> _______________________________________________
> dispatch mailing list
> dispatch at ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch