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

From: Bernard Aboba <[email-masked]>
Date: Fri, 10 Mar 2017 14:31:10 -0800

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.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 10 Mar 2017 16:11:38 -0800

This makes sense to me. Alternatively, we could leave the flag as an
implementation detail, and simply say to cull dynamically created entries
upon receiving a BYE:

      with that SSRC, *and, if it was created dynamically via receipt*

*      of a RTP or RTCP packet*, remove the entry for that SSRC from the

      incoming SSRC table.

On Fri, Mar 10, 2017 at 2:31 PM, Bernard Aboba <[email-masked]>
wrote:

> The distinction is important because only "latched" SSRCs should be
> removed due to receipt of a BYE (or a timeout).
>
>       [RFC7941], Section 4.2.6 <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the incoming SSRC mapping table
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 16 Mar 2017 20:30:52 -0600

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 <[email-masked]> 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: 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Mar 2017 15:16:12 +0100

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 ?
>
>> On Mar 10, 2017, at 3:31 PM, Bernard Aboba <[email-masked]
>> <mailto:[email-masked]>> 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.
>>
>> 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:
>>
>> <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the incoming SSRC mapping table
>> [email-masked] <mailto:[email-masked]>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Mar 2017 11:07:38 -0400

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 <
[email-masked]> 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
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Mar 2017 16:38:17 +0100

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