Re: [rtcweb] JSEP: RTP demux algorithms

Den 23. sep. 2016 10:56, skrev Magnus Westerlund:
> Hi,
> 
> I think the use cases looks fairly covering.
> 
> I want to add an alternative way of thinking on how the SDES item (MID,
> RID) related demultiplexing part is handled. So the RID and MID in RTP
> header extensions or in RTSP SDES packets results in these values being
> bound to the SSRC until further notice. So packets arriving without
> actual RTP header extensions can still be handled according to the SSRCs
> associated SDES items. From my perspective all the cases with MID and
> RID can be handled on a per packet basis rules without latching the SSRC
> to a specific receiver. Instead what is "latched" is the SDES values to
> the SSRC. Still at the point of change there needs to take the
> combination of SSRC and Seq into account to avoid miss routing packets.
> 
> So my general handling algorithm would be this sequence:
> 
> 1. Check if RTP header extensions update any SDES item for the SSRC.
>    a. If they do, mark the Sequence number and keep the old SDES item as
> valid prior to this extended sequence number.
> 
> 2. Determine the set of relevant SDES items that applies for this
> packet, i.e. use SSRC + RTP seq to look up the SDES items, e.g. MID and
> RID.
> 
> 3. Perform the demuxing algorithm

I don't understand this as written.
When an RTP packet arrives before the RTCP packet containing SDES, we
can't latch to the content of the RTCP packet; we haven't seen it yet.

You can, in theory, latch RID and MID for the SSRC to the values in the
SDES packet you haven't seen yet, but that seems somewhat backwards.

The problematic sequence is:

1) RTP packet(s) with header extensions
2) RTP packet(s) without header extensions
3) SDES RTCP packet

(I'm assuming that we require consistency between SDES and RTP header
extensions.
What do we do if they're inconsistent?)

> On another part, I find Jonathan's use case for setting the MID or RID
> using RTCP an interesting one. This put some light on the question that
> in a session where MID and RIDs are configured, if one receive packets
> with an SSRC that lacks these SDES items, what do you do, buffer or
> discard?
> 
> Cheers
> 
> Magnus
> 
> Den 2016-09-16 kl. 21:33, skrev Jonathan Lennox:
>> Just that RTCP counts for latching, and that SSRCs’ MIDs can change.
>>
>>> Agree with both of these.  I think they are both the same as “Whiskey
>>> & Soda Example” - or am I missing something about theses?
>>>
>>>> On Sep 16, 2016, at 11:59 AM, Jonathan Lennox <jonathan@vidyo.com
>>>> <mailto:jonathan@vidyo.com>> wrote:
>>>>
>>>> I’m not going to come up with beverage names for my examples, but
>>>> feel free to make up your own.
>>>>
>>>> 1. The PT are all the same.  An RTCP source description for an SSRC
>>>> contains a MID.  This latches the MID.  Later, RTP packets with this
>>>> SSRC arrive without a MID. They go to the place matching the MID that
>>>> was in RTCP.
>>>>
>>>> 2. The PT are all the same.  A packet contains MID1.  It goes to the
>>>> place that matches MID1, latching the SSRC to MID1.  Later, a packet
>>>> with the same SSRC contains MID2. This moves the latching, so the
>>>> SSRC is now latched to MID2.
>>>>
>>>>
>>>>> On Sep 15, 2016, at 6:18 PM, Cullen Jennings <fluffy@iii.ca
>>>>> <mailto:fluffy@iii.ca>> wrote:
>>>>>
>>>>>
>>>>> To propose a few use case….
>>>>>
>>>>> “Whiskey & Soda Example”
>>>>> The PT are all the same. Early packets, and any packets after a SSRC
>>>>> change, contain a MID. If the packet has  MID, it goes to the place
>>>>> that matches that MID *and* it latches that SSRC so any future SSRC
>>>>> that don’t have a MID go the to the same place.
>>>
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> 
> 