TTK Asterisk - звонящий на номер ТТК слышыт прерывисто.

[lamobot]

Всем бобра коллеги!

Значит такая проблема, человек звонит на номер, арендованный у ТТК, внутренний абонент астера все слышит нормально, а звонящий слышит прерывисто или звук искажается.
На астере еще несколько транков, т.ч. от РТК, пчелайн и т.д. Все ок!

Снял дамп на астере, прослушал акулой, астер "слышит" обоих собеседников отлично. Т.е. при проигрывании файла дампа ни каких искажений я не услышал.

ТП ТТК говорит проверять инет. Чего его проверять если остальные как работали так и работают?!

Ехать в гости к ТП с битой или может еще варианты есть?

[ded]

Вариант: прежде чем ехать с битой - делать замеры
mtr IP_addr_TTK -u
опция -u говорит об измерениях трассы посылкой UDP пакетов.

Ваш парадокс в том, что безупречная запись разговора на Астериске, как и дампа, не указывает на источник проблемы.
Ведь если ровные идеальные RTP (UDP) ТХ пакеты убегают звонящему, который слышит прерывисто, то значит проблема где-то в исходящем канале, на трассе между Астериском и ТТК. И это можно детектировать через mtr (My traceroute), который покажет например, ужасный джиттер на одном из узлов. Мы наблюдали такое, свяше 4500 мсек периодически на маршруте.

[lamobot]

Благодарю! Интересная тулза, записал.

Судя по цЫфирькам, ни чего критичного. Хотя, предпоследний хоп, все ж, напрягает не много.

[Показать] Спойлер: mtr

Код: выделить все

Loss%   Snt   Last   Avg  Best  Wrst StDev
0.0%   216    0.8   2.2   0.7  48.7   5.0
0.0%   216    1.0   2.5   0.8  33.7   5.2
0.0%   216    1.6   2.2   1.3  28.1   2.9
0.0%   215    5.9   6.3   5.7  33.8   2.6
0.0%   215    5.5  49.3   5.3 419.6  70.6
0.0%   215    5.6   5.7   5.5   7.6   0.2

Дали еще одну вводную, если внутренний клиент звонит через этот же транк, то проблем со звуком нет. Как так?

[ded]

Worst 419.6 - худший. То есть иногда тормозится неоправданно. Это и есть джиттер.

Как так?

Как-то.
Замеры tcpdump надо делать не на вашей стороне, а у ТТК.
Что будет выявлено при анализе - перепутанный порядок RTP пакетов, т.е. нарушенное секвенсирование, как результат слишком "умного" буфера FIFO на предпоследнем узле.

[lamobot]

Благодарю! Вы, скорее всего, правы.

Сделал эксперимент, завел этот транк от ТТК на другой астер, в другом офисе, подружил два астера и проблема исчезла. Второй астер в сети другого провайдера и проблем нет.

Еще раз, спасибо!