Subject: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2011 12:53:37 +0100

This is the first of 3 messages going to the DISPATCH list (in the hope 
of keeping discussions somewhat organized).

This is the draft of a charter for an IETF working group to consider the 
subject area of "Real time communication in the Web browser platform". 
This is one of a paired set of activities, the other one being a W3C 
activity (either within an existing WG or in a new WG) that defines APIs 
to this functionality.

The two other messages will contain the W3C proposed charter and a 
kickoff for what's usually the most distracting topic in any such 
discussion: The name of the group.
Without further ado:

-------------------------------------

Version: 2

Possible Names:
<This space deliberately left blank for later discussion>

Body:

Many implementations have been made that use a Web browser to support 
interactive communications directly between users including voice, 
video, collaboration and gaming, but until now, such applications have 
required the installation of nonstandard plugins and browser extensions. 
There is a desire to standardize such functionality, so that this type 
of application can be run in any compatible 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 between users using RTP
* interoperate with compatible voice and video systems that are not web 
based
* support direct flows of non RTP application data between browsers for 
collaboration and gaming applications

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 considered as one of the candidates

3) a baseline audio codec for PSTN interoperability. G.711 and iLBC
will be considered

4) a baseline video codec. H.264 and VP8 will be considered

5) Diffserv based QoS

6) NAT traversal using ICE

7) RFC 4833 based DTMF transport

8) RFC 4574 based Label support for identifying streams purpose

9) Secure RTP and keying

10) support for IPv4, IPv6 and dual stack browsers

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 RFC 4833 DTMF, RTP 
and RTCP statistics, state of DTLS/SRTP,  and signalling state.

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,

Milestones:

February 2011 Candidate "sample" documents circulated to DISPATCH

March 2011 BOF at IETF Prague

April 2011 WG charter approved by IESG. Chosen document sets adopted as 
WG documents

May 2011 Functionality to include and main alternative protocols identified

July 2011 IETF meeting

Aug 2011 Draft with text reflecting agreement of what the protocol set 
should be

Nov 2010 Documentation specifying mapping of protocol functionality to 
W3C-specified API produced

Dec 2011 Protocol set specification to IESG

April 2012 API mapping document to IESG

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Jan 2011 07:49:03 -0500

On Jan 6, 2011, at 6:53 AM, Harald Alvestrand wrote:

> This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized).
> 
> This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality.
> 
> The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group.

Dear Harold;

Just to be clear, your intent is to have simultaneously a W3C WG and an IETF WG on this issue ? 

Shouldn't there be some text about coordination between these efforts ? I don't see much discussion in either 
charter as to which is gating, but it seems to me that the W3C work would have to be gated on the IETF work. Isn't there a danger that
the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ? 

Regards
Marshall

> Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible 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:
> 
> * interoperate with compatible voice and video systems that are not web based
> * support direct flows of non RTP application data between browsers for collaboration and gaming applications
> 
> 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
> 
> 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 RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP,  and signalling state.
> 
> 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,
> 
> Milestones:
> 
> April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents
> 
> Aug 2011 Draft with text reflecting agreement of what the protocol set should be
> 
> Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced
> 
> _______________________________________________
> RTC-Web mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2011 14:48:06 +0100

> the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ?
If either effort fails, we don't have an usable result, so that is 
indeed very key. As proposed, I think the IETF work gates the W3C work.

The IETF charter says:

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.

The W3C charter says:

      External Groups

@@@ IETF group on related protocol
    The RTC APIs developed by this group will build upon the protocols
    and formats developed in the IETF @@@ Working Group.

What more words would you suggest we put in?

Finding enough people who have the time to run back and forth between 
them is a key activity; I for one am allocated to this effort, so I'll 
be running.

                      Harald

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 6 Jan 2011 14:52:50 +0100

Nowhere have you specified in the milestones what status the intended deliverables are.

Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some other organisation.

Opus does not yet have a RTP payload format, although I understand one is planned, no drafts exist at the moment.

iLBC is defined as an experimental RFC - does it need to be upgraded to standards track or is there some other reference.

VP8 has no RTP payload format defined, unless it is masquerading under some other name.

Presumably you need a paragraph in the charter relating to working with other groups (in particular IETF WG) to ensure that profiled specifications exist and are brought to standards track level.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: Thursday, January 06, 2011 11:54 AM
> To: [email-masked]'
> Cc: [email-masked]
> Subject: [dispatch] Charter proposal: The activity hitherto 
> known as "RTC-WEB at IETF"
> 
> This is the first of 3 messages going to the DISPATCH list 
> (in the hope of keeping discussions somewhat organized).
> 
> This is the draft of a charter for an IETF working group to 
> consider the subject area of "Real time communication in the 
> Web browser platform". 
> This is one of a paired set of activities, the other one 
> being a W3C activity (either within an existing WG or in a 
> new WG) that defines APIs to this functionality.
> 
> The two other messages will contain the W3C proposed charter 
> and a kickoff for what's usually the most distracting topic 
> in any such
> Many implementations have been made that use a Web browser to 
> support interactive communications directly between users 
> including voice, video, collaboration and gaming, but until 
> now, such applications have required the installation of 
> nonstandard plugins and browser extensions. 
> There is a desire to standardize such functionality, so that 
> this type of application can be run in any compatible 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.
> 
> * support direct flows of non RTP application data between 
> browsers for collaboration and gaming applications
> 
> 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 considered as one of the candidates
> 
> 3) a baseline audio codec for PSTN interoperability. G.711 
> and iLBC will be considered
> 
> 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 RFC 4833 DTMF, 
> RTP and RTCP statistics, state of DTLS/SRTP,  and signalling state.
> 
> 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,
> 
> Milestones:
> 
> Nov 2010 Documentation specifying mapping of protocol 
> functionality to W3C-specified API produced
> 
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Jan 2011 11:42:19 -0500

On Jan 6, 2011, at 8:48 AM, Harald Alvestrand wrote:

