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

[Markus.Isomaki at nokia.com]

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

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. 

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. 

Markus