Страница 1 из 2

Звонки между двумя астерисками

Добавлено: 05 дек 2017, 16:52
w307892309
Здравствуйте.
Было два филиала, между ними L2TP-туннель и OSPF на mikrotik'ах
Астериск были прописаны друг у друга в host и port без регистраций и паролей (и без Ната) и все работало
В один прекрасный момент при входящих с соседнего филиала я начал получать forbidden (403)
Причем, если в настройках пиров я прописываю defaultuser, то звонки проходят, но номер определяется как этот юзер
Есть предположение, что такое поведение связано с обновлением микросипов (других работ не производилось)
Хочется вернуться работоспособность (звонки с филиала на филиал проходят и внутренние номера определяются верно)
Подскажите, как локализовать проблему и где лучше почитать про процесс авторизации, который у меня не проходит?

Re: Звонки между двумя астерисками

Добавлено: 05 дек 2017, 17:41
ded
Как понять по какому протоколу
w307892309 писал(а):Астериск были прописаны друг у друга в host и port без регистраций и паролей (и без Ната)
??
Если поведение связано с обновлением микросипов, то а) отключите SIP ALG (SIP helper), б) изучите опцию insecure=

Re: Звонки между двумя астерисками mikrotik sip alg [решено]

Добавлено: 05 дек 2017, 23:16
w307892309
Прошу прощения, что несколько сумбурно прописал.
соединение по sip, без регистрации, паролей и тп. прописан только host

Проблема появилась после обновления одного из микротиков:
микротик стал дописывать свой внешний адрес в сип-пакеты соответственно звонки не проходили (с такого ip прием звонков не был предусмотрен)

со стороны вызывающего астериска видим: handle_response_invite: Received response: "Forbidden" from ...кто звонит...
со стороны вызываемого астериска видим: handle_request_invite: Failed to authenticate device ...кто звонит...

Сейчас проблему решил вынесением астерисков за нат относительно друг друга и пробросом портом на микротике (раз уж они так хотят использовать внешний адрес)

PS mikrotik 6.40.5, IP->Firewall->Service Port - выключено все, но либо "работает и так", либо еще куда-то засунуто в версии 6.18 такого не было

PS2 - insecure на этот раз не пригодилось, то в процессе экспериментов я вдолбил себе в голову с чем это курят

Re: Звонки между двумя астерисками

Добавлено: 05 дек 2017, 23:34
ded
1) Астериск завсегда лучше не за НАТ, а в DMZ, на реальный адрес.
2) Соединили бы по IAX2 и не было бы таких проблем.

Re: Звонки между двумя астерисками

Добавлено: 06 дек 2017, 20:08
w307892309
к iax тоже склоняюсь.
сейчас получил по второму каналу на каждой точке - его буду использовать только для телефонии, там и настрою.
тем более каналы не широкие и систематически входящий трафик канал забивает - проявляется не потерей пакетов, а увеличением задержки на 100-200 ms

Спасибо (если советует ded и ты не попробовал - сам дурак)

Re: Звонки между двумя астерисками

Добавлено: 06 дек 2017, 20:19
Zavr2008
каналы не широкие и систематически входящий трафик канал забивает
QoS на микротиках настраивается довольно просто.

Re: Звонки между двумя астерисками

Добавлено: 06 дек 2017, 20:24
ded
C увеличением задержки на 100-200 ms можно вытянуть ещё качество через jitter buffer.

Re: Звонки между двумя астерисками

Добавлено: 06 дек 2017, 21:47
w307892309
QoS в микротике действительно настраивается очень просто (сначала два дня на понять как работает, потом просто), а потом на радостях 5-10 человек одновременно что-нибудь скачивают, и то, что они скачивают начинает провайдером ставиться в очередь пока скорости (максимальная для этого клиента и та, с которой отдает сервер) не устаканятся. При этом провайдеры у меня не режут трафик, а "тормозят".
соответственно голосовые пакеты и попадают под эти же тормоза.
Очереди отрабатывают нормально, но получается такое: сначала хорошо слышно, потом слышимый затык (может 0,5 секунды всего), а потом опять нормально. В начале рабочего дня, когда сутра надо посмотреть почту и показать котиков качество телефонии весьма рандомно...

2 ded - jb в этой сети помогает слабо - скачек задержки обычно резкий и короткий, поэтому динамический буфер не успевает "незаметно" вырасти, а сразу его делать большим статическим не хочется, особенно в контексте проблемы с забиванием внешнего канала.

в эту же тему думал про такую настройку - allow=ulaw:30 - в интернетах встречал, но нормального объяснения что это такое не нашел. предполагаю, что это количество миллисекунд голоса, отправляемых за раз. Соответственно мне сложно на основе этого предположить результат подобных изменений и его проверить (вернее проверить, что с ним стало лучше или хуже)

Re: Звонки между двумя астерисками

Добавлено: 07 дек 2017, 07:20
virus_net
w307892309 писал(а):При этом провайдеры у меня не режут трафик, а "тормозят".соответственно голосовые пакеты и попадают под эти же тормоза.
работает shaper
w307892309 писал(а):а потом на радостях 5-10 человек одновременно что-нибудь скачивают
так настройте не QoS, а shaper на локалку, выделите общий шейп на локальную сеть, скорость поставьте меньше чем пропускная по каналу, тем самым резервируя полосу под ваш Aster. Что ж все QoS то лепят вечно... QoS пропускную канала не расширяет.

Re: Звонки между двумя астерисками

Добавлено: 07 дек 2017, 09:51
w307892309
virus_net писал(а):так настройте не QoS, а shaper на локалку, выделите общий шейп на локальную сеть, скорость поставьте меньше чем пропускная по каналу, тем самым резервируя полосу под ваш Aster.
не стал подробно расписывать, но так и сделано.
а работает оно так:
в процессе звонка несколько пользователей начинают смотреть котиков (на ленте типа контакта с автодогрузкой по мере прокрутки)
или большой файл (относительно) качать в несколько потоков.
скорость канала 10 mbps, исходящий трафик - даже меньше 0,5 mbps, а вот входящий до шейпера провайдера может прыгнуть и до 20-30 mbps - и все "лишние" пакеты встают в очередь вместе с голосом asterisk'а
после такого пика система автоматически подстраивает свою скорость, чтобы максимально утилизировать канал - я на своей стороне выставил ограничение на 9 mbps - и при этом не создавало очередь на шейпере (отправляющая сторона отдает трафик с меньшей скоростью) и голос опять ходит нормально.
На графиках, снятых с внешнего порта маршрутизатора это хорошо видно.

При этом в браузере все хорошо и даже при большом количестве пользователей странички грузятся у всех, но с одинаковыми тормозами (если до них доходит) - полоса делится поровну между активными пользователями