> If either effort fails, we don't have an usable result, so that is indeed very key. As proposed, I think the IETF work gates the W3C work.
> 
> The IETF charter says:
> 
> The RTC APIs developed by this group will build upon the protocols and formats developed in the IETF @@@ Working Group.

s/Group./Group and will not be finalized until that work is published./

(Of course, to get published you have to go through the IESG, which is the real point here. I would myself be satisfied with AUTH48 as
a marker for that.)

> Finding enough people who have the time to run back and forth between them is a key activity; I for one am allocated to this effort, so I'll be running.
> 

That is going to be tough, especially as the W3C has "good standing" requirements. 

http://www.w3.org/2005/10/Process-20051014/groups.html#good-standing

which you may lose if "the individual has missed more than one of the last three face-to-face meetings" or
"the individual has missed more than one of the last three distributed meetings."
 
So, to be in good standing with the W3C WG I would have to attend 2 out of 3 F2F meetings somewhere - are any planned ?  

It also says

"Effective participation to Web Real-Time Communications Working Group is expected to consume one work day per week for each participant; two days per week for editors."

I don't know if this is required for "good standing" but taken together this is a hit, or could be (there are a lot of "weasel words" in these
two documents.)

Can you provide insight as to how much of a time commitment the W3C effort will really be ?

Regards
Marshall

P.S. A nit below.

>>> Without further ado:

s/signalling/signaling/

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2011 18:07:17 +0100

> Nowhere have you specified in the milestones what status the intended deliverables are.
Indeed, there isn't even an explicit list of deliverables. That has to 
be added.
My thinking goes like:

- Profile document (or documents): Proposed Standard
- API mapping document: either Info or Proposed
- Scenarios document (I think we need one): Informational

Thoughts?

> Assuming the profile is intended to be proposed standard, then presumably you need to ensure all the constituent parts are of proposed standard, or some equivalent referenceable standard in some ot…
The term I prefer in requirements is "stable reference" - we need to 
know what we refer to.
If we have a standards-track and a non-standards-track spec for the same 
thing, I do think we should most often prefer the standards-track spec, 
but I don't want to be dogmatic about it.
> Opus does not yet have a RTP payload format, although I understand one is planned, no drafts exist at the moment.
Coordination item for the CODEC WG.
> VP8 has no RTP payload format defined, unless it is masquerading under some other name.
I know some people have been working on this, but I don't think there is 
a draft yet.
> Presumably you need a paragraph in the charter relating to working with other groups (in particular IETF WG) to ensure that profiled specifications exist and are brought to standards track level.
Yes, definitely.
>> RSVP, NSIS, LOST, Geolocation, IM&  Presence, NSIS, Resource Priority,
>>
>> Milestones:
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 6 Jan 2011 18:48:46 +0100

> > Assuming the profile is intended to be proposed standard, 
> then presumably you need to ensure all the constituent parts 
> are of proposed standard, or some equivalent referenceable 
> standard in some other organisation.
> The term I prefer in requirements is "stable reference" - we 
> need to know what we refer to.
> If we have a standards-track and a non-standards-track spec 
> for the same thing, I do think we should most often prefer 
> the standards-track spec, but I don't want to be dogmatic about it.

To profile a document to me has a defined meaning, and at least one ISO have defined, i.e. it takes an existing specification or specifications and states which requirements apply. Mandatory requirements can only be mandatory in the profile. Option requirements can become mandatory in the profile. RFC 2026 seems to use the term "Applicability statement" with much the same meaning.

As such, I believe the following applies (quoting from RFC 2026) but this is also my understanding for profile.

   An AS may not have a higher maturity level in the standards track
   than any standards-track TS on which the AS relies (see section 4.1).
   For example, a TS at Draft Standard level may be referenced by an AS
   at the Proposed Standard or Draft Standard level, but not by an AS at
   the Standard level.

So a profile at proposed standard needs to call up proposed standard specifications. I certainly allow us to take equivalent level documents from other organisations. 

I agree this is not the most important thing to get the charter resolved, but it may result in some other IETF groups needing to do a little more work than you expect. The biggest impact would be if iLBC is chosen as that has a codec definition (and payload format) at experimental level (RFC 3951 and RFC 3952). As to why they are experimental, I don't know, but I suspect that IETF was required to produce a payload definition, and for that it needed a referencerable document for the codec definition, but did not want to get involved at that time in standards track activity for the codec itself. (Nowadays that would not be a block to producing a standards track payload type).

In any case, it would seem to send the wrong message to profile something that is still formally experimental.

No issue with your other responses.

Keith

> Sent: Thursday, January 06, 2011 5:07 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]'
> Subject: Re: [dispatch] Charter proposal: The activity 
> hitherto known as "RTC-WEB at IETF"
> 
> Indeed, there isn't even an explicit list of deliverables. 
> That has to be added.
> My thinking goes like:
> 
> > Assuming the profile is intended to be proposed standard, 
> then presumably you need to ensure all the constituent parts 
> are of proposed standard, or some equivalent referenceable 
> standard in some other organisation.
> The term I prefer in requirements is "stable reference" - we 
> need to know what we refer to.
> If we have a standards-track and a non-standards-track spec 
> for the same thing, I do think we should most often prefer 
> the standards-track spec, but I don't want to be dogmatic about it.
> > Opus does not yet have a RTP payload format, although I 
> understand one is planned, no drafts exist at the moment.
> > iLBC is defined as an experimental RFC - does it need to be 
> upgraded to standards track or is there some other reference.
> >
> I know some people have been working on this, but I don't 
> think there is a draft yet.
> > Presumably you need a paragraph in the charter relating to 
> working with other groups (in particular IETF WG) to ensure 
> that profiled specifications exist and are brought to 
> standards track level.
> Yes, definitely.
> > regards
> >
> >
> > Keith
> >
> >> Subject: [dispatch] Charter proposal: The activity 
> hitherto known as 
> >> "RTC-WEB at IETF"
> >>
> >> This is the first of 3 messages going to the DISPATCH list (in the 
> >> hope of keeping discussions somewhat organized).
> >>
> >> This is the draft of a charter for an IETF working group 
> to consider 
> >> the subject area of "Real time communication in the Web browser 
> >> platform".
> being a W3C 
> >> activity (either within an existing WG or in a new WG) 
> that defines 
> >> APIs to this functionality.
> >>
> >> video, collaboration and gaming, but until now, such applications 
> >> have required the installation of nonstandard plugins and browser 
> >> extensions.
> >> There is a desire to standardize such functionality, so that this 
> >> type of application can be run in any compatible 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.
> >>
> >> * interoperate with compatible voice and video systems 
> that are not 
> >> web based
> browsers 
> >> for collaboration and gaming applications
> >>
> >> 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
> >>
> 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 
> >> RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP,  and 
> >> signalling state.
> >>
> >> 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,
> >>
> >> Milestones:
> >>
> >> April 2011 WG charter approved by IESG. Chosen document 
> sets adopted 
> >> as WG documents
> >>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Jan 2011 10:43:37 -0800

