W3C ORTC Community Group Meeting #9
June 24, 2015 10:00AM-11:30AM PDT
Chair: Erik Lagerway (erik@hookflash.com)
W3C CG IPR Policy
Welcome!
About this Virtual Meeting
Information on the meeting:
W3C ORTC Community Group Basics
Associated Sites
Editor’s Draft Changes
Changes from the 07 May Editor’s Draft:
Phillip Hancke’s Review (Issue 198).
Editorial: Philipp Hancke’s Review (Issue 198)
Philipp Hancke’s Review (cont’d)
Editor’s Draft Changes
ICE
RTCWEB/WebRTC 1.0 compatibility
RTCIceCandidateComplete (Issue 207)
May Editor’s draft:
typedef (RTCIceCandidate or RTCIceCandidateComplete) RTCIceGatherCandidate;
dictionary RTCIceCandidateComplete {�};
Proposed change:
typedef (RTCIceCandidate or RTCIceCandidateComplete) RTCIceGatherCandidate;
dictionary RTCIceCandidateComplete {� boolean complete = true;�};
Justin: This seems kind of bizarre, an event with a variable that is only set to a single value. Can't this be handled entirely through IceGathererStateChange?
Robin: IceGatherStateChange tells the local peer that “candidates are complete”. The question is how that information is signaled over the wire and then provided in RTCIceTransport.addRemoteCandidate(). The proposal is to use the RTCIceCandidateComplete dictionary for that purpose, so that state changes are triggered by calling RTCIceTransport.addRemoteCandidate(RTCIceCandidateComplete). Having one attribute seems cleaner than signaling null and passing that to addRemoteCandidate.
Revised RTCIceTransportState Definitions
Enumeration description | |
new | The RTCIceTransport object is waiting for remote candidates to be supplied. In this state the object can respond to incoming connectivity checks. |
checking | The RTCIceTransport has received at least one remote candidate, and a local and remote RTCIceCandidateComplete dictionary was not added as the last candidate. In this state the RTCIceTransport is checking candidate pairs but has not yet found a successful candidate pair, or liveness checks have failed (such as those in [CONSENT]) on a previously successful candidate pair. |
connected | The RTCIceTransport has received a response to an outgoing connectivity check, or has received incoming DTLS/media after a successful response to an incoming connectivity check, but is still checking other candidate pairs to see if there is a better connection. In this state outgoing media is permitted. |
completed | A local and remote RTCIceCandidateComplete dictionary was added as the last candidate to the RTCIceTransport and all appropriate candidate pairs have been tested and at least one functioning candidate pair has been found. |
disconnected | The RTCIceTransport has received at least one local and remote candidate, and a local and remote RTCIceCandidateCompletedictionary was not added as the last candidate, but all appropriate candidate pairs thus far have been tested and failed (or consent checks [CONSENT], once successful, have now failed). Other candidate pairs may become available for testing as new candidates are trickled, and therefore the "failed" state has not been reached. |
failed | A local and remote RTCIceCandidateComplete dictionary was added as the last candidate to the RTCIceTransport and all appropriate candidate pairs have been tested and failed. |
closed | The RTCIceTransport has shut down and is no longer responding to STUN requests. |
Revised ICE State Diagram (199, 216)
Red = additional transitions due to consent loss (connected -> checking) and pending decisions around "what is continuous nomination" (failed -> checking)
Statistics API Error Handling (Issue 214)
Goal: same behavior as in WebRTC 1.0. But what is that?
11 June Editor’s draft (http://w3c.github.io/webrtc-pc/#statistics-model) Section 8.2.1:
However, there is an open issue to return the last stats object instead:
https://github.com/w3c/webrtc-stats/issues/3
Also, a Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1056433
Statistics API Error Handling (cont’d)
The May ORTC Editor’s draft sez (in Section 13.1):
Why??
Statistics API Error Handling (cont’d)
Proposal:
RTCDtmfSender sync with 1.0 (Issue 215)
Goal: same behavior (and spelling!) as in WebRTC 1.0.
But what is that?
11 June Editor’s draft (http://w3c.github.io/webrtc-pc/#peer-to-peer-dtmf ) Section 7:
Same spelling in WebRTC 1.0 and ORTC:
insertDTMF, onetonechange, toneBuffer, duration, interToneGap
Different spelling in WebRTC 1.0 and ORTC:
RTCDTMFSender vs. RTCDtmfSender in ORTC)
RTCDtmfSender sync with 1.0 (cont’d)
Peter Thatcher’s suggestion on the public-webrtc mailing list:
https://lists.w3.org/Archives/Public/public-webrtc/2015Jun/0052.html
I like your rule, which I read as "we use CamelCase, except for that RTC thing at the beginning that we're stuck with".��I'm in favor of changing DTMFSender to be DtmfSender. I don't think there are any backwards compatibility issues with changing the type name (it's just a search and replace in the spec and code base). While we're at it,�can we change the event objects with "RTCDTMF" to "RtcDtmf" as well? Might as well be consistent.��The only change that would have some compatibility implications would be the insertDTMF method. As much as I would like that to be insertDtmf, I'm willing to live with it being insertDTMF.
Questions for the CG
For Discussion Today
Coming Attractions
Support for “generation” (Issue 212)
From Philipp:
How does RTCIceCandidate does deal with the extensibility defined in RFC 5245 -- https://tools.ietf.org/html/rfc5245#section-15.1 (extension-att-name etc). For example, the generation attribute from http://xmpp.org/extensions/xep-0176.html#protocol-syntax is pretty common (e.g. supported in Chrome).
Robin Raymond:
generation does not apply to ORTC since the candidates come from the gatherer which never changes its usernameFragment / password. The restart mechanism happens in the IceTransport which can take a substitute gatherer. So the tracking of the generation has to happen at a high level.
Privacy (Issue 213)
From Philipp Hancke's review comments:
18) page 12, section 3.11 (RTCIceCandidate)
DOMString relatedAddress = "";
unsigned short relatedPort;
I don't think those attributes are useful, just a potential leak of ip addresses when forcing turn-only relays. So I would not expose them.
32) page 20, section 5.8
can be used to reduce leakage of IP addresses in certain use cases.
add a note about setting rel-addr to 0.0.0.0 then
Privacy (cont’d)
Martin Thomson:
Yes, this is a privacy issue, but those values are used to handle some corner cases in the deduplication algorithm. I'd be OK with them being replaced with (salted) hashes or something like that, but then you wouldn't be able to use SDP.
Robin Raymond:
I think the real answer is that the browser will have to enact a privacy mode to hide away the real IP addresses…
Question: Given the desire to maintain compatibility with WebRTC 1.0, is there anything we should do in the ORTC API?
Are these three different problems (each with their own solution), or three symptoms of the same problem?
Three different problems?
Or three symptoms of the same problem?
partial interface RTCPeerConnection {� static Promise<RTCCertificate> generateCertificate (AlgorithmIdentifier keygenAlgorithm);�};
Proposed RTCDtlsTransport changes
partial interface RTCCertificate {� static Promise<RTCCertificate> generateCertificate (AlgorithmIdentifier keygenAlgorithm);�};
[Constructor(RTCIceTransport transport, RTCCertificate certificate)]
partial interface RTCDtlsTransport {� //...�};
Reasoning:
Responding to connectivity checks (Issue 170)
(IMPORTANCE - reminder)
Responding to incoming ICE connectivity checks immediately is desirable to provide faster media setup:
Responding to connectivity checks (Issue 170)
(Agreed Solution "RTCIceTransport constructor")
[Constructor(RTCIceGatherer)]
partial interface RTCIceTransport {
readonly attribute DOMString remoteUsernameFragment; // can get auto-filled
readonly attribute RTCIceRole role; // can get auto-filled
attribute EventHandler? onremotetransportlatched; // needed? use case?
};
// Example:
var iceGatherer = new RTCIceGatherer(..);�var iceTransport = new RTCIceTransport(iceGatherer,..);�var dtlsTransport = new RTCDtlsTransport(iceTransport,..);
Responding to connectivity checks (Issue 170)
Proposed solution to race condition
Problem:
Potential race condition between programmer calling RTCIceTransport.start() with a usernameFragment / role different that an auto-latched incoming remote ICE usernameFragment / role due to asynchronous API;
Solution:
Add a factory method that constructs a brand new RTCIceTransport object with a specific username fragment or fetch a previously associated RTCIceTransport which was auto-latched to the usernameFragment passed in an atomic fashion.
[Constructor(optional RTCIceGatherer gatherer)]
partial interface RTCIceTransport {� //...
static RTCIceTransport createOrUseExisting(RTCIceGatherer gatherer, DOMString usernameFragment);�};
Responding to connectivity checks (cont’d)
(Race condition for incoming DTLS packet before DTLS constructed)
Problem:
Very small window where RTCIceTransport constructed from an RTCIceGatherer (and ready to respond to connectivity checks), but RTCDtlsTransport has not yet been constructed from the RTCIceTransport (so buffering is still needed): �
var iceGatherer = new RTCIceGatherer(..);�var iceTransport = new RTCIceTransport(iceGatherer,..);�// tiny race window where ICE response can be sent but no DTLS transport wired yet�var dtlsTransport = new RTCDtlsTransport(iceTransport,..);
Solution:
Buffer a few packets to prevent the DTLS "hello" packet being lost / retransmitted.
Responding to connectivity checks (Issue 170)
(Questions for ORTC CG)
Question for Community Group:
Are there any comments regarding known deficiencies of the ORTC API at this time?
Good time to speak before implementation is too far along!
Organization / Call for implementation feedback
Mobile C++ ORTC implementation:
https://github.com/openpeer/ortc-lib-sdk
ORTC JS "shims" (i.e. downshim and upshim to / from WebRTC 1.0)
https://github.com/openpeer/ortc-js-shim (vacant repo)
ORTC specification:
https://github.com/openpeer/ortc
ORTC Node JS implementations:
https://github.com/openpeer/ortc-node
Browser Implementations:
Requested at this time (status.modern.ie lists ORTC as "In Development")
ORTC-lib Update
Work on ORTC-lib continues.
If you would like to participate in coding any of the ORTC open source projects then:
Thank you
Special thanks to:
Bernard Aboba - Microsoft
Michael Champion - Microsoft
Justin Uberti - Google
Peter Thatcher - Google
Robin Raymond - Hookflash
Erik Lagerway - Hookflash
For More Information