Некорректное приземление вх. вызовов с TAU32 на Asterisk

[artis35]

Приветствую снова, уважаемые коллеги, профессионалы и просто хорошие ребята)

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

В двух словах схема у нас такая: Городские линии (Ростелеком) -> TAU32 -> Asterisk -> SIP-клиенты и абоненты, подключенные к FXS-портам TAU32.
На стенде мы использовали 2 входящие линии от провайдера, которые подключили соответственно к портам FXO1 и FXO2.
На указанных портах настроены номера 901 и 902 соответственно.
Для передачи вызовов со шлюза на Asterisk я использовал функцию hotline (кстати, это может быть неправильно, хотелось бы уточнить). Т.е. на FXO1 и FXO2 в настройках портов прописаны вызовы на hotline-номера 801 и 802 соответственно.
Еще важные данные для понимания проблемы: на шлюзе (как писал выше) также используются FXS-порты, к которым подключены аналоговые телефоны в офисе. У портов нумерация назначена нами такая: FXS1 - 201, FXS2 - 202, FXS3 - 203, FXS4 - 204, FXS5 - 505, FXS6 - 506, FXS7 - 507, FXS8 - 508.
Также на шлюзе создан SIP-профиль (Profile 2), с помощью которого все порты (FXS и FXO) регистрируются на Asterisk (на нем естественно в sip.conf созданы соответствующие аккаунты).
Причем, что важно. Для номеров, соответствующих FXO-линиям (901, 902 и тп) указан context=incoming; для номеров, соответствующих FXS-линиям (201, 202, 505 и т.п.) указан context=out_tau32. Первый контекст обрабатывает входящие вызовы, второй исходящие.

И, после долгого вступления, теперь собственно о самой проблеме.
При поступлении входящего вызова (от внешнего абонента) через провайдера, допустим на порт FXO1, шлюз принимает вызов (сначала идут статусы Preringing и т.п.), затем осуществляет донабор hotline-номера 801, тем самым вызов должен попадать на контекст incoming, где указана логика обработки вызова, поступающего на экстеншен 801.
И вот тут вырастает странный глюк - по какой-то причине, по принципу абсолютного случайного математического тыка, входящие вызовы со шлюза TAU32 на Asterisk поступают не с номера 901, а с номеров FXS-линий. В частности, входящий вызов (см. дамп eltex_tau32_test2), пришедший на порт FXO1 шлюза (номер 901) на Asterisk попал уже от номера 505, закрепленного за портом FXS5.

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

(Данным логам соответствует дамп TCPDUMP  eltex_tau32_test2)
[Apr 18 20:23:22] NOTICE[1024]: chan_sip.c:22622 handle_request_invite: Call from '505' (172.16.130.225:5060) to extension '801' rejected because extension not found in context 'out_tau32'.
  == Using SIP RTP CoS mark 5


И естественно, такой вызов на Asterisk не обрабатывается и вываливается с ошибкой, т.к. обработка вызова в данном случае ведется контекстом, закрепленным за аккаунтом 505 (т.е. out_tau32), где обработки вызовов на экстеншен 801 не предусмотрено.
Т.е. проблема абсолютно гуляющая - входящие вызовы на Asterisk каждый раз поступают от разных аккаунтов. Если "повезло", то вызовы поступают с аккаунтов 901-904 и обрабатываются верно (т.к. попадают на контекст incoming), а если "не повезло", то вызовы по мнению Asteriskа приходят с аккаунтов, привязанных к FXS-портам и все ломается.

В частности, вот пример логов Asterisk'а, когда звонок все-таки проходит успешно (звонок поступал на FXO1 (901)):

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

