[RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Henry Sinnreich
henry.sinnreich at gmail.com
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
More information about the RTC-Web
mailing list