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

[Harald Alvestrand <[e-mail]>]

On 06/03/2015 02:37 PM, Magnus Westerlund wrote:
> Hi,
>
> I want raise for discussion the fact that I think JSEP does not handle 
> RTP payload type switching as currently specified.
>
> So lets walk through a case of RTP payload type switching and what it 
> means according to the specifications we do have.
>
> So we have an established PeerConnection with one audio track for 
> which we have negotiated the possibility to send both PCM and OPUS. If 
> the sender decides to switch RTP payload type, lets say from OPUS to 
> PCM. The reason is actually not important, but lets say due to a 
> "replace track" API call as currently being discussed on W3C WebRTC 
> group.
>
> When that RTP payload type switch from OPUS to PCM we also have an RTP 
> timestamp rate change, from 48 kHz to 8 kHz. As specified in RTP usage 
> (Section 4.3):
>
>    If performing changes between two RTP payload types that use
>    different RTP clock rates, an RTP sender MUST follow the
>    recommendations in Section 4.1 of [RFC7160].
>
> So lets look at what RFC 7160 says:
>
> 4.1.  RTP Sender (with RTCP)
>
>    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.
>
> Thus, this Payload type change forces the use of a new SSRC.
>
> This in itself should not be a significant issue. The binding to the 
> right media block in the SDP is done using MID. Which, will be sent in 
> an RTP header extension to ensure that stream upon reception is 
> correctly associated. The RTP synchronization information will arrive 
> in RTCP or even in the RTP header extension if the peers both supports 
> RFC 6051. Thus minimal media impacts is to be expected.
>
> But, discussing what happens in this case with Stefan Håkansson we did 
> look into JSEP. And here we clearly have some short commings in the 
> specification.
>
> A. First of all there is an assumption that the value of a=ssrc will 
> not change. For example Section 5.2.2 (Subsequent Offers):
>
>   o  For MediaStreamTracks that are still present, the "a=msid",
>       "a=ssrc", and "a=ssrc-group" lines MUST stay the same.
>
> If an RTP payload type switching has occured that forces a SSRC change 
> then I expect that the actually used SSRCs are included in the offer. 
> Thus, both a=ssrc and a=ssrc-group can change in subsequent offers.

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.

> B. The next question is if a RTP payload type change actually requires 
> the node that performs the change to actually initiate an Offer/answer 
> exchange to update their a=ssrc values?
>
> Clearly JSEP needs to be updated to address these issues.
>
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb