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

[Bernard Aboba <[e-mail]>]

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.