Audio delay on new HW Rev GRP2615 phones


#1

I am working a ticket with GS on this but I was curious to know if anyone else has seen this and / or has found a solution to this.

A few months ago we got in about 200 new GRP2615 phones in a couple of different shipments and we are seeing the same issue with all of the phones out of these shipments. On inbound calls there is an 8 second delay on the audio going back out to the caller. Outbound calls have no delay at all. All of the phones in question have a hardware revision of 2.1c, 2.1d, etc. If I put one of my much older Hardware Rev 2615’s on the same UCM there is no audio delay.

I have duplicated this behavior on several different UCM 63xx models, but it only seems to affect 63xx. And it has happened on every 63xx i have tried (About 10 at this point). It doesn’t happen on my 6510. The only surefire way I have found to resolve this issue is to put the UCM on 1.0.9.10 firmware. Any firmware newer than that has the delay issue and the firmware on the phone makes no difference.

I feel like this might be a NAT issue but I have duplicated it behind multiple routers and multiple network setups at multiple customer locations. We are programming these UCMs the same way we have been for years, the only difference is the Hardware Revision on these phones.

Like I said I am working with GS on this and I am providing them captures, I’m just curious to see if anyone else has experienced it because it’s pretty easy for me to duplicate on any 2.1 Hardware Revision phone.


#2

GRP2615 2.1c, 2.1d, 2.1e different deployments here and in house and haven’t seen this issue.
1.0.7.33 Firmware, 1.0.9.22 Firmware, and different model 6300 UCMs 1.0.15.13


#3

Take a capture of a call as it seems like it should be easy to replicate and and see what is leaving the NIC.

Additionally, make a call between extensions. The phone has no clue of what is external or internal and may even be using the same LAN NIC if the UCM is in switch mode.


#4

Extension to Extension is not affected. It’s also only on SIP, if I do inbound through an FXO port there’s no delay. I have provided the captures to GS already. They said they were seeing some fragmentation in the call flow that wasn’t present in an older phone that doesn’t have the issue.

I haven’t ruled out my SIP carrier as an issue but it’s just odd that this issue is only affecting 2.1 phones. All of my older stock phones do not have this issue. I can put old phones and 2.1 phones side by side on the same system and the old phones work fine and the 2.1 phones have the delay.


#5

I would find it very strange indeed that the phone is the issue given that extension to extension and FXO calling are both fine. The phone has nothing to do with routing how the call goes where, it only goes to the UCM or PBX.

The phone could be the root cause by sending packets that exceed the MTU as that will fragment the messaging. You can possibly test this by setting all the codecs to the same g711u in both the phone, the UCM extension settings for the phone and then the same for the SIP trunk settings.

Then in the phone, also disable the other SIP headers for emergency and the like and finally enable send compact SIP headers in the PBX Settings, SIP settings and ToS.


#6

Only for test, try:
Enable EDRC Feature = 0 [Handset Noise Shield]
P8563 = 0 [Enable Headset Noise Shield]
P8538=0


#7

No change with these settings.


#8

Some of this I had already done in previous troubleshooting with them, disabling the extra header options, setting the SIP Trunks to PCMU only. I did not set the phone itself to PCMU only. I just tried that and no change. I then turned on compact SIP headers and rebooted. Unfortunately the delay is still there on the 2.1 phone. My 1.1 phone is still functioning as it should through all these changes.


#9

The phone must be set to have the codecs the same in order to decrease the amount of data being sent in a packet. Otherwise it will send all 8 default options.


#10

This is an interesting thread please keep us updated on progress we just moving over now to only GRP phones


#11

As per your last suggestion, the only codec I have on the phone and on the extension is PCMU. No other codecs loaded. Prior to that the codecs were at the default setting other than the SIP Trunks which I had set to PCMU only.


#12

And is there any difference?
Can you send me a pcap of a representative call if I DM my email?


#13

check, PCMA may be needed instead of PCMU under some conditions


#14

The profile he has shows USA which would be PCMU/g711u, but some may not put the correct location. If not the USA or N. America. then PCMA/g711a.


#15

yes yes, it was also just to give it a try


#16

So we found the solution to this issue working with GS Support and the provider. Changing the option “Generate In-band Ringing” to yes has eliminated the delay in five different UCMs that I have tested on so far. Firmware on the UCM doesn’t make a difference, with that option set to Never the new phones have the delay. With it set to yes, there is no delay. We’ve never had to touch that setting in the past.


#17

We have occasionally seen this issue when using GRP2615’s on 1.0.7.x and newer firmware connected to Freeswitch 1.10.7 over TLS or UDP, but a factory reset seems to clear this issue up for us.


#18

In my case (exact same issue with GRP2614) ‘generate inband ringing’ did not solve the issue.

I replaced all the phones with GXP2160’s. Problem solved.


#19

So final update on this, Firmware 1.0.21.9 seems to have fixed the issue for me in all circumstances so far. When I asked how they fixed it, their response was “It was not our intention for fix this so one of the changes must have inadvertently corrected the issue.”


#20

I had 1.0.21.9 since initial installation. Problem was present (not sure at the moment if it is resolved or not - please disregard my previous post). UCM still runs 1.0.21.9. I was seriously thinking in going back to 1.0.9.10 until I saw your post from Sep 25…