сказать по делу - пупок развяжется, гораздо лучше с язвить

через любую свободную цифру (префикс) как по аналогии выход в ТфОП (через 9)

без трассировки sip тут думать нечего, только пальцем в небо и направление ветра мерить
вероятнее всего что абоненты Gеnesys и Oktell находятся в запредельной сети т.е. к примеру охе находится в сети 10.253.253.x а запредельная сеть 192.168.1.х за бордерами ввиде Gеnesys и Oktell, суть уловили?
если нет абоненты - Gеnesys и Oktell заходятся в своих сетях с опцией "direct rtp", тобишь в качестве источника rtp для Gеnesys и Oktell выступает сам абонент, но по правилам маршрутизаторами (или что там у вас) абонент с Gеnesys и Oktell не имеют выход (запрет) в сеть охе либо статического маршрута не хватает

делайте трассу sip
1. Gеnesys (или Oktell) -> oxe
2. oxe -> Gеnesys (или Oktell)

стоит у клиента Alcatel OXE R11.1-l1.301-23-j-ru-c7

от провайдера приходит 5 isdn-pri, на OXE все эти потоки объедены в одну TG

в обеденный перерыв приключилось "сие чудо" - отвалились входящие звонки. связист (который у клиента) физически передернул все платы NPRAE которые идут в сторону прова, легче на стало.
исходящие звонки ходят как ни в чем не бывало.

звоню провайдеру и объясняю что setup приходит абсолютно "голый", проверяет и говорит что по трассировки звонка setup уходит полный (есть нью-анс - это показывает на логическом уровне). что там реально происходит на транке (у прова) знает только "анализатор isdn" (который в данный момент был в другом месте) и "сам бог"

продолжалось это безобразие где-то 40 минут и само все рассосалось, провайдер притащил анализатор isdn но так и не успел "заглянуть в душу транка" чтобы посмотреть что там происходит

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

есть несколько вопросов:
1. кому нибудь такое "сие чудо" встречалось?
2. насколько можно верить "t3" и "t3 -data" т.е. возможно ли расхождения (тобишь в "t3 -data" данные одни, а выхлоп в "t3" другой)

вот и сама трассировка "сие чуда"

| (482066:000002) Concatenated-Physical-Event :
| long: 40  desti: 0  source: 0  cryst: 0  cpl: 3  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : SETUP [05]    Call ref :  7f 82
|____________________________________________________________­__________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 94 -> T2 : B channel 20 exclusive
| IE:[1e] PROGRESS_ID (l=2) 82 81
| IE:[29] DATE (l=5)  ->  date :  01 / 02 / 18   12:03
| [a1] Sending complete
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000003) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : STATUS [7d]    Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=3) 81 e3 29 -> [e3]
|    INFORMATION ELEMENT NON-EXISTENT OR NOT IMPLEMENTED
| IE:[14] CALL_STATE (l=1) 06
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000004) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : DISCONNECT [45]  Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 9c -> [9c] INVALID NUMBER FORMAT
| IE:[1e] PROGRESS_ID (l=2) 81 81
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000005) Concatenated-Physical-Event :
| long: 18  desti: 0  source: 0  cryst: 0  cpl: 3  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  7f 82
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000006) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­__________________

апгрейд был с версии 7.1 f5.401.17

по TC1854en начинается с версии 8.0.1
про конфликты что-то не помню чтобы что-то выскакивало

для себя - при апгрейдах буду мигрировать базу хотя бы через одну версию
чувствую что предстоит попотеть с версии 3.1 до 12

основная причина (все остальное можно было пережить)
RA CROXES-15196  3 Major       noflag Kiruba PERUMAL      Kiruba PERUMAL      [Report] : TDM phones are not upd ated with right binaries
часть телефонов обновилась, другая часть осталось при своем (при своем так же остался 80x9)

телефоны которые не обновились не показывали статус Set-Supervision на терминале 4035Т у секретаря (народная мудрость - не надо ссорится с тремя в конторе - это глав.бух, водитель босса и секретарь)

станция в работе, похоже что надо будет перезаливать софт
на stand-by пока пытаюсь что-то понять

netadmin 11.1 -> The internet accesses to the PABX are currently NOT SECURED.

пробывал через все логины, так же

единственное предположение что это возникло когда cho-dat от 7.1 сделал restore в 12 релизе

через ftp подключается, залить файл не дает
логах пишет
Dec 20 10:30:14 xb001004 ftpd[24521]: FTP LOGIN FROM 192.168.6.40 [192.168.6.40], mtcl



sftp в теории через ssh, а он отключен

с security  по дефолту на первое Y/N -> N , на втрое R 1 2 3 -> R , на третье  подтвердить Y/N -> Y
по началу залил m1.403.16b, через ftp базу положил и запустил атс

потом накатил патч m1.403.18b и приехали с ftp

сделали апгрейд ОХЕ до версии 12.0 m1.403.18b (cpu7-2)

теперь появилось самое интересное - не могу через ftp в папку /usr4/BACKUP/IMMED базу положить

есть какие-нибудь мысли?

все гораздо романтичнее с "коллайдер" (петли)

звонок уходит в сторону fmc
варианты:
1. звонок разворачивается на терминирующем шлюзе т.е. куда е1 приходит в fmc, разворот по принципу диал-плана
2. в fmc абонент прописан на удаленной стороне т.е. на ОХЕ и естественно звонок уходит обратно

тут интересует другой вопрос - на сколько автор поста уверен что ему помогает поле REDIRECTING_NUMBER при звонках на fmc?
процесс "коллайдера" уже участвует без REDIRECTING_NUMBER, тем более провайдер меняет на "01  83" и ему особого труда не составит лишнее отрезать

1. версию свой OXE не озвучили, может все банально решается патчем

2. что-то ваши инсталяторы уж сильно перестарались
единственное место где транки могут (возможно) связываться - entity, далее в ход идет транк-группа и ее тип в т.ч. privat/public, в конце тунеля sd/prefix tg/ars

внимание...вопрос - как можно изменить Presentation при forward-е во вне с опцией REDIRECTING_NUMBER если звонок пришел через tg с меткой public....

Ваш аппарат случаем не двух линейный?