Subject: [AVTCORE] Query: Reporting SSRC when you send no streams?

From: Harald Alvestrand <[email-masked]>
Date: Mon, 01 Jun 2015 10:59:39 +0200

This came up in a WebRTC-related context:

If you send no streams, what SSRC should you be using in receiver reports?

If you start sending streams, should your reporting SSRC(s) change?

If you stop sending streams, what should happen? Keep reporting from the 
stream(s) that are gone, or switch to a new (old?) non-sending SSRC?

I'm looking at draft-ietf-avtcore-rtp-multi-stream (and -optimization), 
and they seem to offer plenty of advice for the case where there is more 
than one stream (report on them all in -multi-stream, add them to a 
group in -optimization), but not specifically for the 0->1, 1->0 
transitions.

Of course, I may have overlooked something...

Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 1 Jun 2015 11:19:32 +0200

> If you send no streams, what SSRC should you be using in receiver reports?

You obviously need one, and if there are no known intention to send a 
stream later, then one have to pick one value at random.

> If you start sending streams, should your reporting SSRC(s) change?

I think it is okay for one (first) of the streams that will be sent to 
use the reporting SSRC.

If one consider the multiple clock rates RFC 
(https://datatracker.ietf.org/doc/rfc7160/) one would in most cases 
require a new SSRC. But, the reporting SSRC has no known RTP timestamp 
rate bound to it, prior to picking it. Thus, I don't see a requirement 
to force to use a new SSRC.

However, I also don't see that it would be wrong to use a new SSRC and 
then stop using the previous reporting one. This will of course have the 
down side of reducing the per SSRC bit-rate during the 25+ seconds of 
timeout period for the old reporting.

> stream(s) that are gone, or switch to a new (old?) non-sending SSRC?

I think you should maintain at least one of the SSRCs as reporting SSRC. 
If that has to be replaced if one re-adds streams would depend on the 
timestamp rate, media type and other context associated with the SSRC.

> Of course, I may have overlooked something...

No, I don't think you have overlooked anything.

 From my perspective this could be fit into the 
draft-ietf-avtcore-rtp-multi-stream set of clarifications to ensure 
consistent behaviours. However, I think we need to agree on what the 
recommended behaviour is, and if we make clear that several behaviours 
may occur.

Cheers

Magnus Westerlund

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 03 Jun 2015 16:33:42 +0200

Thanks for the feedback!

One thing I think I overlooked: If I (for other reasons) want to send an 
RTCP BYE on an SSRC, is that also a promise that I won't be using this 
SSRC for sending RR reports?

If so, do I have to jump to another SSRC (possibly a fresh one)?

On 06/01/2015 11:19 AM, Magnus Westerlund wrote:
> then stop using the previous reporting one. This will of course have 
> the down side of reducing the per SSRC bit-rate during the 25+ seconds 
> of timeout period for the old reporting.
>
>
>>
> I think you should maintain at least one of the SSRCs as reporting 
> SSRC. If that has to be replaced if one re-adds streams would depend 
> on the timestamp rate, media type and other context associated with 
> the SSRC.
>
>>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Jun 2015 14:08:10 -0400

> stream later, then one have to pick one value at random.

You also need to track sources and handle any collision with the SSRC
you have picked as usual, potentially re-generating a new one.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 04 Jun 2015 14:09:40 -0400

> SSRC for sending RR reports?

You would use the same SSRC for sending BYEs and RRs.

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 Jun 2015 11:26:03 +0200

> You would use the same SSRC for sending BYEs and RRs.

If one sends RTCP BYE, then the indicated SSRC is going away for any 
usage, RTP or RTCP to my understanding.

Cheers

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Jun 2015 07:58:57 -0600

> usage, RTP or RTCP to my understanding.

Yup. Straight from the RFC:

"BYE SHOULD be the last packet sent with a given SSRC/CSRC."

So if you need to send a BYE for whatever reason but still want to
listen and send RRs, you need to generate a new SSRC.

Simon

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Jun 2015 16:46:55 +0200

Hi,

This is an first draft on some possible text that could be to 
RTP-multi-stream to discuss the raised issues. Please review and provide 
feedback. I have not shown this to my co-authors prior either. We need 
timely feedback on this so that we can improve it prior to the prague 
cut-off. I think the most important questions are. Anything wrong, what 
can we trim, and anything missing?

6.  Adding and Removing SSRCs

    The usage of multiple SSRCs will have the additional effect of making
    it more likely to have dynamic changes in the set of SSRCs, both in
    which SSRCs an endpoint has locally, as well as which the remote
    endpoints uses.  Changes in the set of SSRC an endpoint uses to send
    RTP with are depending on the number of media sources and what
    encodings is produced and their packetization into RTP streams.  So
    these choices affect the number of SSRCs an endpoint currently need
    to have as participant in the RTP session.  Some endpoints may need
    to have a larger number of SSRCs than is currently being used for
    sending media to ensure that it can rapidly start sending.  This as
    the receivers needs the associated context, e.g. clock
    synchronization and SDES CNAME, to be in place when the RTP media
    arrives.

    There are several reasons for why one SSRC may need to be replaced by
    another SSRC.  Changes in how media sources are encoded can for
    example result in the requirement of changing SSRC, see [RFC7160].
    SSRC collisions are another where an endpoint is mandated to change
    its SSRC.

    The transmission of RTCP itself for reporting or feedback also needs
    at least one SSRC.  Thus, an endpoint will need to use at least one
    SSRC even if it currently is in a receiving only mode of operation.
    There exist some considerations if an endpoint changes from an mode
    of receiving only to sending one or more RTP streams for which some
    recommendations can benefit the community.

6.1.  Adding RTP Streams

    When an endpoint joins an RTP session it can have no, one or more RTP
    streams it will or at least is prepared to send.  If it has no RTP
    stream it plans to send with it needs to still generate one SSRC to
    be used for feedback.  If it has one or more RTP streams it will need
    the corresponding number of SSRC values.  The used SSRCs are on RTP
    level made known in the RTP session simply by sending RTP and RTCP
    according to the existing rules, such as the rules for sending
    initial RTCP packets that is clarified in Section 5.2.  The endpoint
    can at any point determine the need for adding an additional RTP
    stream to the RTP session.  At that point the endpoint generates the
    required number of new SSRCs and commence using it.  This, document
    does not discuss any signalling outside of RTP/RTCP that may be
    required due to such an action.

    An endpoint that sent no RTP streams and then determine the need to
    send one or more RTP stream is RECOMMENDED to use the existing SSRC
    for one of these RTP streams.  The reason is that otherwise the
    participant count in the RTP session will be unnecessary increased.
    The participant count will effect the RTCP transmission interval,
    both directly by dividing the RTCP bandwidth between additional
    sources, but also cause additional cross reporting requirements.
    Thus, using an SSRC that so far in the RTP session being only used
    for sending RTCP, and associate it with an RTP stream has no known
    issues.  That will result in that the SSRC becomes associated with a
    particular media type and an RTP timestamp rate from the used payload
    type.

    When adding an RTP stream one can however not re-purpose an existing
    SSRC in many cases, instead one have to add a new SSRC value.  An
    SSRC that an endpoint no longer has any usage for can instead be
    removed from the session.  An existing SSRC can't have its media type
    be changed, nor its RTP timestamp rate per [RFC7160].  One also needs
    to consider what existing bindings that exist to that SSRC in the
    applications and what the RTP stream is used for.  Only if all
    information in the context that exist bound to the SSRC value matches
    the new one can one reuse an SSRC.

6.2.  Removing RTP Streams

    An SSRC is removed from an RTP session in one of two ways.  If no RTP
    or RTCP packets are sent with the SSRC value as source it will time
    out.  However, it is RECOMMENDED to be explicit about when one
    removes an SSRC from usage in an RTP session and send an RTCP BYE
    [RFC3550].  Note, that per RFC3550 the RTCP BYE SHOULD be the last
    RTP/RTCP packet sent in the RTP session for that SSRC at all.  After
    having sent RTCP BYE, if an endpoint needs to send that RTP stream
    again, it needs to generate a new SSRC value as this is now a new
    stream.

    The finality of sending RTCP BYE, means that endpoints needs to
    consider if the ceasing of transmission of an RTP stream is temporary
    or more permanent.  Temporary suspension of media transmission using
    a particular RTP stream (SSRC) should maintain that SSRC as an active
    participant, by continuing RTCP transmission for it.  That way the
    media sending can be resume immediately, knowing that the context is
    in place.  Permanent transmission halting should however, send RTCP
    BYE to allow the other participants to use the RTCP bandwidth
    resources and clean up their state databases.

    When ceasing transmission of RTP streams permanently and intending to
    send RTCP BYE for the streams the endpoint that still will be
    participant in the RTP session needs to keep at least one SSRC in the
    RTP session to be used for RTCP reporting and feedback packets.  As
    some Feedback packets may be bound to media type there might be need
    to maintain one SSRC per media type within an RTP session.  An
    alternative can be to create a new SSRC to use for RTCP reporting and
    feedback.  However, to avoid the perception that an endpoint drops
    completely out of an RTP session such a new SSRC is recommended to be
    first established before terminating the existing SSRCs.

Cheers

Magnus Westerlund

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Jun 2015 11:16:17 -0400

Looks good. One comment:

Le 2015-06-16 10:46, Magnus Westerlund a écrit :
>   An existing SSRC can't have its media type
>    be changed, nor its RTP timestamp rate per [RFC7160].

Surely the media type can be changed, can it not? I'm thinking of
telephone events and comfort noise in particular.

Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 16 Jun 2015 22:49:01 +0200

> telephone events and comfort noise in particular.
The payload type can be changed.

The media type from the m= line (video / audio / application) cannot.

-- 
Surveillance is pervasive. Go Dark.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Jun 2015 16:54:31 -0400

> The media type from the m= line (video / audio / application) cannot.

Ah, right, thanks.

Simon