Избитая тема балансировки Kamailio + X Asterisks
Модераторы: Admins, Модераторы
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Очевидно exit не помог, но и не ожидалось. Начал курить дебаг. И вот что нарыл. В месте, где происходит чтение дайджеста - всё пучком. Далее идет:
Соответственно при успешном звонке, после назначения индекса нонсу, всё идет дальше. Что посоветуете сделать в данном случае?
После чего, ядро освобождает ресурсы и следующее сообщение уже от xlog о false от авторизации.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
Соответственно при успешном звонке, после назначения индекса нонсу, всё идет дальше. Что посоветуете сделать в данном случае?
У меня данная проверка такая же и всё ОК
Ошибка не очевидная, всё что тут могу посоветовать внимательно смотреть дебаг, и экспериментировать и блоками поотдельности.
Код: Выделить всё
if (!proxy_authorize("domain","subscriber")) {
proxy_challenge("domain","0");
exit;
};
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Ошибка была в скрипте. По ходу 2 раза звался proxy_authorize() для одного и того же инвайта. Дальше ему присваивался один индекс нонса, и всё валилось. Обнаружилось это при очень тщательном раскуривании дебага.
Усложняло диагностику то, что помимо этой ошибки, был не правильно составлен скрипт этой самой авторизации, который выполнялся первым, в результате, проверка выполнялась, но даже левые запросы проходили, что создавало впечатление того, что проверка не выполняется.
Вообщем сам виноват. Продолжу настраивать. Как разберусь в фейлом нод - дам знать. Пока искал решение авторизации видел интересный, и судя по всему рабочий, вариант этой самой фильтрации. Как сделаю - выложу.
Усложняло диагностику то, что помимо этой ошибки, был не правильно составлен скрипт этой самой авторизации, который выполнялся первым, в результате, проверка выполнялась, но даже левые запросы проходили, что создавало впечатление того, что проверка не выполняется.
Вообщем сам виноват. Продолжу настраивать. Как разберусь в фейлом нод - дам знать. Пока искал решение авторизации видел интересный, и судя по всему рабочий, вариант этой самой фильтрации. Как сделаю - выложу.
Что имеется ввиду под фейлом нод? модуль диспетчер умеет отслеживать живые ноды
Последний раз редактировалось indeec 03 дек 2010, 14:06, всего редактировалось 1 раз.
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Спорный вопрос как лучше делать. Если кластер А из 2х машин, как в моем случае, то возможно установка маленького таймаута оправдана и не надо ничего больше городить. Но если кастер большой, то мне кажется, что маркать мервые астериски нужно, потому что если пол кластера умрет, то звонки будут ходить с большими задержками. Вообщем буду експерементировать.
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Приступил к работе над фейловером. Почитал доку ( 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)
чтобы не ждать долго ответа от гейта. В случае одного провала он всеравно не попадет в пробинг.
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)
чтобы не ждать долго ответа от гейта. В случае одного провала он всеравно не попадет в пробинг.
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Я сделал очень просто: скачал сорцы своей же версии, и сделал банальный make --prefix=/ all
Потом взял скомпиленый модуль диспетчера и заменил ним свой из RPM. Всё заработало. То есть ничего изобретать не нужно - если будете собирать из сорцов - всё соберется как надо.
Касательно конфигов - выложу чуть позже, когда запустимся и правки в конфигах закончаться. В целом, я смотрел конфиги сгенеренные через сайт - они вполне себе замечательные, то есть вполне можно начать с них. Я же начал с выложеных конфигов не первой свежести и из-за этого потерял кучу времени и сил. Впрочем результата всеравно достиг и уже когда узнал про сайт переползать на его конфиг желания не было.
Сам разброс у меня происходит в отдельной секции и там все примитивно:
ds_select_dst и потом возвращаюсь в основной роут, который борется с натом и определяет пути для onreply и для on failure.
Если роут зафейлился по причине таймаута, то берем следующий гейт пока не кончаться все.
Вообще если есть конкретные вопросы, то мне кажется, будет лучше если я на них отвечу либо кусками конфига, либо комментариями.
Потом взял скомпиленый модуль диспетчера и заменил ним свой из RPM. Всё заработало. То есть ничего изобретать не нужно - если будете собирать из сорцов - всё соберется как надо.
Касательно конфигов - выложу чуть позже, когда запустимся и правки в конфигах закончаться. В целом, я смотрел конфиги сгенеренные через сайт - они вполне себе замечательные, то есть вполне можно начать с них. Я же начал с выложеных конфигов не первой свежести и из-за этого потерял кучу времени и сил. Впрочем результата всеравно достиг и уже когда узнал про сайт переползать на его конфиг желания не было.
Сам разброс у меня происходит в отдельной секции и там все примитивно:
ds_select_dst и потом возвращаюсь в основной роут, который борется с натом и определяет пути для onreply и для on failure.
Если роут зафейлился по причине таймаута, то берем следующий гейт пока не кончаться все.
Вообще если есть конкретные вопросы, то мне кажется, будет лучше если я на них отвечу либо кусками конфига, либо комментариями.
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Продолжая разраборку уткнулся в проблему с запросом SUBSCRIBE и К. Все модули для presence поствил и подключил. Софтфон X-Lite - отлично видит присутствие своего контакт листа. Но хардварные телефоны Yealink и Linksys - не видят. Пакетики ходят, всё отлично, подписка проходит. НО. У них во-первых запрос идет с другим Event. X-lite: presence, Hardphones: dialog, во-вторых разниться диалог после подписки. X-lite шлет свои состояния через PUBLISH и получает NOTIFY ( как и должно быть ), а хардфон свои состояния не публикует вообще никак.
И всё бы можно было свалить на хардфоны, вот только с астериском напрямую они работают замечательно.
Кто-то сталкивался с чем-то похожим? Кому удавалось подружить К с хардфонами для запросов SUBSCRIBE и какими?
И всё бы можно было свалить на хардфоны, вот только с астериском напрямую они работают замечательно.
Кто-то сталкивался с чем-то похожим? Кому удавалось подружить К с хардфонами для запросов SUBSCRIBE и какими?
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
Появился еще один вопрос. Есть К и А. К имеет 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
Да, если выдать астериску реальный адрес, чтобы к нему можно было достучаться извне и попросить К говорить по реальной сети только, то всё работает без вопросов.
Какие есть варианты куда копать?
Скажем есть звонок с 100 на 101. Первый инвайт генериться от 100 и приходит к А. А генерит инвайт для 101.
И вставляет в From, To уже приватные адреса. Это логично, т.к. внешних интерфейсов Астериск не имеет, но в таком варианте звонок не может состояться, т.к. пришедший пакет имеет в своих хедерах приватные адреса, о которых ничего не знает UAC.
И получается что в запросном инвайте:
From: 100@PUBLIC
To: 101@PUBLIC
А в ответном:
From: 101@PRIVATE_ASTERISK_IP
To: 100@PRIVATE_KAMAILIO_IP
Да, если выдать астериску реальный адрес, чтобы к нему можно было достучаться извне и попросить К говорить по реальной сети только, то всё работает без вопросов.
Какие есть варианты куда копать?
externip в sip.conf
Но не совсем понятно что вы хотите получить, вопервых позвонить c 100 на 101 можно вообще без астериска. Если вы всёже хотите пропускать вызовы через asterisk для каких-то мультимедийных штук - то последний инвайт так же должен возвращаться к 101 через камаилио, который должен проксировать. в таком случае всё должно работать, даже не смотря на то что в сообщениях кой где будут фигурировать серые адреса. Но в такой конфигурации вам ещё нада внимательно смотреть на проксирование медиа трафика с помощью камаилио.
Но не совсем понятно что вы хотите получить, вопервых позвонить c 100 на 101 можно вообще без астериска. Если вы всёже хотите пропускать вызовы через asterisk для каких-то мультимедийных штук - то последний инвайт так же должен возвращаться к 101 через камаилио, который должен проксировать. в таком случае всё должно работать, даже не смотря на то что в сообщениях кой где будут фигурировать серые адреса. Но в такой конфигурации вам ещё нада внимательно смотреть на проксирование медиа трафика с помощью камаилио.
-
- Сообщения: 27
- Зарегистрирован: 19 дек 2009, 00:59
скорее всего выставлением правильных флагов для force_rtp_proxy...[url=http://asteriskforum.ru/viewtopic.php?p=65827#65827][img]http://asteriskforum.ru/images/quotebackarrow.gif[/img][/url] itreers @ Вт Сен 25, 2012 16:01 писал(а):Как решили проблему с проксированием?
http://www.kamailio.org/docs/modules/3. ... proxy.html
рву шаблоны. дорого.