Проблемы с качеством звука

[romeotomsk]

Простите за туповаты вопросы... сразу себя по лбу стукнул как только отправил предыдущее сообщение! все ответы нашел в такой связке sip.conf.0+on-line переводчик+google )))))))

[romeotomsk]

В общем теперь ситуация обратная, со стороны моего шлюза практически нет никаких искажений, 0,6 % или менее того или вообще все значения по нулям. Однако со стороны моего SIP-провайдера потери в jitter соствояют порой до 28%, ну и соответственно wrang timestamps. По идее, мой сип провайдер до меня ведет старую добрую PSTN-телефонию, которая у них на оборудовании преобразовывается в VoIP, затем по медной паре через HDSL-модем ко мне в астериск. По логике при такой схеме пакет не должен особо много гулять по сети в поисках пункта назначения и jitter не должен появляться в таких больших размерах.

[romeotomsk]

И еще одно, со стороны провайдера голос ко мне может приходить с ошибкой drop by jitter buff: 0(0%) но при этом Wrong timestamp 239(16.6%) - один из случае. Результаты взяты при помощи дампа+вирешарк. Не совсем понима. как это так, я думал, что эти два понятия взаимосвязаны.

[romeotomsk]

У кого есть мысли по поводу следующего: сделал дамп сетевого интерфейса, с которого астериск общается с внешним миром, картина следаюущая
From 217.18.137.50(провайдер) to 192.168.1.198(asterisk) Drop by jitter buff 0, Out of Seq 0, Wrong timestamp 0
From 192.168.1.198(asterisk) to 192.168.1.199 (VoIP-шлюз) Drop by jitter buff 51, Out of Seq 0, Wrong timestamp 43
From 192.168.1.199(VoIP-шлюз) to 192.168.1.198 (asterisk) Drop by jitter buff 0, Out of Seq 0, Wrong timestamp 1
Вот, речь конечно про один и тот же звонок. Пока только одни такой звонок обнаружил. Обычно если от провайдера голос не рваный приходит, то он и дальше на шлюз приходит не рванный.
В чем может быть дело? Сам астериск гони? Или быть может моя сетка гонит, хотя астериск и шлюз воткнуты в роутер DI-804, в котором я на оба эти порта поставил наивысший приоритет в плане QoS. (Сам роутер уже смотрит во внешку)

[ded]

Да нет, сам оператор гони.
Наивысший приоритет в плане QoS! Вы можете приоретизировать только исходящий трафик, входящий как пришёл - криво/не криво, с пропаданиями или без - так и воспроизводится. Почитайте в википедии - QoS нисходящего потока (если там не затёрли её).

[romeotomsk]

Спасибо большое! Ваши ответы всегда очень ценны! Вооружившись присланной вами командой для снятия дампа и установкой вирешарка, я стал понимать больше в VoIP и в частности причины моих конкретных проблем. )))

[ded]

Я тоже

[romeotomsk]

Еще один непонятный момент, делаю дамп, открываю его варишарком, делаю анализ VoIP звонков, нахожу там такую картину. Входящий голос мой абонент слышит, а вот исходящий голос моего абонента вызываемый абонент не слышит, хотя голос от моего абонента ушел до провайдера без проблем, по крайней мере я никаких ошибок в варишарке не увидел???? Есть подозрения что мой голосовй шлюз dlink так работает, но с другой сторонры голос то на провайдера ушел??? или это ничего еще не значит?

[romeotomsk]

Помогите, люди добрые, обшарил уже весь инет! Собеседник перестает меня слышать через время. Не все такие звонки, но частенько бывает. Уже сделал дамп не только со своей стороны, но и добился, чтоб и провайдер сделал дамп с его стороны. RTP-поток от меня уходит, все нормально, просто в определенный момент времени перестает слышать мой голос, ну и соответственно кладет трубку.
|Time | 10.60.4.18 |
| | | 10.60.1.2 |
|15294,058| INVITE SDP (g711A telephone-eventRTPType-101) |SIP From: "469961" <sip:469961@10.60.1.2 To:<sip:903903@10.60.1.2
| |(5060) ------------------> (5060) |
|15294,068| 100 Trying| |SIP Status
| |(5060) <------------------ (5060) |
|15294,132| RTP (g711A) |RTP Num packets:2581 Duration:51.600s SSRC:0xAECDA195
| |(21322) <------------------ (18882) |
|15294,148| 183 Session Progress |SIP Status
| |(5060) <------------------ (5060) |
|15294,415| 200 OK SDP (g711A) |SIP Status
| |(5060) <------------------ (5060) |
|15294,415| ACK | |SIP Request
| |(5060) ------------------> (5060) |
|15294,698| RTP (g711A) |RTP Num packets:2540 Duration:50.940s SSRC:0x7C1EA181
| |(21322) ------------------> (18882) |
|15345,714| BYE | |SIP Request
| |(5060) ------------------> (5060) |
|15345,750| 200 OK | |SIP Status
| |(5060) <------------------ (5060) |
вот, в момент времени 15342 (это я уже определил, когда восстановил голос) собеседник перестает меня слышать, я понимаю это и ложу трубку, соответственно приходит запрос BYE в 15345, все, никаких ошибок, нормальное начало разговора, нормальное завершение. Провайдер говорит, что мол это моя станция шлет BYE, поэтому собеседник перестает слышать, мол шлет команду BYE, когда на самом деле я еще не положил трубку, вот сейчас точно вижу, что не шлет моя станция никаких необоснованных BYE. У кого есть мысли, мы в тупике, и я и провайдер. Пакеты не могут гулять долго, потому что у нас выделенная линия до провайдера (мы с ним находимся в одном городе), а сам провайдер представляет собой тех, кто собственно и предоставляет PSTN в городе. т.е. SIP-клиент-выделенная линия-SIP-сервер+обоурдование провайдера-PSTN вот как-то так.

[ded]

Нужно отследить ещё: если в момент, когда собеседник перестает слышать, RTP поток в его сторону прекращается - тогда это проблема траспортного уровня. Если не прекращается - проблема програмная, где угодно сидящая по пути следования к собеседнику. Там ведь какой-то биллинги и шлюз оператора предполагается? Такая ерунда вполне может быть следствием кривоты биллинга (RADIUS?), который считает, что это соединение нужно загасить в одностороннем порядке, так как на счету кончились деньги.