Hi Harald,

Thanks for putting this together; some discussion in-line.

On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand <[email-masked]> wrote:
> subject area of "Real time communication in the Web browser platform". This
> is one of a paired set of activities, the other one being a W3C activity
> (either within an existing WG or in a new WG) that defines APIs to this
> functionality.
>
> The two other messages will contain the W3C proposed charter and a kickoff
> for what's usually the most distracting topic in any such discussion: The
> name of the group.
> Without further ado:
>
> interactive communications directly between users including voice, video,
> collaboration and gaming, but until now, such applications have required the
> installation of nonstandard plugins and browser extensions. There is a
> desire to standardize such functionality, so that this type of application
> can be run in any compatible browser.
>

In at least some of the contexts identified above, there is a
long-lived identifier
associated with the individuals who will have interactive
communications; that is,
there is a context-specific presence architecture in addition to the
implementation-specific
real-time communications.  Though the text below occasionally says "users",
there does not seem to be any work being defined that would touch on this.
I see that in the last sentence you explicitly rule it out of scope.
Without this,
this seems to be limited to an architecture where a mediating server provides
the initial signaling path.  If that is the scope, I think that should be made
explicit as a design statement, not inferred from the lack of presence.

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

> collaboration and gaming applications

Okay "direct flows of non-RTP application data" goes beyond scope creep;
to satisfy this completely, we are talking an end-point-to-end-point tunnel,
which will run afoul of a lot of folks who dearly love packet inspection.  I
would say that it would be best to first tackle the voice/video bits and then
tackle this problem.  Re-charter the WG to cover this, in other words, after
the first bit is done.

I also note that you're using "between browsers", rather than "among browsers".
Is it intended that this facility should allow for multi-party communication?
Leaving aside the non-RTP issues, that would add floor control, media mixing,
etc. to the task list.  Again, I think it should either be explicitly
in-scope or out-of-scope.

> Fortunately very little development of new protocol at IETF is required for
> this, only selection of existing protocols and selection of minimum

The ICE spec is clear that the NAT traversal it provides does not
help establish the signaling between agents.  For this browser-to-browser
mechanism, if we are limiting this to situations where a mediating web server
provides the initial signaling path, that's okay.  If there is a
different model, though,
we may need additional tools here.

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

I think the sentence above has some extra words; is the browser talking
to application running in the browser?  Can it be re-phrased?

These events and state need to include
> information such as: receiving RFC 4833 DTMF, RTP and RTCP statistics, state
> of DTLS/SRTP,  and signalling state.
>
> 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,
>
> Milestones:
>

Pretty aggressive, given the number of moving parts.  It's also not
clear why the November 2011 doc (I assume 2010 is a typo) is
done in the IETF, rather than the W3C.  Or is it joint work?

regards,

Ted Hardie

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 06 Jan 2011 13:18:52 -0600

> which will run afoul of a lot of folks who dearly love packet inspection.

Why should the IETF and W3C abide by the folks who love deep packet
inspection? I would like to see some IESG guidance here, since it is
contrary to Internet and to the Web. Break of privacy, etc.

To accelerate clarity here, what does Harald and people on the list think?

Thanks, Henry

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Jan 2011 11:37:28 -0800

> To accelerate clarity here, what does Harald and people on the list think?

Hi Henry,

I'm not a huge fan of packet inspection.  But "any application data" is clearly
well beyond the audio/video use case that motivated this work in the first
place.  I expect that it would make firewall traversal significantly
harder unless
it lost privacy; that trade-off would make the voice/video privacy *worse*.

It also will make the communication among browsers in a multi-party
mode move from known issues (media mixing and floor control) to something
closer to that of an overlay network.  That's not impossible (setting
up an overlay
when you have a rendezvous server, basically moves it from mediating
the signaling
path to being an enrollment server), but is also not simple.  Is it
really needed
for job one here?

regards,

Ted

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 6 Jan 2011 14:46:37 -0500

> To accelerate clarity here, what does Harald and people on the list think?

As far as I know, there have never had any DPI concerns raised in AMT, which is a tunneling protocol (which
might BTW have useful pieces if tunneling is needed here). 

http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-10

Regards
Marshall

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2011 21:54:45 +0100

> To accelerate clarity here, what does Harald and people on the list think?
My personal opinion:

At the workshop, several use cases were identified where stuff that is 
not audio or video needed to be communicated from one browser to another 
quickly enough that relaying via backend web server(s) is problematic - 
the canonical poster child is the movement of bullets in a first-person 
shooter game, but there are other cases; I think Lisa mentioned that in 
Second Life, the placement of audio sources in the stereo field needs to 
be communicated reasonably synchronously with the sound itself.

I am hesitant to rule point-to-point traffic that isn't audio or video 
out of scope, given the discussion at the workshop; certainly, given the 
RAVEN RFC (RFC 2804), I do not want to rule it out of scope because it's 
hard to write packet inspection state machines that can tell what's 
going on here.

                        Harald

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Jan 2011 13:25:17 -0800

On Thu, Jan 6, 2011 at 12:54 PM, Harald Alvestrand <[email-masked]>wrote:

