[RTW] Comments on draft-alvestrand-dispatch-rtcweb-protocols-00
Stefan Håkansson LK
stefan.lk.hakansson at ericsson.com
Sun Jan 2 08:43:49 CET 2011
>>In general I believe we need a framework document that describes how
>>the various protocol and API specs are used to build an interoperable
>>"RTC-Web" implementation. In my opinion that document should not be
>>like RFC 5411 (Hitchhiker's guide to SIP), which is merely listing of
>>different SIP related standards. Instead, the RTC-Web framework
>>document should define what is the minimum set that everyone needs to
>>implement to get interop at a reasonable level. (What that reasonable
>>level is needs to be agreed upon, of course. I assume it includes at
>>least transport and NAT traversal for audio/video streams.)
>I agree, and that is where I want this to go. In addition, we need use case documentation that allows us to verify that >the use cases we envision are satisfiable within the framework.
We also need to decide were such a FW doc should be developed. IETF could be a natural place, but it is quite close in definition to the "Profile" recommendation proposed by the draft W3C charter.
//Stefan
> -----Original Message-----
> From: rtc-web-bounces at alvestrand.no
> [mailto:rtc-web-bounces at alvestrand.no] On Behalf Of Harald Alvestrand
> Sent: den 2 januari 2011 07:45
> To: Markus.Isomaki at nokia.com
> Cc: rtc-web at alvestrand.no; dispatch at ietf.org
> Subject: Re: [RTW] Comments on
> draft-alvestrand-dispatch-rtcweb-protocols-00
>
> On 12/30/10 17:10, Markus.Isomaki at nokia.com wrote:
> > Hi,
> >
> > A few comments and questions on rtcweb-protocols-00:
> >
> > In general I believe we need a framework document that
> describes how
> > the various protocol and API specs are used to build an
> interoperable
> > "RTC-Web" implementation. In my opinion that document should not be
> > like RFC 5411 (Hitchhiker's guide to SIP), which is merely
> listing of
> > different SIP related standards. Instead, the RTC-Web framework
> > document should define what is the minimum set that
> everyone needs to
> > implement to get interop at a reasonable level. (What that
> reasonable
> > level is needs to be agreed upon, of course. I assume it
> includes at
> > least transport and NAT traversal for audio/video streams.)
> I agree, and that is where I want this to go. In addition, we
> need use case documentation that allows us to verify that the
> use cases we envision are satisfiable within the framework.
> > I understand that the current document is not yet intended for that
> > purpose, but it is just trying to get discussion started. But if we
> > pick this draft as a baseline going forward, it would be useful to
> > make the use of language more consistent. At the moment some things
> > are defined with "MUST" statements while others are more vague. I
> > think the "MUST" statements are good and everything that is really
> > required by an implementation needs to be expressed that
> way. (It is
> > naturally good to have some descriptive text around the exact
> > requirements, as long as the requirements are clear.)
> Yes, the vagueness is in direct proportion to how far I'm
> away from being able to read some sort of consensus that
> stuff needs inclusion. As discussion goes forward, I expect
> it to be sharpened.
> Note that even the MUSTs are merely trial balloons at the
> moment - I wouldn't be unhappy with carrying most of them
> forward, but it is highly likely that some of them are wrong,
> and others may want to be left open rather than mandated.
> Discussion will show.
> > Section 4 defines data framing and security. I believe the
> challenging part of data framing will be to ensure we get the
> video calls interoperable. I don't have that much experience
> on the details, but I know that getting RTP/AVPF stuff
> implemented and interoperable is not that trivial. Various
> groups such as IMTC and UCIF have worked on interoperability
> profiles for video calls. The easy approach might be just to
> mandate the basics (RTP/AVP), get that well working across
> browsers and then extend based on that experience. If those
> other groups come up with something useful and public, those
> profiles could be borrowed.
> Agreed 100%. It might even help interoperability. Do you have
> citable references to the current state of that work?
> I'm worried about not including AVPF, since there is stuff in
> AVPF (including the various NACKs and reference frame
> requests) that is vital for getting efficient reliable
> communication over lossy networks using some of the potential
> codecs. Matter for further discussion.
> > Section 6 is about connection management. That will be the
> really hard part of this exercise. I do support the notion
> that at least initially we should focus on transport, framing
> and formats of media, and say that those can be setup in
> proprietary ways (presumably the browser using HTTP or
> websocket as transport for the actual setup). For that the
> APIs would "only" need to support what is input/output to
> ICE/STUN/TURN and codec selection, while the rest happens in
> Javascript within the application. But going forward I think
> we do need to pick up either SIP/SDP or XMPP/Jingle as the
> baseline, in order to make things easy to use.
> If we can have a common definition of "connection" that we
> can offer up (through APIs) to SIP/SDP engines or XMPP/Jingle
> engines as "the object to be manipulated", I think we've
> already won a lot. I don't want to trap us at the forefront
> of more battlefronts than we have to have.
> While it would be nice to have only one engine to relate to,
> I am afraid of bringing this discussion into this group.
> > Markus
> >
> >
>
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
More information about the RTC-Web
mailing list