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

[Bernard Aboba <[e-mail]>]

Magnus said:

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

[BA] I do agree that this is a basic scenario that should work. However,
Section 5.2.1 of draft-ietf-rtcweb-rtp-usage indicates that RFC 6051 is
RECOMMENDED, but not mandatory.

"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?"

[BA]Today in audio scenarios the use of a=ssrc is not very prevalent
outside of WebRTC, and yet the switching scenario you describe still
typically works without an additional O/A exchange.  So a developer
experienced in legacy systems might be surprised if another O/A exchange
was needed.  So I wonder if the a=ssrc line should always be required (and
if it is not there, whether the audio scenario should be expected to "just
work").

One argument in favor of requiring a=ssrc is that at the RTP level the
switching scenario may not be that easily distinguished from a scenario
where multiple SSRCs are being received at once (where a mediadiscarded
Event might be appropriate).  Also, in video scenarios the a=ssrc line is
much more common (e.g. where one of several simulcast streams is being
received, the SSRC can change along with characteristics of the video such
as framerate and resolution).

Overall though, IMHO the behavior in this scenario is currently
under-specified.  The Unified Plan document included some text relating to
this, but it doesn't seem to have made its way into any WG work items.

On Wed, Jun 3, 2015 at 5:37 AM, Magnus Westerlund <
[e-mail]> 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.
>
> 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
>