Re: Issue 48: Undefined RTCRtpListener behavior

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