Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching

[Magnus Westerlund <[e-mail]>]

Roman Shpount skrev den 2015-06-04 23:02:
> On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>     If we want to have a mechanism that:
>
>     a) allows PT switching
>     b) uses different clock rates (and therefore different SSRCs)
>     c) doesn't need renegotiation on SSRC change
>
>     I would think that the initial SDP would have to contain a=ssrc
>     fields for *all* the possible SSRCs - that is, one "a=ssrc:<nnnn>
>     cname:<cname>" line per payload type.
>
>     Section 5.2.1 already specifies that there will be multiple a=ssrc
>     lines (and a=ssrc-group lines) in the case of RTX data. So it's not
>     exactly a novel solution.
>
>
> I agree with one small correction -- it is not a separate SSRC per
> payload type, but separate SSRC per clock rate. For instance, if you
> have G.711 audio, RFC 4733 tones and CN at 8KHz, there is going to be a
> payload type for each of them, but all this media should use the same
> SSRC. Opus, RFC 4733 tones and CN at 48Khz (and you will need to specify
> to different payloads for tones and CN for different clock rates), will
> use second SSRC.
>
> The reason for separate SSRCs is to have RTCP reports to work correctly,
> which requires to use the same time units for all the media under
> particular SSRC. Multiple payloads running with the same clock rate can
> re-use the same SSRC without any issues. It actually is beneficial to
> use the same SSRC since they can be synchronized based on the RTP time
> stamps which would be more precise then ntp time.

However, this can't work as RFC 7160 says in Section 4.1:

   An RTP Sender with RTCP turned on MUST use a different SSRC for each
    different clock rate.  An RTCP BYE MUST be sent and a new SSRC MUST
    be used if the clock rate switches back to a value already seen in
    the RTP stream.

Note the second sentence. One would still have to do a new round of 
signalling to prime a new SSRC for the previous rate after having 
switched to be able to switch back to that Payload Type.


I would to some degree argue that renegotiation is not needed here. My 
preference would be for a solution that rather use header extensions to 
indicate what "purpose" the new RTP stream has so that one understands 
that this is the replacement for an earlier RTP stream.

For the cases where a source is encoded into a single encoded stream and 
put in one RTP stream I think all the necessary indications are there. 
MID for which m line it belongs. The PT will indicate if it a source RTP 
stream or an Redundancy RTP stream (FEC or RTX).

It is when one comes to scalability layers sent in multiple RTP streams 
it becomes problematic to determine on RTP level which is which, without 
looking into payload header info to determine which layer the payload 
contains.

Having said that I do wonder if this will be a problem, especially in 
gateways to legacy. Where this behaviour will make the legacy peer fall 
over. Thus requiring a gateway that remap back to a single stable SSRC, 
possibly with loss of synch information. Please remember that there are 
reasons why the SSRC change was made as the required behaviour.

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