Правильно описать входящий Trunk для разных линий с одного IP

Question

Добрый день!

Подскажите как правильно описывать Trunk, чтобы разделять по каналам в Asterisk'е.

Допустим провайдер создал три учётные записи у себя.

0151*100
0151*101
0151*102

Я описал у себя их следующим образом:

[0151_100]
nat=never
dtmfmode=rfc2833
context=from-trunk
type=peer
insecure=invite
username=0151*100
fromuser=0151*100
secret=XXXXX
host=sip.provider.xxx
port=5060
promiscredir=yes
allow=alaw
allow=ulaw
allow=g729

[0151_101]
nat=never
dtmfmode=rfc2833
context=from-trunk
type=peer
insecure=invite
username=0151*101
fromuser=0151*101
secret=XXXXX
host=sip.provider.xxx
port=5060
promiscredir=yes
allow=alaw
allow=ulaw
allow=g729

[0151_102]
nat=never
dtmfmode=rfc2833
context=from-trunk
type=peer
insecure=invite
username=0151*102
fromuser=0151*102
secret=XXXXX
host=sip.provider.xxx
port=5060
promiscredir=yes
allow=alaw
allow=ulaw
allow=g729

строчки регистрации вида:

register=0151звезда100:XXXXX@sip.provider.xxx:5060/0151звезда100 register=0151звезда101:XXXXX@sip.provider.xxx:5060/0151звезда101 register=0151звезда102:XXXXX@sip.provider.xxx:5060/0151звезда102

Проблема в том что все входящие приходят в Trunk 0151_100:

[2012-03-19 10:33:13] VERBOSE[7003] pbx.c:     -- Executing [0151*100@from-trunk:1] Set("SIP/0151_100-000006e5", "__FROM_DID=0151*100") in new stack
[2012-03-19 10:33:15] VERBOSE[7005] pbx.c:     -- Executing [0151*101@from-trunk:1] Set("SIP/0151_100-000006e6", "__FROM_DID=0151*101") in new stack
[2012-03-19 10:33:25] VERBOSE[7013] pbx.c:     -- Executing [0151*102@from-trunk:1] Set("SIP/0151_100-000006ed", "__FROM_DID=0151*102") in new stack
[2012-03-19 10:33:45] VERBOSE[7039] pbx.c:     -- Executing [0151*101@from-trunk:1] Set("SIP/0151_100-000006f7", "__FROM_DID=0151*101") in new stack
[2012-03-19 10:34:16] VERBOSE[7103] pbx.c:     -- Executing [0151*100@from-trunk:1] Set("SIP/0151_100-00000702", "__FROM_DID=0151*100") in new stack
[2012-03-19 10:38:22] VERBOSE[7400] pbx.c:     -- Executing [0151*102@from-trunk:1] Set("SIP/0151_100-00000735", "__FROM_DID=0151*102") in new stack
[2012-03-19 10:38:47] VERBOSE[7418] pbx.c:     -- Executing [0151*102@from-trunk:1] Set("SIP/0151_100-0000073b", "__FROM_DID=0151*102") in new stack
[2012-03-19 10:39:41] VERBOSE[7500] pbx.c:     -- Executing [0151*100@from-trunk:1] Set("SIP/0151_100-00000751", "__FROM_DID=0151*100") in new stack
[2012-03-19 10:39:41] VERBOSE[7512] pbx.c:     -- Executing [0151*101@from-trunk:1] Set("SIP/0151_100-00000752", "__FROM_DID=0151*101") in new stack

С помощью _FROMDID я отправляю на нужный внутренний канал, и в принципе всё работает. Но мне интересно понять, как правильно нужно описать Trunk'и, чтоб они корректно распределялись. С исходящими звонками проблем нет. Каждый идёт в свой Trunk.

Для чего это нужно: поставил FOP2 и там видны эти самые Trunk'и, и получаются что все входящие приходят на один Trunk, и это вызывает путаницу...

За ранее спасибо.

Accepted Answer

1

Астериск не сможет разделить эти транки если стоит insecure=invite. Единственный способ - использовать разные DID.

Тут подробнее http://igorg.ru/2012/02/22/sip-trank-neskolko-uchyotok/

ссылка удалить спам редактировать

ответил 2012-03-19 11:57:39 +0400

switch
8334 ● 11 ● 7 ● 92
http://lynks.ru/

Comments

Мда уж... Спасибо ) Не знал что существует такая врождённая проблема в Asterisk'е.

Раз уж вы так хорошо разбираетесь в этой теме, подскажите пожалуйста, а что можно использовать в insecure вместо invite, чтобы проблему решить? insecure=port?

Nerian ( 2012-03-19 12:23:58 +0400 )редактировать

это не проблема. это функционал.

zzuz ( 2012-03-19 12:28:58 +0400 )редактировать

на сайте уважаемого igorg вроде все написано подробно, я врядли точнее скажу...

switch ( 2012-03-19 12:32:03 +0400 )редактировать