> At the workshop, several use cases were identified where stuff that is not
> audio or video needed to be communicated from one browser to another quickly
> enough that relaying via backend web server(s) is problematic - the
> canonical poster child is the movement of bullets in a first-person shooter
> game, but there are other cases; I think Lisa mentioned that in Second Life,
> the placement of audio sources in the stereo field needs to be communicated
> reasonably synchronously with the sound itself.
>
> I am hesitant to rule point-to-point traffic that isn't audio or video out
> of scope, given the discussion at the workshop; certainly, given the RAVEN
> RFC (RFC 2804), I do not want to rule it out of scope because it's hard to
> write packet inspection state machines that can tell what's going on here.
>

Right. The thinking was that since we need to do a fair amount of work to
allow audio and video to be exchanged safely and reliably peer-to-peer, we
should allow web applications (with some limits) to use this transport
mechanism for exchanging their own application data.

The plan also is to be able to leverage DTLS to allow the creation of secure
transports, which will have additional implications for DPI.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Jan 2011 14:00:23 -0800

>From a practical perspective, once you say "application data", the ability
to limit this seems to approach zero pretty quickly.  Even ignoring the
network-based firewall, doesn't this now require me to have a browser-based
firewall, to express my policies for what traffic I permit over this?

> transports, which will have additional implications for DPI.

Agreed.  More importantly, I think that reinforces the idea that this is not
a simple add-on to audio/video functionality.  As I argued in
draft-hardie-mdtls-session,
you are really creating a multi-flow session layer.  I personally
think that's a fine
thing, but it is not an adjunct to a charter-it's the top-line bullet
item in my view.

regards,

Ted

PS.  As an aside, both Jake and I have since left Panasonic and the
project mentioned in
the draft cited above.  I do not believe that the sponsor lab will release the
code created for it at this time so the discussion I had with some
folks on that in Beijing
will likely need to take other paths.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Jan 2011 14:32:50 -0800

> firewall, to express my policies for what traffic I permit over this?

The connection is limited by the browser same-origin policy, so the
application can only connect to places blessed by the application server,
similar to XmlHttpRequest. We don't worry about apps making XmlHttpRequest
over TLS, where there is little ability to control the data, and I think we
should try to think of these transports the same way.

---

From: David Singer <[email-masked]>
Date: Thu, 6 Jan 2011 16:22:21 -0800

> the W3C WG might start building on early solutions discussed in the IETF, only to have the IETF WG decide to go in a different direction ? 

Hi 

I'm sorry if this has already been said, but I am pretty sure that the W3C's work should provide a pretty general framework into which all sorts of instantiations (protocols and implementations) can be fit.  An example might be "a URL that addresses the remote end goes here" and a URL has a protocol part (before the colon) and an 'address' part (after it).  Sure, the first protocol instantiated (in definition and code) should be the stuff worked on with the IETF, but the architecture should not preclude others.  I am sure there will be back and forth, and it's important that the functional division into pieces, and the architectural division between 'markup' (w3c) and 'protocol' (ietf) be agreed, and that the final pieces do, in fact work together.

But I think it very important that we see at least two layers of definition here: modularization, framework, and so on, which is pretty general;  and specific modules that fit into that framework and make our first working system, which need to be very specific.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Jan 2011 17:06:50 -0800

> should try to think of these transports the same way.

First, I'm not sure that everyone has the same view "of not worry" here.
Second, I'm really not sure that the threat model is the same.  If I have
an open pipe between any two peers which can carry any traffic which
fits over DTLS, the situation is a bit different from that where https
is running through to a server.  And the chances that someone terminates
and re-originates the TLS flow seems to me to go up in some common cases
if it has this characteristic.

But I think the charter comment for now is that this is a major chunk of work,
and that it has considerations outside those for audio and video.  To me,
that means it needs to be called out (either in its own documents or in a
re-charter), so that it doesn't gate the base functionality.

Please remember as well that just because the initiating use case for this
protocol work is browser based there is no reason to presume that it
will stay browser based for all time.  Even in this framework a
browser-initiated DTLS
flow could be handed off to another "helper" app.

Again, I think this is potentially a lot of work.  That doesn't mean I
think it is
bad work; I think it means it has to be scoped appropriately.

regards,

Ted

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 7 Jan 2011 10:38:30 +0100

Harald,

With one exception, this draft charter does not mention signalling (SIP/SDP), and I assume it is intended to be out of scope, although that is not explicitly stated.

The one exception is "8) RFC 4574 based Label support for identifying streams purpose".
This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: 06 January 2011 11:54
> To: [email-masked]'
> Subject: [RTW] Charter proposal: The activity hitherto known 
> as "RTC-WEB at IETF"
> 
> (in the hope 
> consider the 
> this type 
> such as HTML 
> traditional way 
> applications 
> is required 
> manipulation 
> phase of the

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 07 Jan 2011 14:30:39 +0100

On 01/06/11 19:43, Ted Hardie wrote:
> On Thu, Jan 6, 2011 at 3:53 AM, Harald Alvestrand<[email-masked]>  wrote:
I think what you mean is that at this level, we're not taking a position 
on what an "user" is, or whether the concept of "user" even has meaning 
for the application (think chatroulette for one example of an 
application where there are no long-lived user identifiers).

I would certainly agree that this is a reasonable restriction of our 
work, and would welcome suggested text on how to write that into the 
charter.
> in-scope or out-of-scope.
I did not intend "between" to indicate that there were only two parties, 
but think that we're building point-to-point communications, not N-to-N.

In one interpretation of the distinction .... I think we're 
standardizing point-to-point communications at this time, since all the 
proven-viable multipoint communication applications have been built out 
of point-to-point links rather than using underlying multipoint 
technologies like multicast.

In another interpretation ... I think we should limit ourselves to 
providing a toolbox. I think floor control (except for possibly 
providing the signalling channels floor control needs) is out of scope; 
MAITAI may be a better place to discuss media mixing.

> we may need additional tools here.
If we can make the mediating-web-server model work, I think we have 
success; if we can't make it work, we have a failure. So obviously 
that's my first priority. What text changes do you think are needed?
> to application running in the browser?  Can it be re-phrased?
I think there's an extra "that" - when an event happens at the 
communications interface, this event needs to be propagated over the API 
to the Javascript that is running in a Web page - that Web page is what 
I've been thinking of as "the application". (There are other moves 
around that want to run "web pages" in other contexts than a currently 
open tab in a broswer, but for the moment, "a tab in a browser", or even 
"a set of tabs in a browser" is a reasonable synonym for "application", 
I think).
>> IM&  Presence, NSIS, Resource Priority,
>>
>> Milestones:
>>
More or less done this way at random. I think of this as joint work; 
documents may move between the organizations as we progress, but I'm not 
sure how the W3C document model works yet.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 08 Jan 2011 15:02:43 +0100