(Данным логам соответствует дамп TCPDUMP  eltex_tau32_test1)
-- Executing [802@incoming:1] NoOp("SIP/904-00000077", "") in new stack
    -- Executing [802@incoming:2] Answer("SIP/904-00000077", "") in new stack
    -- Executing [802@incoming:3] Goto("SIP/904-00000077", "ivr,s,1") in new stack
    -- Goto (ivr,s,1)
    -- Executing [s@ivr:1] NoOp("SIP/904-00000077", "") in new stack
    -- Executing [s@ivr:2] Set("SIP/904-00000077", "fname=2014_04_18_20:15-") in new stack
    -- Executing [s@ivr:3] Set("SIP/904-00000077", "recdir=/etc/asterisk/Recordings/2014/04/18") in new stack
    -- Executing [s@ivr:4] System("SIP/904-00000077", "mkdir /etc/asterisk/Recordings/2014/04/18") in new stack
    -- Executing [s@ivr:5] MixMonitor("SIP/904-00000077", "/etc/asterisk/Recordings/2014/04/18/2014_04_18_20:15-.wav") in new stack
    -- Executing [s@ivr:6] GotoIfTime("SIP/904-00000077", "8:00-18:00,mon-fri,*,*?default:holyday") in new stack
    -- Goto (ivr,s,7)
    -- Executing [s@ivr:7] NoOp("SIP/904-00000077", "") in new stack
    -- Executing [s@ivr:8] Wait("SIP/904-00000077", "2") in new stack
  == Begin MixMonitor Recording SIP/904-00000077
    -- Executing [s@ivr:9] BackGround("SIP/904-00000077", "/etc/asterisk/ivr/hello_holi") in new stack
    -- <SIP/904-00000077> Playing '/etc/asterisk/ivr/hello_holi.slin' (language 'en')
  == Spawn extension (ivr, s, 9) exited non-zero on 'SIP/904-00000077'
  == MixMonitor close filestream
  == End MixMonitor Recording SIP/904-00000077
  == Using SIP RTP CoS mark 5


Как мы здесь видим, Астериск почему-то воспринимает вызов опять же не с номера 901, а с 904, но так как для обоих номеров контекст указан incoming, то вызов обрабатывается верно.

Ниже привожу набор данных.
1) TCPDump eltex_tau32_test1: http://yadi.sk/d/QB9moizPMnAnK
2) TCPDump eltex_tau32_test2: http://yadi.sk/d/QqqCveNMMnAnT
3) Конфиг на ТАУ32 - прилеплен к посту.

Содержимое sip.conf:

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

[miacip]
type=friend
context=out_tau32
host=dynamic
canreinvite=no
qualify=yes
disallow=all
dtmfmode=auto
allow=alaw
allow=ulaw
insecure=port,invite

;experimental account for FXO
;first 4 lines - lines from Rostelecom
[901](miacip)
context=incoming
secret=qwerty
username=901

[902](miacip)
context=incoming
secret=qwerty
username=902

[903](miacip)
context=incoming
secret=qwerty
username=903

[904](miacip)
context=incoming
secret=qwerty
username=904

[201](miacip)
secret=qwerty
username=201

;Grishin AA (202)
[202](miacip)
secret=qwerty
username=202

;Rezerv (203)
;[203](miacip)
;secret=qwerty
;username=203

;Datacenter Office (204)
[204](miacip)
secret=qwerty
username=204


Содержимое extensions.conf

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

[incoming]
;Detection of incoming calls from outside
;incoming call from line 901
exten => _801,1,NoOp
exten => _801,2,Answer
exten => _801,3,Goto(ivr,s,1)

;incoming call from line 902
exten => _802,1,NoOp
exten => _802,2,Answer
exten => _802,3,Goto(ivr,s,1)

;дальше переход на IVR


[Aleksey_ts]

Добрый день!

Просмотрел два приложенных дампа (eltex_tau32_test1 и eltex_tau32_test2). В них нашел вызовы, сделанные с одного и того же порта FXO в разное время. Один вызов успешен, второй - нет.

Вы утверждаете что при звонке с ТАУ иногда вызов приходит не с 901 порта, а с 505. В таком случае информация о номере 505 должна содержаться в заголовках From или Contact (в зависимости от того, где анализируется этот номер) запроса INVITE от ТАУ.
Рассмотрим INVITE при неуспешном вызове:

