Re: Issue 48: Undefined RTCRtpListener behavior

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