[RTW] New proposed charter text. Please review before the BoF.

[Roni Even]

Cullen,
I support your view that negotiation is required not only to support
interoperability with current systems using different codec but also for
future codecs support. I just want to bring past experience of H.323 where a
mandatory video codec was defined (H.261 which was the codec used at the
time) and caused a burden on developers later that had to support it even
though it was not widely used just for compliance. My view is that selecting
a mandatory codec is difficult but removing it from being mandatory when it
becomes a burden is even more difficult.

Another experience on choosing a video codec is that not only new codecs are
developed but the codec itself can evolve adding higher capabilities that
may require negotiation allowing the sender to send a higher quality video
stream. So selecting a codec and more precisely an operation point of a
codec with no good negotiation may not be a good choice.
Thanks
Roni Even



> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-
> bounces at alvestrand.no] On Behalf Of Cullen Jennings
> Sent: Tuesday, March 22, 2011 5:16 AM
> To: Elwell, John
> Cc: Ted Hardie; Hutton, Andrew; rtc-web at alvestrand.no; Christer
> Holmberg
> Subject: Re: [RTW] New proposed charter text. Please review before the
> BoF.
> 
> 
> So at one point we had some text along the lines of the proposed
> 
>     "Solutions that require mediation functions to achieve
> interoperation might be acceptable, provided such functions are not
> unduly complex, expensive or detrimental to performance."
> 
> But I think that sort of text does not turns out to be useful in a
> charter. It is so vague and ambiguous that it does not guide the work.
> So lets dig into the things that might guide the work and see what we
> could do in a charter.
> 
> Clearly we need extensibility and ways of negotiating new things. There
> many points were we need extensibility but video codecs are one of
> them. Twelve years down the road, its highly likely that there will be
> new codecs in browsers beyond what we have today - who knows, perhaps
> they will do 3D. Clearly we need a way for an browser application to
> find out which codecs that browser supports then use that for
> negotiation. But, in as Henning nicely put it, to avoid failure of
> negotiation, we need some minimal set of things all browsers have.
> 
> With something like crypto algorithms for SRTP, the odds are good we
> can easily find something that was both acceptable to browsers and was
> widely supported by legacy voip equipment that does SRTP. With
> something like narrowband audio codecs it gets harder, but it is
> probably possible to come to something workable for a many cases. Phone
> BCP did. As you point out, video in some way has the highest cost of
> interoperability failure, but the bad news is that unfortunately legacy
> voip equipment already has widespread interoperability failure on video
> codec choices. Probably the most prevalent codec in interactive
> sessions is H.263 but much of the new equipment does not support that.
> Even the equipment that supports H.264 AVC (ignoring SVC), there are so
> many variants that much of the H.264 systems have no common way of
> interoperating with other H.264 systems. To have widespread support for
> legacy video equipment, browsers would have to implement a lot of
> codecs and profiles. H.26
>  5 is slated to be completed before I would expect this work to be
> deployed in the bulk of browser. Then there is the MPEG work on codecs
> that proponents hope will be royalty free. Not to mention some other
> obvious candidates that are widely used. GIven the lack of a common
> video codec in existing legacy equipment, I don't see how this working
> group could fix that. However, I think this working group needs to pick
> something that ensure that equipment compliant with specifications from
> the proposed WG does not suffer from the same video interoperability
> failure as legacy equipment.
> 
> On the topic of what will be the hardest point of interoperability with
> legacy systems, I think it will be ICE like connectivity check issues.
> Every proposal I have seen so far has solved the problem of authorizing
> where the browser can send packets RTP by some connectivity check
> scheme such as ICE. However, ICE is not implemented the major of legacy
> voip equipment and I think this will end up being the biggest factor
> reducing what legacy equipment can work. Someone in the working group
> might think of a clever way to avoid this problem but I have not herd
> one yet.
> 
> I want the charter to clearly allows the WG to figure out the right way
> to map to existing SIP systems. To do this, I think the browser has to
> be able to report what codecs and other extensibility options it
> supports then allow the application to influence what gets used to
> allow negotiation with the far end. In my mind, the current charter,
> particularly point 5 and 6, provide that.
> 
> With regards to backwards compatibility with legacy voip systems, it's
> going to be a balance with tradeoffs.  We can't have a charter that
> says everything must support all legacy devices because the legacy
> device can't even talk to all other legacy devices. I want the WG to be
> able to make these decision and have consensus the balance right before
> publishing the specifications that would come out of the WG. But making
> theses choices is the work in this working group is largely about.
> 
> The WG needs to define an architecture that allows the sort of long
> term extensibility that David mentioned while at the same time make
> sure that systems compliant with the work can done suffer from
> interoperability failures. From my point of view the current charter
> would give the WG the room to make theses choices.
> 
> Cullen
> 
> 
> 
> On Mar 21, 2011, at 8:36 AM, Elwell, John wrote:
> 
> > OK, so what I think Christer and Andy are saying is that it is not
> just about having the right the mandatory-to-implement protocols,
> codecs, etc., but also about sufficient control at the API so that
> appropriate ones can be selected when interoperating with existing
> equipment. I would agree with that. Do Christer and Andy consider my
> text proposal for the charter to be sufficient, or does it need
> changing or extending?
> >
> > John
> >
> >> -----Original Message-----
> >> From: Hutton, Andrew
> >> Sent: 21 March 2011 14:16
> >> To: Elwell, John; Christer Holmberg; Ted Hardie
> >> Cc: rtc-web at alvestrand.no
> >> Subject: RE: [RTW] New proposed charter text. Please review
> >> before the BoF.
> >>
> >> Hi,
> >>
> >> I think Christer's comment is really important.
> >>
> >> If the web application is going to be responsible for
> >> ensuring interoperability with SIP or anything else then the
> >> API between the browser and the web application needs to be
> >> flexible and powerful to enable this interoperability to take
> >> place. So I believe the charter needs to make it clear that
> >> the input for this API that the IETF provides to W3C will
> >> take in to account the fact that the web application has to
> >> achieve interoperability with non RTC-Web based systems of
> >> which SIP/SDP based systems are the obvious example.
> >>
> >> Regards
> >> Andy
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: rtc-web-bounces at alvestrand.no
> >>> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Elwell, John
> >>> Sent: 21 March 2011 07:41
> >>> To: Christer Holmberg; Ted Hardie
> >>> Cc: rtc-web at alvestrand.no
> >>> Subject: Re: [RTW] New proposed charter text. Please review
> >>> before the BoF.
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Christer Holmberg [mailto:christer.holmberg at ericsson.com]
> >>>> Sent: 19 March 2011 11:22
> >>>> To: Ted Hardie; Elwell, John
> >>>> Cc: rtc-web at alvestrand.no
> >>>> Subject: RE: [RTW] New proposed charter text. Please review
> >>>> before the BoF.
> >>>>
> >>>> Hi,
> >>>>
> >>>> Regarding interoperability (or, creating new solutions in
> >>>> general), there are a couple of things we need to consider.
> >>>>
> >>>> One is of course the protocols supported by the browser (e.g
> >>>> RTP, ICE etc).
> >>>>
> >>>> The second, which I THINK John is referring to, is to ensure
> >>>> that web applications (whether they are SIP based or based on
> >>>> something else) are able to ENABLE the browser protocols and
> >>>> features in a good and effective way. For that we need to
> >>>> ensure that the API between the browser and the web app is
> >>>> powerful enough.
> >>> [JRE] That might be one of the consequences - if the browser
> >>> is able to use a protocol that is not interoperable with
> >>> existing equipment and a protocol that is interoperable, then
> >>> clearly an application wanting to interoperate would want to
> >>> be able to choose the latter.
> >>>
> >>> That was not the main point of my proposed addition to the
> >>> charter - the main point was that the set of
> >>> mandatory-to-implement protocols in the browser should
> >>> include those that can interoperate in a reasonable way with
> >>> existing equipment. Based on discussions to date, the most
> >>> problematic is likely to be codecs, particularly video
> >>> codecs, because of the cost and performance degradation when
> >>> transcoding has to be done.
> >>>
> >>> John
> >>>
> >>>
> >>>>
> >>>> In the ucreqs document, we have tried to differentiate
> >>>> between those two things by having separate browser
> >>>> requirements and API requirements.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>> ________________________________________
> >>>> From: rtc-web-bounces at alvestrand.no
> >>>> [rtc-web-bounces at alvestrand.no] On Behalf Of Ted Hardie
> >>>> [ted.ietf at gmail.com]
> >>>> Sent: Friday, March 18, 2011 7:38 PM
> >>>> To: Elwell, John
> >>>> Cc: rtc-web at alvestrand.no
> >>>> Subject: Re: [RTW] New proposed charter text. Please review
> >>>> before the BoF.
> >>>>
> >>>> On Fri, Mar 18, 2011 at 10:17 AM, Elwell, John
> >>>> <john.elwell at siemens-enterprise.com> wrote:
> >>>>> Ted,
> >>>>>
> >>>>> In the same way that charters tend to call out "horizontal"
> >>>> topics for special mention, such as security, privacy and
> >>>> NAT/firewall, I believe the ability to achieve interop with
> >>>> existing equipment should also be given a mention.
> >>>>
> >>>> Hi John,
> >>>>
> >>>> Unsurprisingly, I am also a fan of interoperability.  But I think
> >>>> there are multiple ways to scope interoperability.  The charter
> >>>> currently does it by focusing on the interoperability we
> >> get at the
> >>>> protocol level, largely by choosing tools for this toolkit
> >>> that match
> >>>> the tools already in place (e.g. RTP, ICE, etc.).  I agree that we
> >>>> shouldn't select tools that are in place but unusable.  I
> >>> think we end
> >>>> up having to trust the working group on this anyway, as it
> >>> will decide
> >>>> which tools are unusuable even if we insert a "don't pick unusable
> >>>> tools" section.
> >>>>
> >>>> So the basic question boils down to:  do we also want to
> >>> assert a need
> >>>> for interoperability with a specific application or set of
> >>>> applications in the charter?
> >>>>
> >>>> My personal take is no.  Those are use cases, and important
> >>> ones.  But
> >>>> the charter is focused on building a toolkit "to enable
> >>> innovation on
> >>>> top of a set of basic components."  I have no doubt that
> >>> someone will
> >>>> be able to build a fully backwards compatible service using these
> >>>> components and a gateway,.  But the more important charter
> >>> goal is to
> >>>> get the component set right to enable them to build more
> >> than that.
> >>>> And I think calling out that specific use case is more
> >>> likely to limit
> >>>> our vision than to result in more clarity in picking protocols and
> >>>> tools.
> >>>>
> >>>> Again, just my personal opinion,
> >>>>
> >>>> regards,
> >>>>
> >>>> Ted Hardie
> >>>>
> >>>>> Note that I stop short of demanding backwards compatibility,
> >>>> but instead make a somewhat more flexible proposal.
> >>>>>
> >>>>> Using defined protocols isn't necessarily sufficient if we
> >>>> pick things that are not implemented. As an extreme case,
> >>>> take S/MIME, for example.
> >>>>>
> >>>>> John
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Ted Hardie [mailto:ted.ietf at gmail.com]
> >>>>>> Sent: 18 March 2011 17:01
> >>>>>> To: Elwell, John
> >>>>>> Cc: rtc-web at alvestrand.no
> >>>>>> Subject: Re: [RTW] New proposed charter text. Please review
> >>>>>> before the BoF.
> >>>>>>
> >>>>>> On Fri, Mar 18, 2011 at 5:04 AM, Elwell, John
> >>>>>> <john.elwell at siemens-enterprise.com> wrote:
> >>>>>>> Ted,
> >>>>>>>
> >>>>>>> I think there needs to be some mention of interop with
> >>>>>> existing real-time applications using IETF protocols (such as
> >>>>>> SIP, RTP). Something along the lines of:
> >>>>>>> "Work should take account of browser-based applications
> >>>>>> that require to interoperate with existing applications using
> >>>>>> IETF protocols such as SIP and RTP and commonly deployed
> >>>>>> audio and video codecs. Solutions that require mediation
> >>>>>> functions to achieve interoperation might be acceptable,
> >>>>>> provided such functions are not unduly complex, expensive or
> >>>>>> detrimental to performance."
> >>>>>>>
> >>>>>>
> >>>>>> So, my personal read is that these work items:
> >>>>>>
> >>>>>> "4.     Define which RTP functions and extensions shall be
> >>>> supported
> >>>>>> in the client and their usage for real-time media,
> >>> including media
> >>>>>> adaptation to ensure congestion safe usage.
> >>>>>> 5.     Define what functionalities in the solution,
> >> such as media
> >>>>>> codecs, security algorithms, etc., can be extended and how the
> >>>>>> extensibility mechanisms works.
> >>>>>> 6.     Define a set of media formats that must or should
> >>>> be supported
> >>>>>> by a client to improve interoperability."
> >>>>>>
> >>>>>> and this general statement which follows the work items:
> >>>>>>
> >>>>>> "This work will be done primarily by using already defined
> >>>> protocols
> >>>>>> or functionalities. "
> >>>>>>
> >>>>>> Those seem to cover the same ground as your "take
> >>> account of".  If
> >>>>>> your aim is to get to something more concrete, like "you
> >>>> must be able
> >>>>>> to build a browser-based SIP softphone using the tools
> >>>> identified by
> >>>>>> this group", I think you need to unpack that a bit more.
> >>>> Some of the
> >>>>>> presence aspects of that toolkit, for example, may not be
> >>>> identified
> >>>>>> here.
> >>>>>>
> >>>>>> To put this another way, my personal read is that
> >> we're aiming to
> >>>>>> create the toolkit needed to build real-time media
> >>>> applications in web
> >>>>>> contexts.  Any specific application, including a SIP
> >>>> softphone, would
> >>>>>> be a use of the toolkit; those will be covered by
> >> something like
> >>>>>> draft-holmberg-rtcweb-ucreqs-00.txt as a use case, rather
> >>>> than in the
> >>>>>> charter.
> >>>>>>
> >>>>>> Again, just my personal take on this.
> >>>>>>
> >>>>>> regards,
> >>>>>>
> >>>>>> Ted Hardie
> >>>>>>
> >>>>>>
> >>>>>>> John
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: rtc-web-bounces at alvestrand.no
> >>>>>>>> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of
> >> Ted Hardie
> >>>>>>>> Sent: 17 March 2011 16:18
> >>>>>>>> To: rtc-web at alvestrand.no
> >>>>>>>> Subject: [RTW] New proposed charter text. Please review
> >>>>>>>> before the BoF.
> >>>>>>>>
> >>>>>>>> Name: Real-Time Communication in WEB-browsers (RTCWeb)
> >>>>>>>>
> >>>>>>>> There are a number of proprietary implementations that
> >>>>>> provide direct
> >>>>>>>> interactive rich communication using audio, video,
> >>>> collaboration,
> >>>>>>>> games, etc. between two peers' web-browsers. These are not
> >>>>>>>> interoperable, as they require non-standard extensions or
> >>>>>> plugins to
> >>>>>>>> work.  There is a desire to standardize the basis for such
> >>>>>>>> communication so that interoperable communication can be
> >>>>>> established
> >>>>>>>> between any compatible browsers. The goal is to enable
> >>>>>> innovation on
> >>>>>>>> top of a set of basic components.   One core component
> >>>> is to enable
> >>>>>>>> real-time media like audio and video, a second is to
> >>>>>> enable datagram
> >>>>>>>> and byte stream data transfer directly between clients.
> >>>>>>>>
> >>>>>>>> This work will be done in collaboration with the W3C.
> >>>> The IETF WG
> >>>>>>>> will produce architecture and requirements for selection
> >>>>>> and profiling
> >>>>>>>> of the on the wire protocols. The architecture needs to be
> >>>>>> coordinated
> >>>>>>>> with W3C.  The IETF WG work will identity state
> >>>>>> information and events
> >>>>>>>> that need to be exposed in the APIs as input to W3C. The
> >>>>>> W3C will be
> >>>>>>>> responsible for defining APIs to ensure that
> >>>> application developers
> >>>>>>>> can control the components.
> >>>>>>>>
> >>>>>>>> The security goals and requirements will be developed by
> >>>>>> the WG. The
> >>>>>>>> security model needs to be coordinated with the W3C.
> >>>> The work will
> >>>>>>>> also consider where support for extensibility is needed. RTP
> >>>>>>>> functionalities, media formats, security algorithms are
> >>>> example of
> >>>>>>>> things that commonly needs extensions, additions or
> >>>>>> replacement, and
> >>>>>>>> thus some support for negotiation between clients
> >> is required.
> >>>>>>>>
> >>>>>>>> The WG will perform the following work:
> >>>>>>>> 1.     Define the communication model in detail, including
> >>>>>> how session
> >>>>>>>> management is to occur within the model.
> >>>>>>>> 2.     Define a security model that describes the security
> >>>>>> goals and
> >>>>>>>> how the communication model can achieve these goals.
> >>>>>>>> 3.     Define how NAT and Firewall traversal is to occur.
> >>>>>>>> 4.     Define which RTP functions and extensions
> >> that shall be
> >>>>>>>> supported in the client and their usage for real-time
> >>>>>> media, including
> >>>>>>>> media adaptation to ensure congestion safe usage.
> >>>>>>>> 5.     Define what functionalities in the solution,
> >>>> such as media
> >>>>>>>> codecs, security algorithms, etc., that can be extended
> >>>> and how the
> >>>>>>>> extensibility mechanisms works.
> >>>>>>>> 6.     Define a set of media formats that must or should
> >>>>>> be supported
> >>>>>>>> by a client to improve interoperability.
> >>>>>>>> 7.     Define how non RTP datagram and byte stream data
> >>>>>> communication
> >>>>>>>> between the clients can be done securely and in a
> >>>>>> congestion safe way.
> >>>>>>>> 8.     Provide W3C input for the APIs that comes from the
> >>>>>>>> communication model and the selected components and
> >>>>>> protocols that are
> >>>>>>>> part of the solution.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> This work will be done primarily by using already defined
> >>>>>> protocols or
> >>>>>>>> functionalities. If there is identification of missing
> >>>> protocols or
> >>>>>>>> functionalities, such work can be requested to be done
> >>>> in another
> >>>>>>>> working group with a suitable charter or by requests for
> >>>>>> chartering it
> >>>>>>>> in this WG or another WG. 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, Location services, IM & Presence,
> >>>>>> Resource Priority.
> >>>>>>>>
> >>>>>>>> The products of the working group will support security
> >>>>>> and keying as
> >>>>>>>> required by BCP 61 and be defined for IPv4, IPv6, and
> >>> dual stack
> >>>>>>>> deployments. The Working Group will consider the
> >>> possibility of
> >>>>>>>> defining a browser component that implements an
> >>> existing session
> >>>>>>>> negotiation and management protocol. 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.
> >>>>>>>>
> >>>>>>>> Milestones:
> >>>>>>>>
> >>>>>>>> Aug 2011 Architecture and Security and Threat Model
> >>> sent to W3C
> >>>>>>>>
> >>>>>>>> Aug 2011 Use cases and Scenarios document sent to W3C
> >>>>>>>>
> >>>>>>>> Sept 2011 Architecture and Security and Threat Model to IESG
> >>>>>>>> as Informational
> >>>>>>>>
> >>>>>>>> Sept 2011 Use cases and Scenarios for RTCWeb document sent
> >>>>>> to IESG as
> >>>>>>>> Informational
> >>>>>>>>
> >>>>>>>> Dec 2011 RTCWeb and Media format specification(s) to
> >>> IESG as PS
> >>>>>>>>
> >>>>>>>> Dec 2011 Information elements and events APIs Input to W3C
> >>>>>>>>
> >>>>>>>> Apr 2012 API to Protocol mapping document submitted to
> >>>> the IESG as
> >>>>>>>> Informational (if needed)
> >>>>>>>> _______________________________________________
> >>>>>>>> RTC-Web mailing list
> >>>>>>>> RTC-Web at alvestrand.no
> >>>>>>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
> >>>>>>>>
> >>>>>>
> >>>> _______________________________________________
> >>>> RTC-Web mailing list
> >>>> RTC-Web at alvestrand.no
> >>>> http://www.alvestrand.no/mailman/listinfo/rtc-web
> >>> _______________________________________________
> >>> RTC-Web mailing list
> >>> RTC-Web at alvestrand.no
> >>> http://www.alvestrand.no/mailman/listinfo/rtc-web
> >>>
> >>
> > _______________________________________________
> > RTC-Web mailing list
> > RTC-Web at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtc-web
> 
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web