> It's RTP so it's both XMPP and SIP. Both XMPP and SIP can disable video
> through signalling but the thing is that an RTP stream could also be
> independantly of the signaling session.
> We rely on those BYEs to fire the events that cause the video component
> be removed.
So if a video session is terminated through signaling but a BYE is never
received, the video component stays alive?
If a session is entirely terminated, everything is destroyed. If it's only
downgraded fom AV to A, then yes, the video component would remain there
until a new video stream appears or the call goes down.
This is what happens with asterisk's av echo for example ... and it's
probably not such a big deal.
>> What happens with two clients whose RTCP streams aren't able to "talk"
>> to each other at all?
> I suppose it would worsen user experience to some extent. It wouldn't
> completely break video tho.
>> Both approaches ARE a security problem, as is the current situation
>> (well not from a privacy point of view, but security is not only
>> but attack resiliency as well).
>> While I can't quote an RFC, I think it was/is an error to ever send
>> packets when SRTP is in use. At least SRTCP mandates the use of
>> authentication - because of the sensitive BYE packets.
> This doesn't mean we shouldn't look for ways to smoothen user transition
> if we can.
Of course not
Depending on your answer to my question above:
If the video component is also removed through signaling it's probably not
too much of an issue. If it is not removed, then we should fix that - a BYE
can get lost anyway.
We could. I remember we actually had that on our todo list but then didn't
get around to it. Not sure if it turned out to be tricky or if we simply got
drawn away by other issues.
Also, fixing bye-s would still leave keyframe requests unattended. I dont
think theres an easy way around that which is why I think we should commit
and see exactly how annoying these problems are.
-- sent from my mobile
SRTCP has a mode where the packet content is only authenticated, not
encrypted. We could set that option in the hope that older clients ignore
the SRTCP appendix of each packet. We would of course loose the
confidentiality, it should therefore at least be possible to enable it again
(and by default enabled after some period of time).
> At this point we could probably commit this to unstable and try to
On Oct 15, 2011 7:44 PM, "Bauersachs Ingo" <firstname.lastname@example.org> wrote:
> evaluate how both versions work together.