Всем добрый день!
Имеем ОХЕ (R8.0.1-g1.503-17-b-ru-c7s2) и неизвестный Меридиан. Стык по ABC-F транк-группе (QSIG-GF). Изначально все проектировалось для набора внутренних номеров между станциями, и это работает (на стороне ОХЕ Routing Number и так далее). Теперь хочу организовать выход в город через каналы Мерина и проблема в том, что по префиксу занятия моей ABC-F транк-группы ни одной цифры я послать не могу. Вот трасса

______________________________________________________________________________
| (378259:000066) 1063: Send_IO1 (link-nbr=22, sapi=0, tei=0) :
| long: 344 desti: 0 source: 15 cryst: 0 cpl: 22 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 00 08
|
| CONCATENATION OF 2 SEGMENTED MESSAGES
|______________________________________________________________________________
|
| [a1] Sending complete
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a1 83 89 -> T2 : B channel 9 preferred
| IE:[1c] FACILITY (l=137)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=6):
| [80] Source Entity (l=1) End_PTNX
| [82] Destination Entity (l=1) End_PTNX
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=52):
| Invoke Ident. : 2ee0 (12000)
| OP: ECMA RO_CALLING_NAME (0)
| [30] Sequence (l=40)
| [80] Name presentation allowed (l=9) 'PABX Test'
| [a6] Sequence of Ecma extension (l=27)
| [30] Sequence (l=25)
| [06] Object id. (l=7) 2b 0c 02 88 52 b6 73
| [30] Sequence (l=14)
| [80] Context specific (l=1) 00
| [81] Context specific (l=9) 50 41 42 58 20 54 65 73 74
| [a1] INVOKE (l=69):
| Invoke Ident. : 0001 (1)
| OP: ALCATEL RO_CLASSMARKS (1)
| [30] Sequence (l=56)
| [80] Feature identifier (l=5) 06 44 47 3f 04
| [82] Cug (l=1) 01
| [83] SubNetwork number (l=1) 00
| [ab] Sequence of Project data (l=41)
| [30] Sequence (l=15)
| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (134621715)
| [30] Sequence (l=9)
| [83] Current entity (l=1) 01
| [84] Initial kind of call (l=1) 11
| [85] Context specific (l=1) 01
| [30] Sequence (l=22)
| OP :RO_SERVER_ACCESS_INFO (134621715)
| [30] Sequence (l=16)
| [80] Language (l=1) 01
| [81] type of set (l=1) 05
| [84] Feature identifier 2 (l=5) 00 c0 20 00 46
| [86] Priority of call (l=1) 00
| IE:[27] NOTIF_INDI (l=78)
| 83 : discriminator for notif. extention
| [30] Sequence (l=75)
| OP :ALCATEL CHARGING_INFO (112)
| [30] Sequence (l=65)
| [12] Numeric string (l=5) 35 36 38 33 31
| [80] Context specific (l=2) 05 00
| [81] Context specific (l=1) 01
| [82] Context specific (l=10) 20 20 20 20 20 20 20 20 20
| 20
| [86] Context specific (l=1) 01
| [87] Context specific (l=1) 00
| [ab] Sequence of Project data (l=31)
| [30] Sequence (l=29)
| OP :RO_SPECIFIC_CHARGING_INFO (134621715)
| [30] Sequence (l=23)
| [80] Context specific (l=2) 05 02
| [81] Context specific (l=9) 12 07 39 33 31 39 39 35 30
| [00] Universal unknown (l=131) 05 35 36 38 33 31
| IE:[27] NOTIF_INDI (l=24)
| 83 : discriminator for notif. extention
| [30] Sequence (l=21)
| OP : 1b77 (7031)
| [30] Sequence (l=10)
| [12] Numeric string (l=5) 35 36 38 33 31
| [02] Integer (l=1) 01
| IE:[27] NOTIF_INDI (l=14)
| 83 : discriminator for notif. extention
| [30] Sequence (l=11)
| OP : 1b7d (7037)
| [05] ARG NULL (l=0)
| IE:[6c] CALLING_NUMBER (l=7) -> 00 81 Num : 56831
| IE:[70] CALLED_NUMBER (l=9) -> 80 Num : 99319950
| IE:[7d] HLC (l=2) 91 81
| [95] Locking shift. codeset : 5
| IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)
|______________________________________________________________________________

______________________________________________________________________________
| (378260:000068) Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 0 cpl: 22 us: 0 term: 1 type a5
| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 08
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 d1 -> [d1] INVALID CALL REFERENCE VALUE
|______________________________________________________________________________

______________________________________________________________________________
| (378260:000069) Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 0 cpl: 22 us: 0 term: 1 type a5
| tei: 0 >>>> message received : REL COMP [5a] Call ref : 80 08
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 d1 -> [d1] INVALID CALL REFERENCE VALUE
|______________________________________________________________________________


Что-то я даже не знаю, кого винить.

Вообще-то странно, что оно у вас заработало по ABC-F. Или все таки QSIG?
Пропишите дискриминаторы и маршрутизацию. И все должно работать.

дык qsig-gf работает через создание транковой группы abc-f с дальнейшем указанием в роута qsig-gf, что тут странного

А все заработало! Просто в параметрах ARS тип роута с дефолтного поменял на QSIG-GF и вуаля!

Вылезла другая беда. При входящем звонке с мерина вижу имя звонящего, строчкой ниже - внутренний номер. (Аппарат 4039). При снятии трубки строка с именем исчезает, остается только номер. Соответственно, пропущенные тоже только номером остаются. Как сделать, чтобы имя не пропадало?

Боюсь что никак, это всетаки звонок по транковой группе, имена в неотвеченных показываются при внутренних звонках, откладывается номер, но в Phone book есть соответствие между номером и именем.
Для каких-то (наверное не слишком большого количества) можно прописать или в Phone book (номер+имя) или speed dialing (служебные номера типа А1000, с номером префикс+номер и displayed name), префикс естественно из используемых в ext.callback translation.
Т.е. суть идеи - чтоб станция знала соответствие имени и номера.

VAD, спасибо, через SpeedDial я, конечно, уже сделал. Но это криво, так как в конторе много тысяч народа с постоянной ротацией пользователей на номерах. Упарюсь я поддерживать все это в порядке. Но, в любом случае, спасибо за ответ.

как-то для интереса пробывал состыковать самсунг и ОХЕ, с именами так и не получилось http://forum.intersyst.ru/read.php?7,8078,8098#msg-8098

error
Посмотрел трассы той темы и заметил такм строчку
IE:[32] EI_PARTY_CATEGORY (l=1) -> EXTENSION (1)
А у меня почему-то при входящем звонке
IE:[32] EI_PARTY_CATEGORY (l=1) -> UNKNOWN (0)

У кого косяк? У меня или у мерина?

А какие-то проблемы при этом возникают?
И кроме того - входящий звонок с абонента Меридиана или входящий из города, а далее через Меридиан в ОХЕ.

Если входящий звонок с абонента меридиана, то Unknown, если с другого Энтерпрайза (где-то там еще включен в тот же меридиан примерно той же схемой) через мерин транзитом, то там Extension. А проблема одна и та же - пропадают имена при снятии трубки. От другого алкателя даже еще хуже - от мериновских абонентов внутренний номер приходит с двумя лишними цифрами в начале, их через Ext Callback обрабатываю и потом через Speed Dialing имена присваиваю, все красиво. А от алкателя приходят голые 5 цифр внутреннего номера, отрезать нечего и Speed Dialing не создать. А из Phonebook имя почему-то не берет.

А чего SD не создать?
Пишите А1000, номер9+12345, имя

Бывает еще интересно (не всегда) System/ Other/ Externel signaling - поставить "да" на Number used unknown.

В этом случае часто появляются перед номером буквы А, С или В.

У вас при звонках с QSIG может добавиться В. Ее легко обрабатывать в ext. callback translation. Например пишите В, удалить 1, добавить префикс выхода на QSIG. И call back заработает.

И вновь продолжается бой...
С того времени много воды утекло, теперь схема такова: моя ОХЕ включена честным ABC-F линком в 4400, которая, в свою очередь, связана с Мерином по QSIG-GF. При звонке на меня абонентов Мерина сквозь ABC-F ко мне долетает 225хххх, а в обратку я должен набирать только 5хххх. Пытался откусить 22 через Ext Callback Translation - не работает (хотя городские и мобильные отрабатываются верно). В чем проблема? Кстати, на 4400 коллбэки на мерин тоже не работают, но они и не парятся. А мне хотелось бы...

зачем такой огород городить т.е. не преще на мерине при наборе 225хххх откусить 22 что набор прошел ввиде 5хххх

и еще по чистому стыку abc-f ОХЕ-4400 надо запретить передачу имени в utf-8 (смотрите в system в одном из разделов)

На меридиане откусить что-либо не получается, так как это "священная корова" и тамошние спецы шлют всех лесом.
А чем повредит передача имени по UTF8, если эти поля везде пустые?

На мерине при наборе 225хххх откусить 22 очень просто

shat330 Написал:
-------------------------------------------------------
> На мерине при наборе 225хххх откусить 22 очень
> просто

Насколько я понял, речь идеот о CLID. А отдавать разные CLID в разные стороны на Меридиане не очень просто

"откусывать" лишние цифры надо не через Ext. callback translation, а через Network routing table.
У вас в транковой группе есть remote network - это ссылка на Network routing table, там в частности есть Rank of first digit to be sent - с какой цифры номера посылать набор, в вашем случае по идее с 3-й. Ну и прочие вещи там есть.

VAD, параметр Rank of first digit to be sent, насколько я понял из хелпа, работает на исходящие вызовы в сторону Remote Network. А мне надо обработать входящие. Как бы то ни было, установка цифры 3 ничего не поменяла.

как на счет того чтоб сделать еще один "роут намбер" с 225хххх специально для мерина если конечно 22 не задействованна у вас на атс

Опять не то. Это от мердиана приходит 225хххх, но набирать в него надо именно 5хххх, по-другому не работает.

расмотрим другую ситуацию - если через транковую группу которая смотрит на мерина используется только исключительно для внутрих звонков и звонки с мерина по каким либо причинам не пытаются сделать городской звонок (т.е. транзитом через вашу атс) то можно задествовать DID translator по входу т.е. описать все номера которые базируются на вашей атс и которые идут далее от вашей атс к самсунгам, ЛыЖам и т.д.
в DID translator описываем 225хххх -> 5хххх и так все останые номера ваши и не ваши

еще пришла в голову мысль такая
на форуме где-то говорилось что можно поставить какую-то галку чтоб номер иденцифировался с буквой "В" впереди, делаем копию роут намбер которая определяет направление "5хххх" но только будет еще одно новое направление "В225хххх", тут ни какию проблем не должно возникнуть

Чего-то я, видимо, не догоняю. Мне надо просто откусить 2 первые цифры А-НОМЕРА через Ext Callback Translation. Для корректного коллбэка. Я просто пытаюсь понять, почему модификация городских и мобильных АОН-ов проходит нормально, а внутренних 225хххх (и любых других, их там немалый набор) не происходит вообще.

А какие у вас цифры вообще в трансляторе прописаны? Может просто формат номеров у вас перекрывается уже созданными трансляторами? Тогда может и не работать как вамм нужно.

Э-э... Какое отношение имеет транслятор (работает с B-номерами) к External Callback Translation (работает с А-номерами)? Или у меня уже перелом мозга наступил?

Я как раз и имел ввиду транслятор в External Callback Translation, циферки, которые в нем прописаны.



Редактировано 1 раз. Последний раз 15.10.2009 18:42 пользователем Vsjakov.

Нет, там все честно, пересечений нет.