> This is an SDP attribute. How would this be used if SDP is indeed out of scope? If SDP is in scope, we certainly need more text describing its relevance.
There isn't much text in 4574 - the main point of the RFC seems to be 
that it's possible to create labels for streams before creating the 
stream. Those labels could be independent of the signalling mechanism.

The trend I see now is that most APIs and protocols people define (for 
instance Jabber/XMPP, JSON-based descriptions) have some kind of mapping 
to SDP, so SDP-as-a-format may not be so important (I heartily dislike 
multiple things about the specific format), but SDP-as-a-semantic 
becomes more important over time, and can't be ignored.

                       Harald

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Jan 2011 08:20:36 +0100

> From: Harald Alvestrand [mailto:[email-masked]] 
> Sent: 08 January 2011 14:03
> To: Elwell, John
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [RTW] Charter proposal: The activity hitherto 
> > With one exception, this draft charter does not mention 
> signalling (SIP/SDP), and I assume it is intended to be out 
> of scope, although that is not explicitly stated.
> >
> > This is an SDP attribute. How would this be used if SDP is 
> indeed out of scope? If SDP is in scope, we certainly need 
> more text describing its relevance.
[JRE] RFC 4574 is little more than an SDP syntax (for conveying an application-specific label). As such, if we don't use the SDP syntax, I don't see how RFC 4574 can apply at all.
The problem we need to solve, if I understand correctly, is for the application to instruct the browser what source and sink to use for a given medium. For audio, this means telling the browser which microphone and which speaker to use. For video, this means telling the browser which camera to use and where on the display to render received video. I don't see the relevance of RFC 4574 for achieving this.

John

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 10 Jan 2011 06:22:43 -0500

Hi,

I agree with John. The 'label' RFC is essentially syntax.

It seems to me this source/sink issue has some things in common with the work in CLUE (formerly maitai) in the sense that it too has to face the issue of linking devices with streams...

It may be that they need a common protocol mechanism...

Regards, 

Peter Musgrave

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Jan 2011 10:44:29 -0500

> It may be that they need a common protocol mechanism...

This issue is broader than that too.

To date with sip we have mostly been assuming degenerate cases where 
there is only one source/sink for every media stream, or that if there 
are more then it is policy of the user of the device to make the 
mapping. (E.g. choosing to use the headset rather than the handset or 
speaker.) Any time you want to give another party a say in this decision 
you need a way to signal it.

	Thanks,
	Paul

---

From: Roni Even <[email-masked]>
Date: Mon, 10 Jan 2011 18:37:30 +0200

Hi,
Look at RFC4796 that defines the content attribute that has the semantics of
the stream. The semantics can be extended. What it lacks is the expected
behavior that can be specified in a profile. 
Roni Even

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Monday, January 10, 2011 5:44 PM
> To: [email-masked]
> Subject: Re: [dispatch] [RTW] Charter proposal: The activity hitherto
> > It seems to me this source/sink issue has some things in common with
> the work in CLUE (formerly maitai) in the sense that it too has to face
> the issue of linking devices with streams...
> >
> >> [JRE] RFC 4574 is little more than an SDP syntax (for conveying an
> application-specific label). As such, if we don't use the SDP syntax, I
> don't see how RFC 4574 can apply at all.
> >> The problem we need to solve, if I understand correctly, is for the
> application to instruct the browser what source and sink to use for a
> given medium. For audio, this means telling the browser which
> microphone and which speaker to use. For video, this means telling the
> browser which camera to use and where on the display to render received
> video. I don't see the relevance of RFC 4574 for achieving this.
> >>
> >> John
> >>
> >>
> >>>
> >>>                        Harald
> >>>
> >>>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5774 (20110110) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 
> 
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5774 (20110110) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5774 (20110110) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Jan 2011 11:19:53 -0800

Hi Harald,

Some replies in-line.

On Fri, Jan 7, 2011 at 5:30 AM, Harald Alvestrand <[email-masked]> wrote:
>>> This
>>> kickoff
> I think what you mean is that at this level, we're not taking a position on
> what an "user" is, or whether the concept of "user" even has meaning for the
> application (think chatroulette for one example of an application where
> there are no long-lived user identifiers).
>
> I would certainly agree that this is a reasonable restriction of our work,
> and would welcome suggested text on how to write that into the charter.
>>>

How about:

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.

>>> as
>>  I
> I did not intend "between" to indicate that there were only two parties, but
> think that we're building point-to-point communications, not N-to-N.
>
> In one interpretation of the distinction .... I think we're standardizing
> point-to-point communications at this time, since all the proven-viable
> multipoint communication applications have been built out of point-to-point
> links rather than using underlying multipoint technologies like multicast.
>
> In another interpretation ... I think we should limit ourselves to providing
> a toolbox. I think floor control (except for possibly providing the
> signalling channels floor control needs) is out of scope; MAITAI may be a
> better place to discuss media mixing.
>

So, maybe this would be clearer if I asked it in a different way.  Are
you thinking of something like websockets run between two peers?
Or are you thinking of layered tunnel model?

>>> for
> If we can make the mediating-web-server model work, I think we have success;
> if we can't make it work, we have a failure. So obviously that's my first
> priority. What text changes do you think are needed?

