- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 12 Sep 2014 22:19:29 -0700
- To: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Cc: "public-ortc@w3.org" <public-ortc@w3.org>
I don't know if there's a document. That's just what I remember from discussions. In particular, I remember Martin talking about it. I'm sure there are subtle differences. On Fri, Sep 12, 2014 at 10:18 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote: > 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:20:37 UTC