diff --git a/lib/installer-exclude/libjitsi.jar b/lib/installer-exclude/libjitsi.jar index fad55b6ae..ec4ab1595 100644 Binary files a/lib/installer-exclude/libjitsi.jar and b/lib/installer-exclude/libjitsi.jar differ diff --git a/src/net/java/sip/communicator/service/protocol/media/MediaAwareCallPeer.java b/src/net/java/sip/communicator/service/protocol/media/MediaAwareCallPeer.java index bdc84a6e2..d9e1733b9 100644 --- a/src/net/java/sip/communicator/service/protocol/media/MediaAwareCallPeer.java +++ b/src/net/java/sip/communicator/service/protocol/media/MediaAwareCallPeer.java @@ -1182,4 +1182,33 @@ public void setConfInfoScheduled(boolean confInfoScheduled) * mediaType that we have with this CallPeer. */ public abstract MediaDirection getDirection(MediaType mediaType); + + /** + * {@inheritDoc} + * + * When a ConferenceMember is removed from a conference with a + * Jitsi-videobridge, an RTCP BYE packet is not always sent. Therefore, + * if the ConferenceMember had an associated video SSRC, the stream + * isn't be removed until it times out, leaving a blank video container in + * the interface for a few seconds. + * TODO: This works around the problem by removing the + * ConferenceMember's ReceiveStream when the + * ConferenceMember is removed. The proper solution is to ensure + * that RTCP BYEs are sent whenever necessary, and when it is deployed this + * code should be removed. + * + * @param conferenceMember a ConferenceMember to be removed from + * the list of ConferenceMember reported by this peer. If the + * specified ConferenceMember is no contained in the list, no event + */ + @Override + public void removeConferenceMember(ConferenceMember conferenceMember) + { + MediaStream videoStream = getMediaHandler().getStream(MediaType.VIDEO); + if (videoStream != null) + videoStream.removeReceiveStreamForSsrc( + conferenceMember.getVideoSsrc()); + + super.removeConferenceMember(conferenceMember); + } }