If the text I suggested above clarifying that this is mediating-web-server
works for you, I don't think additionally text is needed here.

>>> of
> communications interface, this event needs to be propagated over the API to
> the Javascript that is running in a Web page - that Web page is what I've
> been thinking of as "the application". (There are other moves around that
> want to run "web pages" in other contexts than a currently open tab in a
> broswer, but for the moment, "a tab in a browser", or even "a set of tabs in
> a browser" is a reasonable synonym for "application", I think).
>>
>>> WG
>>> documents
I think that we need to be a bit more careful on the
dependencies, as it has not been my experience that joint
work has resulted in a congruent set of people working on them
in the two organizations.   Can we make the deliverable for
the November 2011 doc the release of a draft, with a note it
is intended as a substrate to the W3C work?  That would
make the W3C work have a dependency on this draft delivery.

regards,

Ted Hardie

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Jan 2011 15:24:02 +0100

Hi,

I have some comments/questions on the proposed charter.

GENERAL:
--------

In my opinion it is good that the charter lists tasks that have to be solved, but I don't think the charter should specify the technical solutions.

For example, rather than saying "RFC 4833 based DTMF transport" it should say "DTMF transport".

Because, we haven't discussed different DTMF transport mechanisms, and I don't think we shall discuss them as part as the charter discussion.

The same comment applies to NAT traversal, identification of media stream purposes etc.

Similar, I don't think the charter shall list different codecs, but only say that the intention is to choose a baseline codec for audio and video.

NEGOTIATION:
------------

The charter talks about baseline codecs and transport (RTP/RTCP). But, I think it shall also cover the possibility to negotiate the usage of other codecs and transports.

INTEROPERABILITY:
-----------------

The charter says:

"interoperate with compatible voice and video systems that are not web based"

And, later a baseline codec for PSTN interoperability is mentioned.

But, interoperability is much more than having a codec. You will need some "gateway" that performs mapping between the web based system and the non-web based system. Is the working group supposed to define such mapping?

QOS:
----

What is the thinking behind the addition of DiffServ?

W3C API:
--------

The charter seems to put requirements on the W3C API. In particular, it talks about "signalling state". What is that?

FUTURE WORK:
------------

If we are going to list potential future work, I would like to add "connection control" to the list.

Regards,

Christer

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 12 Jan 2011 07:49:33 -0500

I think this is an interesting and important activity, but I want to point out a few points of concern with the current proposal.

> * interoperate with compatible voice and video systems that are not web 

which, btw, you already re-interpreted to mean "brower-to-browser" in a later email. 

I would therefore recommend that, if a single baseline codec is to be selected, the criteria are stated in the charter. If the criteria are to be defined later by the group, then that should be stated in the charter, with at least some indication of what the group wants to accomplish here. 

Nit: Codecs are not protocols (cf. "The following protocols..."). 

Regards. 

Alex

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 12 Jan 2011 05:38:22 -0800

Hi, 

I also think this is very useful work. 

I would really like have IETF side step the video codec choice vortex. There has been a long and impassioned CODEC dialog wrt the <video> tag in HTML5 (which I have only observed from afar) and I am not sure we are well served by having our own version of that. 

Is it necessary for the charter to specify a baseline CODEC choice? What are the implications of just saying that CODECs will be negotiated (as per usual in SIP)?

There is lots of REALLY GOOD stuff this group can do to ensure anything you can put in RTP can go between web browsers (or from a web browser to a SIP endpoint) in a secure, NAT-tolerant way. 

Peter Musgrave

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Jan 2011 14:43:11 +0100

> which, btw, you already re-interpreted to mean "brower-to-browser" in a later email.
Aside: I'm worried about this bullet in the charter; I'm not convinced 
it's either clear enough or saying the right thing. I know we have to do 
browser-to-browser; unless we can define "compatible voice and video 
systems" in a way that people have a common understanding of, we might 
be better off dropping the line from the charter or moving it to the 
section "work that we're not doing but might look at after a recharter".
> I would therefore recommend that, if a single baseline codec is to be selected, the criteria are stated in the charter. If the criteria are to be defined later by the group, then that should be sta…
I don't think we can get the criteria in the charter. In fact, I wonder 
if we have to add a criteria document to the deliverables. As an 
example, a statement was made yesterday that Theora's delay 
characteristics make it "unsuitable for interactive use" - while I have 
little reason to disbelieve that statement, a discussion of exactly how 
many ms of the ~200 ms latency budget of a typical interactive video 
call we can allow the codec to consume can easily consume many messages 
and many days/weeks of time.

I think it's important that the charter states that there should *be* a 
mandatory-to-implement, and that we're envisioning evaluating existing 
codecs rather than inventing new ones.

Suggestions for appropriate text?

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 12 Jan 2011 14:31:34 -0500

> codecs rather than inventing new ones.

The next to last paragraph seems to indicate that the last paragraph is not a desirable constraint. It may be more prudent to let the application select the most appropriate codec. 

I am therefore in agreement with Peter that it would be best to leave the choice of codecs outside the scope of this work.  

> Suggestions for appropriate text?

Just remove the need for mandatory codecs.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Jan 2011 15:11:41 -0500

FWIW ..I agree with Harald here. How can you promote a minimum profile of
interoperability unless you can say "at least use this"? 

> codecs rather than inventing new ones.

The next to last paragraph seems to indicate that the last paragraph is not
a desirable constraint. It may be more prudent to let the application select
the most appropriate codec. 

I am therefore in agreement with Peter that it would be best to leave the
choice of codecs outside the scope of this work.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Jan 2011 22:11:44 +0100

> I am therefore in agreement with Peter that it would be best to leave the choice of codecs outside the scope of this work.
This is a standard IETF interoperability argument.

If there is no mandatory-to-implement, you are constrained to 
interworking with those who implement an overlapping subset of what you 
implement - in practice, this means that you create multiple islands of 
interoperability (usually corresponding to vendor groupings or profiling 
standards). We push the problem off to someone else.

I would like to believe that what we're creating is the only profiling 
necessary for interoperability. And if that's our goal, I don't think 
there is a way around a mandatory-to-implement.

                     Harald

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 12 Jan 2011 15:37:55 -0600

Are there zero RFCs that already define a mandatory to implement codec?

If there is one such RFC, could you cite it and be done?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Harald Alvestrand
Sent: Wednesday, January 12, 2011 4:12 PM
To: Alex Eleftheriadis
Cc: [email-masked]
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as
"RTC-WEB at IETF"

On 01/12/2011 08:31 PM, Alex Eleftheriadis wrote:
> The next to last paragraph seems to indicate that the last paragraph
is not a desirable constraint. It may be more prudent to let the
application select the most appropriate codec.
>
> I am therefore in agreement with Peter that it would be best to leave
the choice of codecs outside the scope of this work.
This is a standard IETF interoperability argument.

                     Harald

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Jan 2011 16:45:29 -0500

> The next to last paragraph seems to indicate that the last paragraph is
not a desirable constraint. It may be more prudent to let the application
select the most appropriate codec.

Humm SIP Forum could do this :-) Profiles_R_Us!  

