If the application provided RTCRtpRtxParameters.ssrc to send() then an SSRC Conflict Event will be thrown in event of a conflict. The application would then substitute an alternate SSRC for the conflicting one and call send() again. Note that if ssrc is unset, the browser will choose it (see Section 9.11.1) and an SSRC Conflict Event will not be thrown - the browser will fix the conflict on its own. As to how the application should choose a new SSRC, calling a cryptographic random number generator (e.g. RandomSource.getRandomValues in WebCrypto API, NOT Math.random()) would make sense. Example 7 in Section 6.5 could show how this would work. On Aug 22, 2014, at 10:27 AM, Iñaki Baz Castillo <notifications@github.com<mailto:notifications@github.com>> wrote: How is the application supposed to set the SSRC in case of rtx in which a different SSRC is required? See for example the SDP that Chrome Canary generates (some attributes filtered): m=video 50171 RTP/SAVPF 100 116 117 96 a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=rtpmap:96 rtx/90000 a=fmtp:96 apt=100 a=ssrc-group:FID 627174652 1381966277 a=ssrc:627174652 cname:638pIYStIf81SFYg a=ssrc:627174652 msid:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse 86db55fa-2187-4823-aa85-ebc45476e7ce a=ssrc:627174652 mslabel:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse a=ssrc:627174652 label:86db55fa-2187-4823-aa85-ebc45476e7ce a=ssrc:1381966277 cname:638pIYStIf81SFYg a=ssrc:1381966277 msid:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse 86db55fa-2187-4823-aa85-ebc45476e7ce a=ssrc:1381966277 mslabel:Xu3aJz6U26OYp0MPbbk9WP2GJp6LBydxOIse a=ssrc:1381966277 label:86db55fa-2187-4823-aa85-ebc45476e7ce — Reply to this email directly or view it on GitHub<https://github.com/openpeer/ortc/issues/143#issuecomment-53092848>.
Received on Friday, 22 August 2014 19:13:40 UTC