- From: Roman Shpount via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Feb 2017 19:24:18 +0000
- To: public-webrtc-logs@w3.org
I do not think RFC 4572 allows media playback before SDP answer. Ideal behavior is to process and decode media, but not to pass it for playback so that media can be played as soon as answer is received without waiting for the new iframe. From what I understand this is the proposed behavior when allowUnverifiedMedia flag is not set. This being said, if you set the allowUnverifiedMedia flag and do allow media playback before answer is received, then you need to take into account that signaling normally goes over some sort of centralized infrastructure while media goes direct between two end points. Signaling often traverses multiple servers, which are non-local, can become temporary overloadedm or fail-over. Things which result in user detectable issues (and starting playback and then stopping and then starting again is such as issue), should be avoided. In case of services that we operate, in case of fail-over, signaling can be delayed up to about 16 sec. The 5 sec delay will not be sufficient for me since it will require a much more frequent heartbeat monitoring between signaling servers. Even in case of two end points on the same network communicating with remote signaling server, simple internet connection disruption can cause TCP packet delay which is higher then 5 sec which will in turn delay the answer. -- GitHub Notification of comment by rshpount Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279808261 using your GitHub account
Received on Tuesday, 14 February 2017 19:24:25 UTC