@rshpount as I've understood it the use case is when the media set-up outraces the SDP answer propagation back to the offerer when the answerer has a legacy device (that can't send a ```pranswer```). That to me says the timeout should be something more like 1 second (in what normal scenarios would the answer take more than 1 second *more* than the media?). The use case is not about handling signaling servers that go down. A fundamental question to me is if ```However, it MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer.``` from RFC 4572 allows playing the media at all before the answer is received. (BTW the PR looks fine to me, except for perhaps the timeout should be more 1 sec than 5 IMO, given this is allowed by 4572) -- GitHub Notification of comment by stefhak Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279804379 using your GitHub accountReceived on Tuesday, 14 February 2017 19:10:44 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC