hikvision ds-kb8112 +*+ gigaset - изменение длины пакета?

[sasa]

потому что вируталка

[ded]

+ + +
если Hyper-V - проблема синтетического clocking
https://www.google.com/search?q=asteris ... und+choppy

[Vlad1983]

все паркеты с флагом "Mark" и часто кривой seqno
такого бардака я еще не встречал ни разу

попробовать выставить в rtp.conf strictrtp=no

[amateur]

Мне кажется звук где то внутри * портится при трансформации 40мс в 20 мс.

Может и не кажется. Панель не указывает ptime. Следовательно, со стороны Asterisk он должен устанавливаться в default - 20мс. Но по факту панель шлет аудио кадрами по 40мс. Вполне возможно, что Asterisk, исходя из установленного на канале ptime, из каждого пакета берет только первые 20мс, а оставшиеся 20 отбрасывает. Надо конечно исходники подробнее поизучать. Давно не занимался этой темой...

В общем, если предположение верное, то нужно каким-то образом принудительно устанавливать ptime=40 для вызовов от/к панели. Каким способом это сделать пока сказать не могу. Не исключено, что надо будет изготовить патч

[ded]

все пакеты с флагом "Mark" и часто кривой seqno
такого бардака я еще не встречал ни разу

Это работа высокопроизводительного виртуального свича в Hyper-V, в котором гигабитный трафик возможно и быстро обрабатывается, но вот мелкие пакеты UDP/RTP - плохо, нарушается секвенсирование.

Панель не указывает ptime. Следовательно, со стороны Asterisk он должен устанавливаться в default - 20мс.

Можно попробовать установить всем в дефолт в sip.conf

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

[general]
......
allow=alaw:40

[Vlad1983]

Это работа высокопроизводительного виртуального свича в Hyper-V, в котором гигабитный трафик возможно и быстро обрабатывается, но вот мелкие пакеты UDP/RTP - плохо, нарушается секвенсирование.

свичи внутренности RTP впринципе не могут менять
это это китайское говно делает

[ded]

Возможно я как-то неверно себе это представляю.
Как делает? Вот просто посылает RTP пакеты, нумеруя их по порядку: 1, 2, 3, 4, 5
буфер интерфейса панели проходят прямиком, попадают в буфер сетевого интерфейса на сервере, где виртуалка Астериск. Там виртуальный свич сам занимается нарезкой виртуальных интерфейсов и очередей/буферов к ним. Это верно?

[Godz]

+ + +
если Hyper-V - проблема синтетического clocking
https://www.google.com/search?q=asteris ... und+choppy

Не, у меня на vmware крутится, машина 6 ядер, 32 гига оперативки - ничем вообще большне не занята.

Панель не указывает ptime. Следовательно, со стороны Asterisk он должен устанавливаться в default - 20мс. Но по факту панель шлет аудио кадрами по 40мс. Вполне возможно, что Asterisk, исходя из установленного на канале ptime, из каждого пакета берет только первые 20мс, а оставшиеся 20 отбрасывает.
В общем, если предположение верное, то нужно каким-то образом принудительно устанавливать ptime=40 для вызовов от/к панели. Каким способом это сделать пока сказать не могу. Не исключено, что надо будет изготовить патч

Все указывает что вы правы, реально по бульканью и графику похоже что первые 20 мс берет, попробую посравнивать пакеты.
Но я пробовал этой панели ставить allow=alaw:40 и астериск начал на нее отправлять с 40мс интервалом, но может на трафик "от нее" эта настройка не распространяется и * продолжает смотреть ptime.

Там виртуальный свич сам занимается нарезкой виртуальных интерфейсов и очередей/буферов к ним. Это верно?

Да, виртуальный свич выстраивает буфер из пакетов, но во внутрь пакетов не лезет. RTP пакеты это банальные udp посылки, их вирт свич никак не трогает, как пришли, так в машину и пихает не меняя ни байта.

[Godz]

все паркеты с флагом "Mark" и часто кривой seqno
такого бардака я еще не встречал ни разу

Если вы когда нибудь хотя бы допустите мысль связаться с hikvision, просто вспомните этот дамп wireshark .

попробовать выставить в rtp.conf strictrtp=no

Попробовал, насколько понимаю по дампу и ухом - лучше сильно не стало, дамп заатачил.

P.S. Спасибо всем кто откликнулся поковырять это китайское говно, мир на нем клином не сошелся, если усилия по вправке мозгов этой какуле превысят разумные - пойду куплю панель от beward, у них к sip не было нареканий.

[Godz]

Мне кажется звук где то внутри * портится при трансформации 40мс в 20 мс.

Вполне возможно, что Asterisk, исходя из установленного на канале ptime, из каждого пакета берет только первые 20мс, а оставшиеся 20 отбрасывает.

Неа, проверил. Нашел пакет от Панели на *, нашел два пакета сразу после с * на gigaset. Астериск ровно разбил один пакет на две части - сравнил по Payload rtp пакетов, на скрине черным второй пакет. Получается где то плечо * -> gigaset косячит.