Список форумов Asterisk Forum Asterisk Forum
The Asterisk Open Source PBX - Russian Community
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ПравилаПравила   ГруппыГруппы   ИзбранноеИзбранное    LinksСсылки   РегистрацияРегистрация 
 RSSRSS   ПрофильПрофиль   Войти и проверить личные сообщения   ВходВход 

Избитая тема балансировки Kamailio + X Asterisks
На страницу 1, 2  След.
 
Список форумов Asterisk Forum -> OpenSER    вывод темы на печать
Предыдущая тема :: Следующая тема  
Автор Сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Пт Ноя 19, 2010 16:18    Заголовок сообщения: Избитая тема балансировки Kamailio + X Asterisks

Добрый день, надеюсь на вашу помощь.

Есть Камаилио ( дальше К ), есть 2 астериска ( дальше А ). Пользователи регаются на К, после чего К отдает запрос на один из А, по раундробину.

Звонки так же должны балансироваться по нему же, но тут получается следующая проблема:
Если пир, допустим, прошел регистрацию на А1, но К бросает его звонок на А2, получаем сообщение

[Nov 19 12:58:51] NOTICE[23510]: chan_sip.c:20200 handle_request_invite: Call from '102' to extension '101' rejected because extension not found in context 'a_context'.

На сколько я понимаю решение: нужно при балансировке звонков, учитывать на каком А зареган был пользователь и туда и отправлять первый инвайт.

Но не понимаю как это сделать и где взять информацию о том, где именно зарегался пир. В location этой информации нет.

Возможно я не правильно понимаю решение. Надеюсь на вашу помощь.

Спасибо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Пт Ноя 19, 2010 18:31    Заголовок сообщения:

Пользователи регаются на kamailio или asterisk? Если на kamailio то вообще не важно на какой астериск отдаётся вызов
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
ZloMurz



Зарегистрирован:
31.01.2008
Сообщения: 303

Статус: Оффлайн 

СообщениеДобавлено: Пт Ноя 19, 2010 19:06    Заголовок сообщения:

Не получится у тебя то что ты хочешь сделать. Меняй схему на такую что пользователи регаются только на kamailio.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Пт Ноя 19, 2010 20:16    Заголовок сообщения:

Ну регаются сначала на К, а потом делается forward на А.

2ZloMurz: Ок, предположим они зарегались на К, а на А не регаются как быть дальше?А всеравно не приймет вызов от незареганого пира.

Спасибо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
ZloMurz



Зарегистрирован:
31.01.2008
Сообщения: 303

Статус: Оффлайн 

СообщениеДобавлено: Сб Ноя 20, 2010 07:13    Заголовок сообщения:

примет, можно выставить для kamailio insecure и asterisk будет обрабатывать запросы от kamailio. C матчастью у тебя туго похоже. Не до конца понимаешь что делаешь и зачем.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Сб Ноя 20, 2010 17:12    Заголовок сообщения:

2ZloMurz: Ок, возможно я не совсем понятно объясняю проблему, поэтому кажется, что с мат частью проблемы. Хотя, конечно, на гуру я и не претендую. Попробую объяснять немного по-другому.

Ваша схема мне понятна, не ясен один ньюанс: каким образом так спроксировать инвайт, чтобы пир говорил с К, а К отправляло запросы на А, подставляя в них свой IP, то есть фактически выдавая себя за пир? Если Вас не затруднит, дайте, пожалуйста, пример только этого блока кода для К. Если я правильно Вас понял.

То что я понял, то сигнальный и RTP трафик должен проходить так:

Пир <-> K <-> A

Спасибо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Сб Ноя 20, 2010 21:06    Заголовок сообщения:

Если инвайт идёт на камаилио, и камаилио проксирует его на астериск - айпишник камаилио уже будет в пересланном запросе. Этого достаточно что бы в астериске сделать пир по ip.
Собсно да, проблема с матчастью.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 09:01    Заголовок сообщения:

