Re: [webrtc-pc] strawman text to show how unverfieid media would work

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 
using your GitHub account

Received on Tuesday, 14 February 2017 19:24:25 UTC