[jitsi-users] SIP calls to landlines get dropped silently after a while


#1

Hi All,

My SIP calls to landlines start off well but then disconnect after I've
been talking for a while. This usually occurs between ten minutes and an
hour into the conversation.

I'm guessing it's triggered by a communication problem between Jitsi and my
SIP server. Does anyone else face this issue when using Jitsi with
NodePhone (sip.internode.on.net)?

The problem occurs far more frequently with Jitsi than it did with
Linphone. However, as the latter is broken in other ways, I'm hoping we
can get Jitsi working properly instead.

Basically, I suddenly stop hearing anything but Jitsi doesn't notify me
that the call has ended. When I phone the person back, they say the call
had been cut at that point.

Will I need to fire up Wireshark to determine the cause of this problem, or
is there an easier way? Alternatively, do you think it could be caused by
PulseAudio on Linux somehow?

···

--
Regards, Xavion.


#2

Hi,

[..] do you think it could be caused by PulseAudio on Linux somehow?

Yes, always!

But, what is the current state of NAT traversal for SIP in Jitsi? I
remember it lacked support for various NAT traversal methods, and if
this is still the case, I can imagine the PSTN gateway somehow doing
something nasty with the RTP stream, maybe including reinviting peers,
which fails.

Did you have a look at Jitsi's logs?

Do the other people say the call got cut as in hung up or as in "didn't
hear anything anymore"?

-nik

···

--
<Natureshadow> Auf welchem Server liegt das denn jetzt…?
<mirabilos> Wenn es nicht übers Netz kommt bei Hetzner, wenn es nicht
            gelesen wird bei STRATO, wenn es klappt bei manitu.

2013-05-19 - 05-21 Geocaching-Tour Hamburg (2 Betten frei)
2013-06-28 - 06-30 http://project-eck.de Koblenz
2013-08-01 - 08-04 http://berlin-mega.de Berlin (2 Betten frei)
2013-08-28 - 09-02 http://prora2013.de Rügen
2013-12-27 - 12-31 30c3 Hamburg (2 Betten frei)

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296


#3

Hey guys,

Hi,

[..] do you think it could be caused by PulseAudio on Linux somehow?

Yes, always!

But, what is the current state of NAT traversal for SIP in Jitsi?

Same as before. We rely on Hosted NAT traversal. I don't think this
could be the problem though. I've updated our FAQ entry on the matter:

http://jitsi.org/faq/stun

I
remember it lacked support for various NAT traversal methods, and if
this is still the case, I can imagine the PSTN gateway somehow doing
something nasty with the RTP stream, maybe including reinviting peers,
which fails.

If only it was that. Personally I've been looking for a solid excuse to
start working on ICE for SIP for a while now and can't find any
(fortunately WebRTC provides one that is not so solid but still an
excuse :wink: ). Some clarifications here:

I've only seen the reINVITEs you describe happen on Asterisk in cases
where both peers are connected through IP to asterisk, which is not the
case on an IP to PSTN call. Note however, that it is impossible to use
ICE through Asterisk anyway as it would force use of hosted NAT
traversal, which automatically prevents ICE from running.

I'll answer Xavion's mail in a sec.

Cheers,
Emil

···

On 04.05.13, 08:31, Dominik George wrote:

Did you have a look at Jitsi's logs?

Do the other people say the call got cut as in hung up or as in "didn't
hear anything anymore"?

-nik

--
https://jitsi.org


#4

Hey Xavion,

Hi All,

My SIP calls to landlines start off well but then disconnect after I've
been talking for a while. This usually occurs between ten minutes and
an hour into the conversation.

When you say "disconnect" do you really mean that? Or do you just stop
hearing while media seems to still be flowing in both directions? Do you
notice something weird in the call stats? Like a lot of packets being
discarded?

I'm guessing it's triggered by a communication problem between Jitsi and
my SIP server. Does anyone else face this issue when using Jitsi with
NodePhone (sip.internode.on.net <http://sip.internode.on.net>)?

The problem occurs far more frequently with Jitsi than it did with
Linphone. However, as the latter is broken in other ways, I'm hoping we
can get Jitsi working properly instead.

Basically, I suddenly stop hearing anything but Jitsi doesn't notify me
that the call has ended. When I phone the person back, they say the
call had been cut at that point.

Will I need to fire up Wireshark to determine the cause of this problem,
or is there an easier way? Alternatively, do you think it could be
caused by PulseAudio on Linux somehow?

We've noticed something similar but we haven't been able to put our
collective finger on it yet.

Could you please open an issue for this?

Thanks,
Emil

···

On 04.05.13, 07:28, Xavion wrote:

--
https://jitsi.org


#5

Hi Guys,

Thanks for the prompt and detailed replies. I have just filed a bug
report<https://java.net/jira/browse/JITSI-1147>as requested.

When the problem occurs, I stop hearing anything but the call seems to stay
alive. At the other end, the person later says it was cut (i.e.
disconnected). I don't think they mean that it went silent for a while
until I finally decided to end the call. I'll see if I can get more
precise information from them the next time it happens.

As I haven't made any lengthy landline calls for a few days, the relevant
Jitsi log files are no longer available. The next time this problem
occurs, I'll be sure to send them to you before they're deleted. I'll also
keep an eye on the call stats to see if there's anything weird going on.

Does anyone know of a test landline (PSTN) number in Australia that I can
call from my SIP server? This will allow me to repeat the test as many
times as necessary without having to annoy anyone in the process.

···

--
Regards, Xavion.


#6

I got bored of waiting and made another call to one of my relatives. It
got cut after about ten minutes and all I heard was the usual silence. The
person at the other end received disconnection beeps almost immediately.
I've attached the call logs and a screenshot of the technical information.
I can't seem to find a way to attach this archive to the bug
report<https://java.net/jira/browse/JITSI-1147>I filed earlier. Maybe
someone with higher access privileges can do so
instead.

There's one other interesting piece of information that's worth noting. A
subsequent PSTN call, using the Google Talk browser plugin, was also cut.
However, the person said they could still hear me talking this time. In
other words, they heard me saying that I couldn't hear them anymore.
Anyway, have a read of the logs and let me know if you find anything of
relevance. If not, perhaps we should take a closer look at PulseAudio
instead.

Cut-Call.zip (115 KB)