Openser (kamailio) в качестве load balanser-a
Второй месяц работаю над созданием нормального load balansera к * в количестве n штук. Схема работы
Теперь обясняю как это работает.
Есть некоторая сеть где сидит некоторое количество абонентов, и есть другая сеть которая за натом. Решили делать лоадбалансинг для того чтобы улучшить надежность нашей IP-PBX Asterisk. В качестве балансировщика поставили openser, и в качестве PBX 2 Asterisk.
Все клиенты регятся только на Openser-е, на астериске только звонки, запись разговоров, очереди и т.д. и т.п.
Долго и упорно изучал опесер, читал книгу http://www.asteriskforum.ru/viewtopic.php?t=2237, читал сайт www.openser.org, который нынче вот здесь http://www.kamailio.net/, а также http://www.voip.rus.net/, http://www.voip-info.org/.
Добился в итоге неплохих результатов. В принципе все работает. Балансировщик свою задачу выполняет, в statefull режиме пакеты туда сюда маршрутизиует. Asterisk-и загружены равномерно.
Для клиентов которые тусуются за nat-ом созданы правила позволяющие его преодолевать и заворачивает трафик на mediaproxy.
В общем не буду подробно останавливаться на разъяснении конфигурационного файла, который лежит в атаче.
В общем в принципе достаточно рабочая конфигурация но есть пару НО.
1. Хотелось бы сделать чтобы уже установленные звонки не зависели от состояния asterisk. Т.е. чтобы rtp траффик шел напрямую от mvts до openser. Падает астериск а текущим разговорам пофигу. canreinvite=yes не помогает.
2. Возникают иногда ситации. Юзверь куда-то звонит, но набирает неправильно номер. Ему отдается сообщение service unvailable c кодом 503. Затем это сообщение транслируется оконечному устройству которое инициировало звонок, а т.к. это ошибка то это устройство звонок останавливает а на openser-е возникает незаконченная транзакция, т.к. INVITE был, a Cancel или Bye не было. Транзакция залипает на стадии отправки пакета с методом Ask. В итоге имеем, следующий звонок этого клиента интерпретируется Openser -ом ни как новая транзакция а как продолжение предыдущей и звонок маршрутится не туда куда нужно и соответсвенно звонок никуда не уходит. Если пару минут подождать то транзакция удаляется и можно звонить снова. Но это не очень хорошо.
Вижу выход только в отлавливании сообщения с кодом 503 и отправки в секцию где транзакция будет прибиваться. т.е. в onreply_route[1] ищем статус 503 и отправляем в route(5), где убиваем транзакцию при помощи t_release(). Вроде должно работать однако ситуация повторяется.
Вот это пока 2 мои трудности, может кто может мне помочь их решить.
Взамен отвечу на любые вопросы по моей конфигурации openser -а. Думаю многим бы это пригодилось.
Давайте пополнять русcкоязычное комьюнити openser. Штука очень полезная для VoIP.
Последний раз редактировалось: ZloMurz (Ср Авг 27, 2008 13:14)
_________________
"Фантазия важнее знания.", Альберт Эйнштейн
_________________
ys
http://voip.rus.net/
тему подвешу наверх - свежа и актуальна, (хоть и не Астериск напрямую, будет приятным исключением).
в виде исключения разрешаю в данной теме постить полные конфиги (только используйте теги).
| Цитата: |
| t_on_failure(failure_route) Функция определяет блок, который будет обрабатывать ответы на SIP запросы в том случае, если транзакция завершилась с отрицательным результатом |
| Цитата: |
| t_on_reply(reply_route) Функция определяет блок, который будет обрабатывать ответы на SIP запросы, управление которому передается каждый раз при приеме (промежуточных и финальных ) ответов в пределах транзакции. |
я конечно пытался обрабатывать ситуацию именно в failure_route, но
| Код: |
| if (status=~"(503)") { xlog("L_INFO", "503\n"); } |
в failure_route статус 503 не ловит, а onreply_route ловит.
Сейчас вот запустил openserctl monitor и вижу в Transaction Statistics что inuse_transactions = 0 после того как совершаю вызов на неправильный или несуществующий номер, т.е. походу залипших транзакций в памяти не остается. Вот тогда интересно что мешает следующему звонку повторить весь путь а не идти сразу на обработку ACK запросов.
Added after 3 hours 10 minutes:
Ура.
Кажется победил!!! Достаточно было внести в конфигурацию
| Код: |
| disable_dns_blacklist=yes |
и все стало нормально отрабатываться.
Так что если кто столкнется с траблой когда на оконечку прилетает 473 Filtering destination смело ставьте эту опцию.
Вопрос по canreinvite все еще актуален.
| ZloMurz писал(а): |
| 1. Хотелось бы сделать чтобы уже установленные звонки не зависели от состояния asterisk. Т.е. чтобы rtp траффик шел напрямую от mvts до openser. Падает астериск а текущим разговорам пофигу. canreinvite=yes не помогает. |
А зачем вы тут используете asterisk? У вас ведь пользователи на kamailio.
_________________
"Фантазия важнее знания.", Альберт Эйнштейн
В итоге хотим сделать чтобы сам опенсер крутился на кластере из 2-ух машин и обслуживал кучу астерисков, часть из которых будет обеспечивать связью офис, а другая предоставлять клиентам телефонии различные SIP фишки.
Еще есть задумка попробовать вместо астериска callweaver. Кстати сразу вопрос кто-нить юзал его, стоит возиться?
Хотя я думаю вы защищаетесь не с той стороны. Как часто * то падает? Может не стоит ее до такого то доводить?
т.е. если вы на уровне распределения нагрузки разбросаете звонки по астерискам, то почему ему то падать?
_________________
"Фантазия важнее знания.", Альберт Эйнштейн
| ZloMurz писал(а): |
| ...Openser (который теперь kamailio)... |
кстати.. а что тогда есть OpenSIPS? или уже несколько клонов? тогда какой самый "правильный"?
Тот, кто из них будет сильнее развиваться, тот и правильный.
Время покажет.
_________________
ys
http://voip.rus.net/
| ToxaP писал(а): |
| Хотя я думаю вы защищаетесь не с той стороны. Как часто * то падает? Может не стоит ее до такого то доводить? т.е. если вы на уровне распределения нагрузки разбросаете звонки по астерискам, то почему ему то падать? |
Кстати наверное согласен
Added after 4 minutes:
2 anest:
я когда начал курить OpenSer то он и был OpenSer-ом, а как-то прихожу на работу набираю сайт ихний а меня редиректит на OpenSIPs, а про то что опенсер таки стал kamailio узнал несколько позже. Я так понял что разработчики kamailio это в некотором роде "консерваторы" и для них главное стабильность, а конфликт приведший к разделению проекта, произошел со стороны OpenSIPs -вцев. Но могу ошибаться.
А куда делся замечательный проэкт генерирующий конфиги к Kamailio/SER ?
Kamailio (OpenSER) Config Generator
http://www.sipwise.com/wizard
Может где-то на просторах Интернета есть копия данного сайта ?
| ZloMurz писал(а): |
| Еще есть задумка попробовать вместо астериска callweaver. Кстати сразу вопрос кто-нить юзал его, стоит возиться? |
Я сейчас с ним активно вожусь... Здесь http://www.asterisk-support.ru/forum/19/ оставляю впечатления...
_________________
Maksim Timofejev
В принципе и так всех слышно, просто странно как-то себя ведет связка. Я полагаю траф начинает ходит через медиапрокси после re-INVITE. Вот думаю чей это косяк kamailio или asterisk.
Может есть у кого соображения на сей счет?
OpenSER 1.2.3 на FreeBSD ставил из портов.
| Код: |
| ds_select_dst("1","4"); forward(); return; |
Т.е. отдаешь астеру не t_relay-ем, а forward-ом. У меня с t_relay тоже помню долго тупил опенсер с обнаружением нерабочей ноды астериска
Added after 47 minutes:
В итоге оставил t_relay() и выставил
modparam("tm", "fr_timer", 3)
modparam("tm", "fr_inv_timer", 120)
Т.е. ждем ответа от астерикса не более 3х секунд, а если получили ответ то уже 120.
Переключение практически не заметно со стороны клиента.
Относительно forward() то выяснил, что функции forward() и send() не сохраняют состояние т.е. перекидывают сообщение и и забывают про транзакцию...
Added after 38 minutes:
Большущий респект, допилил свой опенсер, теперь как часы работает.
Ыыы.
Ну можно, но не нужно.
Радиус поражения граблями сильно увеличивается, если к asterisk прикрутить h323.
Лудше отдавать на сисько по SIP.
_________________
ys
http://voip.rus.net/
Извиняюсь за вопрос в старой ветке, но тема актуальна.
Как решили вопрос с медиа между юзверями в 1 домене ?
А рвать сессию по прошествии произвольного времени как-нибудь можно? Я так понимаю, Kamailio работает только по пришествую определенных сообщений. Он не отслеживает текущие сессии, чтоли?
А нафига трафик в одном домене гнать через астер ? Когда они в пределах сера могу нормально говорить...
При стыковке сера с астером, при звонке сер только гоняет сигнализацию, а ртп прет напрямую на астер.