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

[Harald Alvestrand]

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