Вот вы, господа, в прибитом топике, именуемым "Openser (kamailio) в качестве load balanser-a" призываете специалистов и других работающих с K объеденяться и делится опытом, потому как документации мало, а вопросов много и их надо решать. А здесь, уже второй раз указываете мне на слабое знание матчасти. Если бы у меня были сильные знания матчасти, то я бы тут не вопросы задавал, а ответы раздавал, с ссылками и примерами, как я решил ту или инную проблему, потому что как вы знаете, это занимает очень много времени и нервов. Вы же без аргументов ( ссылок, примеров ) обвиняете в не знании. Не красиво это.

Еще важные детали по моей задаче, которые я не указал:
1. Астериски многоклиентные, то есть в системе есть куча клиентов в екстеншеном 101, например, и все они деляться на основании контекстов. Именно поэтому важно чтобы звонок приходил от пира. Если он прийдет от безликого К, как тогда определить какой именно клиент звонил?

2. Я смотрел и завел конфиг уважаемого ZloMurz. Но это не совсем то что мне нужно. Клиенты регаются на К, да, но учитывая условие 1, где клиенты разделены на основании префиксов, я уже сделать звонок не могу без префикса, что логично, ведь в location пиры сохраняются уже с префиксами.

Возможно для решения задачи мне лучше при регистрации на К, бросать регистрацию на все астериски сразу? Таким образом, куда бы не пришел звонок, он пройдет нормально. Но не вижу как сделать запрос к нескольким хостам сразу. Можно вообще такое сделать на К?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 11:51    Заголовок сообщения:

Так не нада делать.
Нада регистрировать людей на камаилио, пробрасывать звонки на астериски. В камаилио в инвайт сообщении уходящем на астер передавать имя пользователя звонящего. Дальше анализировать его на астериске и перекидывать в нужный контекст.

PS: "Проблема с матчастью" - лично я говорил о проблеме с пониманием самого протокола SIP, а не камаилио. Из личного опыта скажу - нельзя на камаилио сделать ничего толкового пока не будет понимания полной механики хождения SIP сообщений.
PSS: Не знаю как у остальных, но лично мне пришлось окунуться в SIP глубоко только тогда когда возникла необходимость настроить камаилио. Тоесть у Вас всё в переди)
PSSS: Так как описано в прошлом Вашем сообщении сделать можно. Для этого нужно делать forward-ы REGISTER сообщений на все астериски. Придётся разобраться с ответами на них(не пересылать же клиенту несколько ответов на один запрос регистрации?)). Потом убедиться в актуальности данных на обоих астерисках(никто не исключает ситуацию когда регистрация дойдёт только на один сервер, а на второй почему-то нет). Ну и всё поидее.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 12:33    Заголовок сообщения:

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

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

Еще один момент который мне до сих пор не ясен: А1 и А2, юзают базу для авторизации пользователей. Почему при регистрации на А1, А2 считает, что у него пир не зареган? В таблицах информации о том, на каком именно А прошел авторизацию пир - нет. Было бы очень удобно: К отправляет в кластер А пакет про регистрацию, после чего шлет звонки на любой астер и тот базируясь на таблице, всё делает как надо. Но сейчас это почему-то не работает ... я что-то упускаю?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 12:55    Заголовок сообщения:

Я так понимаю речь идёт о SIP-REALTIME. Это механизм позволяющий перенести конфиги в базу данных, и следовательно получить кой какое удобство от этого. Но сама работа астериска остаётся прежней, меняется только источник конфигурационных данных.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 13:09    Заголовок сообщения:

Да, речь об realtime. Помимо конфигурации, там есть сущность sipregs куда А складывает проведенные регистрации. Строчки в базе, при регистрациях что на одном, что на другом сервере - идентичны. Я так понимаю, что А, хранит еще данные у себя в памяти где-то и sipregs - это просто справочная информация или все же таблица играет роль при определении зарегистрирован пир или нет? В таблице есть все необходимые данные для этого.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 13:43    Заголовок сообщения:

