Calls dropping - *seems* to be isolated to cordless handsets


#1

This system is giving me trouble on a few fronts - see my other “no audio” post.

They are having dropped calls. I haven’t yet captured an example of one. But all of the ones that have been reported to me so far have been on their Grandstream DP720 cordless handsets.

I can’t be absolutely positive (yet) that no calls are dropping on the hard-wired desk phones (GXP-2170’s) but so far I have no confirmed reports of that.

Does anyone have any experience with the DP720’s and dropped calls? This is my only client (a mechanic) that relies heavily on those units.

Thanks in advance.

Mike


#2

I captured one call yesterday that the client reported as having “dropped.”

The “BYE” signal came from the DP720 handset involved in the call. I suspect that the user will deny having hit the “end” button on the handset. Listening to the call, it sounds like the two parties were saying good bye, when the other party (not my client) added some more audio. I could envision that on my client’s side, the user may have hung up thinking the call was over. Again, I suspect this will be denied.

Is there any scenario where a handset (or desktop phone, for that matter) would send a BYE signal mistakenly/spontaneously without input from the user? I remember analog setups (HT702, etc.) where there were settings that you could make the hangup less sensitive. Anything like that in this environment?

I’ll keep working on capturing more data.

Mike


#3

There are various reasons, but in your trace see if it might have a reason code such as Q.850: cause code 16 or other. The code may provide a clue…

Keep in mind that the handset is DECT and the device responding is the base. Unfortunately, there is no visibility as to what goes on between the HS and base. So, it is unknown if the HS/base lost signal for that split second, if session timers were satisfied, user error, call waiting user error, etc…

At this point I can only suggest that you keep up with the latest firmware.


#4

Here’s the packet:
8977 59.377661 192.168.11.16 192.168.11.2 SIP 587 Request: BYE sip:1006@192.168.11.2:5060

.16 is the DECT base, .2 is the UCM. The packet immediately before this one was RTP.

I’m not seeing a reason code in the packet content window . . . there’s a portion that says, “tag=85053380” - is that what I’m looking for? (I’m using Wireshark, but my understanding of that software is newbie level at best!)


#5

Like this -


#6

Mine looks like this:
image


#7

Found this thread that may have something to do with my problem:

Not a very clear resolution in that thread either.


#8

Well there is no requirement that the header be included and it may not be in the same order as shown in mine, I suppose it may also be possible that it only reports the reason when it can identify the reason. You might do a capture from the UCM of the DP while doing a call and end the call normally from the DP and see if the code shows up.


#9

I think I may have found the problem. On the DP750, the cordless handset used most often (and has the most dropped calls) was set up in HS Mode as “circular” instead of HS1. (Under DECT-SIP). No matter how many times I changed it back, it would revert to “circular” when I rebooted the base station. I finally disabled that account and rebuilt a new one and pointed it to HS1. Then it stayed that way after several reboots. I also upgraded the firmware on the base while I was at it. (It was only one version behind.)

Unfortunately they’re closed over the weekend, so I’ll have to wait for Monday for battle conditions. :slight_smile:

I’ll come back with an update once we see how things go on Monday.

Mike


#10

Tom here…

Short answer: Buy Yealink T26P cordless sets to replace the DP720’s

No offence, but I replaced the DP units 3x at two locations that really use them alot. Nearly lost both clients as subscribers.

Installed Yealink Cordless to the UCMs and clients are happy.

Sorry can’t explain it.


#11

#12

#13

CORRECTION. I mean YEALINK W52P.