RE: Error handling

That all sounds perfectly reasonable to me.

I think that on point 2, the role that a particular peer plays doesn’t really matter long term.  People talk about this potentially changing over time, which I find suspect, but it does suggest that these needn’t be fixed.  I think that in terms of reporting, it might be good to know who is who, but that’s secondary.  To avoid confusion, it’s also perfectly sound to make a “suggestion”.

From: Robin Raymond [mailto:robin@hookflash.com]
Sent: Thursday, 31 October, 2013 8:25
To: Martin Thomson
Cc: public-orca; Anniruddh Koppal (Persistent Systems Ltd.)
Subject: 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]



[cid:image001.jpg@01CED61A.636573D0]
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 :)