Re: Error handling

Yes, Annirudh does bring up good points:

- error handling / statistics

[RR] Agreed. Some issues are complete failure cases, others are 
recoverable, others are more statistics of ongoing smaller 
failures/glitches. I think the first step here is identifying the nature 
of all the possible errors and how to handle them.

- RTCConnection.connect/close

[RR] One time use only. There's just too much ambiguity in my mind to 
handle a reconnection, especially given ICE effectively has to redo the 
connectivity checks and we have to gather candidates again in many 
situations.

- RTCConnection.removeStream

[RR] Agreed. It should just stop sending over RTP, no harm in restarting 
I think. The media track being closed cannot be restarted but that's a 
separate condition.

- RTCTrack / pause

[RR] I have no preference. If there's already a method on the media 
track this might be redundant. However, it might be that you want to 
keep the media track going but pause to particular people on the 
receiving end using the same track, in which case a pause method has value.

- RTCTrack / remove

[RR] I would prefer a pause. I guess I'd have to see the use cases on 
this one myself. I'm not sure how I feel about it either.

[RR]  ---

Other points to 'fix / clarify':
1) I don't like the way DTMF is done, I just have to fix that. It 
shouldn't be in the main interface and be independent. I like Martin's 
earlier proposal which is similar to what I had envisioned too.
2) I've got a problem with the "roles" factor in the ICE. It's not clear 
who is the connector / connectee. That needs to have clarification to 
avoid needless ICE role conflicts.
3) Data channel - I would like a similar approach to DTMF
4) IANA's role - that needs to be clarified to get the agreements on 
what defines a codec and its parameters out of this spec, there's no 
reason we can't namespace codecs and have the definition of each codec 
tied to its respective namespace
5) getters/setters vs attributes - I'd like to see more attributes and 
less getters / setters
6) errors/statistics - repeating, but it's pretty important

---[RR]


> Martin Thomson <mailto:martin.thomson@gmail.com>
> 21 October, 2013 2:23 PM
> Annirudh raised a number of good questions about the specification.
>
> This points to a greater concern: the level of consideration given to
> error handling is probably inadequate.
>
> · For RTCConnection, should there be an ‘onerror’ event too ?
>
> [MT] I should think so. At some point, it makes sense to report that
> we are no longer able to proceed. With trickle ICE, this relies on a
> signal that there are no more candidates forthcoming. Of course, this
> is a network, and things change, but we do want to be able to build
> user-level feedback into applications.
>
> · For RTCConnection.connect/close, once an established
> connection is closed by user and later if they try to connect again,
> should the process start from scratch like exchanging track
> information etc. or try to re-establish connection with available data
> ?
>
> [MT] I'd like to see RTCConnection be a one-use object. Reusing
> objects tends to make code more brittle. GC is cheap enough.
>
> · For RTCCOnnection.removeStream, should the linked
> RTCTracks be stopped and removed too if this stream is the only stream
> they are linked to?
>
> [MT] I would hope that removing streams only disconnects them from
> consideration. Note that stopped tracks cannot be restarted.
>
> · For RTCTrack, should there be a ‘pause’ method too ?
>
> [MT] There is an enabled property on the MediaStreamTrack. While my
> preference is for an explicit pause()/resume() on network
> transmission, I believe that other groups are tending toward the use
> of enabled=true/false for this purpose.
>
> · For RTCTrack.remove(), how should the track be
> ‘un-removed’ or perhaps enabled again if the user wishes to ?
>
> [MT] I don't like this concept much, so I'm not going to comment 
> further :)
>