Re: [rtcweb] JSEP-19: Impact of BYE on ssrc table (Appendix B)

[Bernard Aboba <[e-mail]>]

Consider the impact of calling transceiver.stop().  This stops the sender,
and then sends a BYE.  However, due to reordering, the RTCP BYE can arrive
while there are still RTP packets in flight, and if the signaled SSRCs are
removed they will be thrown away unnecessarily.

Another cause of a BYE could be an SSRC conflict.  However, in this case we
should expect MID SDES packets as well as the MID RTP header extension to
be emitted with the new SSRC, so that a new "latched" entry will be
installed. Therefore removing "latched" entries on receipt of a BYE does
not have the same consequences.

On Tue, Mar 21, 2017 at 10:16 AM, Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> I have to agree with Cullen here. If one sends a RTCP BYE on an SSRC that
> is signalled, then one better do an signalling update with a new signalled
> SSRC before starting the RTP stream if one changes ones mind about it being
> ended.
>
> Cheers
>
> Magnus
>
> Den 2017-03-17 kl. 03:30, skrev Cullen Jennings:
>
>>
>> Looking at the RTP specs ... it seems like it would not matter if an
>> endpoint initially learned about a SSRC via RTP or SDP, either way it
>> seems like the state for the SSRC should be mostly removed at the BYE.
>> Thoughts on why we would handle them differently ?
>>
>> (If we do need to handle them differently, this looks like an OK approach
>> )
>>
>>
>> On Mar 10, 2017, at 3:31 PM, Bernard Aboba <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>> In the algorithm described in Appendix B, SSRCs that are entered into
>>> the SSRC table due to signalling are not distinguished from those that
>>> are "latched" into the table dynamically.
>>>
>>> The distinction is important because only "latched" SSRCs should be
>>> removed due to receipt of a BYE (or a timeout).
>>>
>>> My suggestion of how to address this is to add a "D" flag to an SSRC
>>> table entry, indicating that the entry was added dynamically.
>>>
>>> For example:
>>>
>>>       If the packet has a MID, and the packet's extended sequence number
>>>       is greater than that of the last MID update, as discussed in
>>>       [RFC7941], Section 4.2.6
>>> <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the
>>> incoming SSRC mapping table
>>>       to include an entry [with the "D" flag set] that maps the packet's
>>>       SSRC to the "m=" line for that MID.
>>>
>>> Also:
>>>
>>>       If the packet's payload type is in the payload type table, update
>>>       the the incoming SSRC mapping table to include an entry
>>>       [with the "D" flag set] that maps the packet's SSRC to the "m="
>>>       line for that payload type.  In addition, route the packet to the
>>>       associated "m=" line and stop.
>>>
>>> Then when a BYE is received, check the "D" flag:
>>>
>>>       If the packet is of type BYE, it indicates that the RTP streams
>>>       referenced in the packet are ending.  Therefore, for each SSRC
>>>       indicated in the packet that is found in the incoming SSRC table,
>>>       first deliver a copy of the packet to the "m=" line associated
>>>       with that SSRC, but then [if the "D" flag is set] remove the
>>>       entry for that SSRC from the incoming SSRC table.
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>