[jitsi-dev] [jitsi-videobridge] Missing remote downstream RTP media (audio/video) - Jitsi-Videobridge BUG ???


#1
···

Hi,

My best guess is that the problem stems from the way the jitsi client

configures jitsi-videobridge (over COLIBRI). A good amount of changes

have been introduced since it was last tested or used actively (by our

team).

  1. Are you referring the new changes made to jitsi client or videobridge? Or both?

  2. I have also tested the same three jitsi-clients i.e. jitsi-windows, jitsi-ubuntu and jitsi-android with videobridge on jit.si server. They all work well with jit.si server, although not 100% of the time.

2a. May I know what version of the jitsi-videobrige is being installed at jit.si server?

  1. I have compared the jitsi-android debug log when logged to jit.si and my own server. I was not able to detect any major

differences in the protocol exchanges during videobridge setup; except below debug log differences captured on jitsi-android (not working test case):

Additional Stanza send from abc123 (jvb initiator) to leopard (invitee)

==== Additional stanza received by jitsi-android (prior to encode audio graph creation process) ========

02-11 14:46:58.823: D/SMACK(20758): RECV (0):

2

connected

1544483604audiosendrecv

leopard@jvb.example.org

connectedaudiosendrecv

=================================

Following is missing from no working test case (as reported in my previous message).

====== Debug log on android-jitsi (when log onto jit.si server) ============

02-10 14:37:30.355: I/Jitsi(12450): [96] net.sf.fmj.media.Log.info()
Resetting queue, last seq added: 9223372036854775806, current seq: 40105

02-10 14:37:30.355: I/Jitsi(12450): [97] fmj.createProcessor() ### Creating
Processor for DataSource ###:
[org.jitsi.impl.neomedia.device.ReceiveStreamPushBufferDataSource at cab9aef](http://lists.jitsi.org/mailman/listinfo/dev) for
type: raw

==================================

3a. Does the debug log above provide you new insight into the problem?
  1. When testing with jitsi-android (jvb initiate not implemented yet), I always use jitsi-windows as the videobridge initiator.

I will find a way to perform debug log on jitsi-windows, so I can compared the difference when log to jit.si and own servers.

Will update you on my findings.

Regards,

CM Eng

======================================

On 11/02/16 23:30, cmeng.gm wrote:

Hi Boris Grozev,

After I terminated the videobridge call, I observed the following debug messages log from JVB.

JVB 2016-02-12 13:16:36.561 INFO: [65] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10004/udp/host -> 92.168.1.100:5001/udp/host (audio.RTCP), failing.

JVB 2016-02-12 13:16:36.562 INFO: [63] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10003/udp/host -> 192.168.1.100:5000/udp/host (audio.RTP), failing.

JVB 2016-02-12 13:16:49.041 INFO: [125] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10002/udp/host -> 118.201.189.22:5001/udp/srflx (audio.RTCP), failing.

JVB 2016-02-12 13:16:49.041 INFO: [124] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10001/udp/host -> 118.201.189.22:5000/udp/srflx (audio.RTP), failing.

JVB 2016-02-12 13:16:51.557 INFO: [127] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10004/udp/host -> 192.168.1.100:5001/udp/host (audio.RTCP), failing.

JVB 2016-02-12 13:16:51.558 INFO: [126] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10003/udp/host -> 192.168.1.100:5000/udp/host (audio.RTP), failing.

JVB 2016-02-12 13:17:04.040 INFO: [63] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10001/udp/host -> 118.201.189.22:5000/udp/srflx (audio.RTP), failing.

JVB 2016-02-12 13:17:04.041 INFO: [65] org.ice4j.ice.ConnectivityCheckClient.processTimeout() timeout for pair: 192.168.1.8:10002/udp/host -> 118.201.189.22:5001/udp/srflx (audio.RTCP), failing.

Look like JVB was actually sending UDP data out during the active call session???

It might have been just sending ICE consent checks and no media.

But why none is being observed on wireshark or received by both jitsi-android and jitsi-windows clients???

My best guess is that the problem stems from the way the jitsi client

configures jitsi-videobridge (over COLIBRI). A good amount of changes

have been introduced since it was last tested or used actively (by our

team).

Regards,

This email has been sent from a virus-free computer protected by Avast.
www.avast.com