[jitsi-dev] [jitsi-commits] master: 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


#1

Hello,

When I made this commit we agreed (off-list) that it is a temporary
workaround for the problem of an RTCP bye not being sent by the videobridge.

I now think that "manually" removing ReceiveStream-s from a MediaStream,
when we somehow know (e.g. from signaling) that it won't be used is a
valid thing to do, and therefore the solution should not be considered a
workaround (although the implementation is a bit hackish and should be
improved).

ReceiveStream-s are automatically created (in FMJ) and added to a
MediaStream when a packet with a "new" SSRC arrives. So, removing a
ReceiveStream from a MediaStream is not something final.

I have come upon a different situation (when someone is put on hold) in
which the RTP flow in a video stream stops, but no RTCP bye is sent (and
in fact the stream is kept alive). The result is the same as before --
there is a black video container (or one frozen on a single frame) in
the user interface. It stays there for a few seconds until the
ReceiveStream times out and is removed from the MediaStream.

I think that we should employ a similar solution (remove ReceiveStream-s
from the MediaStream) when someone is put on hold.

Any thoughts?

Regards,
Boris

···

On 7/18/13 12:58 PM, boris@jitsi.org wrote:

Repository : ssh://lists.jitsi.org/jitsi

On branch : master
Link : https://github.com/jitsi/jitsi/compare/c1557f7519c1137bb0b9687303373666d35d71fc...82c41a77473887421350e6dcf81497acf0ec6917

---------------------------------------------------------------

commit 82c41a77473887421350e6dcf81497acf0ec6917
Author: Boris Grozev <boris@jitsi.org>
Date: Thu Jul 18 12:56:38 2013 +0300

    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.
    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.

---------------------------------------------------------------

82c41a77473887421350e6dcf81497acf0ec6917
lib/installer-exclude/libjitsi.jar | Bin 1452379 -> 1452847 bytes
.../service/protocol/media/MediaAwareCallPeer.java | 29 ++++++++++++++++++++
2 files changed, 29 insertions(+)

diff --git a/lib/installer-exclude/libjitsi.jar b/lib/installer-exclude/libjitsi.jar
index fad55b6..ec4ab15 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 bdc84a6..d9e1733 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 abstract class MediaAwareCallPeer
      * <tt>mediaType</tt> that we have with this <tt>CallPeer</tt>.
      */
     public abstract MediaDirection getDirection(MediaType mediaType);
+
+ /**
+ * {@inheritDoc}
+ *
+ * When a <tt>ConferenceMember</tt> is removed from a conference with a
+ * Jitsi-videobridge, an RTCP BYE packet is not always sent. Therefore,
+ * if the <tt>ConferenceMember</tt> 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
+ * <tt>ConferenceMember</tt>'s <tt>ReceiveStream</tt> when the
+ * <tt>ConferenceMember</tt> 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 <tt>ConferenceMember</tt> to be removed from
+ * the list of <tt>ConferenceMember</tt> reported by this peer. If the
+ * specified <tt>ConferenceMember</tt> 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);
+ }
}

_______________________________________________
commits mailing list
commits@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/commits