Having duplicate ssrcs for just SRTCP is still really problematic from a crypto perspective. You'll either need to fix your media server, or perhaps work around by using multiple PeerConnections.

Best regards,
Byron Campen

On 2/22/16 8:55 AM, Alexander Abagian wrote:
The server is not awaiting different video SSRCs from the single participant. Unified Plan makes Firefox to 
add extra m-section to local SDP with "recvonly" attribute for other participants then the first 
one. (Logically they are could not be needed at all; the browser have to send single audio and sigle video 
stream to the server, and that's all). Despite of "recvonly" attribute, the Firefox, being a single 
participant from the server's point of view,  sends RTCPs with different SenderSSRC (pointed in that 
"recvonly" m-sections a=ssrc attributes), which is unsupported by the media server.

So, Firefox acts as if it uses different RTP sessions for each peer, but 
actually it works inside a single multi-party RTP session.

I don't need to replace ssrcs for real RTP streams, but need it for RTCP RR 
packets.





On Monday, February 22, 2016 at 5:12:17 PM UTC+3, Byron Campen wrote:
On 2/22/16 8:00 AM, Alexander Abagian wrote:
Is it possible to force Firefox to use the same SSRC of the same media type for 
each participant ?
      No, because if we did that we would be breaking spec pretty badly;
the whole point of an SSRC is to have a unique identifier, and lots of
stuff breaks if they aren't unique (including compromising the security
of SRTP).

      What problem are you trying to solve here?

Best regards,
Byron Campen
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media

_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media

Reply via email to