непонятное поведение IAX2 транка

[630]

проблема заключается в следующем. есть 2 сервера, на одном установлен elastix 1.5.2 и соответственно asterisk 1.4, на другом elastix 2.0 и asterisk 1.6. между ними кинут iax2 транк. на первом 3-х значная нумерация, на втором 4-х значная. присутствуют и SIP и IAX номера, задача объединить оба диалплана. транк поднят нормально, звонки ходят в обе стороны. НО при звонке со второго сервера с сип-номера на первый сервер, тоже на сип-номер, CID определяется нормально и абонент видит реальный CID со второго сервера. а вот при звонке наоборот все не так. абоненту второго сервера приходит звонок как будто с внутреннего iax-номера того же сервера. как будто транка не существует в природе.

вот куски логов

лог сервера c elastix 1.5

[Apr 6 14:39:45] VERBOSE[8537] logger.c: -- Accepting AUTHENTICATED call from 192.168.1.252:
> requested format = ulaw,
> requested prefs = (ulaw|gsm|alaw),
> actual format = ulaw,
> host prefs = (ulaw|alaw|gsm),
> priority = mine
[Apr 6 14:39:45] VERBOSE[26152] logger.c: -- Executing [129@default:1] Macro("IAX2/test2-9231", "exten-vm|novm|129") in new stack

все нормально, звонок приходит по транку как и положено и дальше отправляется по своему назначению на номер 129

лог сервера с elastix 2.0

[Apr 6 14:48:55] VERBOSE[2768] chan_iax2.c: -- Accepting AUTHENTICATED call from 192.168.1.115:
> requested format = alaw,
> requested prefs = (alaw|ulaw|gsm),
> actual format = ulaw,
> host prefs = (ulaw|gsm|alaw),
> priority = mine
[Apr 6 14:48:55] VERBOSE[2989] pbx.c: -- Executing [1129@from-internal:1] Macro("IAX2/1199-3254", "exten-vm,1129,1129") in new stack
звонок отправляется куда надо, на номер 1129, вот только он делает вид что пришел не с транка между астерисками а с внутреннего номера 1199 который поднят на нем самом. и вообще в логе никаких следов что транк существует.

на первом сервере то же есть iax номер 199 с точно теми же настройками но там таких глюков нет.

единственная мысль что все дело все-таки в контекстах, но долгая игра с ними ни к чему не привела.

[ded]

Не очень логичный диалплан - 3х значные на одном и 4-х значные на другом.
Логичней было бы 3-х значные на обоих, а первой цифрой регулировать направление в транк по маске.
Типа [1-4]ХХ - на первом, [5-7]XX на втором.
Или, использовать четвёртую (впереди) цифру как префикс - 1ХХХ и 2ХХХ

Ситуацию можно поправить и контекстами, но играться нужно дольше. Или "обратитесь к системному администратору".

[630]

не очень логично потому что это тестовая конфигурация. в боевом режиме все так и будет, везде 4-х значная нумерация с разницей по первым двум цифрам. планируется объединить порядка 6 астеров в разных городах.

по сип-транку в этой тестовой конфигурации в пределах локальной сети все ходит нормально.

в одном городе тоже астер версии 1,6 и нет внутренних iax номеров. подняли транк с ним, все нормально. CID передается как положено. но в других городах есть версии 1,4 с внутренними iax`ами. если будет такая ситуация то будет неприятно. тем более что причины ее абсолютно непонятны.

с контекстами все в теории просто, с обоих концов засовываю этот транк в from-internel и все должно работать. пробовал в default, свои контексты создавал, ничего не меняется.
с маршрутизацией все в порядке, звонки-то ходят. но вот почему 1.6 вместо транка упорно считает звонок пришедшим с экстеншна... при том что в реальности-то он приходит по транку, не из глубины же процессора материализуется.

а "обратитесь к системному администратору" не получится, я он и есть...

[ded]

а "обратитесь к системному администратору" не получится, я он и есть...

Да ну? А кто консультирует консультантов?
Кто инсталлирует ОС системному администратору?
Вы напрасно взялись объединять 6 серверов не имея достаточного представления как всё материализуется из глубины процессора. При звонке всегда происходит внутренняя аутентификация who-is-who по юзеру в первую очередь. И если снаружи позвонил родственный экстеншн "Петя" <129> а на станции есть свой такой же "Таня" <129>, то на экране будет видно, что звонит Таня, а не Петя.

[630]

я это прекрасно понимаю, именно поэтому одинаковых экстеншнов нет ни на одном сервере. на всех своя нумерация. и на тестовых в том числе. но когда я звоню с номера 129 на номер 1110 а звонок приходит почему то от внутреннего номера 1199 который вообще даже не поднят нигде а просто заведен, этого я не понимаю и потому обращаюсь за помощью. считать ли это глюком или все-таки есть какая-то закономерность? может вы сталкивались с подобным?

[ded]

когда я звоню с номера 129 на номер 1110 а звонок приходит почему то от внутреннего номера 1199 который вообще даже не поднят нигде а просто заведен, этого я не понимаю

Возможно номер 1199 заводился и был удалён. Бывает, что он остаётся в нативной базе astdb.
Увидеть его остатки можно командой
CLI>database showkey 1199
всю базу можно просмотреть по
CLI>database show

Если ясно видно
Executing [1129@from-internal:1] Macro("IAX2/1199-3254" то можно предполагать что есть (был) IAX2 пир (или юзер) 1199.
Всё это просматривается командами dialplan show from-internal и по инключдам, а также поиском по файлам.
Также можно предполагать самодельные конструкции в from-internal-custom или их остатки.

[630]

1199 заведен и существует в текущий момент. так же как 1197 и 1195. все три номера иаксовые. просмотр базы действительно выявил следы одного левого транка давно уничтоженного. следы были удалены.
from-internal-custom не существует у меня. вообще в плане контекстов все по дефолту почти. есть пара кастом-контекстов для групп абонентов но в них нет ничего чтобы объясняло подобное поведение. к тому же в них никак не включены ни транк ни номер 1199 ни номер 1129 (для примера). в стандартном from-internal тоже ничего необычного.
в целом я склонен считать это глюком несовместимости версий астера 1.4 с 1.6 по сетевой реализации иакс протокола.
и вот почему, я начал подсоединять другие города, в двух городах стоит 1.6, еще в 3 - 1.4. подключал к нашему серверу с 1.6. города с 1.6 подсоединились нормально сразу, никаких проблем. а вот в те города где астер 1.4 звонки ходят только в одну сторону. от 1.6 к 1.4. в обратно направлении получаю "... busy now ..." транк при этом поднимается в оба конца, везде статус "зарегестрирован". долго думал что дело в сети, потом решил ради эксперимента поднять транк с городов где 1.4 к нашему серверу с 1.4. все заработало.
вывод 1.4 с 1.4 по иаксу дружат отлично, 1.6 с 1.6 тоже. а вот 1.4 с 1.6 налитчествуют глюки непонятного происхождения и разнообразного характера. причем обратная совместимость есть, с 1.6 на 1.4 все в порядке.

[perlik]

Если стоит FreePBX то поставить птичку на Intra company route.

[630]

тоже пробовал. в общем, как я понимаю, никиких более здравых идей чем непонятный глюк ни у кого нет.

[perlik]

тоже пробовал. в общем, как я понимаю, никиких более здравых идей чем непонятный глюк ни у кого нет.

что конкретно выводится на экран? Можно ли нарисовать схемку кто куда звонит с каким Outbound CID и что получается на другой стороне. И желательно CLI звонка сюда запостить нормальный, а не то что там