[jitsi-dev] audio goes silent


#1

Hi,

I'm having a major issue with incoming calls and Jitsi audio.

I've posted the following on the dev list:
http://java.net/nonav/projects/jitsi/lists/dev/archive/2012-07/message/229

I was wondering if I could open a JIRA bug report?
I have some Jitsi log files I'd like to send (*.log *.pcap).

At times (quite often) SIP user accounts who answered incoming calls would experience audio silence during conversation (caller would hear callee but callee would not hear caller). The only way to regain audio both ways would be to toggle the "pause/on hold" button twice (I don't know what that implies).
Seems to happen only with SIP so it may be a JAIN-SIP issue. Other softphone non-Java SIP apps have been tested and do not have this issue.

Can I open a JIRA bug report?

Thanks,

Vieri


#2

Hey Vieri,

Hi,

I'm having a major issue with incoming calls and Jitsi audio.

I've posted the following on the dev list:
http://java.net/nonav/projects/jitsi/lists/dev/archive/2012-07/message/229

I was wondering if I could open a JIRA bug report? I have some Jitsi
log files I'd like to send (*.log *.pcap).

At times (quite often) SIP user accounts who answered incoming calls
would experience audio silence during conversation (caller would hear
callee but callee would not hear caller). The only way to regain
audio both ways would be to toggle the "pause/on hold" button twice
(I don't know what that implies).

It basically restarts the media streams.

Seems to happen only with SIP so it
may be a JAIN-SIP issue. Other softphone non-Java SIP apps have been
tested and do not have this issue.

I find this unlikely. It's not impossible of course but this sounds to
me as something that's related to RTP. Not necessarily a Jitsi issue
though. It could also be that some of the middle boxes (NATs or SBC)
stop relaying media at some point.

Can I open a JIRA bug report?

Can we see the log files first? Also, have you noticed if media
continues flowing in both directions in cases where audio cuts? Can we
also have a couple of accounts for the server that presents the issue?
You can send those to support@bluejimp.com.

Thanks,
Emil

···

On 17.08.12, 09:46, Vieri wrote:

Thanks,

Vieri

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#3

Hi Emil,

I find this unlikely. It's not impossible of course but this
sounds to
me as something that's related to RTP. Not necessarily a
Jitsi issue
though. It could also be that some of the middle boxes (NATs
or SBC)
stop relaying media at some point.

There's nothing between my Asterisk server and the client.
Between the remote end and the Asterisk server there's an ISDN line/BRI service.

Can we see the log files first?

I sent them to bluejimp.com.
Please note that some log entries are specific to our customized Jitsi app. However, nothing regarding RTP has been changed in the source code.
In any case, if you require logs from "native Jitsi" I can install the original app on the user's PC and regenerate the logs.

Also, have you noticed if
media
continues flowing in both directions in cases where audio
cuts?

I'll check asap.

Thanks,

Vieri

···

--- On Fri, 8/17/12, Emil Ivov <emcho@jitsi.org> wrote:


#4

Media still flows in both directions during "audio cuts".
I tested by running the following on an Asterisk server (IP addr. of Asterisk server: 10.215.147.112, RTP ports between 10000 and 20000, IP addr. of Jitsi client: 10.215.144.242 - same LAN subnet):

tcpdump -n src or dst portrange 10000-20000 and src or dst host 10.215.144.242

During "audio cuts" I still had bi-directional flow:

09:25:18.549434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.559434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.569434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.579434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.589434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.599434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.599434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.619435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.629435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.639435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.649435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.649435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.669435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.669435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45
09:25:18.679436 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length 45
09:25:18.699436 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length 45

So doesn't this imply that the issue must be on the client's end?

If clicking on the "pause" button twice resets media streams then maybe a quick and ugly hack would be to quickly auto-reset media streams during an active call every 3 seconds (the user should barely notice it). I know this is really ugly and probably not feasible but I'm stuck for now.

I know I don't have much data to debug this and that I will soon migrate from my current Asterisk 1.4.31 installation to Kamailio + Asterisk 10 (so the server/PBX part will change in time) but I must say that with my current installation (Asterisk 1.4.31) and under the same conditions (same client PC at IP addr. 10.215.144.242) another softphone was used and never had such "audio cuts" (SJphone/1.60.289a from SJ Labs). I even asked the user to exit Jitsi and start SJphone to make/receive calls and there have been no problems since. So the only thing that changed in my setup is the client software (network, server, call routing including PSTN lines used and client hardware are the same).

What else can I try?

Thanks,

Vieri

.

···

--- On Fri, 8/17/12, Emil Ivov <emcho@jitsi.org> wrote:

Also, have you noticed if
media
continues flowing in both directions in cases where audio
cuts?


#5

Hey Vieri,

We'll try to have a look at this toward the and of the week. Until then, it
would indeed be helpful to have a couple of test accounts at your box.

Incidentally, is this a problem that has occurred only recently?

--sent from my mobile

···

On Aug 21, 2012 11:22 AM, "Vieri" <rentorbuy@yahoo.com> wrote:

--- On Fri, 8/17/12, Emil Ivov <emcho@jitsi.org> wrote:

> Also, have you noticed if
> media
> continues flowing in both directions in cases where audio
> cuts?

Media still flows in both directions during "audio cuts".
I tested by running the following on an Asterisk server (IP addr. of
Asterisk server: 10.215.147.112, RTP ports between 10000 and 20000, IP
addr. of Jitsi client: 10.215.144.242 - same LAN subnet):

tcpdump -n src or dst portrange 10000-20000 and src or dst host
10.215.144.242

During "audio cuts" I still had bi-directional flow:

09:25:18.549434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.559434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.569434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.579434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.589434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.599434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.599434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.619435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.629435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.639435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.649435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.649435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.669435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.669435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.679436 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.699436 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45

So doesn't this imply that the issue must be on the client's end?

If clicking on the "pause" button twice resets media streams then maybe a
quick and ugly hack would be to quickly auto-reset media streams during an
active call every 3 seconds (the user should barely notice it). I know this
is really ugly and probably not feasible but I'm stuck for now.

I know I don't have much data to debug this and that I will soon migrate
from my current Asterisk 1.4.31 installation to Kamailio + Asterisk 10 (so
the server/PBX part will change in time) but I must say that with my
current installation (Asterisk 1.4.31) and under the same conditions (same
client PC at IP addr. 10.215.144.242) another softphone was used and never
had such "audio cuts" (SJphone/1.60.289a from SJ Labs). I even asked the
user to exit Jitsi and start SJphone to make/receive calls and there have
been no problems since. So the only thing that changed in my setup is the
client software (network, server, call routing including PSTN lines used
and client hardware are the same).

What else can I try?

Thanks,

Vieri


#6

Hey Vieri,

one more thing, as media don't stop durring the problem call, it will
be useful to have a wireshark pcap dump of sip and rtp that flows
between the problem side and the server. Again you can send those to
support@bluejimp.com.

Regards
damencho

···

On Tue, Aug 21, 2012 at 12:55 PM, Emil Ivov <emcho@jitsi.org> wrote:

Hey Vieri,

We'll try to have a look at this toward the and of the week. Until then, it
would indeed be helpful to have a couple of test accounts at your box.

Incidentally, is this a problem that has occurred only recently?

--sent from my mobile

On Aug 21, 2012 11:22 AM, "Vieri" <rentorbuy@yahoo.com> wrote:

--- On Fri, 8/17/12, Emil Ivov <emcho@jitsi.org> wrote:

> Also, have you noticed if
> media
> continues flowing in both directions in cases where audio
> cuts?

Media still flows in both directions during "audio cuts".
I tested by running the following on an Asterisk server (IP addr. of
Asterisk server: 10.215.147.112, RTP ports between 10000 and 20000, IP addr.
of Jitsi client: 10.215.144.242 - same LAN subnet):

tcpdump -n src or dst portrange 10000-20000 and src or dst host
10.215.144.242

During "audio cuts" I still had bi-directional flow:

09:25:18.549434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.559434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.569434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.579434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.589434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.599434 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.599434 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.619435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.629435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.639435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.649435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.649435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.669435 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.669435 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45
09:25:18.679436 IP 10.215.147.112.11516 > 10.215.144.242.5004: UDP, length
45
09:25:18.699436 IP 10.215.144.242.5004 > 10.215.147.112.11516: UDP, length
45

So doesn't this imply that the issue must be on the client's end?

If clicking on the "pause" button twice resets media streams then maybe a
quick and ugly hack would be to quickly auto-reset media streams during an
active call every 3 seconds (the user should barely notice it). I know this
is really ugly and probably not feasible but I'm stuck for now.

I know I don't have much data to debug this and that I will soon migrate
from my current Asterisk 1.4.31 installation to Kamailio + Asterisk 10 (so
the server/PBX part will change in time) but I must say that with my current
installation (Asterisk 1.4.31) and under the same conditions (same client PC
at IP addr. 10.215.144.242) another softphone was used and never had such
"audio cuts" (SJphone/1.60.289a from SJ Labs). I even asked the user to exit
Jitsi and start SJphone to make/receive calls and there have been no
problems since. So the only thing that changed in my setup is the client
software (network, server, call routing including PSTN lines used and
client hardware are the same).

What else can I try?

Thanks,

Vieri


#7

Hi Damian,
I'll try to get that asap.

Thanks,

Vieri

···

--- On Tue, 8/21/12, Damian Minkov <damencho@jitsi.org> wrote:

it will
be useful to have a wireshark pcap dump of sip and rtp that
flows
between the problem side and the server.


#8

Damian,

I just sent a full trace (all packets) between the server and the Jitsi client at the BlueJimp e-mail address.
There was 1 audio cut during the dump.

Thanks,

Vieri

···

--- On Tue, 8/21/12, Damian Minkov <damencho@jitsi.org> wrote:

one more thing, as media don't stop durring the problem
call, it will
be useful to have a wireshark pcap dump of sip and rtp that
flows
between the problem side and the server.


#9

The approx. time the audio cut occurred was 14:20.

At 14:20:36 I can see the SIP message:
580 Status: 481 Call leg/Transaction does not exist

Vieri

···

--- On Tue, 8/21/12, Vieri <rentorbuy@yahoo.com> wrote:

--- On Tue, 8/21/12, Damian Minkov <damencho@jitsi.org> > wrote:

> one more thing, as media don't stop durring the
problem
> call, it will
> be useful to have a wireshark pcap dump of sip and rtp
that
> flows
> between the problem side and the server.

Damian,

I just sent a full trace (all packets) between the server
and the Jitsi client at the BlueJimp e-mail address.
There was 1 audio cut during the dump.