У астериска есть своя ASTDB. Но тут утверждать не готов, там ли оно хранится, или всёже в памяти. Не проверял
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 16:16    Заголовок сообщения:

Используется таблица. Удалось настроить как хотел. Спасибо за участие, пойду читать книжки дальше.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
ZloMurz



Зарегистрирован:
31.01.2008
Сообщения: 303

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 19:30    Заголовок сообщения:

indeec писал(а):

PSSS: Так как описано в прошлом Вашем сообщении сделать можно. Для этого нужно делать forward-ы REGISTER сообщений на все астериски. Придётся разобраться с ответами на них(не пересылать же клиенту несколько ответов на один запрос регистрации?)). Потом убедиться в актуальности данных на обоих астерисках(никто не исключает ситуацию когда регистрация дойдёт только на один сервер, а на второй почему-то нет). Ну и всё поидее.

так сделать нельзя. kamailio сам не создает запросы или пакет, он их пересылает, т.е. пришел ему регистер, он конечно может его отфорвардить на A1, но не на A1 и A2. Тиражировать запросы он не умеет.

Added after 8 minutes:

Dark_Angel вы изобретаете велосипед.

Вот ряд тезисов для экспериментов:

1.SIP клиенты регаются только на kamailio, и храняться в базе данных location
2. Invite от клиентов или шлюзов терминации попадают сначала на kamilio, а затем распределяются на asterisk ноды.
3. в asterisk создаете SIP peer kamailio, аля
Код:

[kamailio]
insecure=port,invite
type=friend
host=xxx.xxx.xxx.xxx

3. Обрабатываете маршрутизацию на asteisk, для удобства можете настроить им единый dial-plan через realtime таблицу, базу можно держать на kamailio
4. Если нужно позвонить на SIP peer зареганный на kamailio, то делать это надо так Dial(SIP/abonent@kamailio)

Вот и все. А про матчасть я пишу потому что вы еще толком с asterisk не разобрались, а уже полезли на kamailio, а он не в пример сложнее. Про нехватку времени и желание что-либо быстро запустить быстрее чем поймете как, лучше никому не рассказывайте, это мало кого трогает, если нужно что-то быстро и из коробки то это однозначно в раздел работа.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Вс Ноя 21, 2010 23:30    Заголовок сообщения:

ZloMurz писал(а):

так сделать нельзя. kamailio сам не создает запросы или пакет, он их пересылает, т.е. пришел ему регистер, он конечно может его отфорвардить на A1, но не на A1 и A2. Тиражировать запросы он не умеет.


Если я в конфиге напишу:
Код:

forward("x.x.x.x:yy");
forward("z.z.z.z:yy");
exit;

запрос не будет растиражирован?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
ZloMurz



Зарегистрирован:
31.01.2008
Сообщения: 303

Статус: Оффлайн 

СообщениеДобавлено: Пн Ноя 22, 2010 07:29    Заголовок сообщения:

Нет.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Пн Ноя 22, 2010 09:41    Заголовок сообщения:

2ZloMurz: Спасибо за рабочую схему, я именно так вчера и сделал, как Вы описали. Вроде бы всё работает, сейчас занимаюсь настройкой остальных фич К. Попутно возник вопрос: как исключить мертвый А, из выбора маршрутов? Сейчас если А тупит, то К ждет таймаут, потом идет дальше. Но так происходит при каждом звонке, что не есть гут. В описании модуля диспетчера есть что-то про установку одному из значений списка значения probbing и якобы тогда он не будет участвовать в выборке. Как это делаете Вы? Я ничего, кроме:

1. Таймаут
2. Обработка причины отказа. Если таймаут, ставим текущему dst статус пробинг.
3. Берем следующий.

Не вижу. Но не понятно как их оттуда потом доставать. Можете что-то посоветовать по этому поводу?

