Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description

[Magnus Westerlund <[e-mail]>]

Hi,

Please see below for my feedback on this.

Den 2017-02-02 kl. 23:19, skrev Cullen Jennings:
>
>> On Jan 31, 2017, at 10:43 AM, Jonathan Lennox <[e-mail]>
>> wrote:
>>
>> In general, this looks good.
>>
>> I have one question, however.  What should happen if an RTP packet
>> (without a MID) is received for a stream that has an existing
>> mapping to an m= line, but whose PT is not valid for that m= line?
>>
>> Should it 1. Cause the stream’s mapping to be moved to another m=
>> line, if the received PT is in the payload type table for some
>> other m= line? or 2. Be an error?
>
>
> Imagine a case where we have two sends call A and B and they each use
> one PT that is unique and go to different m lines on receiver C via a
> SFU.  Initially C get a packet from B with a given SSRC and the PT
> and creates a mapping for it. But imagine that A and B had an SSRC
> collision which they sort that out and A ends up having the SSRC that
> B initially used. If you don't have the PT override the SSRC, the
> packets are going to go to the wrong m-line because the PT points at
> the m-line A is using but the old SSRC incorrectly points at the
> m-line B is using.
>
> To put this a different way, if the packet has a mid, I think it is
> very clear the mid has to override the PT. Same for the PT. The mid
> is effectively just an extended PT.
>
> I'm not thinking to much about the case where SSRC is signalled in
> SDP but ignoring that case for a second, I think the really easy
> thing to specify, implement, and understand works is simply a
> priority order where roughly
>
> 1) if you have mid, use that and latch the SSRC
> 2) if you have a unique pt, use that and latch the SSRC
> 3) if you have a latched SSRC use that
>
> If you had signaled SSRC, guess I would insert that as step 1.5 of
> use  that
>

The issue as I see it is when and how you update the RTP stream to m= 
line mapping table. I think we have to be clear and separate the actions 
for how the RTP stream to m= line table is built and how it is updated.

Signalling:

Build mid to m= line table
If a=ssrc is used, enter SSRC in RTP stream to m= line table. Add flag 
(signalled) to entry.


On Reception of RTP stream not in RTP stream to m= line table:

1) if you have mid, use that and add to RTP stream table.
2) if you have a unique pt, use that and add to RTP stream table

If the RTP stream is in the RTP stream to m= line table. On RTP packet 
reception check if update is needed:

1) New MID, then update RTP stream entry, unless signalled
2) If PT indicates different m= line, update entry unless signalled or 
set by MID.

The point of looking on the problem from this direction is that we 
actually need to care about what set the entry originally and if it has 
precedence.

Yes, the question of how one removes or updates stale entries are 
important. But this brings out the question for the above. Is an entry 
set by MID to be overwritten by a PT change? Yes, it will be possible to 
construct edge cases where one or the other approach will be 
sub-optimal. However, I think biasing the usage for working correctly 
with MID and having sub-optimal behaviors in other cases that can be 
avoided by for example the SFU not making bad choices, like not 
suppressing SSRC collisions between the different SSRC spaces.

So entry updates are happening for the following reasons.

New SDP: Remove all signalled entries not explicitly included in new 
signalling message. Explicitly listed entries are updated to indicate 
the correct m= line.

RTCP BYE: Remove SSRC from table (using timeout procedure to avoid RTP 
packet reordering from reinstating entry), unless signalled?

SSRC timeout. If the SSRC times out on RTP/RTCP level, then the entry is 
also removed, unless signaled.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------