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

Magnus Westerlund <> Mon, 01 June 2015 09:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F4CC1A90D9 for <>; Mon, 1 Jun 2015 02:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rNXdFQwmGssZ for <>; Mon, 1 Jun 2015 02:19:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1F461A90D8 for <>; Mon, 1 Jun 2015 02:19:35 -0700 (PDT)
X-AuditID: c1b4fb3a-f79ec6d000006dc0-9a-556c23a54011
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BB.D9.28096.5A32C655; Mon, 1 Jun 2015 11:19:33 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 1 Jun 2015 11:19:33 +0200
Message-ID: <>
Date: Mon, 01 Jun 2015 11:19:32 +0200
From: Magnus Westerlund <>
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 <>,,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvre5S5ZxQgz33FC1e9qxktzjW18Vm 8WbrMmYHZo8rE66weizYVOqxZMlPpgDmKC6blNSczLLUIn27BK6M429nshYsEamYfPgTcwPj XIEuRk4OCQETiXVPprNB2GISF+6tB7OFBI4ySqz6qdzFyAVkL2OU+PZgEjtIgldAW+Lax92s IDaLgIrE99s3WEBsNgELiZs/GsGaRQWiJKY+XscCUS8ocXLmEzBbRCBQYte6DrBeYQE3ic37 N0Et05FY0TQVLM4poCux4dFsoF0cHMwC9hIPtpaBhJkF5CWat85mhijXlmho6mCdwCgwC8mG WQgds5B0LGBkXsUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGKQHt/y22sF48LnjIUYBDkYl Ht4Fe7JDhVgTy4orcw8xSnOwKInzenaFhAoJpCeWpGanphakFsUXleakFh9iZOLglGpgnG2s F3LIxfoby6vyXBb5TQ5cK0WaksO+5SiWt/gm5zXv8SyUXxM5dd+rycdPtlVfPvT92uZ7gtlq 2W5rTs6+9lvOTcIv3LKEV+zY+iXzpVfa9x40Wmvy+0nuJOYL+1Yzc//9nly+U2jm9I/PY/0f ZCt1tkSVLbZL+e/h8C3o7l3HXvHYxIlaSizFGYmGWsxFxYkABdvDLzMCAAA=
Archived-At: <>
Subject: Re: [AVTCORE] Query: Reporting SSRC when you send no streams?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jun 2015 09:19:37 -0000

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 
( 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.


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: