- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Sat, 13 Sep 2014 06:29:43 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: Bernard Aboba <Bernard.Aboba@microsoft.com>, "public-ortc@w3.org" <public-ortc@w3.org>
I remember the discussion too, which as I recall came up as part of the "plan" discussions. For example, your suggested rules seem compatible the discussion in Section 3.2 of: http://tools.ietf.org/html/draft-roach-mmusic-unified-plan However, I cannot seem to find that material in WG work item to cite. > On Sep 12, 2014, at 22:20, "Peter Thatcher" <pthatcher@google.com> wrote: > > 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 06:30:18 UTC