Re: Issue 48: Undefined RTCRtpListener behavior

Peter Thatcher said:

"A few comments:

1. nit:  withn -> within

2.  Why are we using parameters.encodings[i].codecPayloadType on the
receiver side?  Shouldn't we be using parameters.codecs[i].payloadType?  I
would expect the value of parameters.encodings[i].codecPayloadType to
basically be ignored on the receiver side (except perhaps for when needed
for receiving FEC or RED)

[BA] Good point.

3.  I don't think we need to get to the detail of saying "ssrc is set to
zero" or "muxId is set to the empty string".  We just need to specify that
with no SSRC set, the SSRC match is effectively a wild card, or likewise
for the muxId.

[BA] Right.

4.  If we get a packet with muxId X, and there is no RtpReceiver with muxId
X, then it will route the packet to any RtpReceiver that understands the
PT.  I think this is a mistake.  I think an unset muxId should not mean
wild card.  It should mean "match packets with an unset muxId".

[BA] You're probably right.  If an RTP packet has a muxId, it is probably meant for a Receiver with a muxId matching rule, so it shouldn't match a rule with an unset muxId.

5.  As an alternative to the receiver table, I suggest a ruleset using just
three simple maps:  ssrc => receiver, muxId => receiver, and PT =>
receiver.    Then the rules would be:

a.  (Fill ssrc => receiver) Set ssrc_table[ssrc] = receiver for each ssrc
in the parameters.encodings passed to each receiver  by
RtpReceiver.receive().
b.  (Fill muxid => receiver) Set muxid_table[muxId] = receiver for the
parameter.muxId passed to each receiver by Receiver.receive()
c.  (Fill PT => receiver) Set pt_table[pt] = receiver for each pt in
parameters.codecs passed to each receiver by Receiver.receiver(), but only
if parameters.muxId is unset and no ssrcs are in parameters.encodings.
d.  (Avoid collisions) If ssrt_table[ssrc], muxid_table[muxId], or
pt_table[pt] would ever be set to a conflicting value, the call to
Receiver.receive (or Receiver.setTransport) will fail with an exception.

[BA] Can you elaborate on what you mean by "conflicting value"?

e.  (SSRC match) If receiver = ssrc_table[packet.ssrc] is set, route the
packet to the receiver.  But if the receiver does not understand packet.PT,
fire the unhandledrtp event.

f.  (muxId match and SSRC latch) If packet.muxId is set and receiver =
muxid_table[packet.muxId] is set, route the packet to the receiver and set
ssrc_table[packet.ssrc] = receiver.  But if the receiver does not
understand packet.PT, fire the unhandledrtp event.

g.  (muxId unmatched) If packet.muxId is set and muxid_table[packet.muxId]
is unset, fire the unhandledrtp event.

h.  (PT match and SSRC latch) If receiver = pt_table[packet.pt] is set,
route the packet to the receiver and set ssrc_table[packet.ssrc] = receiver.

Not that this means empty muxId is not wildcard, and receivers with set
muxIds and SSRCs also don't accept packets with muxIds or SSRCs outside of
the set ones.  I think that's more what we want then so much wild card
behavior.  And, I think this is a more simple set of rules that is easier
to implement.

What do you think?"

[BA] At first glance, the above rules appear to work for the use cases posted here: http://lists.w3.org/Archives/Public/public-ortc/2014Dec/0014.html

Not sure that this is a complete set of use cases, though (or that I understand the proposal fully enough to understand how it would apply).

Received on Tuesday, 9 December 2014 18:40:23 UTC