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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------