GRP2604p lost RTP packets "wrong sequence number"

#1

Hello, everyone.
Our company uses phones GRP2604p and UCM6302, there are phones of other models, but the question specifically for this model.
Users complain about delays during the first seconds of call, and the voice delay is true there is about 1-3 seconds.
We began to collect packets on the PBX and found the problem that the PBX in communication with this model of phone reports “wrong sequence of numbers”, and gives great data loss and delays at start. The problems are observed in two directions from the PBX to the phone and from the phone to the PBX. With other models everything is normal, no delays and losses.

Can anyone suggest what is wrong, if the problem is in the settings, but they are the same for all models, or maybe there is a problem in the firmware of this model?

grp2604
grp2604.jpg980x277 101 KB

#2

Maybe someone will have the same problem.
The staff helped to solve it by advising to disable FEC mode, “Enable Audio RED with FEC” on WebUI.
At the moment everything works pretty stable.

#3

Enable Audio RED with FEC is already activated by default,
strange that if you enable FEC on the UCM the audio has some degradation, it should be an audio protocol from Grandstream that is supposed to improve the audio not worsen it.

#4

FEC is forward error correction and is not GS specific. Keep in mind that the other side also has to support the same function in their sending/receiving of RTP. There are RFCs that define its use in SIP/SDP, but I do not know of anyone actively using it from a SIP provider perspective. SD-WAN companies, Asterisk and Opus can support FEC and GS does indeed have their own proprietary version for use between some GS device and others do use FEC and presumably it will grow, but one needs to check and understand when and where to use before assuming it sounds like a good idea.

https://documentation.grandstream.com/knowledge-base/ucm630x-audio-video-qos-improvements-guide/

#5

“GS-FEC is a proprietary algorithm developed by Grandstream to minimize the effects of audio/video packet
loss and can handle up to 50% packet loss in audio. This option is also available in the web portals of
supported Grandstream product models”.

https://documentation.grandstream.com/wp-content/uploads/2021/10/UCM63xx_Audio_Video_QoS_Improvements_Guide.pdf

#6

I stated that as well.

However, while I have no idea if the implementation that GS has provided is robust and without any issue, I also do not know what codec was in use or if the settings were enabled in the UCM as well and with what parameters.

The post did not mention what other models of phones and if they are enabled in the phone as well as the UCM and from a different perspective, where the phones are located relative to the UCM and if such is really needed.

There are simply too many questions in my mind to assume that the two devices were setup to use the function correctly, that the function itself as implemented by GS is without bugs and more to the point that the manuals provide any insight as to how best to use -

From the GRP6204P manual -

image
image.png1126x131 13.8 KB
.

I guess setting “No” is meant to be a mystery or not supported or ??? (just a typo, but still).

#7

Hi Larry,

combination today I was reading the sentence that I copied above you, and combination earlier I read that you mentioned the FEC, I just copied the sentence thinking I didn’t read it,
I did this test yesterday
I activated a remote WAVE APP, and the audio wasn’t really satisfactory,
so I activated the audio FEC on the same extension,
it will be a coincidence but the audio was definitely improved.

So I thought I’d read GS’s audio FEC references.

Maybe my experience today could help someone.

It is also true that when you are in the area, and you connect to the mobile data with your cell phone, the internet network is not stable and full of pitfalls, perhaps in my case the audio was not improved only for activating the FEC, but for a set of circumstances …

#8

I have not played around with it yet, as I have not had a need. My issue with it is that when GS indicated to simply turn it off. That to me is like going to the doctor and telling him that when you do x, it hurts and his response is well, don’t do X anymore and the hurt will go away.

However, with Wave I do not think there is quite the same number of settings as with the other although I could be wrong.

#9

Yes, it’s on by default, and we had it on. On the advice of the specialists, we disabled this option on the phone to see if there will be any changes. The change was for the better. I do not know how it should ideally be :slight_smile: but it was so.
Almost everything on the PBX and machines is by default and we expect there will be problems.

#10

Hi
For a general understanding of the picture, I can add some information :slight_smile:
UCM 6302 fw1.0.17.11, GRP2615 fw1.0.9.22, GRP2604p fw1.0.3.72, GAC2500 fw1.0.3.42, DP752 fw1.0.17.8.
All devices are in the same VLAN, basic settings are default, G.722 codec is used.
No problems with other phones except GRP2604, and FEC can be turned on or off only on them. There is no such function on the other devices.
For us turning off the FEC had the effect we wanted, the delays disappeared, the loss of packets stopped.

#11

try to insert only the PCMU (or PCMA) codec

#12

We already tried that, it didn’t work.

#13

TRY:

P8563=0 [Enable Headset Noise Shield]
P8538=0 [Enable Handset Noise Shield 2.0]

#14

We interviewed the employees while testing the system after turning off the FEC, the employees said that it was almost perfect, so try any other solutions does’t make sense :slight_smile:
Perhaps colleagues from the GS will solve the problems in the work of the system in the future.
Thank you for your participation and advices :slight_smile:

#15

I was telling you that, on the contrary, I have turned on the FEC on the phones, and instead the two settings above are turned off,
it could also be that if they are all ON, they conflict with each other

#16

I must have misunderstood.
Okay, when I have a chance I will definitely check this point.