>> это не проблема. это функционал.

Каким образом данный функционал настраивается? Что мне нужно изменить в выше приведенной конфигурации чтобы разделить входящие звонки по транкам в зависимости от имени пользователя/DID?

Nerian ( 2012-03-19 13:11:17 +0400 )редактировать

только если вы заставите провайдера звонить с аутентификацией или отдавать вам правильный DID

switch ( 2012-03-19 13:15:28 +0400 )редактировать

Уже хорошо.

Провайдер отдает правильный DID: _FROMDID=0151100, __FROM_DID=0151101, _FROMDID=0151*102,

в зависимости от линии с которой пришёл вызов. Что прописать чтобы Asterisk по нему сопоставлял транки входящие?

Nerian ( 2012-03-19 13:20:10 +0400 )редактировать

ну дык вот имеете свой DID для каждого транка, по DID и разруливайте. Но в логах будет только первый транк ;)

switch ( 2012-03-19 13:26:53 +0400 )редактировать

Так так сейчас и есть ) По DID и CallerID и разруливаю ) Напрягает даже не то что в логах только первый транк, а то что в операторской панеле (FOP2) видно что все входящие идут через один транк. Ну да ладно. Раз нельзя то успокоюсь на этом.

Nerian ( 2012-03-19 15:04:31 +0400 )редактировать

Answer 2

0

Можно вылечить, только не совсем средствами Asterisk, а средствами iptables.

Что сделал я:

iptables -t nat -A OUTPUT -d 0.0.0.1 -j DNAT --to-destination --==ip-адрес сервера SIP==--

iptables -t nat -A OUTPUT -d 0.0.0.2 -j DNAT --to-destination --==ip-адрес сервера SIP==--

Что это даёт? Все исходящие пакеты на адрес 0.0.0.1 будут направляться на --==ip-адрес сервера SIP==--. Вроде бы ничего, НО! все ответы приходящие от сервера будут так же приходиться (как будто бы) с адреса 0.0.0.1 - это так работает механизм подмены адресов DNAT/SNAT из iptables. Это позволяет создать секцию типа type=peer по ip-адресу серверва соединений, который теперь всегда будет корректно назначаться именно тому каналу, который должен быть связан с этим IP.

Аналогично с 0.0.0.2.

Можно использовать любой удобный адрес, у меня шла настройка нескольких учётных записей мультифона, там адрес 193.201.229.35, я выбрал:

iptables -t nat -A OUTPUT -d 193.201.229.34 -j DNAT --to-destination 193.201.229.35

iptables -t nat -A OUTPUT -d 193.201.229.33 -j DNAT --to-destination 193.201.229.35

Соответственно необходимо подправить строчки регистрации на Asterisk, теперь в качестве сервера сипов надо будет указывать не адрес сервера, а то, что мы "подменяем" правильным адресом в iptables, то есть в моём примере регистрация идёт на 193.201.229.34 и 193.201.229.33 вместо 193.201.229.35 (это sbc.megafon.ru).

register => tcp://89xxXXXxxXX@multifon.ru:CoOlPaSsWd:89xxXXXxxXX@193.201.229.33:5060/my_ext1

register => tcp://89xxXXXxxXX@multifon.ru:CoOlPaSsWd:89xxXXXxxXX@193.201.229.34:5060/my_ext2

Лучшего решения я не нашёл.

Нужные настройки в секциях пиров sip.conf asterisk:

[xxx]
; симмка 89xxXXXxxXX с мультифона - SIP от мегафона
type=peer                       ; только пир - определение по ip адресу!!!
host=193.201.229.34             ; !!!!! этот адрес заменяется в iptables на правильный 193.201.229.35
insecure=port,invite            ; обязательно так!!! Иначе входящий вызов не пройдёт!!!
context=incoming_calls          ; контекст этот для входящих звонков, экстенжн указан в регистрации
fromuser=89xxXXXxxXX            ; это нужно ТОЛЬКО для исходящих вызовов!!!
fromdomain=multifon.ru          ; это нужно ТОЛЬКО для исходящих вызовов!!!
secret=xyz                      ; это нужно ТОЛЬКО для исходящих вызовов!!!

P.S. Чтобы iptables корректно обрабатывал преобразования необходимо использовать модули ip nat sip и ip conntrack sip (или nf nat sip и nf conntrack sip, вместо пробелов в названиях модулей - подчёркивания)

Проверить их наличие можно при помощи команды lsmod | grep sip, если они не загружаются автоматически, надо установить их загрузку в /etc/modules

ссылка удалить спам редактировать

ответил 2014-08-31 02:37:30 +0400

Валерий_ещё_один
1 ● 1

обновил 2014-09-01 16:20:31 +0400

Comments

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

meral ( 2014-08-31 03:44:39 +0400 )редактировать

Провайдер самый обычный. Провайдер этой подмены вообще не видит, всё происходит внутри стека сервера телефонии. Попробуйте у себя, поделитесь.

