Re: Issue 48: Undefined RTCRtpListener behavior

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:12:32 UTC