Freephoneline won't disconnect on hangup

[mikesil93]

I'm using FFL 3.2.7.0 app on a Win 10 64-bit PC. Starting from a certain Win 10 update, or possibly by coincidence with FFL server side changes, the app stopped disconnecting any phone call when the other party plays a prerecorded message, like an answering machine or on hold. When clicking "End Call" button, even many times over, my side of the conversation is ended, but the other side's connection is not closed. So I can't fully disconnect a call until the other party hangs up. When I hahgup and try to make another call to any number, the 2 calls overlap so I can hear answering machine or on-hold message from the previous call still playing indefinitely long. When hanging up again and calling any number, FFL server says "your line is already in use". If an original on hold call takes 40+ min, I have to wait that long to call someone again, despite hanging up 40 min ago. This looks like an obvious FFL app or server bug, it no longer recognizes hangup signal from FFL app to end the call. If I exit the app and restart again, then try to call any number, the previous call still remains active and overlaps. Also incoming calls won't go through until the previous call is disconnected by the other party.

My question is: FFL continues to provide service to millions of Canadians with this app. What makes them think it can be used without any update forever while operating systems and Fongo servers software are regularly updated? There are a number of bugs of this app reported years ago and never fixed. Obviously FFL server protocol changed, and it no longer recognizes FFL app hangup message, so waits until the other party hangups. Does anyone experience the same issue, and how it can be fixed without FFL updating their app or server soft?

[Liptonbrisk]

possibly by coincidence with FFL server side changes

FPL servers aren't handling calls any differently.

the app stopped disconnecting any phone call when the other party plays a prerecorded message, like an answering machine or on hold

The app is incapable of discerning the difference between live voice, a prerecorded message, or an answering machine message. Audio is audio.

FFL continues to provide service to millions of Canadians with this app

I'm skeptical that millions of Canadians are using the desktop app.

What makes them think it can be used without any update forever

That is a valid question, in my opinion. But, so far, the app continues to be able to accept and place calls.

Obviously FFL server protocol changed

No.

it no longer recognizes FFL app hangup message

It does for me. 3.2.7.0 with
Win 10 Pro x64 Version
10.0.15063 Build 15063

I only use the desktop app for testing purposes when people have problems, mostly.

Does anyone experience the same issue, and how it can be fixed without FFL updating their app or server soft?

I originally wrote these instructions for a Windows 8 user (only affects instructions for Windows update), but you can modify them easily enough for Windows 10:
http://forum.fongo.com/viewtopic.php?f= ... 63&p=74810. I would go through the steps in the order listed, carefully (especially step 7). If those steps don't help you,
then, unfortunately, I'm out of ideas. On the surface, your issue, to me, seems related to java, some background process hanging or eating resources, or an audio driver issue.

[mikesil93]

On the surface, your issue, to me, seems related to java, some background process hanging or eating resources, or an audio driver issue.

I'm quite advanced user, and have been using FFL app for many years. Just recently the server started to fail disconnecting calls on the other end, which means it doesn't receive or properly handle "End Call" message, because it ends on my side, but not on the other side. Wireshark shows constant flow of packets from server to the app, and no reply from the app except periodic registration & keep alive packets once the call is disconnected. I tried to fully uninstall and reinstall the app, but to no avail. Java handles the app UI, and audio driver controls how digital audio signal is interpreted by audio card & speakers, so they don't seem related to packets interpreting by the server. I'm constantly monitoring PC resource use in real time, and there are no background processes eating resources beyond normal, or hanging in a way that would affect only disconnect packets, but not any other packets send by the app. If the app were failing to send packets, it would manifest in various ways, not only by one problem. Also, its obvious the server properly receives and handles registration and call initiating packets from the app. Only packets ending the call are not interpreted properly by the server, hence my assumption is the server code has changed. I can post what packets the app sends on "End Call" button press.

Also, I don't think there is Win 10 build and version you posted. Run winver to check: I've "Version 1703 (OS Build 15063.540)". Does the app end a call for you when the on hold service on the other end is still talking or playing music, and you can place a new call without problems right away? I found its different when a human is on the other end, possibly from server standpoint, and the packets flow character is definitely different, if flow details are used by the server to identify caller presence. There is still a good reason to use the desktop app: with a good mic call audio quality is much better, cleaner and crisper compare to using Fongo Mobile, and it matters in many ways.

[Liptonbrisk]

I'm quite advanced user

Whether you are doesn't change the fact the app (or something else on your system) isn't working properly for you. I never suggested you weren't an advanced user.

Just recently the server started to fail disconnecting calls on the other end, which means it doesn't receive or properly handle "End Call" message

In SIP protocol, the message is called "BYE"; the response should be "200 OK". If you're using Wireshark, this is the type of stuff you should be looking for.

because it ends on my side, but not on the other side

It doesn't end because I doubt the app on your computer is functioning properly when you click "End".

Java handles the app UI, and audio driver controls how digital audio signal is interpreted by audio card & speakers, so they don't seem related to packets

They do matter with respect to whether a java program runs properly--and whether drivers are causing your system to stop responding when requests are made.
And attempting to resolve related issues in Windows 10 (despite the link being a Windows 7 thread) is always fun: https://answers.microsoft.com/en-us/win ... 6ff6503e85 (here, the user suspects an audio issue involving his network card). I've also seen audio issues manifest on some systems when audio has been streaming for awhile; programs stop responding properly to user input. Fixes can involve updating audio/sound card drivers. This can be a useful tool to help diagnose potential latency and driver issues: http://www.resplendence.com/latencymon.

