Скажем есть звонок с 100 на 101. Первый инвайт генериться от 100 и приходит к А. А генерит инвайт для 101.
И вставляет в From, To уже приватные адреса. Это логично, т.к. внешних интерфейсов Астериск не имеет, но в таком варианте звонок не может состояться, т.к. пришедший пакет имеет в своих хедерах приватные адреса, о которых ничего не знает UAC.
И получается что в запросном инвайте:
From: 100@PUBLIC
To: 101@PUBLIC
А в ответном:
From: 101@PRIVATE_ASTERISK_IP
To: 100@PRIVATE_KAMAILIO_IP
Да, если выдать астериску реальный адрес, чтобы к нему можно было достучаться извне и попросить К говорить по реальной сети только, то всё работает без вопросов.
Какие есть варианты куда копать?
Но не совсем понятно что вы хотите получить, вопервых позвонить c 100 на 101 можно вообще без астериска. Если вы всёже хотите пропускать вызовы через asterisk для каких-то мультимедийных штук - то последний инвайт так же должен возвращаться к 101 через камаилио, который должен проксировать. в таком случае всё должно работать, даже не смотря на то что в сообщениях кой где будут фигурировать серые адреса. Но в такой конфигурации вам ещё нада внимательно смотреть на проксирование медиа трафика с помощью камаилио.
| itreers @ Вт Сен 25, 2012 16:01 писал(а): |
| Как решили проблему с проксированием? |
скорее всего выставлением правильных флагов для force_rtp_proxy...
http://www.kamailio.org/docs/modules/3.1 ... proxy.html
_________________
рву шаблоны. дорого.
Есть Камаилио ( дальше К ), есть 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 этой информации нет.
Возможно я не правильно понимаю решение. Надеюсь на вашу помощь.
Спасибо.
2ZloMurz: Ок, предположим они зарегались на К, а на А не регаются как быть дальше?А всеравно не приймет вызов от незареганого пира.
Спасибо.
Ваша схема мне понятна, не ясен один ньюанс: каким образом так спроксировать инвайт, чтобы пир говорил с К, а К отправляло запросы на А, подставляя в них свой IP, то есть фактически выдавая себя за пир? Если Вас не затруднит, дайте, пожалуйста, пример только этого блока кода для К. Если я правильно Вас понял.
То что я понял, то сигнальный и RTP трафик должен проходить так:
Пир K A
Спасибо.
Собсно да, проблема с матчастью.
Еще важные детали по моей задаче, которые я не указал:
1. Астериски многоклиентные, то есть в системе есть куча клиентов в екстеншеном 101, например, и все они деляться на основании контекстов. Именно поэтому важно чтобы звонок приходил от пира. Если он прийдет от безликого К, как тогда определить какой именно клиент звонил?
2. Я смотрел и завел конфиг уважаемого ZloMurz. Но это не совсем то что мне нужно. Клиенты регаются на К, да, но учитывая условие 1, где клиенты разделены на основании префиксов, я уже сделать звонок не могу без префикса, что логично, ведь в location пиры сохраняются уже с префиксами.
Возможно для решения задачи мне лучше при регистрации на К, бросать регистрацию на все астериски сразу? Таким образом, куда бы не пришел звонок, он пройдет нормально. Но не вижу как сделать запрос к нескольким хостам сразу. Можно вообще такое сделать на К?
Нада регистрировать людей на камаилио, пробрасывать звонки на астериски. В камаилио в инвайт сообщении уходящем на астер передавать имя пользователя звонящего. Дальше анализировать его на астериске и перекидывать в нужный контекст.
PS: "Проблема с матчастью" - лично я говорил о проблеме с пониманием самого протокола SIP, а не камаилио. Из личного опыта скажу - нельзя на камаилио сделать ничего толкового пока не будет понимания полной механики хождения SIP сообщений.
PSS: Не знаю как у остальных, но лично мне пришлось окунуться в SIP глубоко только тогда когда возникла необходимость настроить камаилио. Тоесть у Вас всё в переди)
PSSS: Так как описано в прошлом Вашем сообщении сделать можно. Для этого нужно делать forward-ы REGISTER сообщений на все астериски. Придётся разобраться с ответами на них(не пересылать же клиенту несколько ответов на один запрос регистрации?)). Потом убедиться в актуальности данных на обоих астерисках(никто не исключает ситуацию когда регистрация дойдёт только на один сервер, а на второй почему-то нет). Ну и всё поидее.
Вариант с проксированием звонка мне больше нравится, чем куча регистраций, аля костыль. Попробую научиться просировать звонок, потому что сейчас звонки на астериски приходят от пиров.
Еще один момент который мне до сих пор не ясен: А1 и А2, юзают базу для авторизации пользователей. Почему при регистрации на А1, А2 считает, что у него пир не зареган? В таблицах информации о том, на каком именно А прошел авторизацию пир - нет. Было бы очень удобно: К отправляет в кластер А пакет про регистрацию, после чего шлет звонки на любой астер и тот базируясь на таблице, всё делает как надо. Но сейчас это почему-то не работает ... я что-то упускаю?
| 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, а он не в пример сложнее. Про нехватку времени и желание что-либо быстро запустить быстрее чем поймете как, лучше никому не рассказывайте, это мало кого трогает, если нужно что-то быстро и из коробки то это однозначно в раздел работа.
| ZloMurz писал(а): |
| так сделать нельзя. kamailio сам не создает запросы или пакет, он их пересылает, т.е. пришел ему регистер, он конечно может его отфорвардить на A1, но не на A1 и A2. Тиражировать запросы он не умеет. |
Если я в конфиге напишу:
| Код: |
| forward("x.x.x.x:yy"); forward("z.z.z.z:yy"); exit; |
запрос не будет растиражирован?
1. Таймаут
2. Обработка причины отказа. Если таймаут, ставим текущему dst статус пробинг.
3. Берем следующий.
Не вижу. Но не понятно как их оттуда потом доставать. Можете что-то посоветовать по этому поводу?
Касательно теражирования запросов: мне кажется можно использовать модуль uac для этого и соответственно uac_req_send() и формировать запрос руками. В теории должно работать.
Насчет probing не пробовал. Возможно интересная фича, поэкспериментируйте, и выложите для общественности.
Added after 49 seconds:
Запрос руками формировать это костыль. Такую схему потом замучаешься поддерживать.
Сейчас вопрос по авторизации запросов от зареганых UAC на К.
Итак, клиенты регаются на К ( www_authorize() ), К вносит их в базу. Всё замечательно, но нам еще надо проверять каждый приходящий инвайт на то, разрешенный это инвайт или нет, перед тем как его проксировать на А, т.к. К публичный.
Проверку запроса я выполняю через proxy_authorize(). Сразу после старта К, всё работает как должно: клиент регается, шлет запрос. Если не зареган, то послать не может. Но буквально через секунд 40, все звонки начинают отшиваться с ошибкой 407 Proxy Authentication Required. Этот ответ дает функция proxy_authorize(), которая почему-то начинает отдавать 407.
Никаких вменяемых ответов на то, почему это происходит в Инете я найти не могу. ЧЯДНТ?
У метя что-то подобное было когда камаилио не успевал обработать ASK и слал 407 повторно.
Внешне kamailio может и не выглядеть нагруженным. В конфиге debug включён, xlog юзается?
Ещё интересно cat kamailio.log| grep ERROR
Вот диалог между 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: From: "1_104" ;tag=pyxxe Call-ID: mjqenljapmqadzq@test.local CSeq: 196 INVITE Contact: 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: ;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.8ebe From: "1_104" ;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: ;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.8ebe From: "1_104" ;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: From: "1_104" ;tag=pyxxe Call-ID: mjqenljapmqadzq@test.local CSeq: 197 INVITE Contact: 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: : [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: ;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.1be1 From: "1_104" ;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: ;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.1be1 From: "1_104" ;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: From: "1_104" ;tag=suayr Call-ID: rfuiigeorxyjeis@test.local CSeq: 782 INVITE Contact: 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: ;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.6905 From: "1_104" ;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: ;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.6905 From: "1_104" ;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: From: "1_104" ;tag=suayr Call-ID: rfuiigeorxyjeis@test.local CSeq: 783 INVITE Contact: 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: From: "1_104" ;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: 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: From: "1_104" ;tag=suayr Call-ID: rfuiigeorxyjeis@test.local CSeq: 783 INVITE Contact: 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: From: "1_104" ;tag=suayr To: 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: 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" ;tag=as0d376f73 To: Contact: 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" ;tag=as0d376f73 To: 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: 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" ;tag=as0d376f73 To: Contact: 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: From: "1_104" ;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: To: ;tag=nkmlc From: "1_104" ;tag=as0d376f73 Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160 CSeq: 102 INVITE Contact: 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: To: ;tag=nkmlc From: "1_104" ;tag=as0d376f73 Call-ID: 47a670cd11039e9e7404fd455fdc541d@213.40.195.160 CSeq: 102 INVITE Contact: 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: From: "1_104" ;tag=suayr To: ;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: Content-Length: 0 |
Как видим разницы между ответами от UA нет вообще никакой:
1. INVITE
2. Ответ от К - 407
3. ACK
4. DIGEST
Строчка 7(24628) NOTICE: : [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; } |
В логе никаких ошибок нет.
Я уже не знаю куда копать. Хоть садись и пиши свою авторизацию через базу. Но ведь бред же. Должно же работать?
Буду благодарен, если поможете разобраться.
Дальше рекомендую записать развёрнутый лог kamailio когда звонок проходит и когда нет, и сравнить.
| Цитата: |
| 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 от авторизации.
Соответственно при успешном звонке, после назначения индекса нонсу, всё идет дальше. Что посоветуете сделать в данном случае?
| Код: |
| if (!proxy_authorize("domain","subscriber")) { proxy_challenge("domain","0"); exit; }; |
Ошибка не очевидная, всё что тут могу посоветовать внимательно смотреть дебаг, и экспериментировать и блоками поотдельности.
Усложняло диагностику то, что помимо этой ошибки, был не правильно составлен скрипт этой самой авторизации, который выполнялся первым, в результате, проверка выполнялась, но даже левые запросы проходили, что создавало впечатление того, что проверка не выполняется.
Вообщем сам виноват. Продолжу настраивать. Как разберусь в фейлом нод - дам знать. Пока искал решение авторизации видел интересный, и судя по всему рабочий, вариант этой самой фильтрации. Как сделаю - выложу.
Последний раз редактировалось: indeec (Пт Дек 03, 2010 14:06)
Если у Вас есть работающая конфигурация с отсечением плохих гейтов, поделитесь пожалуйста, я думаю многим будет полезно.
Но у меня оно не используется, я просто выбираю другую ноду в случае если транзакция заканчивается неудачей. Для этого есть ds_next_dst(). Помоему пингать ноды имеет смысл только если работаем в stateless, или в каких-то специфических условиях
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)
чтобы не ждать долго ответа от гейта. В случае одного провала он всеравно не попадет в пробинг.
И еще если не жалко покажи конфиги которыми раскидываешь звонки на asterisk сервера.
Потом взял скомпиленый модуль диспетчера и заменил ним свой из RPM. Всё заработало. То есть ничего изобретать не нужно - если будете собирать из сорцов - всё соберется как надо.
Касательно конфигов - выложу чуть позже, когда запустимся и правки в конфигах закончаться. В целом, я смотрел конфиги сгенеренные через сайт - они вполне себе замечательные, то есть вполне можно начать с них. Я же начал с выложеных конфигов не первой свежести и из-за этого потерял кучу времени и сил. Впрочем результата всеравно достиг и уже когда узнал про сайт переползать на его конфиг желания не было.
Сам разброс у меня происходит в отдельной секции и там все примитивно:
ds_select_dst и потом возвращаюсь в основной роут, который борется с натом и определяет пути для onreply и для on failure.
Если роут зафейлился по причине таймаута, то берем следующий гейт пока не кончаться все.
Вообще если есть конкретные вопросы, то мне кажется, будет лучше если я на них отвечу либо кусками конфига, либо комментариями.
И всё бы можно было свалить на хардфоны, вот только с астериском напрямую они работают замечательно.
Кто-то сталкивался с чем-то похожим? Кому удавалось подружить К с хардфонами для запросов SUBSCRIBE и какими?
| Цитата: |
| И всё бы можно было свалить на хардфоны, вот только с астериском напрямую они работают замечательно. |
Подозреваю, что Астериск сам рассылает запросы и определяет онлайность/оффлайность юзерагентов