Избитая тема балансировки Kamailio + X Asterisks

[indeec]

Замените break на exit в конфиге
Дальше рекомендую записать развёрнутый лог kamailio когда звонок проходит и когда нет, и сравнить.

[Dark_Angel]

Очевидно exit не помог, но и не ожидалось. Начал курить дебаг. И вот что нарыл. В месте, где происходит чтение дайджеста - всё пучком. Далее идет:

6(1678) DEBUG: auth [api.c:246]: authorization is OK
6(1678) DEBUG: auth [api.c:194]: nonce index= 9
6(1678) DEBUG: auth [index.c:187]: nonce already used
6(1678) DEBUG: auth [api.c:198]: nonce index not valid

После чего, ядро освобождает ресурсы и следующее сообщение уже от xlog о false от авторизации.

Соответственно при успешном звонке, после назначения индекса нонсу, всё идет дальше. Что посоветуете сделать в данном случае?

[indeec]

У меня данная проверка такая же и всё ОК

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

if (!proxy_authorize("domain","subscriber")) {
    proxy_challenge("domain","0");
    exit;
};

Ошибка не очевидная, всё что тут могу посоветовать внимательно смотреть дебаг, и экспериментировать и блоками поотдельности.

[Dark_Angel]

Ошибка была в скрипте. По ходу 2 раза звался proxy_authorize() для одного и того же инвайта. Дальше ему присваивался один индекс нонса, и всё валилось. Обнаружилось это при очень тщательном раскуривании дебага.

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

Вообщем сам виноват. Продолжу настраивать. Как разберусь в фейлом нод - дам знать. Пока искал решение авторизации видел интересный, и судя по всему рабочий, вариант этой самой фильтрации. Как сделаю - выложу.

[indeec]

Что имеется ввиду под фейлом нод? модуль диспетчер умеет отслеживать живые ноды

[Dark_Angel]

Возможно Вы правы, но я такой возможности в модуле найти не могу. Более того, тогда зачем в нем функция ds_mark_dst() если он сам умеет это делать?

Если у Вас есть работающая конфигурация с отсечением плохих гейтов, поделитесь пожалуйста, я думаю многим будет полезно.

[indeec]

У модуля есть настройки "пинга" нод
Но у меня оно не используется, я просто выбираю другую ноду в случае если транзакция заканчивается неудачей. Для этого есть ds_next_dst(). Помоему пингать ноды имеет смысл только если работаем в stateless, или в каких-то специфических условиях

[Dark_Angel]

Спорный вопрос как лучше делать. Если кластер А из 2х машин, как в моем случае, то возможно установка маленького таймаута оправдана и не надо ничего больше городить. Но если кастер большой, то мне кажется, что маркать мервые астериски нужно, потому что если пол кластера умрет, то звонки будут ходить с большими задержками. Вообщем буду експерементировать.

[Dark_Angel]

Приступил к работе над фейловером. Почитал доку ( http://www.kamailio.org/docs/modules/1. ... tcher.html ) , действительно есть работа с фейловером, но у меня она почему-то не работает. Я сделал так:

modparam("dispatcher", "ds_ping_from", "sip:pinger@test.local")
modparam("dispatcher", "ds_probing_mode", 1)
modparam("dispatcher", "ds_probing_threshhold", 1)
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 5)
modparam("tm", "fr_timer", 5000)
modparam("dispatcher", "flags", 2)

Некоторые переменные выставлены специально, хотя дефолтно они уже такие. Тем не менее - ничего не происходит. К не спрашивает А ни о чем, когда А падает, гейт продолжает считаться нормальным. Если в файл роут поставить ds_mark_dst(2), то А становится в пробинг, но оттуда уже не возвращается.

Мне кажется, что у меня диспетчер скомпилирован без поддержки фейловера. Я ставил К из rpm c офсайта (3.0.3), но в дебаге никаких ругательств на flags = 2, которое включает поддержку - нет.

Сейчас попробую пересобрать К из исходников, но что-то мне подсказывает, что это не поможет.

Added after 11 minutes:

И так в RPM он собран без фейловера. Сорцы спасли.

Всё остальное описано в доке по модулю. Никаких костылей делать не надо. Ничего вообще делать не надо. Просто расставить правильные ключи и он всё сделает сам. Отличный модуль.

Рекомендую только поставить
modparam("dispatcher", "ds_ping_interval", 5)
чтобы не ждать долго ответа от гейта. В случае одного провала он всеравно не попадет в пробинг.

[ZloMurz]

Расскажи как собрал dispatcher с нужной опцией.

И еще если не жалко покажи конфиги которыми раскидываешь звонки на asterisk сервера.

[Dark_Angel]

Я сделал очень просто: скачал сорцы своей же версии, и сделал банальный make --prefix=/ all

Потом взял скомпиленый модуль диспетчера и заменил ним свой из RPM. Всё заработало. То есть ничего изобретать не нужно - если будете собирать из сорцов - всё соберется как надо.

Касательно конфигов - выложу чуть позже, когда запустимся и правки в конфигах закончаться. В целом, я смотрел конфиги сгенеренные через сайт - они вполне себе замечательные, то есть вполне можно начать с них. Я же начал с выложеных конфигов не первой свежести и из-за этого потерял кучу времени и сил. Впрочем результата всеравно достиг и уже когда узнал про сайт переползать на его конфиг желания не было.

Сам разброс у меня происходит в отдельной секции и там все примитивно:
ds_select_dst и потом возвращаюсь в основной роут, который борется с натом и определяет пути для onreply и для on failure.

Если роут зафейлился по причине таймаута, то берем следующий гейт пока не кончаться все.

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

[Dark_Angel]

Продолжая разраборку уткнулся в проблему с запросом SUBSCRIBE и К. Все модули для presence поствил и подключил. Софтфон X-Lite - отлично видит присутствие своего контакт листа. Но хардварные телефоны Yealink и Linksys - не видят. Пакетики ходят, всё отлично, подписка проходит. НО. У них во-первых запрос идет с другим Event. X-lite: presence, Hardphones: dialog, во-вторых разниться диалог после подписки. X-lite шлет свои состояния через PUBLISH и получает NOTIFY ( как и должно быть ), а хардфон свои состояния не публикует вообще никак.

И всё бы можно было свалить на хардфоны, вот только с астериском напрямую они работают замечательно.

Кто-то сталкивался с чем-то похожим? Кому удавалось подружить К с хардфонами для запросов SUBSCRIBE и какими?

[kks]

И всё бы можно было свалить на хардфоны, вот только с астериском напрямую они работают замечательно.

Подозреваю, что Астериск сам рассылает запросы и определяет онлайность/оффлайность юзерагентов

[Dark_Angel]

Да нет, ну сабскрайбы он принимает и нотифаи рассылает только подписчикам. Всё сугубо в рамках RFC.

[Dark_Angel]

Оказалось, что астериску не нужны PUBLISH чтобы понять, что хост в онлайне. Телефоны не слали PUBLISH, а слали только SUBSCRIBE и К честно считала их в оффлайне, тогда как у А, похоже есть workaround для этого.

[Dark_Angel]

Появился еще один вопрос. Есть К и А. К имеет 2 интерфейса - приватная сеть и интернет. А имеет только приватную сеть. Устройства регаются на К, соответственно имеют контакты вида 100@X.X.X.X и 101@X.X.X.X.

Скажем есть звонок с 100 на 101. Первый инвайт генериться от 100 и приходит к А. А генерит инвайт для 101.

И вставляет в From, To уже приватные адреса. Это логично, т.к. внешних интерфейсов Астериск не имеет, но в таком варианте звонок не может состояться, т.к. пришедший пакет имеет в своих хедерах приватные адреса, о которых ничего не знает UAC.

И получается что в запросном инвайте:
From: 100@PUBLIC
To: 101@PUBLIC

А в ответном:
From: 101@PRIVATE_ASTERISK_IP
To: 100@PRIVATE_KAMAILIO_IP

Да, если выдать астериску реальный адрес, чтобы к нему можно было достучаться извне и попросить К говорить по реальной сети только, то всё работает без вопросов.

Какие есть варианты куда копать?

[indeec]

externip в sip.conf
Но не совсем понятно что вы хотите получить, вопервых позвонить c 100 на 101 можно вообще без астериска. Если вы всёже хотите пропускать вызовы через asterisk для каких-то мультимедийных штук - то последний инвайт так же должен возвращаться к 101 через камаилио, который должен проксировать. в таком случае всё должно работать, даже не смотря на то что в сообщениях кой где будут фигурировать серые адреса. Но в такой конфигурации вам ещё нада внимательно смотреть на проксирование медиа трафика с помощью камаилио.

[Dark_Angel]

Решил тогда же. Проблема была в проксировании медиа трафика между К и астериском. Надо было включать разные режимы rtpproxy для инвайтов от клиента и астериска.

[itreers]

Как решили проблему с проксированием?

[Игорь]

Как решили проблему с проксированием?

скорее всего выставлением правильных флагов для force_rtp_proxy...

http://www.kamailio.org/docs/modules/3. ... proxy.html

[itreers]

Прошу прощения, а можно немного подробнее. Я с rtpproxy ранее вообше дела не имел.