Касательно теражирования запросов: мне кажется можно использовать модуль uac для этого и соответственно uac_req_send() и формировать запрос руками. В теории должно работать.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
ZloMurz



Зарегистрирован:
31.01.2008
Сообщения: 303

Статус: Оффлайн 

СообщениеДобавлено: Пн Ноя 22, 2010 10:14    Заголовок сообщения:

Есть такой параметр modparam("tm", "fr_inv_timer", 120), им можно регулировать таймаут, который система ожидает ответа ноды.

Насчет probing не пробовал. Возможно интересная фича, поэкспериментируйте, и выложите для общественности.

Added after 49 seconds:

Запрос руками формировать это костыль. Такую схему потом замучаешься поддерживать.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Пн Ноя 22, 2010 10:53    Заголовок сообщения:

Кстати, тем кто мучается с конфигами будет полезен сайт http://www.sipwise.com/index.php/products+start=3 К сожалению, я его нашел только сейчас, когда уже почти все вопросы решены. Может он кому-то сохранит кучу времени.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Ср Дек 01, 2010 14:55    Заголовок сообщения:

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

Сейчас вопрос по авторизации запросов от зареганых UAC на К.

Итак, клиенты регаются на К ( www_authorize() ), К вносит их в базу. Всё замечательно, но нам еще надо проверять каждый приходящий инвайт на то, разрешенный это инвайт или нет, перед тем как его проксировать на А, т.к. К публичный.

Проверку запроса я выполняю через proxy_authorize(). Сразу после старта К, всё работает как должно: клиент регается, шлет запрос. Если не зареган, то послать не может. Но буквально через секунд 40, все звонки начинают отшиваться с ошибкой 407 Proxy Authentication Required. Этот ответ дает функция proxy_authorize(), которая почему-то начинает отдавать 407.

Никаких вменяемых ответов на то, почему это происходит в Инете я найти не могу. ЧЯДНТ?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Чт Дек 02, 2010 15:33    Заголовок сообщения:

407 шлётся каждый раз, при первой отсылке invite, после чего UA должен послать запрос с авторизацией. Но перед invite UA должен послать ASK.
У метя что-то подобное было когда камаилио не успевал обработать ASK и слал 407 повторно.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Чт Дек 02, 2010 15:52    Заголовок сообщения:

Увы, не тот случай, т.к. инвайты не проходят с вероятностью 100% после 40 секунд, и К не нагружен, поэтому не может не успеть обработать. Ошибка вероятно с алгоритмом.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
indeec



Зарегистрирован:
17.05.2009
Сообщения: 87
Откуда: Киев

Статус: Оффлайн 

СообщениеДобавлено: Чт Дек 02, 2010 17:17    Заголовок сообщения:

Покажите хотя бы sip диалог между UA и kamailio.
Внешне kamailio может и не выглядеть нагруженным. В конфиге debug включён, xlog юзается?
Ещё интересно cat kamailio.log| grep ERROR
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Dark_Angel



Зарегистрирован:
19.12.2009
Сообщения: 27

Статус: Оффлайн 

СообщениеДобавлено: Пт Дек 03, 2010 08:40    Заголовок сообщения:

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

Вот диалог между UA и K, когда звонок не проходит, т.е. через 40 секунд:
Цитата:

