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

[Magnus Westerlund <[e-mail]>]

Hi,

This hasn't gotten any bad feedback, thus I intended to include it in an 
update of draft-ietf-avtcore-rtp-multi-stream.

Cheers

Magnus
(as editor)

Magnus Westerlund skrev den 2015-06-16 16:46:
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>
>


-- 

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