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

From: Cullen Jennings <[email-masked]>
Date: Mon, 17 Jan 2011 21:58:38 -0700

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.

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 18 Jan 2011 08:43:46 -0500

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:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jan 2011 08:27:21 -0600

> 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…

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

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 18 Jan 2011 09:38:45 -0500

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:

> 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
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: Alex Eleftheriadis <[email-masked]>
Date: Tue, 18 Jan 2011 10:00:12 -0500

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

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 18 Jan 2011 10:07:02 -0500

> 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

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 18 Jan 2011 11:20:30 -0600

+1

Thanks, Henry

On 1/18/11 8:27 AM, "Adam Roach" <[email-masked]> 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.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Jan 2011 13:28:54 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Marshall Eubanks
Sent: Tuesday, January 18, 2011 10:07 AM
To: Alex Eleftheriadis
Cc: [email-masked]; 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. 

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.
>> 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?
>>>> 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.
>>> 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.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Jan 2011 16:16:06 +0100

Hi,

A simple comment in this email.

> 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 som…

This name is already taken, there is an active TSV WG called STORM that
works on Storage Specifications.

-- 

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: [email-masked]
----------------------------------------------------------------------

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 20 Jan 2011 10:52:32 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: den 18 januari 2011 05:59
> To: DISPATCH list
> Cc: [email-masked]
> 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 
> 
> 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:
> 
> 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
> 
> 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:
>

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 20 Jan 2011 09:37:04 -0600

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" <[email-masked]>
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
>

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 20 Jan 2011 10:45:04 -0500

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.

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 <[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Jan 2011 08:58:12 -0800

Howdy,

> 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 negot…

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 20 Jan 2011 20:59:37 +0100

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/?include_text=1

Br,
Stefan

> From: Ted Hardie [mailto:[email-masked]] 
> Sent: den 20 januari 2011 17:58
> To: Stefan Håkansson LK
> Cc: Cullen Jennings; DISPATCH list; [email-masked]
> Subject: Re: [RTW] [dispatch] The charter formerly know as 
> RTC-WEB take 3
> 
> Howdy,
> 
> > 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
> >
> 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
> >>
> >> WAVVE: Web And Voice Video Enablement REALTIME WEBCOMM WREALTIME 
> >> WEBTIME WEBFLOWS BRAVO  Browser Realtime Audio and VideO COBWEB 
> >> COmmuication Between WEBclients WHEELTIME
> >>
> >>
> >>
> >> Body:
> >>
> >> 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.
> >>
> >> 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
> >>
> >> 3) a baseline audio codec for PSTN interoperability. G.711 
> and iLBC 
> >> will
> >> 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.
> >>
> 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.
> >>
> spirit of BCP 
> >> 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:
> >>
> >> Aug 2011 WG draft with text reflecting agreement of what 
> the profile 
> >> set
> >>          should be
> >>
> >> Nov 2011 Documentation specifying mapping of protocol 
> functionality 
> >> to

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 20 Jan 2011 21:02:58 +0100

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:[email-masked]]
Sent: den 20 januari 2011 16:45
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Cullen Jennings; DISPATCH list; [email-masked]
Subject: Re: [dispatch] The charter formerly know as RTC-WEB take 3

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.

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stefan,

Thanks, Henry

On 1/20/11 3:52 AM, "Stefan Håkansson LK" <[email-masked]<mailto:[email-masked]>>
wrote:

>> From: [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Cullen Jennings
>> Cc: [email-masked]<mailto:[email-masked]>
>> and iLBC will
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ted Hardie <[email-masked]>
Date: Thu, 20 Jan 2011 14:42:33 -0800

Howdy,

Some comments in-line.

On Thu, Jan 20, 2011 at 11:59 AM, Stefan Håkansson LK
<[email-masked]> 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
> 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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 20 Jan 2011 17:06:16 -0600

>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" <[email-masked]>
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
> 
>>  
>>  
>> 
>> On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <[email-masked]>
>> wrote:
>>  
>>> Hi  Stefan,
>>>  
>>> 
>>>>> >> * have interactive real time voice and video  pairwise be

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 21 Jan 2011 08:46:22 +0100

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" 
>     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:[email-masked]]
>         *Sent:* den 20 januari 2011  16:45
>         *To:* Henry Sinnreich
>         *Cc:* Stefan Håkansson LK; Cullen  Jennings; DISPATCH list;
>         [email-masked]
>         *Subject:* Re:  [dispatch] The charter formerly know as
>         RTC-WEB take 3
>
>
>         >>>
>         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.
>
>         >>>
>         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
>         <[email-masked]>  wrote:
>
>             Hi  Stefan,
>
>
>              control. It is not
>             control. It is not

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 21 Jan 2011 08:47:05 +0100

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

> Sent: den 20 januari 2011 23:43
> To: Stefan Håkansson LK
> 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
> >
> >> Subject: Re: [RTW] [dispatch] The charter formerly know as RTC-WEB 
> >> take 3
> >>
> >> Howdy,
> >>
> support media 
> >> format negotiation. Proposal: "The API must enable media format 
> >> negotiation and application influence over media format selection".
> >> >
> >>
> >> 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
> >>
> >>
> >> 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
> >> >
> standardize 
> traditional 
> protocols,

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 21 Jan 2011 08:50:18 +0100

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:[email-masked]]
Sent: den 21 januari 2011 08:46
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; [email-masked]; DISPATCH list
Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)

>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" <[email-masked]> wrote:

Br,
Stefan

Stephen  Botzko

On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <[email-masked]>  wrote:

Hi  Stefan,

Thanks, Henry

