You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This Issue tracker is only for reporting bugs and tracking code related issues.
Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.
Description
Occasionally Jigasi hit the issue that SIP audio stopped working and likely its due to:
When having two capture devices available, its possible that concurrent Jigasi SIP call causes DevicePreferences field ordered wrongly due to race condition. (loadDevicePreferences/saveDevice/writeDevicePreferences)
As a result, the non preferred noTransferData audio silence capture device will be wrongly picked as the preferred one and causes no audio issue. The noTransferData audio silence capture device will remain as the most preferred device until the race condition reset it, or restart the Jigasi server.
Current behavior
Jigasi stopped forwarding SIP audio data.
Expected Behavior
Jigasi should always successfully forward audio data.
Possible Solution
Proper fix probably require refractory the Devices.java class
Disable noTransferData audio silence capture device from AudioSilenceSystem is being used as a temp hack as its not needed for Jigasi SIP gateway mode.
src/main/java/org/jitsi/impl/neomedia/device/AudioSilenceSystem.java | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/main/java/org/jitsi/impl/neomedia/device/AudioSilenceSystem.java b/src/main/java/org/jitsi/impl/neomedia/device/AudioSilenceSystem.java
index 48a0db72..b5bb41a7 100644
--- a/src/main/java/org/jitsi/impl/neomedia/device/AudioSilenceSystem.java
+++ b/src/main/java/org/jitsi/impl/neomedia/device/AudioSilenceSystem.java
@@ -64,6 +64,9 @@ protected void doInitialize()
// capture device is required but no audio samples from it are necessary
// such as negotiating signalling for audio but actually RTP translating
// other participants/peers' audio.
+ System.out.println("AudioSilenceSystem Disable "
+ + "AudioSilenceCaptureDevice:" + DataSource.NO_TRANSFER_DATA);
+ /*
captureDevices.add(
new CaptureDeviceInfo2(
"AudioSilenceCaptureDevice:" + DataSource.NO_TRANSFER_DATA,
@@ -73,6 +76,7 @@ protected void doInitialize()
+ DataSource.NO_TRANSFER_DATA),
DataSource.SUPPORTED_FORMATS,
null, null, null));
+ */
setCaptureDevices(captureDevices);
}
Steps to reproduce
It's hard to reproduce, as it only happens when simultaneous requests come in.
Environment details
The text was updated successfully, but these errors were encountered:
This Issue tracker is only for reporting bugs and tracking code related issues.
Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.
Description
Occasionally Jigasi hit the issue that SIP audio stopped working and likely its due to:
When having two capture devices available, its possible that concurrent Jigasi SIP call causes DevicePreferences field ordered wrongly due to race condition. (loadDevicePreferences/saveDevice/writeDevicePreferences)
As a result, the non preferred noTransferData audio silence capture device will be wrongly picked as the preferred one and causes no audio issue. The noTransferData audio silence capture device will remain as the most preferred device until the race condition reset it, or restart the Jigasi server.
Current behavior
Jigasi stopped forwarding SIP audio data.
Expected Behavior
Jigasi should always successfully forward audio data.
Possible Solution
Proper fix probably require refractory the Devices.java class
Disable noTransferData audio silence capture device from AudioSilenceSystem is being used as a temp hack as its not needed for Jigasi SIP gateway mode.
Steps to reproduce
It's hard to reproduce, as it only happens when simultaneous requests come in.
Environment details
The text was updated successfully, but these errors were encountered: