у меня супер идея есть - префикс длиной в 8

Андрей, поделиться технологией будешь или сдулся  8)  

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

можно сделать так:
8 "ARS Prof.Trg Grp" c Discriminator No. 7 (к примеру)
Translator->External Numbering Plan->Numbering Discriminator создаете новое правило набора (17 к примеру) , направление 1 через ars 27
Translator->Automatic Route Selection->Numbering Command Table создаете новый с номером (37 к примеру) и указать в "Associated Ext SIP gateway" номер sip-gw (берется отсюда SIP->SIP Ext Gateway)
в Translator->Automatic Route Selection->ARS Route list создаете лист 27, далее в ARS Route 1 не забываем указать в "Numbering Command Tabl. ID" 37, Quality - Speech. так же в "Time-based Route List" добавить Route Number : 1
в Entities -> Discriminator Selector -> Discriminator 07 : 17

и на закуску: можно конечно набор отправить сразу в TG через "Ext Gateway" но версию атс не озвучили

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

через любую свободную цифру (префикс) как по аналогии выход в ТфОП (через 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 базу положить

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