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). > My next step is watching the shorewall.log in time of the call is > interrupted. > > 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. > 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. 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. 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. Regards. _______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