_______________________________________________
RTC-Web mailing list
[email-masked]<mailto:[email-masked]>
http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: Justin Uberti <[email-masked]>
Date: Fri, 21 Jan 2011 00:12:32 -0800

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 <
[email-masked]> 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:[email-masked]]
> *Sent:* den 21 januari 2011 08:46
> *To:* Henry Sinnreich
> *Cc:* Stefan Håkansson LK; Stephen Botzko; Cullen Jennings;
> [email-masked]; DISPATCH list
> *Subject:* Rate control and codec adaption (Re: [RTW] [dispatch] The
> charter formerly know as RTC-WEB take 3)
>
> 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
>
>
> ------------------------------
> *From:* Stephen Botzko  [mailto:[email-masked]<[email-masked]>]
>
> *Subject:* Re:  [dispatch] The charter formerly know as RTC-WEB take 3
>
>
> >>>
> need to be in the RFCs.  I believe market forces  are sufficient - SIP
> itself is one proof point.
>
> Stephen  Botzko
>
>
>
> >>  [mailto:[email-masked] <[email-masked]>] On
>  Behalf Of Cullen Jennings
> RTC-Web mailing [email-masked]://www.alvestrand.no/mailman/listinfo/rtc-web
>
>
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 21 Jan 2011 09:38:05 +0100

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:[email-masked]]
Sent: den 21 januari 2011 09:13
To: Stefan Håkansson LK
Cc: Harald Alvestrand; Henry Sinnreich; Cullen Jennings; [email-masked]; 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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: den 21 januari 2011 08:46
To: Henry Sinnreich
Cc: Stefan Håkansson LK; Stephen Botzko; Cullen Jennings; [email-masked]<mailto:[email-masked]>; DISPATCH list
Subject: Rate control and codec adaption (Re: [RTW] [dispatch] The charter formerly know as RTC-WEB take 3)

Thanks, Henry

On 1/20/11 2:02 PM, "Stefan Håkansson LK" <[email-masked]<http://[email-masked]>> wrote:

Br,
Stefan

Cc: Stefan Håkansson LK; Cullen  Jennings; DISPATCH list; [email-masked]<http://[email-masked]>

Stephen  Botzko

On Thu, Jan 20, 2011 at 10:37 AM, Henry Sinnreich <[email-masked]<http://[email-masked]>>  wrote:

Hi  Stefan,

Thanks, Henry

On 1/20/11  3:52 AM, "Stefan Håkansson LK" <[email-masked]<http://[email-masked]>>
wrote:

>> From: [email-masked]<http://[email-masked]>
>> Cc: [email-masked]<http://[email-masked]>

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 21 Jan 2011 16:58:41 +0100

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 Jan 2011 18:04:06 -0800

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

> > 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 s…

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 26 Jan 2011 23:44:38 -0600

+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" <[email-masked]> 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.
> 
>>> 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
>>>

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 12:01:53 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de Henry Sinnreich
Envoyé : jeudi 27 janvier 2011 06:45
À : Cullen Jennings; MARJOU Xavier RD-CORE-LAN
Cc : [email-masked]; DISPATCH list; Kundan Singh
Objet : Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3

+1

Thanks, Henry

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Jan 2011 09:18:45 -0600

> 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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 27 Jan 2011 09:46:37 -0600

+1
Henry

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 27 Jan 2011 10:48:03 -0500

+1

Peter Musgrave

On 2011-01-27, at 10:18 AM, Adam Roach wrote:

> 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

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 27 Jan 2011 16:53:01 +0100

+1

/Sal

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 27 Jan 2011 16:57:08 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 27 January 2011 15:19
To: Cullen Jennings
Cc: [email-masked]; DISPATCH list; Xavier Marjou
Subject: Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3

/a

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 16:15:27 +0000

Hi,

>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

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 17:30:12 +0100

+1

Regards

Jean-François Jestin

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Adam Roach
Envoyé : jeudi 27 janvier 2011 16:19
À : Cullen Jennings
Cc : [email-masked]; DISPATCH list; MARJOU Xavier RD-CORE-LAN
Objet : Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3

/a

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 27 Jan 2011 12:08:54 -0600

>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, "[email-masked]" <[email-masked]>
wrote:

> 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 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

---

From: <[email-masked]>
Date: Thu, 27 Jan 2011 20:07:56 +0000

Hi Henry,

>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).

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:

> 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.

Markus

---

From: David Singer <[email-masked]>
Date: Fri, 28 Jan 2011 12:04:34 +0900

On Jan 28, 2011, at 1:15 , [email-masked] wrote:

> 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.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 28 Jan 2011 15:12:10 -0600

Hi Markus,

>> establishing and controlling media sessions is in scope for the

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, "[email-masked]" <[email-masked]>
wrote:

> 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:
> 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:
> 
> 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
>

---

From: Erik Lagerway <[email-masked]>
Date: Fri, 28 Jan 2011 14:09:30 -0800

+1

Erik Lagerway

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 29 Jan 2011 09:15:23 -0500

I disagree with this, Adam. This wording assumes that there WILL be a 
protocol selected for establishment and control of media selection, and 
thus the work of the group is to choose between SIP or Jingle (H323 
again anyone? ;)). However, I am quite convinced that choosing a 
protocol is both unnecessary and a step in the wrong direction. I think 
that debate should happen within the group. As such, I suggest something 
more along the lines of:

"The group will decide whether or not the protocol suite needs to 
include a protocol for the actual setup and control of the media 
sessions (such as SIP or Jingle or another candidate), and if one is 
deemed necessary, select it and define a profile if needed."

I'll reply separately on why I don't think the browser needs to include 
one at all. My comment here is strictly on charter words.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Chief Technology Strategist                    Mobile: +1 (732) 766-2496
Skype                                          SkypeIn: +1 (408) 465-0361
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net