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

[Magnus Westerlund <[e-mail]>]

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

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------