error handling

An area where the spec does not delve into much detail yet is the error handling strategy. To make an example among other possible ones:

RTCDtlsTransport does not offer any way to communicate failure to establish transport currently. There is neither a failure callback in the constructor, nor a "failed" state. A possible way to address this is to add such a "Failed" state to the RTCDtlsTransportState enum and use it to notify via onstatechange event.

Thoughts? (on either this specific scenario or the more general issue)



Adalberto Foresti
Principal Program Manager
Microsoft Open Technologies, Inc.
A Subsidiary of Microsoft Corporation



-----Original Message-----
From: Robin Raymond [mailto:robin@hookflash.com] 
Sent: Wednesday, January 22, 2014 8:48 PM
To: public-orca
Subject: Proposed RTCRtpSender / Receiver / DTLS and Ice objects draft update


After feedback from the community, I've decided to incorporate Peter's RTCRtpSender / Receiver and dtls / ice object split concepts / proposals.

I've incorporated the ideas proposed thus far:

http://htmlpreview.github.io/?https://raw2.github.com/robin-raymond/ortc/1c2065af84d21882203f6f735f06d181312cc6ec/ortc.html


As compared to the previous version:
http://htmlpreview.github.io/?https://raw2.github.com/openpeer/ortc/1458338dbfe13dcabb2f0d9d5ddb73e490e23a5a/ortc.html


These changes have some impact and require some fixes as a result:
1) RTCSocket - this object is still required to allow for forking situations, but perhaps should be renamed to something more appropriate and also likely something that can be passed into the RTCIceTransport instead. We still need Ice server options which are currently missing from the proposal too.

2) RTCStream - not sure having a stream object makes much sense anymore if we treat each MediaStreamTrack as an independent thing constructed from and RTCRtpSender / RTCRtpReceiver object, and it's also no longer obtainable from the RTCIceTransport (formerly known as RTCConnection)

3) RTCDTMFTrack - this object doesn't make much sense anymore and I think we should entertain proposals on how to rework this idea into a new model (left in document to be reworked)

4) RTCDataChannel - this object now requires some reworking because it doesn't wire the same way give the Dtls/Ice object split.

5) Dtls fingerprinting needs to be incorporated into the dtls object

I'll have more feed back to provide in subsequent emails to follow...

Regards,
Robin

Received on Sunday, 26 January 2014 21:17:38 UTC