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

[Magnus Westerlund <[e-mail]>]

Den 2017-03-21 kl. 16:07, skrev Bernard Aboba:
> 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.

When one receives an RTCP BYE, one can't remove the SSRC immediately, 
there needs to be a bit a shorter timeout before its state is removed to 
avoid this issue.

This is quite clear even in RFC 3550, Section 6.2.1 says:

    Entries MAY be deleted from
    the table when an RTCP BYE packet with the corresponding SSRC
    identifier is received, except that some straggler data packets might
    arrive after the BYE and cause the entry to be recreated.  Instead,
    the entry SHOULD be marked as having received a BYE and then deleted
    after an appropriate delay.


>
> 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.

I think this is clearly a valid reason for receiving a BYE, packet, and 
in fact you can receive multiple BYEs in this case, one from each 
endpoint attempting to use the same SSRC. But, that should be visable 
due to the different CNAME entries in the compound RTCP packet.

This is a valid case where one might not be removing the entry. In some 
cases a particular endpoint may not be aware of the collision and 
continue to transmit using the SSRC that collided while the other 
endpoint is changing the SSRC.

However, I don't see an issue with removing the entry after the above 
considerations has been applied, as neither are related to if the state 
is signalled or not.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------