07:14:26.301384 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 746) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 718
E.....@.3.A.[H...(..........INVITE sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKtoaibsjq
Max-Forwards: 70
To: <sip:104@213.40.195.161>
From: "1_104" <sip:1_104@213.40.195.161>;tag=pyxxe
Call-ID: mjqenljapmqadzq@test.local
CSeq: 196 INVITE
Contact: <sip:1_104@91.72.15.26:1049>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 205

v=0
o=twinkle 1474645557 2022793409 IN IP4 176.249.0.2
s=-
c=IN IP4 91.72.15.26
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

07:14:26.301551 IP (tos 0x10, ttl 64, id 36379, offset 0, flags [none], proto: UDP (17), length: 504) 213.40.195.161.sip > 91.72.15.26.neod2: [bad udp cksum 12d1!] UDP, length 476
E.......@....(..[H........."SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKtoaibsjq
To: <sip:104@213.40.195.161>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.8ebe
From: "1_104" <sip:1_104@213.40.195.161>;tag=pyxxe
Call-ID: mjqenljapmqadzq@test.local
CSeq: 196 INVITE
Proxy-Authenticate: Digest realm="213.40.195.161", nonce="4cf898f00000004668de005b29e8b61459d4adbcfbef8389"
Server: kamailio (3.0.3 (i386/linux))
Content-Length: 0


07:14:26.449998 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 386) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 358
E.....@.3.C?[H...(.......n.pACK sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKtoaibsjq
Max-Forwards: 70
To: <sip:104@213.40.195.161>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.8ebe
From: "1_104" <sip:1_104@213.40.195.161>;tag=pyxxe
Call-ID: mjqenljapmqadzq@test.local
CSeq: 196 ACK
User-Agent: Twinkle/1.4.2
Content-Length: 0


07:14:26.452360 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 959) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 931
E.....@.3.A.[H...(..........INVITE sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKyfyakzsa
Max-Forwards: 70
Proxy-Authorization: Digest username="1_104",realm="213.40.195.161",nonce="4cf898f00000004668de005b29e8b61459d4adbcfbef8389",uri="sip:104@213.40.195.161",response="f537d5a2b13175027e34f0ae6100c07f",algorithm=MD5
To: <sip:104@213.40.195.161>
From: "1_104" <sip:1_104@213.40.195.161>;tag=pyxxe
Call-ID: mjqenljapmqadzq@test.local
CSeq: 197 INVITE
Contact: <sip:1_104@91.72.15.26:1049>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 205

v=0
o=twinkle 1474645557 2022793409 IN IP4 176.249.0.2
s=-
c=IN IP4 91.72.15.26
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

7(24628) NOTICE: <script>: [Fri Dec 3 07:14:26 2010] Detected INVITE before authorization 1_104 -> 104
07:14:26.453917 IP (tos 0x10, ttl 64, id 36380, offset 0, flags [none], proto: UDP (17), length: 504) 213.40.195.161.sip > 91.72.15.26.neod2: [bad udp cksum 6d8a!] UDP, length 476
E.......@....(..[H........."SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKyfyakzsa
To: <sip:104@213.40.195.161>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.1be1
From: "1_104" <sip:1_104@213.40.195.161>;tag=pyxxe
Call-ID: mjqenljapmqadzq@test.local
CSeq: 197 INVITE
Proxy-Authenticate: Digest realm="213.40.195.161", nonce="4cf898f000000047e514dee2ad65f481a2a51d0d1f0c8ae6"
Server: kamailio (3.0.3 (i386/linux))
Content-Length: 0


07:14:26.600851 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 386) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 358
E.....@.3.C?[H...(.......n..ACK sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKyfyakzsa
Max-Forwards: 70
To: <sip:104@213.40.195.161>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.1be1
From: "1_104" <sip:1_104@213.40.195.161>;tag=pyxxe
Call-ID: mjqenljapmqadzq@test.local
CSeq: 197 ACK
User-Agent: Twinkle/1.4.2
Content-Length: 0



А вот диалог, когда проходит:
Цитата:

07:30:06.926909 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 745) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 717
E.....@.3.A.[H...(........@~INVITE sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKysgvduzl
Max-Forwards: 70
To: <sip:104@213.40.195.161>
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 782 INVITE
Contact: <sip:1_104@91.72.15.26:1049>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 204

v=0
o=twinkle 374372867 2101308157 IN IP4 176.249.0.2
s=-
c=IN IP4 91.72.15.26
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

07:30:06.927417 IP (tos 0x10, ttl 64, id 36634, offset 0, flags [none], proto: UDP (17), length: 504) 213.40.195.161.sip > 91.72.15.26.neod2: [bad udp cksum 469d!] UDP, length 476
E.......@....(..[H........."SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKysgvduzl
To: <sip:104@213.40.195.161>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.6905
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 782 INVITE
Proxy-Authenticate: Digest realm="213.40.195.161", nonce="4cf89c9c00000001021961305c83cc5305f8568a4a9ec6be"
Server: kamailio (3.0.3 (i386/linux))
Content-Length: 0


07:30:07.074991 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 386) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 358
E.....@.3.C?[H...(.......n..ACK sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKysgvduzl
Max-Forwards: 70
To: <sip:104@213.40.195.161>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.6905
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 782 ACK
User-Agent: Twinkle/1.4.2
Content-Length: 0


07:30:07.077346 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 958) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 930
E.....@.3.A.[H...(..........INVITE sip:104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport;branch=z9hG4bKgomsuukn
Max-Forwards: 70
Proxy-Authorization: Digest username="1_104",realm="213.40.195.161",nonce="4cf89c9c00000001021961305c83cc5305f8568a4a9ec6be",uri="sip:104@213.40.195.161",response="d28c50b3fe020e494500019a126d3ab8",algorithm=MD5
To: <sip:104@213.40.195.161>
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 783 INVITE
Contact: <sip:1_104@91.72.15.26:1049>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 204

v=0
o=twinkle 374372867 2101308157 IN IP4 176.249.0.2
s=-
c=IN IP4 91.72.15.26
t=0 0
m=audio 8000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

07:30:07.079844 IP (tos 0x10, ttl 64, id 36635, offset 0, flags [none], proto: UDP (17), length: 362) 213.40.195.161.sip > 91.72.15.26.neod2: [bad udp cksum fedf!] UDP, length 334
E..j....@..+.(..[H.......V..SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKgomsuukn
To: <sip:104@213.40.195.161>
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 783 INVITE
Server: kamailio (3.0.3 (i386/linux))
Content-Length: 0


07:30:07.080125 IP (tos 0x10, ttl 64, id 57320, offset 0, flags [none], proto: UDP (17), length: 896) 213.40.195.161.sip > 213.40.195.160.sip: [bad udp cksum 59d7!] UDP, length 868
E.......@.e..(...(.......l5.INVITE sip:104@213.40.195.161 SIP/2.0
Record-Route: <sip:213.40.195.161;lr=on;ftag=suayr;nat=yes>
Via: SIP/2.0/UDP 213.40.195.161;branch=z9hG4bK3847.c9d47957.0
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKgomsuukn
Max-Forwards: 69
To: <sip:104@213.40.195.161>
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 783 INVITE
Contact: <sip:1_104@91.72.15.26:1048>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Twinkle/1.4.2
Content-Length: 226

v=0
o=twinkle 374372867 2101308157 IN IP4 176.249.0.2
s=-
c=IN IP4 213.40.195.161
t=0 0
m=audio 40302 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=nortpproxy:yes

07:30:07.094463 IP (tos 0x0, ttl 64, id 14788, offset 0, flags [none], proto: UDP (17), length: 607) 213.40.195.160.sip > 213.40.195.161.sip: [udp sum ok] UDP, length 579
7.(...(.......K6.SIP/2.0 100 Trying
Via: SIP/2.0/UDP 213.40.195.161;branch=z9hG4bK3847.c9d47957.0;received=213.40.195.161
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKgomsuukn
Record-Route: <sip:213.40.195.161;lr=on;ftag=suayr;nat=yes>
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
To: <sip:104@213.40.195.161>
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 783 INVITE
Server: Asterisk PBX 1.6.2.14
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:104@213.40.195.160>
Content-Length: 0


07:30:07.169490 IP (tos 0x0, ttl 64, id 14789, offset 0, flags [none], proto: UDP (17), length: 866) 213.40.195.160.sip > 213.40.195.161.sip: [udp sum ok] UDP, length 838
E..b9...@..3.(...(.......N..INVITE sip:1_104@213.40.195.161 SIP/2.0
Via: SIP/2.0/UDP 213.40.195.160:5060;branch=z9hG4bK60921de5;rport
Max-Forwards: 70
From: "1_104" <sip:104@213.40.195.160>;tag=as0d376f73
To: <sip:1_104@213.40.195.161>
Contact: <sip:104@213.40.195.160>
Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.2.14
Date: Fri, 03 Dec 2010 07:30:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 286

v=0
o=root 451599995 451599995 IN IP4 213.40.195.160
s=Asterisk PBX 1.6.2.14
c=IN IP4 213.40.195.160
t=0 0
m=audio 12434 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

07:30:07.170092 IP (tos 0x10, ttl 64, id 57321, offset 0, flags [none], proto: UDP (17), length: 375) 213.40.195.161.sip > 213.40.195.160.sip: [bad udp cksum bf0b!] UDP, length 347
E..w....@.g..(...(.......c3.SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP 213.40.195.160:5060;branch=z9hG4bK60921de5;rport=5060
From: "1_104" <sip:104@213.40.195.160>;tag=as0d376f73
To: <sip:1_104@213.40.195.161>
Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160
CSeq: 102 INVITE
Server: kamailio (3.0.3 (i386/linux))
Content-Length: 0


07:30:07.170170 IP (tos 0x10, ttl 64, id 36636, offset 0, flags [none], proto: UDP (17), length: 1020) 213.40.195.161.sip > 91.72.15.26.neod2: [bad udp cksum 793f!] UDP, length 992
E.......@....(..[H.........&INVITE sip:1_104@91.72.15.26:1049 SIP/2.0
Record-Route: <sip:213.40.195.161;lr=on;ftag=as0d376f73;nat=yes>
Via: SIP/2.0/UDP 213.40.195.161;branch=z9hG4bKcfc5.d218bfe2.0
Via: SIP/2.0/UDP 213.40.195.160:5060;branch=z9hG4bK60921de5;rport=5060
Max-Forwards: 69
From: "1_104" <sip:104@213.40.195.160>;tag=as0d376f73
To: <sip:1_104@213.40.195.161>
Contact: <sip:104@213.40.195.160>
Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.2.14
Date: Fri, 03 Dec 2010 07:30:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 304

v=0
o=root 451599995 451599995 IN IP4 213.40.195.160
s=Asterisk PBX 1.6.2.14
c=IN IP4 213.40.195.161
t=0 0
m=audio 35048 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=nortpproxy:yes

07:30:07.310232 IP (tos 0x10, ttl 64, id 36637, offset 0, flags [none], proto: UDP (17), length: 32) 213.40.195.161.sip > 91.72.15.26.vfo: [bad udp cksum 7be1!] UDP, length 4
E.. ....@..s.(..[H..... ...J....
07:30:07.320775 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 384) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 356
E.....@.3.CA[H...(.......lrcSIP/2.0 100 Trying
Via: SIP/2.0/UDP 213.40.195.161;branch=z9hG4bKcfc5.d218bfe2.0,SIP/2.0/UDP 213.40.195.160:5060;rport=5060;branch=z9hG4bK60921de5
To: <sip:1_104@213.40.195.161>
From: "1_104" <sip:104@213.40.195.160>;tag=as0d376f73
Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160
CSeq: 102 INVITE
Server: Twinkle/1.4.2
Content-Length: 0


07:30:07.322022 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto: UDP (17), length: 500) 91.72.15.26.neod2 > 213.40.195.161.sip: [udp sum ok] UDP, length 472
E.....@.3.B.[H...(..........SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 213.40.195.161;branch=z9hG4bKcfc5.d218bfe2.0,SIP/2.0/UDP 213.40.195.160:5060;rport=5060;branch=z9hG4bK60921de5
Record-Route: <sip:213.40.195.161;lr=on;ftag=as0d376f73;nat=yes>
To: <sip:1_104@213.40.195.161>;tag=nkmlc
From: "1_104" <sip:104@213.40.195.160>;tag=as0d376f73
Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160
CSeq: 102 INVITE
Contact: <sip:1_104@91.72.15.26:1049>
Server: Twinkle/1.4.2
Content-Length: 0


07:30:07.322282 IP (tos 0x10, ttl 64, id 57322, offset 0, flags [none], proto: UDP (17), length: 443) 213.40.195.161.sip > 213.40.195.160.sip: [bad udp cksum cbff!] UDP, length 415
E.......@.g..(...(........3LSIP/2.0 180 Ringing
Via: SIP/2.0/UDP 213.40.195.160:5060;rport=5060;branch=z9hG4bK60921de5
Record-Route: <sip:213.40.195.161;lr=on;ftag=as0d376f73;nat=yes>
To: <sip:1_104@213.40.195.161>;tag=nkmlc
From: "1_104" <sip:104@213.40.195.160>;tag=as0d376f73
Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160
CSeq: 102 INVITE
Contact: <sip:1_104@91.72.15.26:1048>
Server: Twinkle/1.4.2
Content-Length: 0


07:30:07.324223 IP (tos 0x0, ttl 64, id 14790, offset 0, flags [none], proto: UDP (17), length: 623) 213.40.195.160.sip > 213.40.195.161.sip: [udp sum ok] UDP, length 595
%.(...(.......[.LSIP/2.0 180 Ringing
Via: SIP/2.0/UDP 213.40.195.161;branch=z9hG4bK3847.c9d47957.0;received=213.40.195.161
Via: SIP/2.0/UDP 91.72.15.26:1049;rport=1048;branch=z9hG4bKgomsuukn
Record-Route: <sip:213.40.195.161;lr=on;ftag=suayr;nat=yes>
From: "1_104" <sip:1_104@213.40.195.161>;tag=suayr
To: <sip:104@213.40.195.161>;tag=as42f8b04e
Call-ID: rfuiigeorxyjeis@test.local
CSeq: 783 INVITE
Server: Asterisk PBX 1.6.2.14
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:104@213.40.195.160>
Content-Length: 0


Как видим разницы между ответами от UA нет вообще никакой:
1. INVITE
2. Ответ от К - 407
3. ACK
4. DIGEST

Строчка 7(24628) NOTICE: <script>: [Fri Dec 3 07:14:26 2010] Detected INVITE before authorization 1_104 -> 104 приходит от К, когда proxy_authorize() отдает false, т.к. там есть xlog ( см. скрипт ниже )

Но в обоих случаях ответы от К разные. Во втором, он тупо повторяет 407.

Всё просто как угол дома. Вот кусок конфига, который собственно выбирает куда балансировать звонок. Там же проверяем авторизированный ли инвайт:

Цитата:

# Send to Asterisk
route[TOASTERISK] {
if (method=="INVITE") {
if (!proxy_authorize("", "sipusers")) {
xlog("L_NOTICE", "[$Tf] Detected INVITE before authorization $fU -> $tU\n");
proxy_challenge("", "0");
break;
} else if (!check_from()) {
sl_send_reply("403", "Use From=ID");
break;
}
consume_credentials();
}

ds_select_dst("1", "4");
xlog("L_NOTICE", "Balancing call to asterisk => $du, from $fU \n");

route(RELAY);
exit;
}



В логе никаких ошибок нет.

Я уже не знаю куда копать. Хоть садись и пиши свою авторизацию через базу. Но ведь бред же. Должно же работать?

Буду благодарен, если поможете разобраться.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Список форумов Asterisk Forum -> OpenSER На страницу 1, 2  След. Ответить на тему
Страница 1 из 2

Добавить в Избранное

 
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
You cannot attach files in this forum
You cannot download files in this forum