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