Frame 901 (898 bytes on wire, 898 bytes captured)
Ethernet II, Src: a8:f9:4b:05:ab:92 (a8:f9:4b:05:ab:92), Dst: ba:93:16:3d:9f:83 (ba:93:16:3d:9f:83)
Internet Protocol, Src: 172.16.130.225 (172.16.130.225), Dst: 172.16.130.180 (172.16.130.180)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:801@172.16.130.180 SIP/2.0
Message Header
Via: SIP/2.0/UDP 172.16.130.225;rport;branch=z9hG4bK0FNjNvH93y93B
Max-Forwards: 70
From: <sip:172.16.130.180>;tag=5H2mrNj24a0Zg
To: <sip:801@172.16.130.180>
Call-ID: 216d5c06-41da-1232-6eb1-a8f94b05ab92
CSeq: 58590237 INVITE
Contact: <sip:901@172.16.130.225>
User-Agent: TAU-72 build 2.9.0 sofia-sip/1.12.10
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO
Supported: timer, 100rel, replaces
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 270
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 3739655472664606204 3447495488013198642 IN IP4 172.16.130.225
Session Name (s): Session SDP
Connection Information (c): IN IP4 172.16.130.225
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 35294 RTP/AVP 8 0 96
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:96 telephone-event/8000
Media Attribute (a): fmtp:96 0-16
Media Attribute (a): silenceSupp:off - - - -

В заголовке From нет номера абонента А.

From: <sip:172.16.130.180>;tag=5H2mrNj24a0Zg

Причина в том, что эта информация не была получена от присоединенной АТС из абонентской линии методом FSK (скорее всего на АТС не включен этот метод Caller-ID). Но эти данные не будут приниматься во внимание и, судя по всему, не принимаются Asterisk'ом при обработке вызова. Эта информация для того чтобы более правильно настроить Вашу сеть и выдавать клиентам реальный номер звонящего из сети присоединенного через АЛ оператора.

В заголовке Contact передается реальный адрес порта ТАУ, с которого осуществляется вызов - 901.

Contact: <sip:901@172.16.130.225>

Ниже INVITE при успешном вызове

Frame 1857 (898 bytes on wire, 898 bytes captured)
Ethernet II, Src: a8:f9:4b:05:ab:92 (a8:f9:4b:05:ab:92), Dst: ba:93:16:3d:9f:83 (ba:93:16:3d:9f:83)
Internet Protocol, Src: 172.16.130.225 (172.16.130.225), Dst: 172.16.130.180 (172.16.130.180)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: INVITE sip:801@172.16.130.180 SIP/2.0
Message Header
Via: SIP/2.0/UDP 172.16.130.225;rport;branch=z9hG4bKec5tvK7rm1FXr
Max-Forwards: 70
From: <sip:172.16.130.180>;tag=UK1Q3ZXUKXXBj
To: <sip:801@172.16.130.180>
Call-ID: fafa5d40-41d8-1232-6eb1-a8f94b05ab92
CSeq: 58589990 INVITE
Contact: <sip:901@172.16.130.225>
User-Agent: TAU-72 build 2.9.0 sofia-sip/1.12.10
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO
Supported: timer, 100rel, replaces
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 270
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 5515320775230378742 6651940529732548997 IN IP4 172.16.130.225
Session Name (s): Session SDP
Connection Information (c): IN IP4 172.16.130.225
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 35242 RTP/AVP 8 0 96
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:96 telephone-event/8000
Media Attribute (a): fmtp:96 0-16
Media Attribute (a): silenceSupp:off - - - -

Как видите они идентичны.

Т.е. напрашивается вывод что корень проблемы надо искать в Asterisk. Непонятна причина подмены им номеров звонящих.

[artis35]

Согласен - отчасти это может быть причина Астериска. Но хотелось бы спросить - а по какой причине в заголовке FROM стоит просто адрес шлюза, без указания номера, как например это имеется в поле Contact? Я исходил из такого предположения: если включена опция определения Caller ID, то в поле FROM мы должны увидеть CallerIdnumber@172.16.130.225, а если эта опция отключена - то в указанном поле должен стоять номер FXO-линии, на которую входящий вызов приземлился и откуда, собственно, этот вызов передается в Asterisk (т.е. 901@172.16.130.225). Я предполагал, что именно так и будет, т.к. линия от оператора у нас старая и маловероятно, что шлюз с нее сможет определять номера. Или я где-то не прав?

