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

Kamailio/OpenSIPS и другие производные от SER.

Модераторы: Admins, Модераторы

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

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

Сообщение Dark_Angel » 19 ноя 2010, 16:18

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

Есть Камаилио ( дальше К ), есть 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
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 19 ноя 2010, 18:31

Пользователи регаются на kamailio или asterisk? Если на kamailio то вообще не важно на какой астериск отдаётся вызов

ZloMurz
Сообщения: 303
Зарегистрирован: 31 янв 2008, 15:19

Сообщение ZloMurz » 19 ноя 2010, 19:06

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 19 ноя 2010, 20:16

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

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

Спасибо.

ZloMurz
Сообщения: 303
Зарегистрирован: 31 янв 2008, 15:19

Сообщение ZloMurz » 20 ноя 2010, 07:13

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 20 ноя 2010, 17:12

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

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

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

Пир <-> K <-> A

Спасибо.

indeec
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 20 ноя 2010, 21:06

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 21 ноя 2010, 09:01

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

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

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

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

indeec
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 21 ноя 2010, 11:51

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

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 21 ноя 2010, 12:33

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

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

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

indeec
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 21 ноя 2010, 12:55

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 21 ноя 2010, 13:09

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

indeec
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 21 ноя 2010, 13:43

У астериска есть своя ASTDB. Но тут утверждать не готов, там ли оно хранится, или всёже в памяти. Не проверял

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 21 ноя 2010, 16:16

Используется таблица. Удалось настроить как хотел. Спасибо за участие, пойду читать книжки дальше.

ZloMurz
Сообщения: 303
Зарегистрирован: 31 янв 2008, 15:19

Сообщение ZloMurz » 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, аля

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

&#91;kamailio&#93;
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
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 21 ноя 2010, 23:30

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

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

forward&#40;"x.x.x.x&#58;yy"&#41;;
forward&#40;"z.z.z.z&#58;yy"&#41;;
exit;
запрос не будет растиражирован?

ZloMurz
Сообщения: 303
Зарегистрирован: 31 янв 2008, 15:19

Сообщение ZloMurz » 22 ноя 2010, 07:29

Нет.

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 22 ноя 2010, 09:41

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

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

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

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

ZloMurz
Сообщения: 303
Зарегистрирован: 31 янв 2008, 15:19

Сообщение ZloMurz » 22 ноя 2010, 10:14

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

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

Added after 49 seconds:

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 22 ноя 2010, 10:53

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 01 дек 2010, 14:55

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

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

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

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

Никаких вменяемых ответов на то, почему это происходит в Инете я найти не могу. ЧЯДНТ?

indeec
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 02 дек 2010, 15:33

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 02 дек 2010, 15:52

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

indeec
Сообщения: 87
Зарегистрирован: 17 май 2009, 11:46
Откуда: Киев

Сообщение indeec » 02 дек 2010, 17:17

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

Dark_Angel
Сообщения: 27
Зарегистрирован: 19 дек 2009, 00:59

Сообщение Dark_Angel » 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;
}
В логе никаких ошибок нет.

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

Буду благодарен, если поможете разобраться.

Ответить