- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Sat, 13 Sep 2014 05:18:10 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-ortc@w3.org" <public-ortc@w3.org>
Yes, this would handle the use cases. Is there a document we can cite for this, or do we need to write it down (and risk subtle differences)? > On Sep 12, 2014, at 10:12 PM, "Peter Thatcher" <pthatcher@google.com> wrote: > > I think the latching should be exactly the same as WebRTC 1.0, which I > believe is: > > 1. If the SSRC is recognized, use it. > 2. If the muxId is recognized, use it and latch the SSRC. > 3. If the payload type uniquely routes the packets (only one > RtpReceiver with that payload type), use it and latch the SSRC. > 4. If none of those, fire the "unhandled" event. > > I think that would cover all of the use cases. > > On Wed, Sep 10, 2014 at 3:37 PM, Bernard Aboba > <Bernard.Aboba@microsoft.com> wrote: >> One of the longest outstanding issues relating to the ORTC API has been the >> behavior of the latching rules (see: >> https://github.com/openpeer/ortc/issues/48) that govern how an incoming RTP >> packet is steered to an existing RTCRtpReceiver object (or if such an object >> cannot be identified, when an RTPUnhandled Event is thrown). >> >> >> >> Now that other aspects of the API are more solid, it is a good time to come >> back to the latching rules (and in particular, the goals for those rules). >> >> >> >> Several use cases come to mind: >> >> >> >> 1. Payload Type matching. For audio applications where only a single >> stream is expected, it would be useful if it were not necessary to specify >> RTCRtpEncodingParameters.ssrc or RTCRtpParameters.muxId in either >> RTCRtpReceiver.receive() or RTCRtpSender.send(), only to provide a Payload >> Type value in RTCRtpCodecParameters.payloadType. >> >> 2. SSRC conflict handling. As we have discussed, if the developer >> does not specify SSRCs within the RTCRtpParameters object passed to >> RTCRtpSender.send(), then the browser chooses the SSRCs, and an >> RTCSsrcConflictEvent is never thrown (see Section 6.4). Since there is no >> way for the developer to retrieve the new SSRC value (or the originally >> chosen value for that matter), it would be highly desirable for the latching >> rules to make it unnecessary for the application developer to need this >> information. As an example, fi the developer originally set >> RTCRtpParameters.muxId when calling RTCRtpSender.send(), but did not set >> RTCRtpEncodingParameters.ssrc, it would be useful if the latching rules >> caused the RTP stream with the newly chosen SSRC and the same muxId to be >> steered to the same RTCRtpReceiver that received the stream with the >> previous SSRC and muxId. >> >> >> >>
Received on Saturday, 13 September 2014 05:18:40 UTC