Валерий_ещё_один ( 2014-08-31 11:19:34 +0400 )редактировать

угу. у меня то опыта совсем нету, это я так,фигней маюсь. еще раз. iptables не менет пакеты. только заголовки

meral ( 2014-08-31 12:47:16 +0400 )редактировать

Я рад, что Вы фигнёй занимаетесь, но так-то тут люди для работы обычно пишут, про проблемы. Не мешайте.

Валерий_ещё_один ( 2014-08-31 15:39:56 +0400 )редактировать

да не вопрос. работайте.

meral ( 2014-08-31 15:44:05 +0400 )редактировать

все ответы в других темах будут удалены. ибо подход неверный.

meral ( 2014-09-01 04:45:38 +0400 )редактировать

Я просто хочу помочь всем, кто столкнулся с этой проблемой, разве это плохо? Пусть берут и пользуются. Никакого другого решения я больше не видел, да и судя по ответам авторов, они просто слили этот вопрос или забили на него. Что не так то?

Валерий_ещё_один ( 2014-09-01 16:10:38 +0400 )редактировать

да. плохо. ибо ваше решение некорректно и работает в очень малом количестве случаев. вы даже похоже не понимаете ПОЧЕМУ некоректно.

meral ( 2014-09-01 16:19:58 +0400 )редактировать

Если Вы считаете, что моё решение некорректно - объясните почему.

Укажите области (не-)применимости этого решения, если оно, с Вашей точки зрения, ограничено. Повторюсь ещё раз: нигде решения этой задачи я не видел, везде сливы и забивания.

Валерий_ещё_один ( 2014-09-01 16:38:58 +0400 )редактировать

я вам обьяснил почему. по rfc необходимо брать информацию для авторизации из пакета,а не из адреса откуда занатилося. информация в пакете НЕ МЕНЯЕТСЯ в вашем "решении". потому это решение с точки зрения СТАНДАРТА протокола некорректно. иногда может работать. на тех провайдерах которых такие умные уже достали и они сделали на этот случай хак.

meral ( 2014-09-01 20:21:10 +0400 )редактировать

а. вы еще и contrack_sip включили. ну тогда вообще в пакете может быть что угодно.

meral ( 2014-09-01 20:22:47 +0400 )редактировать

Давайте я с Вами соглашусь. Это - неправильный подход, когда авторизация идёт по ip адресу, хотя она и предусмотрена в астериске. Правильный подход - авторизация по invite. Мультифон в инвайте мне шлёт в поле FROM: адрес звонящего. Есть адрес который можно использовать для авторизации в поле TO: - там указан телефон, куда идёт звонок. Собственно вопрос: каким образом сделать авторизацию корректной? match auth username = yes

Валерий_ещё_один ( 2014-09-01 23:32:33 +0400 )редактировать

asterisk разрабатывалься как ДЕШЕВАЯ замена офисным PBX. никого вообще не волнует ваш случай, ибо он СИЛЬНО усложняет ядро сип стека и отладку и КРАЙНЕ редко используется.

meral ( 2014-09-02 02:19:26 +0400 )редактировать

У меня вот такие условия - астериск используется как шлюз звонков для службы такси, у меня руки связаны - я не могу убрать астериск, вся логика программы на этом висит. Один сип-провайдер даёт мне 2 транка, но у него 1 ip. В зависимости от того на какую линию пришёл звонок - должен включаться разный класс услуг в программе такси, это аксиомы под которые я должен подстроить астериск и программу такси. Да, я с Вами согласен, что неправильно авторизоваться по "подставленному" IP (и вообще авторизоваться по IP), но я вообще никак иначе авторизоваться при INVITE не могу, астериск не позволяет сделать это на тех условиях, в которых провайдер предоставляет телефонию - даже не используя iptables и conntrack - у меня в поле FROM телефон звонящего. Вы меня критикуете за "несоотвествие стандарту", но Вы вообще не предлагаете альтернативного варианта в этих условиях, это неконструктивный диалог.

Валерий_ещё_один ( 2014-09-02 14:22:54 +0400 )редактировать

Два дня просматриваю логи по вечерам, вижу - провайдер в принципе не передаёт авторизацию в процессе передачи звонка (invite от сервера к asterisk, invite от asterisk к серверу, ack от сервера к астериску и тишина), и наконец меня озарило. Это же паранойя. Asterisk с точки зрения провайдера - это очередной СИП-телефон. Серверу СИП-провайдера слать пакеты с авторизацией на сип-телефон, который перед этим регался на сервере - абсурд. Всё правильно, type=peer - самое нужное тут. Если же очень сильно хочется всё-таки проверять, соответствует ли звонок регистрации, то можно назначить экстенжн с невероятным сложным именем, и проверять его во входящих.

Валерий_ещё_один ( 2014-09-04 15:27:31 +0400 )редактировать

Правильно описать входящий Trunk для разных линий с одного IP

2 Ответа

Comments

Comments

Ваш ответ

Закладки и информация

Статистика

Похожие вопросы: