[RTW] Comments on draft-alvestrand-dispatch-rtcweb-protocols-00

[Stefan Håkansson LK]

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