Richard Shockey
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

+1 again I completely agree.

                     Harald

---

From: David Singer <[email-masked]>
Date: Thu, 13 Jan 2011 08:59:10 +0100

I think it important that we layer correctly;  there is a difference between protocol specifications, which typically only mandate enough for that protocol's interoperability, and integration specifications, which attempt to define 'complete stacks'.

For example, the RTP specification (a protocol specification) does not mandate codecs, IIRC.

I think that at least some of this work at the W3C and maybe IETF is indeed about defining structures (e.g. the markup), and then some is instantiating particular protocols, codecs, and so on, within that structure.  I would like the two to be separated.

David Singer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 13 Jan 2011 14:04:27 +0100

> If there is one such RFC, could you cite it and be done?
I don't know if I can answer that question, but there are certainly 
others on the list who know the history here much better than I do....

I googled for "mandatory audio codec rfc", and found that David is right 
about where this has been done before - wherever someone needs to define 
something that actually works together, they posit a MTI codec. I 
haven't found an example of a "tool" specification that does it.

RFC 4298 states that the "BV16 codec was selected as one of the 
mandatory audio codecs in the PacketCable(TM) 1.5 Audio/Video Codecs 
Specification."

RFC 4184 states that "AC-3 ... is a mandatory audio codec for DVD-video, 
Advanced Television Standards Committee (ATSC) digital terrestrial 
television and Digital Living Network Alliance (DLNA) home networking".

3GPP 1999 TS 26.111 names AMR as the mandatory audio codec for (3G-324H) 
multimedia telephone handsets, according to http://www.voiceage.com/amr.php

iLBC is designated by CableLabs as a mandatory component of PacketCable 
voice-over-cable  telephony systems, according to 
http://www.gipscorp.com/files/english/datasheets/VoiceCodecs.pdf

My personal thinking is that a mandatory codec is reasonable for the 
profile document that I tried to create in 
draft-alvestrand-dispatch-rtcweb-protocols, while it is not reasonable 
for the protocol document of draft-alvestrand-dispatch-rtcweb-datagram. 
But if the IETF decides that it doesn't want to address this issue ... 
we (the people who want interoperability of RTC-Web applications) may 
have to start up a third effort in some forum that's willing to define 
the profile needed for interoperability.

                   Harald

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 13 Jan 2011 05:10:42 -0800

In the video conferencing world this was what was required.

The IMTC SIP Parity working group has such a document. It recommends specific CODECs, use of bandwidth tags in a particular way etc. 

The drawback is that document is not publicly available - so if you do go that route then you need to make a choice about a "members only" forum or a body which makes it's work public. 

Peter Musgrave

On 2011-01-13, at 5:04 AM, Harald Alvestrand wrote:

> My personal thinking is that a mandatory codec is reasonable for the profile document that I tried to create in draft-alvestrand-dispatch-rtcweb-protocols, while it is not reasonable for the protocol document of draft-alvestrand-dispatch-rtcweb-datagram. But if the IETF decides that it doesn't want to address this issue ... we (the people who want interoperability of RTC-Web applications) may have to start up a third effort in some forum that's willing to define the profile needed for interoperability.
> 
>                  Harald
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Jan 2011 10:09:02 -0500

On Jan 13, 2011, at 8:04 AM, Harald Alvestrand wrote:

> I don't know if I can answer that question, but there are certainly others on the list who know the history here much better than I do....
> 
> I googled for "mandatory audio codec rfc", and found that David is right about where this has been done before - wherever someone needs to define something that actually works together, they posit a MTI codec. I haven't found an example of a "tool" specification that does it.
> 
> RFC 4298 states that the "BV16 codec was selected as one of the mandatory audio codecs in the PacketCable(TM) 1.5 Audio/Video Codecs Specification."
> 
> RFC 4184 states that "AC-3 ... is a mandatory audio codec for DVD-video, Advanced Television Standards Committee (ATSC) digital terrestrial television and Digital Living Network Alliance (DLNA) home networking".
> 
> 3GPP 1999 TS 26.111 names AMR as the mandatory audio codec for (3G-324H) multimedia telephone handsets, according to http://www.voiceage.com/amr.php
> 
> iLBC is designated by CableLabs as a mandatory component of PacketCable voice-over-cable  telephony systems, according to http://www.gipscorp.com/files/english/datasheets/VoiceCodecs.pdf
> 

I suspect that you would need to create one.

Regards
Marshall

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jan 2011 10:46:13 -0500

I think it important that we layer correctly;  there is a difference between
protocol specifications, which typically only mandate enough for that
protocol's interoperability, and integration specifications, which attempt
to define 'complete stacks'.

***
I think it's important to create specifications that actually make things
work. The concept of layering here is a theory that in practice creates
chaos.   The IETF has made a mess of SIP and I do not want to be one of the
people that have to pick up the pieces when RTC-WEB cannot and will not
deliver a complete functional specification.

