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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 01 July 2015 08:41 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E21A1A12 for <avt@ietfa.amsl.com>; Wed, 1 Jul 2015 01:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wA4vsJq92EZ for <avt@ietfa.amsl.com>; Wed, 1 Jul 2015 01:41:09 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B4B1A1A06 for <avt@ietf.org>; Wed, 1 Jul 2015 01:41:08 -0700 (PDT)
X-AuditID: c1b4fb30-f79706d000007227-a9-5593a7a2f91f
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.11.29223.2A7A3955; Wed, 1 Jul 2015 10:41:06 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Wed, 1 Jul 2015 10:41:06 +0200
Message-ID: <5593A7A1.1030406@ericsson.com>
Date: Wed, 01 Jul 2015 10:41:05 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>, avt@ietf.org, pbos@google.com
References: <556C1EFB.8060005@alvestrand.no> <558036DF.2020807@ericsson.com>
In-Reply-To: <558036DF.2020807@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje6i5ZNDDb6+M7N42bOS3eJYXxeb xZuty5gdmD2uTLjC6rFgU6nHkiU/mQKYo7hsUlJzMstSi/TtErgyls0+wVzQaFfRtV6xgXGh fhcjB4eEgInEzeUuXYycQKaYxIV769m6GLk4hASOMko86V7MAuEsY5TY9raBCaSKV0Bb4vad PmYQm0VARWLz+/1gNpuAhcTNH41sILaoQJTE1MfrWCDqBSVOznwCZosIBErsWtfBCmILC7hJ bN6/iQ3kCCEBH4n77ZYgYU4BHYknDVfBwswC9hIPtpaBhJkF5CWat84G2yQEdEFDUwfrBEaB WUgWzELomIWkYwEj8ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwAA9uOW3wQ7Gl88dDzEK cDAq8fAu9JwcKsSaWFZcmXuIUZqDRUmcd8bmvFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jNFvzOx2cwa26ZW2cEzv1m3oaZDXm7K73GOjva4By2H/zbfCF1zaofZF68aNL3d/nT9tP/Xs qzm3P1jXLPPgmz+htFHg1XnLTdeThLbXzduzgn+H9A6dY/tXBwhOm5zz6ZVs2ASFzCx298c/ ZFnPGgYfEQn22JK77c3NSa4vGpuW59yaHje774ESS3FGoqEWc1FxIgBwWXXbMQIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/FonhBXg3l0tADSip2ChUL8pXW-0>
Subject: Re: [AVTCORE] Query: Reporting SSRC when you send no streams?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 08:41:11 -0000

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  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


-- 

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------