SOLVED A few issues - Audio drop incoming/Call Drops/Multi Registration so on

[DigitalDaz]

@cengbrecht What I would do with this is to do a full TCP dump with rtp, have a google around if you cannot find out how to do it then come back and give us a shout.

Once you have that, at least you can go back then and find out if audio was being sent to/from the PBX at the time that lost audio. This will at least point you in the direction to start looking.

Its possible session timers are coming into play here and contributing to some of the havoc.

I had exactly this issue with my mrs phone. Session timers have been introduced recently and can be a pain.

You can check for this easily in sngrep.

On an outbound call look at the 200OK from Freeswitch:

2018/08/22 01:52:40.694169 192.168.1.118:5060 -> 192.168.1.160:12450
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.160:5060;branch=z9hG4bK2470559023;rport=12450
From: "Daz" <sip:200@192.168.1.118>;tag=3427536712
To: <sip:*9664@192.168.1.118>;tag=FS912mm3QpK9a
Call-ID: 4_573590978@192.168.1.160
CSeq: 2 INVITE
Contact: <sip:*9664@192.168.1.118:5060;transport=tcp>
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Session-Expires: 120;refresher=uas <------------------------------------------------------------ This could be the problem
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 222
Remote-Party-ID: "*9664" <sip:*9664@192.168.1.118>;party=calling;privacy=off;screen=no

If this line is present then go into advanced/sip profiles and edit the internal profile. Look for this:



Change it to:


Then flush memcache and restart the internal profile.

Once you have done this, check sngrep again to see that the line has now gone.

That may be enough, good luck

 

[cengbrecht]

Its possible session timers are coming into play here and contributing to some of the havoc.

In relation to that note above, would this be global?
Remember, the thing is, as a multi-tenant setup, I at my office have had none of these issues.
The current setting of the timer.

As a theory, any issue with changing the second false to true? I could do it as a test. (I have tested a LOT...)

 

[cengbrecht]

But how does the ISP monitor the link? From their gateway to your end point or beyond? If its a ho in between how would they know? At what interval? ...

I have a good relationship with the owner of the company, I will see what his logs include, and such, I have noticed that Teamviewer sometimes will pause intermittently for the same times that calls can go quiet..., you may have something... If thats so, this may be something beyond I will check with him.

 

[DigitalDaz]

In relation to that note above, would this be global?
Remember, the thing is, as a multi-tenant setup, I at my office have had none of these issues.
The current setting of the timer.
View attachment 457
As a theory, any issue with changing the second false to true? I could do it as a test. (I have tested a LOT...)

It would be global but this is not relevant, we haven't used session timers for years anyway purely because they are known to cause issues. I have never known session timers to bring ANY benefit to FusionPBX users, its possible that its a recent error that has caused them to become enabled.

 

[cengbrecht]

I have finally gotten a capture right from the server interface, I have everything, but have filtered just the church.
There is a lot of info there, but I don't understand it, can someone help me read it?

 

[cengbrecht]

Ok Guys!
Ignore that last message, I have done a second one while I was on the phone with the customer ext to ext, from my office to his.
My side had no issues, and the server showed that there was NO loss on the line from the server to either of us.
I have also double checked and it looks like the Provider has some packet loss, just before the head end of the network, we are going to be testing soon.
Thanks for all your help, I will keep this post updated.
As always! If you think of a test, please send her over, and I will run it as best I can.

 

[bcmike]

Just run ping plotter with the parameters I mentioned previously from a host inside the church network to your Digital Ocean server and you'll see exactly which hop the packet loss comes from. You'll also know if there's congestion if you see any latency bursts the correlate with your packet loss. Congestion on a network can at times only last for a minute or two but it'll totally screw a VoIP call.

Good luck!

 

[cengbrecht]

Wow @bcmike, you don't happen to be a particular programmer I know are you?
Those red spikes correlate to my packet loss, and also to the intermittent issues I have with teamviewer.
Also, the network is barely loaded at all.
Second update, looks like traffic to the server hitting Toro-b1-link.telia.net seems to be an issue?

 

[bcmike]

I'm not a programmer (except for maybe shell scripts and occasional php). I'm also extremely new fusionpbx, however I have been in the VoIP business for a long time (asterisk) and I know how to troubleshoot a lot of stuff.

Unfortunately I think the packet loss originates at your gateway and cascades down from there. That makes it really tricky as it could be an internal network problem or a problem with the gateway device itself. At least now you know what the issue is (packet loss) and where to start looking.

My version of ping plotter is a little older, do you mind clicking on the packet loss and taking a screen shot? Also make you samples to include 10.

 

[cengbrecht]

I really am liking your ping plotter.
As you can see, I have started monitoring local, to the server, and to my office.

 

[cengbrecht]

So, now that I am enamoured with PingPlotter.
Here is my office to the church.

 

[bcmike]

You should be able to export the plots to a pp2 file. D you want to send them to me? Hopefully I can open them in my older version

 

[cengbrecht]

You should be able to export the plots to a pp2 file. D you want to send them to me? Hopefully I can open them in my older version

 

[bcmike]

Ok, I had to download the latest version. If you set your focus (at the top beside interval) to 5 seconds and then click in the middle of the red packet loss area, you'll see that the packet loss is %100 starting at your gateway device. The router is the source of your packet loss issue most likely. You might want to try swapping it out with a pfsense box (my personal preference).

 

[bcmike]

I should also mention, I've successfully used Ubiquiti Edge routers but a first had to first disable hardware off loading and SIP ALG.

 

[DigitalDaz]

@cengbrecht Have you disabled session timers yet?

 

[bcmike]

Session timers usually kill a state after a certain time. We're seeing intermittent packet loss, ie the session isn't killed but continues albiet intermittently. You usually wouldn't see a session timer kill an ongoing ICMP connection either.

My moneys on the hardware off loading. I could also be something wierd like a duplex mismatch to the head end equipment, or just bad equipment.

 

[DigitalDaz]

No, the session timer will usually just kill the call or kill the audio on the call.

 

[bcmike]

In his case the audio will resume after a time. Our testing is showing packet loss, this is causing the audio gaps. Whats causing the packet loss is what we're after. I don't believe that's a session timer but I'm open to anything. Extending session timer time outs (or disabling them) is probably a good idea though as they're a pain in the a$$.

 

[cengbrecht]

I will try disabling hardware offloading. Though there is one part that I missed in all this, WISP -> 5port switch -> USG -> switch.
I will be removing that too.
I need to see where that option is...