or hanging in a way that would affect only disconnect packets

Your initial description suggests the app isn't responding properly to you clicking the "End" button at all at that point, which makes me question how "BYE" is being sent.
Regardless, I doubt the app is functioning properly when this problem, that I can't reproduce, occurs.

Only packets ending the call are not interpreted properly by the server

I doubt it's even received in your case.

Also, I don't think there is Win 10 build and version you posted.

It's the same as what you're using: Version 1703 (OS Build 15063.540).

Does the app end a call for you when the on hold service on the other end is still talking or playing music, and you can place a new call without problems right away?

Yes, of course.

I found its different when a human is on the other end, possibly from server standpoint, and the packets flow character is definitely different, if flow details are used by the server to identify caller presence.

No; they aren't. It's not as though the BYE/200 OK messages stop being sent just because RTP data is still being received at the time the End button is clicked. And, no, FPL's servers are not distinguishing between music, answering machine messages, and live voices. The call can also be completely silent with muted mics on both ends without FPL ending the call automatically. It makes no difference

Good luck to you.

[mikesil93]

In SIP protocol, the message is called "BYE"; the response should be "200 OK". If you're using Wireshark, this is the type of stuff you should be looking for.

Sorry for some delay, being busy lately. I fully cleanup existing FPL install with Total Uninstall, and reinstalled again. Same thing happens - any call does not fully disconnect on pressing FPL End button. It disconnects on my side, but not on their side. I run Wireshark and see this:

FPL: CSeq: 3 BYE
Other party: Status: 480 Temporarily Unavailable
Other party (hangs up later): CSeq: 180 BYE
FPL: Status: 200 OK

Wireshark_FFL.jpg (100.92 KiB) Viewed 10244 times

Resplendence.jpg (108.79 KiB) Viewed 10244 times

So, until the other party hangs up, the call continues on their end. If there is an answering machine in Hold-the-line on the other end, the call goes on "forever", and I can't place a new call in FPL. Once the other party hangs up, FPL hangs up too. Any ideas what can cause it? Obviously, Firewall passes FPL packets, otherwise I won't be able to place and receive calls on that PC. Call audio quality and connection sequence are unaffected in both directions. Also, it seems FPL sends BYE request after pressing End button, but for some reason every phone (VoIP, mobile, web) I call is unable to recognize it correctly, and they don't stop the call??? There are no page faults shown in Resplendence Monitor.

[Liptonbrisk]

I tried several calls again with the FPL desktop app. The calls end after I click "end", despite my being placed on hold in a call queue. It doesn't matter if I'm on hold or not when I click
"end". I am able to place a new call immediately.

I'm not positive why there would be a 480 response to BYE, if that was the response to you sending BYE. That seems as though the server is blocking or rejecting the request. Perhaps someone else has an answer. Given that I had surgery recently and am taking strong pain killers, I am not likely to pursue this issue more than I have.

By the way, it's FPL and not "FFL"

[mikesil93]

That's seems as though the server is blocking the request.

Thanks for help you already provided. I assume you mean FPL server... and I suspected it all alone. Is there a way to reach FPL support on this in a manner that would result in a fix rather than talk?

[Liptonbrisk]

That's seems as though the server is blocking the request.

Thanks for help you already provided. I assume you mean FPL server... and I suspected it all alone. Is there a way to reach FPL support on this in a manner that would result in a fix rather than talk?

Well, you can submit a ticket here: https://support.fongo.com/hc/en-us/requests/new

But they don’t provide free tech support for the Desktop app. There’s no incentive for them to provide support since the app and service are free.
I would consider myself lucky if someone responds. Typically tech support ticket requests for the desktop app are automatically closed.

If the issue is with your account or related to your account, then they can do something.

[mikesil93]

This is not a tech support request for the desktop app, but rather a maintenance or bug fix request for FPL server, possibly limited to certain user accounts like mine. Anyway, once the ticket is open, is there a way to check its status on any website or by phone? How to escalate the ticket if ignored? Lets not forget, Fibernetics receives certain incentives in exchange of offering this service, it also has paid options, and is used for non-optional ads delivery to user desktops, so users indeed pay for it one way or another.

[Liptonbrisk]

This is not a tech support request for the desktop app, but rather a maintenance or bug fix request for FPL server, possibly limited to certain user accounts like mine.

If you feel it's an account inquiry, then select "my account inquiry" for the issue type. There's nothing stopping you from submitting a ticket.

I have read about some cases of other SIP servers (not related to Freephoneline) rejecting requests based on whether there's been a MAC address change or IP address change during a session, and I recall you mentioning in
another thread that you had several network adapters and a VPN service. I might suggest trying to disable all other network adapters that you're not using for FPL and also try disabling the VPN (or even try uninstalling it to see whether its virtual network adapter drivers are causing issues). However, I have no clue what conditions would cause SIP code 480 to be the response to BYE with FPL, much less what difference trying this would make since Wireshark should be looking at packets across the same network adapter anyway; so trying to do this may be useless.

Anyway, once the ticket is open, is there a way to check its status on any website or by phone?

Not that I'm aware of, although the ticketing service is through Zendesk

How to escalate the ticket if ignored?

I have no clue.

As far as I can tell, desktop app development has been abandoned since 2013, and there's no free technical support available for it.

Lets not forget, Fibernetics receives certain incentives in exchange of offering this service, it also has paid options

Unless you're paying for long distance, I doubt there's any revenue for them unless your number is receiving incoming calls frequently.
The ads are promoting Fongo, which are from its own related (sister) company.