[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users] hoping for help in protocol analyzation

From: Boris
Subject: Re: [Linphone-users] hoping for help in protocol analyzation
Date: Wed, 3 Nov 2021 20:36:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

Hej Dennis,

sorry for the delay. I had some days-off but didn't forget the thread. Must be frustrating to offer help and get no response. I'm going to avoid that!

Am 14.10.21 um 19:34 schrieb Dennis Filder:
On Wed, Oct 13, 2021 at 19:48:13 +0200, Boris wrote:

I created dumps from the initialization of linphone. Because only
starting linphone does not initiate much traffic, I made a call to my
mobile phone and without accepting.

Okay, that log tells me that Linphone's SIP traffic is translated
correctly like that of your Panasonic phone.  I see nothing weird or
off.  Since the call is not picked up I cannot see if an ACK is
received (which would have been the important part).

It surely will, because outgoing calls just work fine - until 15 minutes....

My next step is watching the shorewall.log in time of the call is

Some more empirical informations:
Two friends of mine are suffering from the same 15-minute-trouble. They
are using a more conventional setup: Linphone for Windows behind a Fritzbox.

Are they using the Fritzbox SIP proxy?  If not it doesn't surprise me
they experience it, too, as Fritzbox OS is just a Linux kernel with a
proprietary user-land.

Sure. No they don't use the Fritzbox SIP proxy.

So, with that in mind, I doubt my network is causing the trouble. But it
(especially the leaf-box) might serve as helpful tool to find the
reason. I could try to dump a whole call with the interruption. What do
you think?

We're getting to a point where I cannot be of much help anymore.
We've found out that the connection is interrupted because after ~15
minutes Linphone/belle-sip runs into a timeout waiting for an ACK
request it expects in response to the INVITE request it previously
sent out to start the phone call.  Either the ACK request is eaten by
a firewall or rejected/discarded at a NAT point, or if it does
actually reach Linphone then the timeout timer is not cancelled which
would be a bug in belle-sip.

Well, for me the issue is caused by the Deutsche Telefon who make simething strange with their Centrex - something that differs from how every other provider does it. Unfortunately DT does not support our beloved OS. So I was hoping to find that out by reverse engineering - and of course with the help of you or somebody who is deeper into SIP as I am (what is not so hard to reach).

To decide this you would have to capture all traffic during the
duration of an entire call on both the router's WAN and LAN interface
and also on the desktop computer you're running Linphone on (ideally
with synchronized clocks to line up the timestamps), then sift through
that and see if the ACK request makes it through.  A difficulty here
is observing the firewall on your desktop since you'd have to employ
the logging target to see what's going on (tcpdump cannot tell which
packets are discarded by netfilter).  You might even have to strace
linphone, too, which will result in tens of megabytes of output.  I'm
beginning to suspect that that incoming connection gets blocked by
your desktop's firewall.

Mmmh, well, yes, quite a way to go.....

All in all troubleshooting NAT-heavy SIP setups in non-trivial
firewall setups is even more of a pain than simpler SIP setups which
is why everyone who's been through it eventually resorts to using SIP
proxies.  They usually also give informative error messages instead of
dropping unfamiliar packets silently.

I will dive deeper into the proxy idea and will keep you informed if there is something coming out. Maybe I can also manage to bring the client directly to the internet without a NATting instance. That would possibly take the natting out of suspicion.....

Any other idea is also welcome!

Thanks an regards,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]