We briefly touched on this issue at the last ORTC CG meeting, and promised to discuss it more at the next meeting (preferably some time in June). To get the ball rolling, here are some ideas on how implementations might behave if receiver.receiver() or sender.send() are called when encodings is not set. Having this be legal (and well defined) seems desirable for several reasons, including allowing a novice ORTC API developer to code a simple Offer/Answer scenario (e.g. for audio) with minimum fuss (or understanding of RtpEncodingParameters). Some thoughts: When parameters.encodings is not set when calling receiver.receive(parameters), then when an incoming packet matches a pt_table[packet.pt] entry, then an ssrc_table[] entry is added, but the pt_table[] entry is not removed. Default values of RTCRtpEncodingParameters (e.g. active = true) are assumed. When parameters.encodings is not set when calling sender.send(parameters), then the browser chooses an SSRC for the sender, otherwise the default values of RTCRtpEncodingParameters are assumed. Comments? ============================================================================================= Filed by Bernard Aboba: https://github.com/openpeer/ortc/issues/187 It is possible for receiver.receive(parameters) or sender.send(parameters) to be called with parameter.encodings not set. What happens then?
Received on Tuesday, 26 May 2015 20:37:08 UTC