Re: error handling

I think we need the ability to surface details about the error; also, an
error could occur at any time, not just while handshaking (e.g. upon
receipt of a DTLS alert).

So while a 'failed' state may make sense, it may be better to simply have
errors trigger a change to "closed" with an accompanying .onerror callback
that surfaces a detailed error object.


On Sun, Jan 26, 2014 at 1:16 PM, Adalberto Foresti (MS OPEN TECH) <
aforesti@microsoft.com> wrote:

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