Re: [ortc] Undefined RTCRtpListener behavior (#48)

Yes, the draft does seem to imply that the packet is routed to the same RtpReceiver. This is consistent with SDP O/A semantics where multiple codecs in the answer implies the ability to switch between them and an RtpReceiver needs to be prepared to receive any payload type that was offered.

The issue is how to behave if multiple streams arrive simultaneously.  The RtpReceiver could switch to the latest stream, which should work for simulcast reception as well as the switching audio event. The question is whether an rtpunhandled event should be fired and if so, when.  Given the potential for reordering, the event cannot be fired where there is only minimal overlap  (e.g. A few packets received on the old SSRC after the switch to the new one). This would preclude firing the event for MRST SVC where the SSRCs are interleaved but the RtpReceivers receivers aren't set up properly because SSRCs were not specified. That seems ok - that situation might be appropriate for a MediaDiscarded event.

I think you mean route to RtpReceiver below, correct?

On Feb 2, 2015, at 3:46 PM, pthatcherg <notifications@github.com<mailto:notifications@github.com>> wrote:

I think my proposal is very similar to this draft in the sense that if you
set either the muxID or the SSRC, it's implied that the PTs don't matter
for demux, just like if this constraint mentioned here were off. If muxID
and SSRC are not set, then it's as though the constraint is set (PTs must
be non-overlapping between RtpSenders). So, the behavior between the two
is quite similar.

The part that seems difficult for us is what we do about SSRC latching, and
the big question is: if you are doing PT demux and you get two packets
with the same PT and different SSRCs, what do you do? Do you route them
both to the same RtpSender, or do you drop the second one? Or something
else? This draft seems to imply that we do route it to the same
RtpSender. If so, I'd suggest we just remove all mentions of "ssrc
latching" from my proposal and match what this draft is doing. On the
other hand, I might be missing something in the draft about this.



On Thu, Jan 29, 2015 at 7:01 AM, aboba <notifications@github.com<mailto:notifications@github.com>> wrote:

> Looking at draft-roach-mmusic-unified-plan Section 3.2, it would appear
> that the muxId and ssrc tables from Peter's proposal are consistent with
> the advise given there. The concerns so far seem to arise with respect to
> payload type demultiplexing, covered in Section 3.2.1.2. Since Peter's
> proposal requires PT uniqueness, I believe it behaves as though the
> constraint is set in Section 3.2.1.2 below:
>
> 3.2.1.2. Payload Type Correlation
>
> To support implementations that cannot implement the RTP header
> extension described in Section 3.2.1.1 but which wish to use the
> BUNDLE mechanism, we allow an alternate (but less-preferred) means of
> correlation using payload type. This approach takes advantage of the
> fact that the offer contains payload types chosen by its creator,
> which will be present in any RTP received from the remote party. If
> these payload types are unique, then they can be used to reliably
> correlate incoming RTP streams to their m= lines.
>
> Because of its inherent limitations, it is advisable to use other
> correlation techniques than PT multiplexing if at all possible. In
> order to accomplish this, we propose, for WebRTC, that use of this
> technique be controlled by an additional constraint passed to
> createOffer by the Web application.
>
> If this constraint is set, the browser MUST behave as described in
> this section. If the constraint is not set, the browser MUST use
> identical PTs for the same codec values within each m-line bundle.
>
> When such a constraint is present, implementations attempt to
> entirely exhaust the dynamic payload type numbering space before re-
> using a payload type within the scope of a local transport address.
> If such a constraint is present and the payload type space would
> ordinarily be exhausted within the scope of a local transport
> address, the implementation MAY (at its discretion) take any of the
> following actions:
>
> 1.
>
> Bind to multiple local transport addresses (using different
> BUNDLE groups) for the purpose of keeping the {payload type,
> transport address} combination unique.
> 2.
>
> Signal a failure to the application.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/openpeer/ortc/issues/48#issuecomment-72038723>.
>

—
Reply to this email directly or view it on GitHub<https://github.com/openpeer/ortc/issues/48#issuecomment-72563587>.