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.
Hi Cullen, Thanks for the summary. I think this is useful work that RAI should take on. I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions. Regards, Peter Musgrave On 2011-01-17, at 11:58 PM, Cullen Jennings 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.
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
On 1/18/11 07:43, Jan 18, Peter Musgrave wrote:
I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
As I mentioned earlier, baseline codecs are far more critical for this effort than for non-real-time web browsing. So someone needs to choose one. It is my understanding that the overall work in this area will be split between the IETF and the W3C, so the decision must be made by one of those two organizations. The W3C could not come to a decision for video codecs when deliberating HTML5, and there is no reason to believe that running the same exercise in that forum with substantially the same participants will yield a different result. What makes a substantive between the W3C and the IETF in this particular regard is the procedure documented in RFC3929, which _guarantees_ that a decision can be made (as long as the working group agrees that the decision must be made). I hope it doesn't come to that, but IETF procedures virtually ensure that we can't deadlock on a decision like the W3C can. /a
Yeah. (sigh) I do agree a common standard is necessary and perhaps the buck does have to stop with us. I do not oppose including this in the charter. I do think we need to segregate this codec recommendation from the plumbing - so those docs can blast ahead as the debate on CODECs rages. Would we contemplate a WEBCODEC group separate from rtcweb since these are activities with very different participants and goals? Regards Peter Musgrave On 2011-01-18, at 9:27 AM, Adam Roach wrote:
On 1/18/11 07:43, Jan 18, Peter Musgrave wrote:
I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
As I mentioned earlier, baseline codecs are far more critical for this effort than for non-real-time web browsing. So someone needs to choose one.
It is my understanding that the overall work in this area will be split between the IETF and the W3C, so the decision must be made by one of those two organizations.
The W3C could not come to a decision for video codecs when deliberating HTML5, and there is no reason to believe that running the same exercise in that forum with substantially the same participants will yield a different result.
What makes a substantive between the W3C and the IETF in this particular regard is the procedure documented in RFC3929, which _guarantees_ that a decision can be made (as long as the working group agrees that the decision must be made). I hope it doesn't come to that, but IETF procedures virtually ensure that we can't deadlock on a decision like the W3C can.
/a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
I think this is a very good idea (separating the two activities). Codecs have evolved a lot over the past several years, and there are a LOT of important details that may be lost to the uninitiated. Making a decision is always easy. Making the right one is tough, and it takes a lot of work. I sure hope the group (RTCWEB or another one) does take the time to truly understand the engineering ramifications of the various choices. And I still thing that leaving it out would be the best choice. --Alex On Jan 18, 2011, at 4:38 PM, Peter Musgrave wrote:
Yeah. (sigh)
I do agree a common standard is necessary and perhaps the buck does have to stop with us.
I do not oppose including this in the charter. I do think we need to segregate this codec recommendation from the plumbing - so those docs can blast ahead as the debate on CODECs rages. Would we contemplate a WEBCODEC group separate from rtcweb since these are activities with very different participants and goals?
Regards
Peter Musgrave
On 2011-01-18, at 9:27 AM, Adam Roach wrote:
On 1/18/11 07:43, Jan 18, Peter Musgrave wrote:
I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
As I mentioned earlier, baseline codecs are far more critical for this effort than for non-real-time web browsing. So someone needs to choose one.
It is my understanding that the overall work in this area will be split between the IETF and the W3C, so the decision must be made by one of those two organizations.
The W3C could not come to a decision for video codecs when deliberating HTML5, and there is no reason to believe that running the same exercise in that forum with substantially the same participants will yield a different result.
What makes a substantive between the W3C and the IETF in this particular regard is the procedure documented in RFC3929, which _guarantees_ that a decision can be made (as long as the working group agrees that the decision must be made). I hope it doesn't come to that, but IETF procedures virtually ensure that we can't deadlock on a decision like the W3C can.
/a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
On Jan 18, 2011, at 10:00 AM, Alex Eleftheriadis wrote:
I think this is a very good idea (separating the two activities). Codecs have evolved a lot over the past several years, and there are a LOT of important details that may be lost to the uninitiated.
I also support separating the two activities, I would suggest into two WG. Regards Marshall
Making a decision is always easy. Making the right one is tough, and it takes a lot of work. I sure hope the group (RTCWEB or another one) does take the time to truly understand the engineering ramifications of the various choices.
And I still thing that leaving it out would be the best choice.
--Alex
On Jan 18, 2011, at 4:38 PM, Peter Musgrave wrote:
Yeah. (sigh)
I do agree a common standard is necessary and perhaps the buck does have to stop with us.
I do not oppose including this in the charter. I do think we need to segregate this codec recommendation from the plumbing - so those docs can blast ahead as the debate on CODECs rages. Would we contemplate a WEBCODEC group separate from rtcweb since these are activities with very different participants and goals?
Regards
Peter Musgrave
On 2011-01-18, at 9:27 AM, Adam Roach wrote:
On 1/18/11 07:43, Jan 18, Peter Musgrave wrote:
I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
As I mentioned earlier, baseline codecs are far more critical for this effort than for non-real-time web browsing. So someone needs to choose one.
It is my understanding that the overall work in this area will be split between the IETF and the W3C, so the decision must be made by one of those two organizations.
The W3C could not come to a decision for video codecs when deliberating HTML5, and there is no reason to believe that running the same exercise in that forum with substantially the same participants will yield a different result.
What makes a substantive between the W3C and the IETF in this particular regard is the procedure documented in RFC3929, which _guarantees_ that a decision can be made (as long as the working group agrees that the decision must be made). I hope it doesn't come to that, but IETF procedures virtually ensure that we can't deadlock on a decision like the W3C can.
/a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ 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
Better two WG's, one focused on the codec issues than totally punting the codec issue completely and having no baseline functionality at all. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks Sent: Tuesday, January 18, 2011 10:07 AM To: Alex Eleftheriadis Cc: rtc-web@alvestrand.no; DISPATCH list Subject: Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3 On Jan 18, 2011, at 10:00 AM, Alex Eleftheriadis wrote:
I think this is a very good idea (separating the two activities). Codecs have evolved a lot over the past several years, and there are a LOT of important details that may be lost to the uninitiated.
I also support separating the two activities, I would suggest into two WG. Regards Marshall
Making a decision is always easy. Making the right one is tough, and it
takes a lot of work. I sure hope the group (RTCWEB or another one) does take the time to truly understand the engineering ramifications of the various choices.
And I still thing that leaving it out would be the best choice.
--Alex
On Jan 18, 2011, at 4:38 PM, Peter Musgrave wrote:
Yeah. (sigh)
I do agree a common standard is necessary and perhaps the buck does have
to stop with us.
I do not oppose including this in the charter. I do think we need to
segregate this codec recommendation from the plumbing - so those docs can blast ahead as the debate on CODECs rages. Would we contemplate a WEBCODEC group separate from rtcweb since these are activities with very different participants and goals?
Regards
Peter Musgrave
On 2011-01-18, at 9:27 AM, Adam Roach wrote:
On 1/18/11 07:43, Jan 18, Peter Musgrave wrote:
I share the concern expressed by many on the list that including
selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
As I mentioned earlier, baseline codecs are far more critical for this
effort than for non-real-time web browsing. So someone needs to choose one.
It is my understanding that the overall work in this area will be split
between the IETF and the W3C, so the decision must be made by one of those two organizations.
The W3C could not come to a decision for video codecs when deliberating
HTML5, and there is no reason to believe that running the same exercise in that forum with substantially the same participants will yield a different result.
What makes a substantive between the W3C and the IETF in this particular
regard is the procedure documented in RFC3929, which _guarantees_ that a decision can be made (as long as the working group agrees that the decision must be made). I hope it doesn't come to that, but IETF procedures virtually ensure that we can't deadlock on a decision like the W3C can.
/a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ 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.org https://www.ietf.org/mailman/listinfo/dispatch
+1 Thanks, Henry On 1/18/11 8:27 AM, "Adam Roach" <adam@nostrum.com> wrote:
On 1/18/11 07:43, Jan 18, Peter Musgrave wrote:
I share the concern expressed by many on the list that including selection of baseline CODECs (audio and video) is something which will consume enormous energy and FWIW I don't see it as necessary for the "plumbing" part of the problem to which the IETF is best suited to provide solutions.
As I mentioned earlier, baseline codecs are far more critical for this effort than for non-real-time web browsing. So someone needs to choose one.
It is my understanding that the overall work in this area will be split between the IETF and the W3C, so the decision must be made by one of those two organizations.
The W3C could not come to a decision for video codecs when deliberating HTML5, and there is no reason to believe that running the same exercise in that forum with substantially the same participants will yield a different result.
What makes a substantive between the W3C and the IETF in this particular regard is the procedure documented in RFC3929, which _guarantees_ that a decision can be made (as long as the working group agrees that the decision must be made). I hope it doesn't come to that, but IETF procedures virtually ensure that we can't deadlock on a decision like the W3C can.
/a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Hi, A simple comment in this email. Cullen Jennings skrev 2011-01-18 05:58:
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
This name is already taken, there is an active TSV WG called STORM that works on Storage Specifications.
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
-- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
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
Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@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".
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
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com
wrote:
Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" < stefan.lk.hakansson@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".
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.org https://www.ietf.org/mailman/listinfo/dispatch
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. Br, Stefan ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com<mailto:henry.sinnreich@gmail.com>> wrote: Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@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".
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> [mailto: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<mailto: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<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ dispatch mailing list dispatch@ietf.org<mailto:dispatch@ietf.org> https://www.ietf.org/mailman/listinfo/dispatch
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Thanks, Henry On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote:
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.
Br, Stefan
From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
>> How does this fit with adaptive codecs? >> 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.
>> Hint: codec selection matters, is actually critical to this effort. >> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote:
Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@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".
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 be
On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote:
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.
Br, Stefan
------------------------------------------------------------------------ *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] *Sent:* den 20 januari 2011 16:45 *To:* Henry Sinnreich *Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no *Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
>>> How does this fit with adaptive codecs? >>> 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.
>>> Hint: codec selection matters, is actually critical to this effort. >>> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote:
Hi Stefan,
> 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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@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". > > 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 be
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required). ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 21 januari 2011 08:46 To: Henry Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3) On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread.... are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10). Thanks, Henry On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote: 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. Br, Stefan ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote: Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@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".
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 be
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard. There was a draft but it has been abandonded ( http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10) On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote:
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
------------------------------ *From:* Harald Alvestrand [mailto:harald@alvestrand.no] *Sent:* den 21 januari 2011 08:46 *To:* Henry Sinnreich *Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list *Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain?
Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" < stefan.lk.hakansson@ericsson.com> wrote:
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.
Br, Stefan
------------------------------ *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com<stephen.botzko@gmail.com>]
*Sent:* den 20 januari 2011 16:45 *To:* Henry Sinnreich *Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no *Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich < henry.sinnreich@gmail.com> wrote:
Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" < stefan.lk.hakansson@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".
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 <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 be
_______________________________________________ RTC-Web mailing listRTC-Web@alvestrand.nohttp://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast. ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 21 januari 2011 09:13 To: Stefan Håkansson LK Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard. There was a draft but it has been abandonded (http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10) On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>> wrote: My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required). ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no<mailto:harald@alvestrand.no>] Sent: den 21 januari 2011 08:46 To: Henry Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; DISPATCH list Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3) On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread.... are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10). Thanks, Henry On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com<http://stefan.lk.hakansson@ericsson.com>> wrote: 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. Br, Stefan ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no<http://rtc-web@alvestrand.no> Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com<http://henry.sinnreich@gmail.com>> wrote: Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com<http://stefan.lk.hakansson@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".
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<http://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<http://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 be
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection- tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this. We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner. Are there any other inband schemes that are up in rfc at this point? Tom From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list <dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast. From: Justin Uberti [mailto:juberti@google.com] Sent: den 21 januari 2011 09:13 To: Stefan Håkansson LK Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard. There was a draft but it has been abandonded ( http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10) On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote: My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required). From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 21 januari 2011 08:46 To: Henry Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3) On 01/21/2011 12:06 AM, Henry Sinnreich wrote: >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. It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread.... are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10). Thanks, Henry On 1/20/11 2:02 PM, "Stefan Håkansson LK" < stefan.lk.hakansson@ericsson.com> wrote: 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. Br, Stefan From: Stephen Botzko [mailto:stephen.botzko@gmail.com ] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3 >>> How does this fit with adaptive codecs? >>> 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. >>> Hint: codec selection matters, is actually critical to this effort. >>> 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. Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich < henry.sinnreich@gmail.com> wrote: Hi Stefan, > 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. How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" < stefan.lk.hakansson@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". > > 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 be _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
TFRC isn't perfect, but it seems to work pretty well in practice. The RTP extension header overhead of 12 bytes per packet is fairly nominal (1%) at today's video bitrates, as is the cost of the RTCP feedback message. I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP. On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote:
It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection-
tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.
Are there any other inband schemes that are up in rfc at this point?
Tom
[image: Inactive hide details for Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actua]Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr
From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list <dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand < harald@alvestrand.no>, "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no ------------------------------
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast.
------------------------------ *From:* Justin Uberti [mailto:juberti@google.com <juberti@google.com>] * Sent:* den 21 januari 2011 09:13* To:* Stefan Håkansson LK* Cc:* Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko* Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard.
There was a draft but it has been abandonded (* http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10*<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> )
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <* stefan.lk.hakansson@ericsson.com* <stefan.lk.hakansson@ericsson.com>> wrote:
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
------------------------------ *From:* Harald Alvestrand [mailto:*harald@alvestrand.no*<harald@alvestrand.no>] * Sent:* den 21 januari 2011 08:46* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; * rtc-web@alvestrand.no* <rtc-web@alvestrand.no>; DISPATCH list* Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote: >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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>> wrote: 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.
Br, Stefan
------------------------------ *From:* Stephen Botzko [* mailto:stephen.botzko@gmail.com*<stephen.botzko@gmail.com>] * Sent:* den 20 januari 2011 16:45* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; *rtc-web@alvestrand.no*<http://rtc-web@alvestrand.no/> * Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
>>> How does this fit with adaptive codecs? >>> 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.
>>> Hint: codec selection matters, is actually critical to this effort. >>> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <* henry.sinnreich@gmail.com*<http://henry.sinnreich@gmail.com/>> wrote: Hi Stefan,
> 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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@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". > > 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*<http://dispatch-bounces@ietf.org/> >> [*mailto:dispatch-bounces@ietf.org*<dispatch-bounces@ietf.org>] On Behalf Of Cullen Jennings >> Sent: den 18 januari 2011 05:59 >> To: DISPATCH list >> Cc: *rtc-web@alvestrand.no*<http://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 be
_______________________________________________ RTC-Web mailing list *RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no> *http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list* **RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no>* **http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com> wrote:
TFRC isn't perfect, but it seems to work pretty well in practice.
in practice where???? -sm The RTP extension header overhead of 12 bytes per packet is fairly nominal
(1%) at today's video bitrates, as is the cost of the RTCP feedback message.
I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP.
On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote:
It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection-
tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.
Are there any other inband schemes that are up in rfc at this point?
Tom
[image: Inactive hide details for Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actua]Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr
From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list <dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand < harald@alvestrand.no>, "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no ------------------------------
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast.
------------------------------ *From:* Justin Uberti [mailto:juberti@google.com <juberti@google.com>] * Sent:* den 21 januari 2011 09:13* To:* Stefan Håkansson LK* Cc:* Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko* Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard.
There was a draft but it has been abandonded (* http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10*<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> )
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <* stefan.lk.hakansson@ericsson.com* <stefan.lk.hakansson@ericsson.com>> wrote:
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
------------------------------ *From:* Harald Alvestrand [mailto:*harald@alvestrand.no*<harald@alvestrand.no>] * Sent:* den 21 januari 2011 08:46* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; * rtc-web@alvestrand.no* <rtc-web@alvestrand.no>; DISPATCH list* Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote: >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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>> wrote: 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.
Br, Stefan
------------------------------ *From:* Stephen Botzko [* mailto:stephen.botzko@gmail.com*<stephen.botzko@gmail.com>] * Sent:* den 20 januari 2011 16:45* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; *rtc-web@alvestrand.no*<http://rtc-web@alvestrand.no/> * Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
>>> How does this fit with adaptive codecs? >>> 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.
>>> Hint: codec selection matters, is actually critical to this effort. >>> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <* henry.sinnreich@gmail.com*<http://henry.sinnreich@gmail.com/>> wrote: Hi Stefan,
> 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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@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". > > 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*<http://dispatch-bounces@ietf.org/> >> [*mailto:dispatch-bounces@ietf.org*<dispatch-bounces@ietf.org>] On Behalf Of Cullen Jennings >> Sent: den 18 januari 2011 05:59 >> To: DISPATCH list >> Cc: *rtc-web@alvestrand.no*<http://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 be
_______________________________________________ RTC-Web mailing list *RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no> *http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list* **RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no>* **http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it <email%3Amascolo@poliba.it> http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
Google Video Chat uses a TFRC-based algorithm for rate control. On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo <saverio.mascolo@gmail.com>wrote:
On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com> wrote:
TFRC isn't perfect, but it seems to work pretty well in practice.
in practice where????
-sm
The RTP extension header overhead of 12 bytes per packet is fairly nominal
(1%) at today's video bitrates, as is the cost of the RTCP feedback message.
I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP.
On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote:
It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection-
tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.
Are there any other inband schemes that are up in rfc at this point?
Tom
[image: Inactive hide details for Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actua]Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr
From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list <dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand < harald@alvestrand.no>, "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no ------------------------------
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast.
------------------------------ *From:* Justin Uberti [mailto:juberti@google.com <juberti@google.com>] * Sent:* den 21 januari 2011 09:13* To:* Stefan Håkansson LK* Cc:* Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko* Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard.
There was a draft but it has been abandonded (* http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10*<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> )
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <* stefan.lk.hakansson@ericsson.com* <stefan.lk.hakansson@ericsson.com>> wrote:
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
------------------------------ *From:* Harald Alvestrand [mailto:*harald@alvestrand.no*<harald@alvestrand.no>] * Sent:* den 21 januari 2011 08:46* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; * rtc-web@alvestrand.no* <rtc-web@alvestrand.no>; DISPATCH list* Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote: >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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>> wrote: 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.
Br, Stefan
------------------------------ *From:* Stephen Botzko [* mailto:stephen.botzko@gmail.com*<stephen.botzko@gmail.com>] * Sent:* den 20 januari 2011 16:45* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; *rtc-web@alvestrand.no*<http://rtc-web@alvestrand.no/> * Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
>>> How does this fit with adaptive codecs? >>> 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.
>>> Hint: codec selection matters, is actually critical to this effort. >>> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich < *henry.sinnreich@gmail.com*<http://henry.sinnreich@gmail.com/>> wrote: Hi Stefan,
> 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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@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". > > 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*<http://dispatch-bounces@ietf.org/> >> [*mailto:dispatch-bounces@ietf.org*<dispatch-bounces@ietf.org>] On Behalf Of Cullen Jennings >> Sent: den 18 januari 2011 05:59 >> To: DISPATCH list >> Cc: *rtc-web@alvestrand.no*<http://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 be
_______________________________________________ RTC-Web mailing list *RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no> *http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list* **RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no>* **http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 <tel:+390805963621> Fax. +39 080 5963410 <tel:+390805963410> email:mascolo@poliba.it <email%3Amascolo@poliba.it>
================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
On Sun, Jan 23, 2011 at 6:41 AM, Justin Uberti <juberti@google.com> wrote:
Google Video Chat uses a TFRC-based algorithm for rate control.
what is the source of this information? -sm
On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo < saverio.mascolo@gmail.com> wrote:
On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com>wrote:
TFRC isn't perfect, but it seems to work pretty well in practice.
in practice where????
-sm
The RTP extension header overhead of 12 bytes per packet is fairly nominal
(1%) at today's video bitrates, as is the cost of the RTCP feedback message.
I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP.
On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote:
It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection-
tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.
Are there any other inband schemes that are up in rfc at this point?
Tom
[image: Inactive hide details for Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actua]Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr
From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list < dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "rtc-web@alvestrand.no" < rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no ------------------------------
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast.
------------------------------ *From:* Justin Uberti [mailto:juberti@google.com <juberti@google.com>] * Sent:* den 21 januari 2011 09:13* To:* Stefan Håkansson LK* Cc:* Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko* Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard.
There was a draft but it has been abandonded (* http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10*<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> )
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <* stefan.lk.hakansson@ericsson.com* <stefan.lk.hakansson@ericsson.com>> wrote:
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
------------------------------ *From:* Harald Alvestrand [mailto:*harald@alvestrand.no*<harald@alvestrand.no>] * Sent:* den 21 januari 2011 08:46* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; * rtc-web@alvestrand.no* <rtc-web@alvestrand.no>; DISPATCH list* Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote: >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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>> wrote: 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.
Br, Stefan
------------------------------ *From:* Stephen Botzko [* mailto:stephen.botzko@gmail.com*<stephen.botzko@gmail.com>] * Sent:* den 20 januari 2011 16:45* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; *rtc-web@alvestrand.no*<http://rtc-web@alvestrand.no/> * Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
>>> How does this fit with adaptive codecs? >>> 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.
>>> Hint: codec selection matters, is actually critical to this effort. >>> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <*henry.sinnreich@gmail.com*<http://henry.sinnreich@gmail.com/>> wrote: Hi Stefan,
> 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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@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". > > 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*<http://dispatch-bounces@ietf.org/> >> [*mailto:dispatch-bounces@ietf.org*<dispatch-bounces@ietf.org>] On Behalf Of Cullen Jennings >> Sent: den 18 januari 2011 05:59 >> To: DISPATCH list >> Cc: *rtc-web@alvestrand.no*<http://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 be
_______________________________________________ RTC-Web mailing list *RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no> *http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list* **RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no>* **http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 <tel:+390805963621> Fax. +39 080 5963410 <tel:+390805963410> email:mascolo@poliba.it <email%3Amascolo@poliba.it>
================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it <email%3Amascolo@poliba.it> http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
On 01/23/11 08:58, Saverio Mascolo wrote:
On Sun, Jan 23, 2011 at 6:41 AM, Justin Uberti <juberti@google.com <mailto:juberti@google.com>> wrote:
Google Video Chat uses a TFRC-based algorithm for rate control.
what is the source of this information?
The Google Video Chat team, where Justin works.
This may be a slightly off topic on this thread, but... I would like to introduce a simpler way to implement a variant of TFRC (actually, this is a window-based congestion control, known as TFWC) for the video streaming applications. Here is the details about the protocol - a window-based congestion control mechanism, TFWC: http://tfwc.hackerslab.eu/ Any comments? Cheers, Soo-Hyun On Mon, Jan 24, 2011 at 01:41, Harald Alvestrand <harald@alvestrand.no> wrote:
On 01/23/11 08:58, Saverio Mascolo wrote:
On Sun, Jan 23, 2011 at 6:41 AM, Justin Uberti <juberti@google.com <mailto:juberti@google.com>> wrote:
Google Video Chat uses a TFRC-based algorithm for rate control.
what is the source of this information?
The Google Video Chat team, where Justin works.
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On 01/23/11 23:02, Soo-Hyun Choi wrote:
This may be a slightly off topic on this thread, but...
I would like to introduce a simpler way to implement a variant of TFRC (actually, this is a window-based congestion control, known as TFWC) for the video streaming applications.
Here is the details about the protocol - a window-based congestion control mechanism, TFWC: http://tfwc.hackerslab.eu/ I think this is off topic for this group - it probably needs to be taken to DISPATCH or wherever rate-control algorithms go. We won't be chartered to work on this kind of problem; if the solution was available to be referenced, it's possible that we could adopt it. My standard questions include:
- Is there a draft? - Is there code? From your page, it is clear that this is for unicast streams only; I approve of making that statement up front. Harald
I think this is off topic for this group - it probably needs to be taken to DISPATCH or wherever rate-control algorithms go.
Thanks for your information. I will consider bring TFWC to DISPATCH.
We won't be chartered to work on this kind of problem; if the solution was available to be referenced, it's possible that we could adopt it.
I didn't intend it to be charted in this group, but tried to introduce a better mechanism than TFRC in some cases, which described in my thesis file - you guys have said that GTalk implements TFRC in video chatting, so I thought it might be beneficial to you in that context. By the way, the solutions and some results are documented in my thesis PDF file. If you guys still think it's clearly off the group's interest, neglect my message(s) about TFWC protocol.
My standard questions include:
- Is there a draft?
No, not yet - we are currently preparing for it.
- Is there code?
Yes - http://tfwc.hackerslab.eu/download (NB: it is not a production-level code.)
From your page, it is clear that this is for unicast streams only; I approve of making that statement up front.
I guess it is not trivial to support multicast streams with a window-based CC mechanism, so it (TFWC is a window-based CC) currently supports unicast only. Cheers, Soo-Hyun
Magor also uses a TFRC-based approach. The TFRC algorithm is very effective. Peter Musgrave On 2011-01-23, at 12:41 AM, Justin Uberti wrote:
Google Video Chat uses a TFRC-based algorithm for rate control.
On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo <saverio.mascolo@gmail.com> wrote:
On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com> wrote: TFRC isn't perfect, but it seems to work pretty well in practice.
in practice where????
-sm
The RTP extension header overhead of 12 bytes per packet is fairly nominal (1%) at today's video bitrates, as is the cost of the RTCP feedback message.
I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP.
On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote: It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection-
tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.
Are there any other inband schemes that are up in rfc at this point?
Tom
<graycol.gif>Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr
From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list <dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast.
From: Justin Uberti [mailto:juberti@google.com] Sent: den 21 januari 2011 09:13 To: Stefan Håkansson LK Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard.
There was a draft but it has been abandonded (http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10)
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote: My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: den 21 januari 2011 08:46 To: Henry Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com> wrote: 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.
Br, Stefan
From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote: Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@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".
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 be
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it
================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Maybe we can work out the details along the way; I think I started the thread, and my purpose was to secure that congestion control of streams would be part of the solution, and to discuss if it should be in the charter. Many mails discussing _how_ to rate control, and no mails against, means to me that people feel that congestion control should be supported. Cullen, Harald: something to add to the charter? //Stefan ________________________________ From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Peter Musgrave Sent: den 23 januari 2011 13:14 To: Justin Uberti Cc: tom_harper@logitech.com; rtc-web@alvestrand.no; Saverio Mascolo Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Magor also uses a TFRC-based approach. The TFRC algorithm is very effective. Peter Musgrave On 2011-01-23, at 12:41 AM, Justin Uberti wrote: Google Video Chat uses a TFRC-based algorithm for rate control. On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo <saverio.mascolo@gmail.com<mailto:saverio.mascolo@gmail.com>> wrote: On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote: TFRC isn't perfect, but it seems to work pretty well in practice. in practice where???? -sm The RTP extension header overhead of 12 bytes per packet is fairly nominal (1%) at today's video bitrates, as is the cost of the RTCP feedback message. I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP. On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com<mailto:tom_harper@logitech.com>> wrote: It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection- tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this. We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner. Are there any other inband schemes that are up in rfc at this point? Tom <graycol.gif>Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>> To: Justin Uberti <juberti@google.com<mailto:juberti@google.com>> Cc: Cullen Jennings <fluffy@cisco.com<mailto:fluffy@cisco.com>>, DISPATCH list <dispatch@ietf.org<mailto:dispatch@ietf.org>>, Henry Sinnreich <henry.sinnreich@gmail.com<mailto:henry.sinnreich@gmail.com>>, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>>, "rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>" <rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>>, Stephen Botzko <stephen.botzko@gmail.com<mailto:stephen.botzko@gmail.com>> Date: 01/21/2011 12:38 AM Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no<mailto:rtc-web-bounces@alvestrand.no> ________________________________ Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast. ________________________________ From: Justin Uberti [mailto:juberti@google.com] Sent: den 21 januari 2011 09:13 To: Stefan Håkansson LK Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; DISPATCH list; Stephen Botzko Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard. There was a draft but it has been abandonded (http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10) On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>> wrote: My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required). ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no<mailto:harald@alvestrand.no>] Sent: den 21 januari 2011 08:46 To: Henry Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; rtc-web@alvestrand.no<mailto:rtc-web@alvestrand.no>; DISPATCH list Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3) On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread.... are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10). Thanks, Henry On 1/20/11 2:02 PM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com<http://stefan.lk.hakansson@ericsson.com/>> wrote: 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. Br, Stefan ________________________________ From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no<http://rtc-web@alvestrand.no/> Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <henry.sinnreich@gmail.com<http://henry.sinnreich@gmail.com/>> wrote: Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com<http://stefan.lk.hakansson@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".
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<http://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<http://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 be
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web -- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621<tel:+390805963621> Fax. +39 080 5963410<tel:+390805963410> email:mascolo@poliba.it<mailto:email%3Amascolo@poliba.it> http://c3lab.poliba.it<http://c3lab.poliba.it/> ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden. _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
anyone knows what cc is used by skype? we did this investigation for skype audio http://c3lab.poliba.it/images/9/9b/Skype-tac10.pdf and this one for video http://c3lab.poliba.it/images/b/b7/Skype_comnet.pdf -sm On Sun, Jan 23, 2011 at 4:30 PM, Stefan Håkansson LK < stefan.lk.hakansson@ericsson.com> wrote:
Maybe we can work out the details along the way; I think I started the thread, and my purpose was to secure that congestion control of streams would be part of the solution, and to discuss if it should be in the charter.
Many mails discussing _how_ to rate control, and no mails against, means to me that people feel that congestion control should be supported.
Cullen, Harald: something to add to the charter?
//Stefan
------------------------------ *From:* rtc-web-bounces@alvestrand.no [mailto: rtc-web-bounces@alvestrand.no] *On Behalf Of *Peter Musgrave *Sent:* den 23 januari 2011 13:14 *To:* Justin Uberti *Cc:* tom_harper@logitech.com; rtc-web@alvestrand.no; Saverio Mascolo
*Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
Magor also uses a TFRC-based approach. The TFRC algorithm is very effective.
Peter Musgrave
On 2011-01-23, at 12:41 AM, Justin Uberti wrote:
Google Video Chat uses a TFRC-based algorithm for rate control.
On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo < saverio.mascolo@gmail.com> wrote:
On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com>wrote:
TFRC isn't perfect, but it seems to work pretty well in practice.
in practice where????
-sm
The RTP extension header overhead of 12 bytes per packet is fairly nominal
(1%) at today's video bitrates, as is the cost of the RTCP feedback message.
I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP.
On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote:
It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection-
tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this.
We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner.
Are there any other inband schemes that are up in rfc at this point?
Tom
<graycol.gif>Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr
From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list < dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "rtc-web@alvestrand.no" < rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM
Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no ------------------------------
Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast.
------------------------------ *From:* Justin Uberti [mailto:juberti@google.com <juberti@google.com>] * Sent:* den 21 januari 2011 09:13* To:* Stefan Håkansson LK* Cc:* Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko* Subject:* Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3)
RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard.
There was a draft but it has been abandonded (* http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10*<http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> )
On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK <* stefan.lk.hakansson@ericsson.com* <stefan.lk.hakansson@ericsson.com>> wrote:
My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required).
------------------------------ *From:* Harald Alvestrand [mailto:*harald@alvestrand.no*<harald@alvestrand.no>] * Sent:* den 21 januari 2011 08:46* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; * rtc-web@alvestrand.no* <rtc-web@alvestrand.no>; DISPATCH list* Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)
On 01/21/2011 12:06 AM, Henry Sinnreich wrote: >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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread....
are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10).
Thanks, Henry
On 1/20/11 2:02 PM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@ericsson.com/>> wrote: 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.
Br, Stefan
------------------------------ *From:* Stephen Botzko [* mailto:stephen.botzko@gmail.com*<stephen.botzko@gmail.com>] * Sent:* den 20 januari 2011 16:45* To:* Henry Sinnreich* Cc:* Stefan Håkansson LK; Cullen Jennings; DISPATCH list; *rtc-web@alvestrand.no*<http://rtc-web@alvestrand.no/> * Subject:* Re: [dispatch] The charter formerly know as RTC-WEB take 3
>>> How does this fit with adaptive codecs? >>> 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.
>>> Hint: codec selection matters, is actually critical to this effort. >>> 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.
Stephen Botzko
On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <*henry.sinnreich@gmail.com*<http://henry.sinnreich@gmail.com/>> wrote: Hi Stefan,
> 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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort.
Thanks, Henry
On 1/20/11 3:52 AM, "Stefan Håkansson LK" <* stefan.lk.hakansson@ericsson.com*<http://stefan.lk.hakansson@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". > > 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*<http://dispatch-bounces@ietf.org/> >> [*mailto:dispatch-bounces@ietf.org*<dispatch-bounces@ietf.org>] On Behalf Of Cullen Jennings >> Sent: den 18 januari 2011 05:59 >> To: DISPATCH list >> Cc: *rtc-web@alvestrand.no*<http://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 be
_______________________________________________ RTC-Web mailing list *RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no> *http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list* **RTC-Web@alvestrand.no* <RTC-Web@alvestrand.no>* **http://www.alvestrand.no/mailman/listinfo/rtc-web*<http://www.alvestrand.no/mailman/listinfo/rtc-web>
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 <tel:+390805963621> Fax. +39 080 5963410 <tel:+390805963410> email:mascolo@poliba.it <email%3Amascolo@poliba.it>
================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it <email%3Amascolo@poliba.it> http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
It’s a proprietary algorithm of our own design, supported by some protocols which exchange feedback in real-time between endpoints. We’re constantly tweaking it based on user feedback and technical statistics we collect. Indeed – as many folks are aware, rate adaptation has always been an area of innovation and differentiation. RTP has provided the tools for feedback but has allowed implementations to do whatever they want. I think it is important that this continues to be the case in the web world – that folks designing RTC applications can innovate and define their own versions of these algorithms. Thanks, Jonathan R. Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Saverio Mascolo Sent: Sunday, January 23, 2011 8:35 AM To: Stefan Håkansson LK Cc: Cullen Jennings; tom_harper@logitech.com; Justin Uberti; Harald Alvestrand; rtc-web@alvestrand.no; Peter Musgrave Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) anyone knows what cc is used by skype? we did this investigation for skype audio http://c3lab.poliba.it/images/9/9b/Skype-tac10.pdf and this one for video http://c3lab.poliba.it/images/b/b7/Skype_comnet.pdf -sm On Sun, Jan 23, 2011 at 4:30 PM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote: Maybe we can work out the details along the way; I think I started the thread, and my purpose was to secure that congestion control of streams would be part of the solution, and to discuss if it should be in the charter. Many mails discussing _how_ to rate control, and no mails against, means to me that people feel that congestion control should be supported. Cullen, Harald: something to add to the charter? //Stefan _____ From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Peter Musgrave Sent: den 23 januari 2011 13:14 To: Justin Uberti Cc: tom_harper@logitech.com; rtc-web@alvestrand.no; Saverio Mascolo Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Magor also uses a TFRC-based approach. The TFRC algorithm is very effective. Peter Musgrave On 2011-01-23, at 12:41 AM, Justin Uberti wrote: Google Video Chat uses a TFRC-based algorithm for rate control. On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo <saverio.mascolo@gmail.com> wrote: On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <juberti@google.com> wrote: TFRC isn't perfect, but it seems to work pretty well in practice. in practice where???? -sm The RTP extension header overhead of 12 bytes per packet is fairly nominal (1%) at today's video bitrates, as is the cost of the RTCP feedback message. I'm not aware of any other standards-track bandwidth estimation algorithms designed to work with RTP/UDP. On Fri, Jan 21, 2011 at 9:46 AM, <tom_harper@logitech.com> wrote: It seems to me neither avpf or tfrc is fully perfect- on the whole tfrc seems to be better than avpf in terms of constant measurement of the connection- tfrc seems scary/impractical at low latencies due to the following: "The TFRC requirements of receiving feedback once per RTT can at times conflict with the AVP RTCP bandwidth constraints, particularly at small RTTs of 20 ms or less" and the fact that it has to be attached as an extension header to every data packet seems like more overhead than is needed, but others opinions may differ on this. We support avpf as defined 5104/4585, but prefer not to use it as in some scenarios we have run into the rtcp bandwidth cap- and then you get no feedback at all in a timely manner. Are there any other inband schemes that are up in rfc at this point? Tom <graycol.gif>Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a tr From: Stefan H嶡ansson LK <stefan.lk.hakansson@ericsson.com> To: Justin Uberti <juberti@google.com> Cc: Cullen Jennings <fluffy@cisco.com>, DISPATCH list <dispatch@ietf.org>, Henry Sinnreich <henry.sinnreich@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "rtc-web@alvestrand.no" <rtc-web@alvestrand.no>, Stephen Botzko <stephen.botzko@gmail.com> Date: 01/21/2011 12:38 AM Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) Sent by: rtc-web-bounces@alvestrand.no _____ Isn't it so that with the AVPF profile you can actually sent RTCP when there is a need (even if a transmission is not due)? This way you can actually react fast. _____ From: Justin Uberti [mailto:juberti@google.com] Sent: den 21 januari 2011 09:13 To: Stefan Håkansson LK Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; rtc-web@alvestrand.no; DISPATCH list; Stephen Botzko Subject: Re: [RTW] Rate control and codec adaption (Re: [dispatch] The charter formerly know as RTC-WEB take 3) RTCP typically isn't sent frequently enough to allow for real-time adjustments in bitrate. TFRC provides a nice mechanism for controlling bitrate in real-time, but the work to apply TFRC to RTP has not yet been codified into a standard. There was a draft but it has been abandonded ( <http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10> http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10) On Thu, Jan 20, 2011 at 11:50 PM, Stefan Håkansson LK < <mailto:stefan.lk.hakansson@ericsson.com> stefan.lk.hakansson@ericsson.com> wrote: My view: we are discussing a problem already solved! The common procedure would be to use info in the RTCP reports from the receiving end to change the transmitted bit rate (if change is required). _____ From: Harald Alvestrand [mailto: <mailto:harald@alvestrand.no> harald@alvestrand.no] Sent: den 21 januari 2011 08:46 To: Henry Sinnreich Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; <mailto:rtc-web@alvestrand.no> rtc-web@alvestrand.no; DISPATCH list Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3) On 01/21/2011 12:06 AM, Henry Sinnreich wrote:
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.
It is not clear to me how to avoid the codec adaptation mechanism fighting the rate control mechanism, without some guidance in the standard for developers. Can you explain? Changing the subject to content of thread.... are we reducing to a previously solved problem, or to a previously unsolved problem? I don't see how this problem actually differs from the one that people will have when operating RTP under TFRC (draft-ietf-avt-tfrc-profile-10). Thanks, Henry On 1/20/11 2:02 PM, "Stefan Håkansson LK" < <http://stefan.lk.hakansson@ericsson.com/> stefan.lk.hakansson@ericsson.com> wrote: 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. Br, Stefan _____ From: Stephen Botzko [ <mailto:stephen.botzko@gmail.com> mailto:stephen.botzko@gmail.com] Sent: den 20 januari 2011 16:45 To: Henry Sinnreich Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; <http://rtc-web@alvestrand.no/> rtc-web@alvestrand.no Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3
How does this fit with adaptive codecs?
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.
Hint: codec selection matters, is actually critical to this effort.
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.
Stephen Botzko On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich < <http://henry.sinnreich@gmail.com/> henry.sinnreich@gmail.com> wrote: Hi Stefan,
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.
How does this fit with adaptive codecs? Hint: codec selection matters, is actually critical to this effort. Thanks, Henry On 1/20/11 3:52 AM, "Stefan Håkansson LK" < <http://stefan.lk.hakansson@ericsson.com/> stefan.lk.hakansson@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".
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: <http://dispatch-bounces@ietf.org/> dispatch-bounces@ietf.org [ <mailto: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: <http://rtc-web@alvestrand.no/> 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 be
_______________________________________________ RTC-Web mailing list <mailto:RTC-Web@alvestrand.no> RTC-Web@alvestrand.no <http://www.alvestrand.no/mailman/listinfo/rtc-web> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list <mailto:RTC-Web@alvestrand.no> RTC-Web@alvestrand.no <http://www.alvestrand.no/mailman/listinfo/rtc-web> http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web -- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 <tel:+390805963621> Fax. +39 080 5963410 <tel:+390805963410> email:mascolo@poliba.it <mailto:email%3Amascolo@poliba.it> http://c3lab.poliba.it <http://c3lab.poliba.it/> ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden. _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web -- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it <mailto:email%3Amascolo@poliba.it> http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
Howdy, On Thu, Jan 20, 2011 at 1:52 AM, Stefan Håkansson LK <stefan.lk.hakansson@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@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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi! Honestly I don't know what CONNEG is. I was after 1. One API where the application (implemented in JS) can query what media formats that are supported 2. The possibility to define the media format to be used when setting up a stream (via an API) With the info acquired with 1. the capabilties of the two peers can be exchanged, and formats can be negotiated. Exactly how this is done is probably out of scope of RTC-Web, at least initially (but maybe there could be some kind of industry standard on how to do this to make interop easier). Note that it is not only to select codec when you set up the stream. You would need to define e.g. framerate, resolution, bitrate, ... I also think that it would be an advantage if the format of the data acquired in 1. is easy to translate to an SDP as described in Section 6 of http://datatracker.ietf.org/doc/draft-alvestrand-dispatch-rtcweb-protocols/?... Br, Stefan
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: den 20 januari 2011 17:58 To: Stefan Håkansson LK Cc: Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Howdy,
On Thu, Jan 20, 2011 at 1:52 AM, Stefan Håkansson LK <stefan.lk.hakansson@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@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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Howdy, Some comments in-line. On Thu, Jan 20, 2011 at 11:59 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
Hi!
Honestly I don't know what CONNEG is.
In the SIP case, starting with http://tools.ietf.org/html/rfc3840 is probably best; it relies on http://tools.ietf.org/html/rfc2703 & friends. Basically, it is a set-interaction content negotiation system where each side declares capabilities and the q-factors for those capabilities, and the best ranked choice from the resulting intersection becomes the basis for further communication. I was after
1. One API where the application (implemented in JS) can query what media formats that are supported 2. The possibility to define the media format to be used when setting up a stream (via an API)
So, it's not entirely clear to me from what is written above whether you mean JS queries the system its resident on for its capabilities (so it can select one) or whether it queries the capabilities of the system with which it is interacting. Can you clarify? regards, Ted Hardie
With the info acquired with 1. the capabilties of the two peers can be exchanged, and formats can be negotiated. Exactly how this is done is probably out of scope of RTC-Web, at least initially (but maybe there could be some kind of industry standard on how to do this to make interop easier).
Note that it is not only to select codec when you set up the stream. You would need to define e.g. framerate, resolution, bitrate, ...
I also think that it would be an advantage if the format of the data acquired in 1. is easy to translate to an SDP as described in Section 6 of http://datatracker.ietf.org/doc/draft-alvestrand-dispatch-rtcweb-protocols/?...
Br, Stefan
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: den 20 januari 2011 17:58 To: Stefan Håkansson LK Cc: Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Howdy,
On Thu, Jan 20, 2011 at 1:52 AM, Stefan Håkansson LK <stefan.lk.hakansson@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@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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi, I meant that JS queries the system it is resident on for its capabilities. This information can then be sent to the system it is interacting with (the peer) so that it, after getting the response from the peer, can select one! Br, Stefan
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: den 20 januari 2011 23:43 To: Stefan Håkansson LK Cc: Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Howdy,
Some comments in-line.
On Thu, Jan 20, 2011 at 11:59 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
Hi!
Honestly I don't know what CONNEG is.
In the SIP case, starting with http://tools.ietf.org/html/rfc3840 is probably best; it relies on http://tools.ietf.org/html/rfc2703 & friends. Basically, it is a set-interaction content negotiation system where each side declares capabilities and the q-factors for those capabilities, and the best ranked choice from the resulting intersection becomes the basis for further communication.
I was after
1. One API where the application (implemented in JS) can query what media formats that are supported 2. The possibility to define the media format to be used when setting up a stream (via an API)
So, it's not entirely clear to me from what is written above whether you mean JS queries the system its resident on for its capabilities (so it can select one) or whether it queries the capabilities of the system with which it is interacting.
Can you clarify?
regards,
Ted Hardie
With the info acquired with 1. the capabilties of the two peers can be exchanged, and formats can be negotiated. Exactly how this is done is probably out of scope of RTC-Web, at least initially (but maybe there could be some kind of industry standard on how to do this to make interop easier).
Note that it is not only to select codec when you set up the stream. You would need to define e.g. framerate, resolution, bitrate, ...
I also think that it would be an advantage if the format of the data acquired in 1. is easy to translate to an SDP as described in Section 6 of
http://datatracker.ietf.org/doc/draft-alvestrand-dispatch-rtcweb-proto
cols/?include_text=1
Br, Stefan
-----Original Message----- From: Ted Hardie [mailto:ted.ietf@gmail.com] Sent: den 20 januari 2011 17:58 To: Stefan Håkansson LK Cc: Cullen Jennings; DISPATCH list; rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3
Howdy,
On Thu, Jan 20, 2011 at 1:52 AM, Stefan Håkansson LK <stefan.lk.hakansson@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@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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
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@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@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
+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@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@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@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@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Hi, Thank you Cullen to expose openly the situation. I agree that discussion must go on on this topic and that the goal is to find a consensus between already in place solutions and programmability of the RTC web solution (from my personal analysis, this being reachable with lower enough APIs in the browser). Still I would like to raise another point which is somehow related to Henry's remark: The charter does not explicitly mention the compatibility with "legacy" VoIP networks/handsets. It is only suggested when saying that: the work will define a solution to "have interactive real time voice and video pairwise between browsers or other devices using RTP" Wherever the discussion on protocols (sig and media) goes, I suggest the working group to keep as a major objective to produce something which is compatible with voice and video systems that are not web based. This compatibility begins with RTP/RTCP usage...as already mentioned in the charter... but this should be stated more explicitly to avoid the group to design an incompatible or complex to interoperate with solution. Harald's proposal was clearer on this point with the mention of: [...] This working group will select and define a minimal set of protocols that will enable browsers to: [...] * interoperate with compatible voice and video systems that are not web based [...] PS: my 2 cents on group naming, +1 to RTCWEB Regards, Jean-François -----Message d'origine----- De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la part de Henry Sinnreich Envoyé : jeudi 27 janvier 2011 06:45 À : Cullen Jennings; MARJOU Xavier RD-CORE-LAN Cc : rtc-web@alvestrand.no; DISPATCH list; Kundan Singh Objet : Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3 +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@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@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@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@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group." I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH). /a
+1 Henry On 1/27/11 9:18 AM, "Adam Roach" <adam@nostrum.com> wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
/a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
+1 Peter Musgrave On 2011-01-27, at 10:18 AM, Adam Roach wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
/a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Ah SIP! Seriously, you need more words to indicate the restriction of such a development to the particular use case for the working group. Regards Keith -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: 27 January 2011 15:19 To: Cullen Jennings Cc: rtc-web@alvestrand.no; DISPATCH list; Xavier Marjou Subject: Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3 On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group." I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH). /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Hi, Adam Roach wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
I think the question at this point is that what aspects of the media session establishment and control *need* to be standardized. Some people think that we have to either pick a concrete protocol like SIP/SDP or XMPP/Jingle or design something new but similar on top of HTTP or WebSocket. Other people seem to think that most of this should actually be outside the scope of the charter, and it is enough that we just standardize the media transport related "enablers" within the browser. Each application/service could then pick/design its own method of establishing the media sessions, on top of HTTP or WebSocket. The first option (choose/design a single common protocol) would have at least four main advantages: 1. There would be no need to re-invent it for each service 2. Inter-service/domain interoperability would be more straightforward 3. Interconnect to SIP/PSTN/Jingle services would be more straightforward 4. The service provider could buy/download and use an existing SIP or XMPP server (The concrete problem with SIP would be, as we are aware of, that it would not suffice to just declare that we use SIP, but we would have to do a lot of profiling within SIP/SDP itself to ensure enough interoperability. I believe Jingle is more monolithic and easier to handle in this sense.) The more liberal approach (let anyone do their own protocol) would probably be easier to get done in IETF, and would still allow service providers to get their services working across browsers. The need for reinventing a protocol for each service could perhaps be mitigated by reusing JavaScript libraries (a la Comet stuff today). Inter-domain/service interop would happen via SIP/XMPP gateways (but end-to-end media could be a challenge). What I worry a bit in this approach is that it might mean that only big/resourceful service providers who know a lot about the technical stuff could build services, while the ones with perhaps innovative services but little technical clue could be left behind (which the big providers present in this work would not necessarily mind). But I don't really know how the service provider scene would be with the browser RTC. From a device/browser vendor perspective my goal would be to make service creation and deployment as easy as possible. I would see this as a bottom up approach that we should first focus on the media transport and NAT traversal issues that everyone agrees are needed, and as those start to shape up, look at the session establishment needs. It could be a phased approach that the browsers first only implement the media support and may add a common setup protocol later on based on the need. Markus
I believe Jingle is more monolithic and easier to handle in this sense.)
This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it. Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they? Let's leave the API out for scope. Thanks, Henry On 1/27/11 10:15 AM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:
Hi,
Adam Roach wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
I think the question at this point is that what aspects of the media session establishment and control *need* to be standardized. Some people think that we have to either pick a concrete protocol like SIP/SDP or XMPP/Jingle or design something new but similar on top of HTTP or WebSocket. Other people seem to think that most of this should actually be outside the scope of the charter, and it is enough that we just standardize the media transport related "enablers" within the browser. Each application/service could then pick/design its own method of establishing the media sessions, on top of HTTP or WebSocket.
The first option (choose/design a single common protocol) would have at least four main advantages: 1. There would be no need to re-invent it for each service 2. Inter-service/domain interoperability would be more straightforward 3. Interconnect to SIP/PSTN/Jingle services would be more straightforward 4. The service provider could buy/download and use an existing SIP or XMPP server
(The concrete problem with SIP would be, as we are aware of, that it would not suffice to just declare that we use SIP, but we would have to do a lot of profiling within SIP/SDP itself to ensure enough interoperability. I believe Jingle is more monolithic and easier to handle in this sense.)
The more liberal approach (let anyone do their own protocol) would probably be easier to get done in IETF, and would still allow service providers to get their services working across browsers. The need for reinventing a protocol for each service could perhaps be mitigated by reusing JavaScript libraries (a la Comet stuff today). Inter-domain/service interop would happen via SIP/XMPP gateways (but end-to-end media could be a challenge). What I worry a bit in this approach is that it might mean that only big/resourceful service providers who know a lot about the technical stuff could build services, while the ones with perhaps innovative services but little technical clue could be left behind (which the big providers present in this work would not necessarily mind). But I don't really know how the service provider scene would be with the browser RTC. From a device/browser vendor perspective my goal would be to make service creation and deployment as easy as possible.
I would see this as a bottom up approach that we should first focus on the media transport and NAT traversal issues that everyone agrees are needed, and as those start to shape up, look at the session establishment needs. It could be a phased approach that the browsers first only implement the media support and may add a common setup protocol later on based on the need.
Markus _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Hi Henry, Henry Sinnreich wrote:
I believe Jingle is more monolithic and easier to handle in this sense.)
This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it.
If by 3rd option you mean that the RTC-Web effort would produce its own specific session establishment protocol, I tend to agree with you. If we think a standardized session establishment protocol is needed, we should take an existing one, and at maximum just worry how it can be transported over HTTP or WebSocket (that may be a valid requirement).
Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they?
Let's leave the API out for scope.
To be clear: Are you saying that we should *not* have the session establishment protocol included in the charter? Or which API do you mean? Because in your earlier mail you supported Adam's suggestion:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Which says that the session establishment protocol is within the scope of the work. And if it is, the associated API will surely be defined on the W3C side.
Thanks, Henry
Markus
Hi Markus, Quoting Adam:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Given the overwhelming deployment of SIP for voice and much video as well, a SIP API is IMO the 1st choice of instantiation for an API. As for IM and chat, quite frankly, it is pure data and not real time media as is the focus here. IM and chat has been around on the Internet in many forms for a long time using various protocols. If we have to chose between two evils: No IM API for now or the double complexity of SIP+XMPP stack emulations in the application scripts, I would rather go without any until the market and especially innovation makes such as decision for us. Here is really an instance where kicking the can down the road makes a lot of sense. Who knows, maybe later social and virtual world protocols may change the picture altogether... Disclaimer: I still think SIMPLE/SIP makes it really simple and works well enough for the simple (no pun intended) usage scenarios considered here for RTC-Web. Thanks, Henry On 1/27/11 2:07 PM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:
Hi Henry,
Henry Sinnreich wrote:
I believe Jingle is more monolithic and easier to handle in this sense.)
This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it.
If by 3rd option you mean that the RTC-Web effort would produce its own specific session establishment protocol, I tend to agree with you. If we think a standardized session establishment protocol is needed, we should take an existing one, and at maximum just worry how it can be transported over HTTP or WebSocket (that may be a valid requirement).
Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they?
Let's leave the API out for scope.
To be clear: Are you saying that we should *not* have the session establishment protocol included in the charter? Or which API do you mean? Because in your earlier mail you supported Adam's suggestion:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Which says that the session establishment protocol is within the scope of the work. And if it is, the associated API will surely be defined on the W3C side.
Thanks, Henry
Markus
+1 Erik Lagerway On Fri, Jan 28, 2011 at 1:12 PM, Henry Sinnreich <henry.sinnreich@gmail.com>wrote:
Hi Markus,
Quoting Adam:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Given the overwhelming deployment of SIP for voice and much video as well, a SIP API is IMO the 1st choice of instantiation for an API.
As for IM and chat, quite frankly, it is pure data and not real time media as is the focus here. IM and chat has been around on the Internet in many forms for a long time using various protocols.
If we have to chose between two evils: No IM API for now or the double complexity of SIP+XMPP stack emulations in the application scripts, I would rather go without any until the market and especially innovation makes such as decision for us.
Here is really an instance where kicking the can down the road makes a lot of sense. Who knows, maybe later social and virtual world protocols may change the picture altogether...
Disclaimer: I still think SIMPLE/SIP makes it really simple and works well enough for the simple (no pun intended) usage scenarios considered here for RTC-Web.
Thanks, Henry
On 1/27/11 2:07 PM, "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com> wrote:
Hi Henry,
Henry Sinnreich wrote:
I believe Jingle is more monolithic and easier to handle in this sense.)
This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it.
If by 3rd option you mean that the RTC-Web effort would produce its own specific session establishment protocol, I tend to agree with you. If we think a standardized session establishment protocol is needed, we should take an existing one, and at maximum just worry how it can be transported over HTTP or WebSocket (that may be a valid requirement).
Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they?
Let's leave the API out for scope.
To be clear: Are you saying that we should *not* have the session establishment protocol included in the charter? Or which API do you mean? Because in your earlier mail you supported Adam's suggestion:
"The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
Which says that the session establishment protocol is within the scope of the work. And if it is, the associated API will surely be defined on the W3C side.
Thanks, Henry
Markus
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Changing the subject as is my habit.... forgive the introductory philosophical distraction. I tend to look at success criteria, and if we need to achieve something to achieve success. If we fail unless we do this work, it MUST be done. If we can succeed without doing this work, it does not have to be done. If we can succeed only if someone else does this work, we need to make sure that other thing also gets done (the classical example here is Javascript APIs for the functions we make available). In this case, I define success (for myself - YMMV) as "browsers ship with well defined, usable functionality that allows audio and video communication between applications running as web pages in those browsers". More functionality (including legacy device interoperability with gateways only in the signalling path) is nice to have, but not essential for me to decide that we have succeeded. The charter is a description of what work is to be done in this WG of the IETF. If the IETF includes a signalling stack in the specification, it helps achieve the goal. But it's not essential, because those bits go across a wire that (likely) points in the direction of webservers that the pages load from, and those webservers can do signalling intermediation as needed. What IS essential is that the semantics (not the syntax) of the information needed to establish the connections between the browsers is known and documented - because otherwise, the goal can't be achieved. I'd be happy if the charter defined somewhat weaselly words like "Describe the information that must be exchanged between the endpoints in order to establish connectivity, and optionally describe how this information can be represented using existing signalling protocols". But I wouldn't be happy with a charter that said "put SIP or XMPP in the browser". It's not necessary for success, so I don't want to be bound to doing it. On 01/27/11 10:08, Henry Sinnreich wrote:
I believe Jingle is more monolithic and easier to handle in this sense.) This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it.
Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they?
Let's leave the API out for scope.
Thanks, Henry
On 1/27/11 10:15 AM, "Markus.Isomaki@nokia.com"<Markus.Isomaki@nokia.com> wrote:
Hi,
Adam Roach wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
I think the question at this point is that what aspects of the media session establishment and control *need* to be standardized. Some people think that we have to either pick a concrete protocol like SIP/SDP or XMPP/Jingle or design something new but similar on top of HTTP or WebSocket. Other people seem to think that most of this should actually be outside the scope of the charter, and it is enough that we just standardize the media transport related "enablers" within the browser. Each application/service could then pick/design its own method of establishing the media sessions, on top of HTTP or WebSocket.
The first option (choose/design a single common protocol) would have at least four main advantages: 1. There would be no need to re-invent it for each service 2. Inter-service/domain interoperability would be more straightforward 3. Interconnect to SIP/PSTN/Jingle services would be more straightforward 4. The service provider could buy/download and use an existing SIP or XMPP server
(The concrete problem with SIP would be, as we are aware of, that it would not suffice to just declare that we use SIP, but we would have to do a lot of profiling within SIP/SDP itself to ensure enough interoperability. I believe Jingle is more monolithic and easier to handle in this sense.)
The more liberal approach (let anyone do their own protocol) would probably be easier to get done in IETF, and would still allow service providers to get their services working across browsers. The need for reinventing a protocol for each service could perhaps be mitigated by reusing JavaScript libraries (a la Comet stuff today). Inter-domain/service interop would happen via SIP/XMPP gateways (but end-to-end media could be a challenge). What I worry a bit in this approach is that it might mean that only big/resourceful service providers who know a lot about the technical stuff could build services, while the ones with perhaps innovative services but little technical clue could be left behind (which the big providers present in this work would not necessarily mind). But I don't really know how the service provider scene would be with the browser RTC. From a device/browser vendor perspective my goal would be to make service creation and deployment as easy as possible.
I would see this as a bottom up approach that we should first focus on the media transport and NAT traversal issues that everyone agrees are needed, and as those start to shape up, look at the session establishment needs. It could be a phased approach that the browsers first only implement the media support and may add a common setup protocol later on based on the need.
Markus _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Howdy, A question in-line. On Fri, Jan 28, 2011 at 7:38 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
Changing the subject as is my habit.... forgive the introductory philosophical distraction.
I tend to look at success criteria, and if we need to achieve something to achieve success.
If we fail unless we do this work, it MUST be done. If we can succeed without doing this work, it does not have to be done. If we can succeed only if someone else does this work, we need to make sure that other thing also gets done (the classical example here is Javascript APIs for the functions we make available).
In this case, I define success (for myself - YMMV) as "browsers ship with well defined, usable functionality that allows audio and video communication between applications running as web pages in those browsers". More functionality (including legacy device interoperability with gateways only in the signalling path) is nice to have, but not essential for me to decide that we have succeeded.
The charter is a description of what work is to be done in this WG of the IETF.
If the IETF includes a signalling stack in the specification, it helps achieve the goal. But it's not essential, because those bits go across a wire that (likely) points in the direction of webservers that the pages load from, and those webservers can do signalling intermediation as needed.
I have described this in the past as a case in which the webserver is the signal path, but your description of "signaling intermediation" sounds more ambitious. In particular, do you mean that it might use different syntax with different clients, using this shared semantics?
What IS essential is that the semantics (not the syntax) of the information needed to establish the connections between the browsers is known and documented - because otherwise, the goal can't be achieved.
Huh. If we have an API at the client side and known semantics for establishing the connections, isn't the easiest way to connect those two a standard protocol syntax for taking the API-expressed desired and signaling it to the intermediating web server?
I'd be happy if the charter defined somewhat weaselly words like "Describe the information that must be exchanged between the endpoints in order to establish connectivity, and optionally describe how this information can be represented using existing signalling protocols".
So, I may just be confused here. Are you saying that we do define RTW syntax as well as semantics used here, and optionally describe a mapping to SIP/XMPP? Or are you saying that we describe only the semantics and optionally define the mapping to signaling protocols. To my ears, it sounds like you mean the second, but the first makes much more sense, as it is difficult to see how we get full interoperability with only a semantics description as a deliverable.
But I wouldn't be happy with a charter that said "put SIP or XMPP in the browser". It's not necessary for success, so I don't want to be bound to doing it.
Each also does many other things, so I agree. But if someone wants to implement as: [RTW API] [Inbound mapping to signaling protocol] [Sip/XMPP] [Outbound mapping to RTW-syntax] then the way they got to the RTW-syntax is no one's affair but their own, right? best regards, Ted Hardie
On 01/27/11 10:08, Henry Sinnreich wrote:
I believe Jingle is more monolithic and easier to handle in this sense.)
This adds even more to the endless discussions of SIP vs. Jingle, actually it also adds a 3rd option and folks who have implemented SIP/SIMPLE may or may not be happy about it.
Bottom line: Adding a 3rd option to the signaling will bog down the RTC-Web work even more. The API should be a separate effort. Oh, the discussions there... Don't expect anyone there to give in easily :-), and why can/should they?
Let's leave the API out for scope.
Thanks, Henry
On 1/27/11 10:15 AM, "Markus.Isomaki@nokia.com"<Markus.Isomaki@nokia.com> wrote:
Hi,
Adam Roach wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it
seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
I think the question at this point is that what aspects of the media session establishment and control *need* to be standardized. Some people think that we have to either pick a concrete protocol like SIP/SDP or XMPP/Jingle or design something new but similar on top of HTTP or WebSocket. Other people seem to think that most of this should actually be outside the scope of the charter, and it is enough that we just standardize the media transport related "enablers" within the browser. Each application/service could then pick/design its own method of establishing the media sessions, on top of HTTP or WebSocket.
The first option (choose/design a single common protocol) would have at least four main advantages: 1. There would be no need to re-invent it for each service 2. Inter-service/domain interoperability would be more straightforward 3. Interconnect to SIP/PSTN/Jingle services would be more straightforward 4. The service provider could buy/download and use an existing SIP or XMPP server
(The concrete problem with SIP would be, as we are aware of, that it would not suffice to just declare that we use SIP, but we would have to do a lot of profiling within SIP/SDP itself to ensure enough interoperability. I believe Jingle is more monolithic and easier to handle in this sense.)
The more liberal approach (let anyone do their own protocol) would probably be easier to get done in IETF, and would still allow service providers to get their services working across browsers. The need for reinventing a protocol for each service could perhaps be mitigated by reusing JavaScript libraries (a la Comet stuff today). Inter-domain/service interop would happen via SIP/XMPP gateways (but end-to-end media could be a challenge). What I worry a bit in this approach is that it might mean that only big/resourceful service providers who know a lot about the technical stuff could build services, while the ones with perhaps innovative services but little technical clue could be left behind (which the big providers present in this work would not necessarily mind). But I don't really know how the service provider scene would be with the browser RTC. From a device/browser vendor perspective my goal would be to make service creation and deployment as easy as possible.
I would see this as a bottom up approach that we should first focus on the media transport and NAT traversal issues that everyone agrees are needed, and as those start to shape up, look at the session establishment needs. It could be a phased approach that the browsers first only implement the media support and may add a common setup protocol later on based on the need.
Markus _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On 01/28/11 10:29, Ted Hardie wrote:
Howdy,
A question in-line.
On Fri, Jan 28, 2011 at 7:38 AM, Harald Alvestrand<harald@alvestrand.no> wrote:
Changing the subject as is my habit.... forgive the introductory philosophical distraction.
I tend to look at success criteria, and if we need to achieve something to achieve success.
If we fail unless we do this work, it MUST be done. If we can succeed without doing this work, it does not have to be done. If we can succeed only if someone else does this work, we need to make sure that other thing also gets done (the classical example here is Javascript APIs for the functions we make available).
In this case, I define success (for myself - YMMV) as "browsers ship with well defined, usable functionality that allows audio and video communication between applications running as web pages in those browsers". More functionality (including legacy device interoperability with gateways only in the signalling path) is nice to have, but not essential for me to decide that we have succeeded.
The charter is a description of what work is to be done in this WG of the IETF.
If the IETF includes a signalling stack in the specification, it helps achieve the goal. But it's not essential, because those bits go across a wire that (likely) points in the direction of webservers that the pages load from, and those webservers can do signalling intermediation as needed.
I have described this in the past as a case in which the webserver is the signal path, but your description of "signaling intermediation" sounds more ambitious. In particular, do you mean that it might use different syntax with different clients, using this shared semantics? That's one possibility. It might also do a similar function to what I think the SIP SBC does, and do address rewriting, stop stuff it doesn't like, or generally do like gateways do (that is, whatever it wants to). But as long as that behaviour doesn't have to be described in the spec to make things work, I think it should be outside of the scope of the working group.
What IS essential is that the semantics (not the syntax) of the information needed to establish the connections between the browsers is known and documented - because otherwise, the goal can't be achieved.
Huh. If we have an API at the client side and known semantics for establishing the connections, isn't the easiest way to connect those two a standard protocol syntax for taking the API-expressed desired and signaling it to the intermediating web server? Yep. But just over the last 2 days, I've heard people shuddering at the idea of SIP/SDP, sneering at the idea of an XML-based format, and contemplating over the idea of a JSON-based format. There will be a long discussion on what to choose, if we have to choose.
I'd be happy if the charter defined somewhat weaselly words like "Describe the information that must be exchanged between the endpoints in order to establish connectivity, and optionally describe how this information can be represented using existing signalling protocols".
So, I may just be confused here. Are you saying that we do define RTW syntax as well as semantics used here, and optionally describe a mapping to SIP/XMPP? Or are you saying that we describe only the semantics and optionally define the mapping to signaling protocols. To my ears, it sounds like you mean the second, but the first makes much more sense, as it is difficult to see how we get full interoperability with only a semantics description as a deliverable. I'm saying that I think we have to describe the semantics, and I'd like to not prejudge the question of syntax.
But I wouldn't be happy with a charter that said "put SIP or XMPP in the browser". It's not necessary for success, so I don't want to be bound to doing it. Each also does many other things, so I agree. But if someone wants to implement as:
[RTW API] [Inbound mapping to signaling protocol] [Sip/XMPP] [Outbound mapping to RTW-syntax]
then the way they got to the RTW-syntax is no one's affair but their own, right? Agreed.
On Fri, Jan 28, 2011 at 3:59 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
I have described this in the past as a case in which the webserver is the signal path, but your description of "signaling intermediation" sounds more ambitious. In particular, do you mean that it might use different syntax with different clients, using this shared semantics?
That's one possibility. It might also do a similar function to what I think the SIP SBC does, and do address rewriting, stop stuff it doesn't like, or generally do like gateways do (that is, whatever it wants to). But as long as that behaviour doesn't have to be described in the spec to make things work, I think it should be outside of the scope of the working group.
I think a core scope question, then, is how complete the APIs to control the behavior of the web-server-as-intermediary need to be? If the working group expects the web server to act as session border controller, do those semantics (especially for QoS and security) get exposed and described by the WG? best regards, Ted Hardie
Hi, Ted Hardie wrote:
On Fri, Jan 28, 2011 at 7:38 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
If the IETF includes a signalling stack in the specification, it helps achieve the goal. But it's not essential, because those bits go across
a
wire that (likely) points in the direction of webservers that the pages load from, and those webservers can do signalling intermediation as needed.
I have described this in the past as a case in which the webserver is the signal path, but your description of "signaling intermediation" sounds more ambitious. In particular, do you mean that it might use different syntax with different clients, using this shared semantics?
I would find it weird if the web server would *want* to do this between browser clients that it is serving. It would seem easiest to use the same protocol for every browser client, and just act as a "signaling proxy". Assuming something like STUN/ICE were used, the web server would not need to deal with NAT traversal issues either. But where the web server may need to do "signaling intermediation" is towards other providers/domains or e.g. native SIP or XMPP clients served in the same domain. If we believe in a world of lot of interconnected providers/domains, that "server-server" interface needs a common standard. For VoIP/video, SIP is a natural choice, while for IM/presence XMPP is the de facto. However, I believe that side is out of scope of the RTC-Web work. If we again assume the use of STUN/ICE and want e2e media across providers/domains, we have to assume that it is possible to map the necessary information on the signaling path: Browser A <-> provider1-protocol <-> SIP/Jingle <-> provider2-protocol <-> Browser B, so that Browser A and B can get the media path up. Is that doable and if we leave the session setup protocol completely open, is there *something* that we can do to make that easier? Some people have talked about defining session setup protocol semantics but not syntax for this purpose. Markus
On Jan 28, 2011, at 1:15 , markus.isomaki@nokia.com wrote:
Hi,
Adam Roach wrote:
On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group."
I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH).
I think the question at this point is that what aspects of the media session establishment and control *need* to be standardized.
I would hope, as I have said before, we standardize at two levels. A) a framework, with clear interfaces, that hangs together (e.g., in this case, 'a session initiation protocol goes here'). B) instantiations within that framework that make at least one working system. I don't want the framework to assume "only XXXX is ever going to be used in this context" even if XXX is the only instantiation of one the modules David Singer Multimedia and Software Standards, Apple Inc.
+1 Regards Jean-François Jestin -----Message d'origine----- De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la part de Adam Roach Envoyé : jeudi 27 janvier 2011 16:19 À : Cullen Jennings Cc : rtc-web@alvestrand.no; DISPATCH list; MARJOU Xavier RD-CORE-LAN Objet : Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3 On 1/26/11 8:04 PM, Cullen Jennings wrote:
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
I would imagine something along these lines would put the topic to rest: "The selection, design and/or extension of a protocol or protocols for establishing and controlling media sessions is in scope for the working group." I think it's a lot better than remaining silent on the topic, since it leaves several avenues open to the working group. We really don't want to get part of the way down this path with people under the misimpression that we *must* design a new protocol, or that we *must* select an existing protocol. I think we should do whichever of these makes the most sense after a careful analysis, and that such analysis is best performed by the working group (not in DISPATCH). /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
participants (23)
-
Adam Roach -
Alex Eleftheriadis -
Cullen Jennings -
David Singer -
DRAGE, Keith (Keith) -
Erik Lagerway -
Harald Alvestrand -
Henry Sinnreich -
jeanfrancois.jestin＠orange-ftgroup.com -
Justin Uberti -
Magnus Westerlund -
Markus.Isomaki＠nokia.com -
Marshall Eubanks -
Peter Musgrave -
Richard Shockey -
Rosenberg, Jonathan -
Saverio Mascolo -
Soo-Hyun Choi -
Stefan Håkansson LK -
Stephen Botzko -
Ted Hardie -
tom_harper＠logitech.com -
Xavier Marjou