I don’t know where to start. Our client has been experiencing occasional dropped calls. Their issue is when three calls come in at a time, it drops all three calls. They have given me time stamps and the cdr reports/recorded calls, verify the dropped call, but the logs show no error messages. It just shows the call leaving the simple bridge, first the extension, then the inbound call. I have never dealt with phone systems and network issues till about a year ago. I am still learning, so any expertise advice would be helpful.
I wouldn’t say it’s a network issue, but who knows?..
I myself don’t have much Wireshark experience, but could be someone else here can provide some pointers.
However, I’d say you should post a call log from these failed calls. Maybe we can spot something.
Also, your provider should be able to tell what they see in their end.
Lastly, what’s your Trunk config?
Have the customer pick up all of their phones at once and see what happens. If the POE from the switch is overloaded or glitch, it should trigger and switch reset, which would do precisely what you are describing.
I was running ping tests to the firewall and the phone server and noticed ping results, at times, in the 1000ms. At least 4 or 5 of them in a row. Would that cause packet loss?
Yes, a two-second ping time could possibly drop all of the extensions.
And they have fiber internet
Vitelity inbound
type=friend
dtmfmode=auto
username=xxxxxxx
secret=xxxxxxxxx
context=from-trunk ; (this could be ext-did or from-pstn as well)
insecure=port,invite
canreinvite=no
host=inbound28.vitelity.net
vitelity out
username=xxxxxxxx
type=friend
trustrpid=yes
sendrpid=yes
secret=xxxxxxxxx
host=outbound.vitelity.net
fromuser=xxxxxxxxx
dtmfmode=auto
context=from-trunk
canreinvite=no
the call logs dont show a failed call. just shows the simple bridge being left. first from the extension, then from the inbound.
No POE here.
Hmmm.
There are a couple of config things in your trunk configs, but I doubt they have anything to do with this. If the extension is leaving the call first, it’s either because the phone is resetting or the switch is.
Now, we have seen this before (last year) with a bad switch, so that might be a prudent thing to check. The long ping times, though, seem to be something I’d be concerned about. Since you are losing three disparate phones on traffic, it would seem that something, somewhere, is causing your phones to reset/reboot/reconnect/something. Until you’ve exhausted that line of thought, it’s where I’d focus.
Once you’re sure that the hardware is OK, you’ll want to move on to the software stuff, and the https://wiki.freepbx.org/display/SUP/Providing+Great+Debug?src=contextnavpagetreemode link should give you plenty of information for diving deep into the protocol woes you might be experiencing.
On the trunk stuff, you have both your inbound and outbound trunks described as “type=friend”. While it shouldn’t make a lot of difference, your inbound should be a “user” type and the outbound should be a “peer” type, unless I got those backwards again - the tabs on the screen will tell you which is which. You also don’t need a context for your outbound connection, since you can’t control the context of that leg of the call once it gets to the remote end. Your “rpid” settings should only be needed on your inbound leg - I’m not sure what they will do on the outbound, but they won’t hurt. Likewise, the DTMF mode on the outbound is probably largely ignored.
here is something else i noticed. The “continue if busy” button is enabled on the outbound trunk of that server only and not on the others we have in production. I never set these up, i was handed them when I started here last Aug. Why would that be enabled, on this one, and not on the other production servers. I’m wondering if the outbound trunk gets busy or congested, it fails over to the other trunk, shutting down calls. The instructions say that it is normally unchecked.
If the outbound trunk fails over to your inbound trunk (a new call is going out and can’t get to your outbound leg server) it will try to use that other leg. If your provider gets squirrely about that, anything could happen…
the trunks are based on support examples from vitelity.
ok update. two outbound calls were made. one at 10:00:41 for 2:57 mins. one at 10:01:15 for 1:01. at exactly 10:02:15 a call came inbound that got hammered and killed after 1 second. Another came in at 10:02:31 and was killed after 13 seconds. a call inbound at 10:02:51 was killed as well. i am not seeing anything in the logs that would show why the calls are being dropped.
I did get a sip response 486 from x1000 as well as x1000 picking up a call on x1008
Pickup(“SIP/1000-0000a928”, “1000&1000@PICKUPMARK&600@from-internal&600@from-internal-xfer&600@ext-group&601@from-internal&601@from-internal-xfer&601@ext-group”) in new stack
[2018-10-15 10:03:05] NOTICE[31291][C-00003302] app_directed_pickup.c: No target channel found for 1000@from-internal.
[2018-10-15 10:03:05] NOTICE[31291][C-00003302] app_directed_pickup.c: No target channel found for 1000@PICKUPMARK.
[2018-10-15 10:03:05] NOTICE[31291][C-00003302] app_directed_pickup.c: SIP/1008-0000a927 pickup by SIP/1000-0000a928
I really dont know where to start because it’s so sporadic.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.