Я страдаю от проблемы, когда по мере увеличения времени вызова я получаю все больше и больше слышимой задержки. на стороне сервера мне сказали запустить ss -4 -l -n | grep udp (что, я думаю, совпадает с ss -4 -l -n -u?).
там я вижу в recvq для большинства соединений либо 0, либо 2304, иногда ненадолго достигая пика выше этого, прежде чем вернуться к одному из них или где-то посередине.
в примере звонка, который длился несколько часов, и у меня была куча задержек, у меня было recvq 180 000 ... что, по моему мнению, было впечатляющим. сам звонок был: почти 7 секунд задержки туда и обратно.
Я не очень хорошо разбираюсь в этом типе устранения неполадок и брожу по Интернету, читая о том, что означают эти значения recv и send.
2304 важное число? размер очереди по умолчанию для моего ящика? (deb 9 работает с FreeSwitch, если это имеет значение).
Кроме того, меня спросили, может ли проблема быть вызвана неправильной работой нашей схемы comcast. инстинктивно я думаю, что нет: если recvq раздут до чертиков, это означает, что пакеты доходят до него и просто застревают в ожидании обработки приложением, прослушивающим этот порт, верно? или пакеты могут попасть в очередь таким образом, что это приведет к ее раздуванию (это весь трафик udp, поток rtp, если это поможет)?
Также приветствуется дальнейшее чтение о том, как устранять проблемы с задержкой.
