- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Tue, 9 Dec 2014 18:39:51 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
- CC: Peter Thatcher <pthatcher@google.com>
- Message-ID: <BLUPR03MB133E35F119F243642C7156AEC650@BLUPR03MB133.namprd03.prod.outlook.com>
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