И еще остался не отвеченным вопрос - а верна ли вцелом схема, когда я входящий на FXO-порт вызов передаю на Asterisk с помощью hotline-номера? Может можно как-то по-другому?

[Aleksey_ts]

Здравствуйте!

Согласен - отчасти это может быть причина Астериска.

Почему отчасти, по сигнализации к ТАУ пока вопросов нет

Но хотелось бы спросить - а по какой причине в заголовке FROM стоит просто адрес шлюза, без указания номера, как например это имеется в поле Contact? Я исходил из такого предположения: если включена опция определения Caller ID, то в поле FROM мы должны увидеть CallerIdnumber@172.16.130.225, а если эта опция отключена - то в указанном поле должен стоять номер FXO-линии, на которую входящий вызов приземлился и откуда, собственно, этот вызов передается в Asterisk (т.е. 901@172.16.130.225). Я предполагал, что именно так и будет, т.к. линия от оператора у нас старая и маловероятно, что шлюз с нее сможет определять номера. Или я где-то не прав?

В руководстве по эксплуатации сказано:

– Use PSTN CallerID – при установленном флаге использовать CallerID, принятый из телефонной линии для вызова в направлении VoIP, иначе – не использовать;

т.е. Если установлен флаг, то номер в заголовке From формируется из информации о вызывающем абоненте, полученной методом FSK со встречной станции. Если эта информация не была получена, то в заголовке From поле userinfo остается пустым.
Снимите флаг Use PSTN CallerID и во From будет передаваться абонентский номер порта и альтернативный АОН, если он настроен.

И еще остался не отвеченным вопрос - а верна ли вцелом схема, когда я входящий на FXO-порт вызов передаю на Asterisk с помощью hotline-номера? Может можно как-то по-другому?

Такой способ вполне имеет право на жизнь ))) Некоторые варианты у нас описаны в базе знаний на сайте. Ознакомиться с ними можете здесь http://eltex.nsk.ru/eltex_kb

[powetr]

Проблема типовая, и "виноват" здесь астериск- посмотрите, используется src=dst port 5060 . Хотя справедливости ради нельзя сказать что это именно виноват, такова архитектура.
Ну во первых, зачем у вас insecure=invite,port? Для такого пира что FXS что FXO - разницы не будет, хост ip то один, а аутентификации нет.В таких случаях,
что и составляет проблему - астер выбирает контекст случайным образом. Это данность просто от незнания, всё достаточно просто преодолимо.
Теперь как решить. Сначала включите аутентификацию (уберите insecure), но тут могут быть проблему другого рода (user mismatch for digest auth).
Можете поступить не совсем элегантно, но проблему решите- создайте на интерфейсе еще один ip адрес из той же подсетки, и разнесите порты по
типу: FXO регистрируйте на ip1, FXS- на ip2. В sip.conf листенинг должен быть на обоих интерфейсах.В такой схеме достаточно в свойствах пира выставить
insecure=invite и путаницы у вас не будет.
Вот как описывает авторитетный источник на своем сайте:
--------------------------------------------------------------------------------------
http://igorg.ru/2012/02/22/sip-trank-neskolko-uchyotok/
У многих существует иллюзия, что при входящем вызове так же произойдет авторизация по указанным логину и паролю, однако это не так (обратите внимание что при настройке транков вы повсеместно используете опцию insecure=invite). При поступлении входящего вызова авторизация не предусмотрена, поэтому поиск пира по имени пользователя и паролю невозможен. Однако поиск транка, по которому поступил вызов происходит и он отображается в наименовании входящего канала. Каким образом? По значению параметра host и port, а так как они одинаковы, то на какой бы номер вызов не поступил входящий вызов, всегда будет найден последний (поведение между версиями asterisk может отличаться) из пиров. В примере — это пир msk2222222.

Наблюдаемые аномалии:
1.Если у пиров, с одним значением host, указаны различные контексты, то будет создаваться впечатление что астериск игнорирует контексты всех пиров, кроме последнего из указанных в конфигурационном файле.
--------------------------------------------------------------------------------------
Если поможет- буду рад, у меня схожее выплыло при интеграции ТАУ-32 с FreePBX, но это скорее от недостатка практики в этой связке