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

Harald Alvestrand <harald@alvestrand.no> Wed, 03 June 2015 14:33 UTC

Return-Path: <harald@alvestrand.no>
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 610791A895B for <avt@ietfa.amsl.com>; Wed, 3 Jun 2015 07:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 5JxKWDdXhLZg for <avt@ietfa.amsl.com>; Wed, 3 Jun 2015 07:33:46 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97E1A8958 for <avt@ietf.org>; Wed, 3 Jun 2015 07:33:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6DBE37C0946; Wed, 3 Jun 2015 16:33:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD73ehe4Yye1; Wed, 3 Jun 2015 16:33:43 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:e536:c983:6fc4:1d46]) by mork.alvestrand.no (Postfix) with ESMTPSA id DD6CD7C02CC; Wed, 3 Jun 2015 16:33:42 +0200 (CEST)
Message-ID: <556F1046.6020102@alvestrand.no>
Date: Wed, 03 Jun 2015 16:33:42 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, avt@ietf.org, pbos@google.com
References: <556C1EFB.8060005@alvestrand.no> <556C23A4.4050500@ericsson.com>
In-Reply-To: <556C23A4.4050500@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/vOnE7pNSrSdF2FcSkAZVJrAQrT0>
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: <http://www.ietf.org/mail-archive/web/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, 03 Jun 2015 14:33:48 -0000

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:
> Harald Alvestrand skrev den 2015-06-01 10:59:
>> This came up in a WebRTC-related context:
>>
>> 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.
>
>
>>
>> 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 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.
>
>>
>> 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...
>
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>