We all know that WebRTC and related APIs are a moving target, no surprise there. There is another proposed change in the dataChannel that could break some things for existing developers, if only temporarily.

I am including a recent message from the W3C WebRTC mail list so the developers not following the W3C discussions around WebRTC APIs,  dataChannel et al, will be informed.

From: Randell Jesup (Mozzila)

We’re getting ready to do a major update to the Mozilla DataChannel implementation to reflect the results of the Interim and recent IETF meeting.  I need a quick answer on the direction to take in the update, as we have some compatibility breaks we must do (wireline protocol changes) and want to minimize the pain for developers.

In this change, per the presentation at the Interim that I hope you all paid attention to (but I think everyone was busy worrying about the wireline issues), createDataChannel() would change from:

channel = peerconnection.createDataChannel(label, dictionary_object)
to
channel = peerconnection.createDataChannel(label, protocol, dictionary_object)

Note that this breaks backwards compatibility.  Now that there are existing (if experimental) applications using this API in both Chrome and Firefox, this will impact those developers (though it’s an easy update – but knowing which one to use isn’t, since we don’t version the API, and I don’t want people to have to sniff UAs).

I propose instead moving the protocol field into the dictionary (and so people who don’t care about it can easily ignore it).

In related news, to support external negotiation I propose adding these fields to the dictionary (and I’ll note that the dictionary is woefully out of date, supporting in the spec only “reliable”)

/* If either maxRetransmitTime or maxRetransmitNum are set, it’s
unreliable, else it’s a reliable channel.  If both are set it’s an
error.  outOfOrderAllowed can be used with any type of channel.  The
equivalent of UDP is { outOfOrderAllowed: true, maxRetransmitNum: 0 }.
The TCP equivalent is {}.
preset is true if the channel is being externally negotiated, and no
wireline OpenRequest message should be sent.  If preset is true, stream
can be optionally used to set a specific SCTP stream to use.  If it’s
false but preset is true, then the application should read the ‘stream’
attribute from the returned DataChannel and convey it to the other end
to pass in via the DataChannelInit dictionary.
*/
dictionary DataChannelInit {
boolean outOfOrderAllowed;
unsigned short maxRetransmitTime;
unsigned short maxRetransmitNum;
DOMString protocol;
boolean preset;
unsigned short stream;
};

Should we include ‘reliable’ in the dictionary for back-compatibility?
Firefox has not implemented ‘reliable’ up until now, we’ve had the above
(minus protocol and the new negotiation support). If included, it would be
shorthand for {} or { outOfOrderAllowed:true, maxRetransmitNum:0 }
(depending on value). We’d need verbiage about mixing it with the detailed
members however.

And I added to the DataChannel webidl:

readonly attribute DOMString protocol;
readonly attribute unsigned short stream;

and had previously added:

readonly attribute boolean ordered;

And the question of the existing ‘reliable’ attribute would come up here, though we
can synthesize a value for it from the dictionary values easily per above. We could expose the detailed parameters from the dictionary; I’m not sure that buys us a lot either way

If you have any interest in WebRTC you should follow the W3C list yourself: http://lists.w3.org/Archives/Public/public-webrtc/

Meetecho was kind enough to offer their services for remote participation at the last IETF meeting, and most others I have attended remotely.

Here is the email to the IETF mail list…

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the
RTCWEB WG session at IETF 86 is available at the following URL:
http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEB

In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com.

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

Cheers,
the Meetecho Team

This email has been automatically generated by The Meetecho Conferencing System

The crew at Microsoft is forging ahead with their “CU-RTC-Web” specification as a counter proposal to the new WebRTC / RTCWEB  proposed standard in the W3C and IETF. My colleague Robin Raymond and I certainly align with Microsoft on some issues, more specifically around SDP but it would have been good if this work took place inside the IETF.

I really can’t see Microsoft changing their tune anytime soon, which means that Enterprise web application developers will likely need to support both WebRTC and CU-RTC-Web if they are to be a plugin-less solution enabling RTC across all browsers. Not ideal.

Dr. Cullen Jennings – video quality comparison

There was no consensus call on MTI video for RTCWEB.

There was a “get a sense” call where Robert Sparks, as a favor to the chairs, asked for a sense of the room if they could live with either VP8 or H.264. Since it was not a consensus call it matters little but it felt like the room was split in this hand-raising exercise.

Plenty of arguments were tabled. Hadriel Kaplan made a great point, “…make them both (VP8 & H.264) MTI…” This seems to be the most sensible thing I have heard in a while and it seems to me that this is likely what the browsers would do anyways. Sadly, this will likely never happen in this MTI debate. It seems more likely that we will not end up with a MTI video codec, which is pretty much how things have been in the SIP world since inception.