I'm quite aware the IETF HATES profiles but the reality is that without them
it's nearly impossible for implementers to actually know what to code.  With
my other hat on, the SIP Forum has struggled for 2 years to deliver a
functional profile of SIP that describes what is the appropriate interface
between a SIP-PBX and a SIP Service Provider and part of that was taking
nearly 2 years to get a simple Option Tag. I strongly advise you not to go
down that road again. 

Harald is right. 

For example, the RTP specification (a protocol specification) does not
mandate codecs, IIRC.

I think that at least some of this work at the W3C and maybe IETF is indeed
about defining structures (e.g. the markup), and then some is instantiating
particular protocols, codecs, and so on, within that structure.  I would
like the two to be separated.

David Singer

---

From: Tom Taylor <[email-masked]>
Date: Thu, 13 Jan 2011 13:35:57 -0500

My personal advice is to leave the mandatory codec issue alone. You'll 
waste a huge amount of energy without getting satisfactory results. 
Notice that all your references were to specifications generated by 
other bodies.

This sort of fight has exhausted other bodies. The IMTC was never the 
same after they fought for a year or so over transport of DTMF around 
1998-99.

> the profile needed for interoperability.
...

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Jan 2011 14:18:30 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tom Taylor
Sent: Thursday, January 13, 2011 1:36 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as
"RTC-WEB at IETF"

Tom .. has SIP ever been the same since we fought over the transport of
DTMF?

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 20:36:32 +0000

Hi,

>Notice that all your references were to specifications generated by

I agree that at least for the time being it is more fruitful to focus the energy elsewhere. There is plenty of useful work that can be done about media transport (the datagram service and the potential bytestream service) and the associated APIs, and I suggest we focus on that. We can try our luck with the codec thing later on. 

Markus

---

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

So we have again the old debate on H.264 licenced vs. OS/free Theora and VP8
video codecs. 

I agree that having one default codec is preferable, but wonder if the IETF
may not take a pass here just as the W3C did and kick the can down the road.

Should this happen, it will still not be a disaster, since the market will
decide. Judging from past events, IP free solutions and OS tend mostly to
win eventually. The IETF cannot/should not protect IP encumbered vendors
from themselves.

Thanks, Henry

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Jan 2011 10:49:14 -0600

> may not take a pass here just as the W3C did and kick the can down the road.

There's a very salient difference.

With HTML5, the decision to not specify a codec (with the tacit 
knowledge that some browsers will support WebM but not H.264, while 
others will support H.264 but not WebM) was annoying, but workable.

It's workable because content providers can simply store two versions of 
content (one in H.264, one in WebM), and deliver the proper one 
according to the browser's capabilities. For example, YouTube already 
does this kind of thing for much of its video.

For the real time web, this slapdash "solution" of storing content in 
multiple formats can't be applied:  we're not dealing with stored 
content. If my browser supports only WebM, and your browser supports 
only H.264, nothing works. I can't communicate with you. And there's no 
workaround.

Even the solution of "well, Adam, why don't you just install another 
browser?" doesn't work (even if I were willing to do so), since none of 
the viable browsers under Linux will support H.264 in the foreseeable 
future. And the solution of "okay, then, go buy another operating 
system" isn't remotely realistic.

/a

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 14 Jan 2011 11:52:37 -0500

On Fri, Jan 14, 2011 at 11:15 AM, Henry Sinnreich <[email-masked]
> wrote:

> I think this is worth considering.  One reason (not IPR related) is that
codec technology ages pretty quickly relative to protocols.  Whatever
mandatory codec we picked would seem pretty lame 10-15 years down the road.
In the beginning, the mandated codec may help interop, later on it just
becomes a boat anchor.  For instance, ITU-T H.32x protocols mandated H.261,
but today no one wants to use it.

Steve B.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Jan 2011 18:56:40 +0100

Hi,

SIP seems to work pretty well, eventhough we don't require any codec for the terminals to support.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]
Sent: Friday, January 14, 2011 6:49 PM
To: Henry Sinnreich
Cc: 'Harald Alvestrand'; [email-masked]
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"

/a

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 18:09:36 +0000

Hi,

>the terminals to support.

I guess we could settle for mandating G.711 for audio in RTC-Web and we'd be on par with the average SIP communication experience :(

Markus

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 14 Jan 2011 13:39:02 -0600

Mandatory to implement will always find the lowest common denominator.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Friday, January 14, 2011 1:10 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as
"RTC-WEB at IETF"

Hi,

Christer Holmberg wrote:
>
>SIP seems to work pretty well, eventhough we don't require any codec
for
>the terminals to support.
>

I guess we could settle for mandating G.711 for audio in RTC-Web and
we'd be on par with the average SIP communication experience :(

Markus

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 16 Jan 2011 12:58:30 +0100

> Mandatory to implement will always find the lowest common denominator.
well, since it is intended to *be* the lowest common denominator, this 
is self-evidently true for any successful mandatory-to-implement.

---

From: David Singer <[email-masked]>
Date: Mon, 17 Jan 2011 08:07:23 -0800

well, SIP is a technology spec., and as such it shouldn't make mandates outside the area it covers (signalling).  An umbrella spec. might (one that says 'implement SIP and ICE and STUN and TURN and RTP and ...')

David Singer

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 18 Jan 2011 08:13:38 -0600

The context of this response was to the point that you won't get the
latest codec with all its bells and whistles.

If this is the case, then declare G.711 and be done.

The underlying point was not to waste time on codec beauty contests.

Mike

-----Original Message-----
From: Harald Alvestrand [mailto:[email-masked]] 
Sent: Sunday, January 16, 2011 6:59 AM
To: Mike Hammer (hmmr)
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] Charter proposal: The activity hitherto known as
"RTC-WEB at IETF"

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Jan 2011 13:27:35 +0200

Hi Roni,

exactly, 4796 allows an application to explain what a media stream
contains. The receiving application can handle the stream as it wishes,
taking into consideration the content information it got.

Cheers,

Gonzalo