Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru
На АТС (R11.0.1-k1.520-42-ru-c0) после одновременного пропадания дублированных Applince-серверов по Ethernet-у, с периодичностью в 11 мин сыпятся инциденты 2813=PH: incident X25: diag=1520 apc=0 ap=34 lcn=разные. При этом все узлы по X25 (172.30.1.x) видятся, изменения по сети Broadcast-ятся. Но В Suproutage (в списке узлов) и при запуске Cleanbroad присутствуют узлы, ранее удаленные из ABC-F сети через удаление Inter-Node Links. Может ли это быть причиной появления инцидентов 2813? И как это исправить? Спасибо. Имеется ABC-F сеть ЦАТС OXE. Одна из многочисленных ОХЕ в сети c R.11.0–k1.400-25-f-ru-c82, включенная по гибридному линку (через VPN-канал оператора связи), не пингуется по Х25-адресу. При этом Broadcast работает, изменения на станцию приходят, изменения с данной станции по сети рассылаются. Пробовали пересоздавать сетевые настройки (через netadmin), гибридный линк с перезагрузкой АТС – не помогло. На других ОХЕ с одинаковыми релизами, настройками и способом включения в сеть - Х25 адреса доступны. Главный вопрос – кто виноват и что делать? И попутно - возможно-ли протестировать Х25 протокол на VPN-канале оператора? (оператор утверждает, что все каналы настроены одинаково) Чем это может грозить работе сети ОХЕ?
Добрый день, коллеги.
Есть ОХЕ 12.1 и Авайя, связанные СИП транком.
При звонке с Алкателя на аппарате Авайи отображается имя абонента. А наоборот - имя транк-группы на алкательском аппарате.
В Phone features COS включен Calling Name CNIP/CNAM
В External signalling parameters включен Calling Nmae presentation.
В параметрах External Gateway параметр RFC 3325 supported by the distant = True
Что еще надо сделать?
Да, транк-группа с типом ABC-F. Пробовал и public, и private - без эффекта.
28.12.2023 00:20:02, Seller_V.]]>
День добрый. Имеется OXE R6.0.1. Проблема в следующем. В mgr почемуто в system неправильный network number и соответсвенно в разделе X25 он тоже неправильный. Там стоит нулевой, а нужно первый. А в netadmin-е всё корректно.
Your system has the private network number 1 and the site number 17
local | IP/X25 tunnel | x001017_tun | 172.30.1.17
При попытке в system поменять 0 на 1 network number станция ругается
"routing or network prefix already on new node/net", хотя к примеру 2 или 3 дает сделать.
Локальный network link удалил, все access point стоят operational в disabled.
Может где-то еще нужно отключить? Или всё перезаливать заново?
15.12.2023 18:23:49, fedoseevka.]]>
Здравствуйте. Подскажите пожалуйста, есть OXE ACT 12rel с шельфом, включенным по INTOF2 оптике (2-3км) . Рядом (10м) с этим шельфом появилась еще одна OXE. Могу ли я без проблем их состыковать через pra платы, т.е допустимо ли в remote шельф ставить Pra и дальше линковать с другой нодой?
08.12.2021 07:10:56, fedoseevka.]]>
Друзья, подскажите пожалуйста по UTF8 по сети ABC-F. В моей сети станций была древняя OXE, еще на unix-e r3.1, Теперь её в сети нету. Из-за неё на данный момент у всех нод в system параметрах System-->Network Parameters-->Network Enable UTF8 крыжик снят (отключен). Релизы станций от 7-го до 12-го. Хочу включить utf8, чтобы при межсетевых вызовах начали отображаться русские имена абонентов. Посему вопрос, это действие требует обязательного ребута станций, или же заработает без него? Поделитесь пожалуйста реальным опытом или мнением по поводу этого. Спасибо.
11.09.2020 10:29:57, fedoseevka.]]>
На сети есть станция «А» R11.2.2-l2.300-33-a-ru-c7s2 с выносом через INTIP3 и станция «В» R7.1-f5.401-17-d-ru-c6s2, соединенная со станцией «А» гибридным IP линком. Абоненты со станции «В» звонят на вынос станции «А» без проблем. А вот при звонках с выноса на «В» периодически происходит следующее: абонент с выноса слышит треск, а у абонента «В» тишина. С самой станции «А» таких жалоб не было. Причем проблема эта проявляется рандомно. На сети передачи данных ошибок тоже вроде как нет. Есть какая-то команда посмотреть трассировку звонков по IP? В инциндентах на станции «А» выдает по плате, через которую включену IP потоки следующее:
10/09/20 08:26:22 000004M|000/15/-/---|=2:4408=INT-IP Ethernet error code 4 (status 1 0 0x5c9 0x00 0x00).
На станции «В» никаких ошибок нет.
10.09.2020 09:15:07, mtch.]]>
Привет коллеги, я не могу мониторинг hybrid link на Alcatel OXE. Через OmniVista4760 или любую команду. Как это сделать. Пожалуйста, помогите мне.
24.07.2020 09:44:04, Alisher Alisherov.]]>
Здравствуйте. Есть удаленная мелкая OXE R 3.1 с сотней абонентов в корпусе WM. Реально может полсотни "живых". Включена в сетку ABC-F к узловой OXE 11.1.
На узловой наводил порядок, освободилось с десяток старых плат Z24, соответственно и лицензии на абонентов. Также имеется пара RT2. когда то по ним работал удаленный шельф, который теперь работает по оптике. В связи с чем возник вопрос. Можно ли эту мелкую древнюю OXE в WM корпусе включить по RT2 к узловой или невозможно? На мелкой есть плата UA32, но совершенно точно аппаратов выше 4010, 4020 и 4035 там никогда не будет.
27.12.2019 11:10:22, fedoseevka.]]>
06.08.2019 07:26:31, Victoriya.]]>
Доброго всем дня. Уважаемые Гуру подскажите пожалуйста что это за ошибка на АТС
INCIDENT NUMBER: 310
Network indicator: Alcatel 4400
OBJECT CLASS: Dhs3Terminal
EVENT TYPE: ProcessingErrorAlarm (10)
PROBABLE CAUSE: CommunicationsSubsystemFailure (6)
SEVERITY: Major
"T2 Dlap Released"
"Describes the release of T2"
"No system reaction."
"Check cabling if release is too long. If the fault persists, note the incident"
"with all its information on an observation sheet (problem report), specifying if"
"possible the error context.";
Обрываются вызова на потоке Е1 и нельзя позвонить. Восстанавливается всё минуты через 3 или 4. Что это за ошибка?. Плата PRA виновата или система дурит или на потоке Е1 безобразия какие то?
11.05.2019 12:34:58, Aleksandr ..]]>
Доброго дня всем. Может кто сталкивался с такой ситуацией? Звонки на всех мобильных операторов идут нормально кроме мегафона. на префикс 920 идёт отбой через 30 сек. Это трэйс с нормального звонка -
Traces Analyser activated
mtracer started ...
(711351:000001) MTRACER host (7.31.0.5, oxe_cs1), version: R10.1.1-j2.603-20-i-ru-c80s1
(711351:000001) MTRACER num: 004, time: 2019/03/20 13:46:48, loss: 0%
____________________________________________________________
____________________________________________________________
| (712230:000089) 992: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 60 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 0a bd
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[1e] PROGRESS_ID (l=2) 80 83
| IE:[6c] CALLING_NUMBER (l=12) -> 21 81 Num : 4722235915
| IE:[70] CALLED_NUMBER (l=12) -> 81 Num : 89103224494
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|____________________________________________________________
____________________________________________________________
| (712230:000091) Concatenated-Physical-Event :
| long: 23 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CALL PROC (02) Call ref : 8a bd
|____________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 9a -> T2 : B channel 26 exclusive
|____________________________________________________________
____________________________________________________________
| (712249:000092) Concatenated-Physical-Event :
| long: 26 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 8a bd
|____________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 84 88
| IE:[1e] PROGRESS_ID (l=2) 82 82
|____________________________________________________________
____________________________________________________________
| (712337:000095) Concatenated-Physical-Event :
| long: 25 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 8a bd
|____________________________________________________________
|
| IE:[29] DATE (l=5) -> date : 20 / 03 / 19 13:48
|____________________________________________________________
____________________________________________________________
| (712337:000096) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 0a bd
|____________________________________________________________
____________________________________________________________
| (712368:000099) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : REL COMP [5a] Call ref : 8a bb
|____________________________________________________________
____________________________________________________________
| (712724:000113) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 26 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 0a bd
|____________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
| IE:[1e] PROGRESS_ID (l=2) 81 88
|____________________________________________________________
____________________________________________________________
| (712725:000114) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : RELEASE [4d] Call ref : 8a bd
|____________________________________________________________
____________________________________________________________
| (712725:000115) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 22 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : REL COMP [5a] Call ref : 0a bd
|____________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________
А это с 920 проблемный -
____________________________________________________________
| (712190:000078) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 56 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 0a bc
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[6c] CALLING_NUMBER (l=12) -> 21 81 Num : 4722235933
| IE:[70] CALLED_NUMBER (l=12) -> 81 Num : 89205565777
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|____________________________________________________________
____________________________________________________________
| (712190:000080) Concatenated-Physical-Event :
| long: 23 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CALL PROC (02) Call ref : 8a bc
|____________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 9b -> T2 : B channel 27 exclusive
|____________________________________________________________
____________________________________________________________
| (712225:000087) Concatenated-Physical-Event :
| long: 27 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 8a bc
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[7d] HLC (l=2) 91 81
|____________________________________________________________
____________________________________________________________
| (712225:000088) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 26 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : STATUS [7d] Call ref : 0a bc
|____________________________________________________________
|
| IE:[08] CAUSE (l=3) 81 e0 04 -> [e0] MANDATORY INFORMATION ELEMENT MISSING
| IE:[14] CALL_STATE (l=1) 03
|____________________________________________________________
____________________________________________________________
| (712253:000093) Concatenated-Physical-Event :
| long: 34 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 8a bc
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[29] DATE (l=5) -> date : 20 / 03 / 19 13:48
| IE:[7d] HLC (l=2) 91 81
|____________________________________________________________
____________________________________________________________
| (712253:000094) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 26 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : STATUS [7d] Call ref : 0a bc
|____________________________________________________________
|
| IE:[08] CAUSE (l=3) 81 e0 04 -> [e0] MANDATORY INFORMATION ELEMENT MISSING
| IE:[14] CALL_STATE (l=1) 03
|____________________________________________________________
____________________________________________________________
| (712600:000105) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 25 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 0a bc
|____________________________________________________________
|
| IE:[08] CAUSE (l=5) 81 e6 33 31 30 -> [e6] RECOVERY ON TIMER EXPIRY
|____________________________________________________________
____________________________________________________________
| (712601:000106) Concatenated-Physical-Event :
| long: 18 desti: 0 source: 0 cryst: 2 cpl: 5 us: 0 term: 0 type a5
| tei: 0 >>>> message received : RELEASE [4d] Call ref : 8a bc
|____________________________________________________________
____________________________________________________________
| (712601:000107) 981: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 22 desti: 0 source: 15 cryst: 2 cpl: 5 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : REL COMP [5a] Call ref : 0a bc
|____________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________
Видно что уже на алерте какая то не такая информация идёт от мегафона и наша АТС по всей видимости требует от мегафона
MANDATORY INFORMATION ELEMENT MISSING
А потом отрубает через 30 сек по таймеру.
и теперь главный вопрос, это можно поправить на Alcatel или только мегафон может решить проблему?
21.03.2019 16:51:22, Aleksandr M.]]>
29.11.2018 07:17:06, VitaliyS.]]>
Добрый день!
После 6 лет нормальной работы появилась проблема со связью между станциями Alcatel A4400 и AVAYA G430 соединенными по протоколу H.323 (оптоволокно через Ростелеком). При внешнем звонке со станции Alcatel на станцию AVAYA абонент станции AVAYA не слышит внешнего абонента, при этом внешний абонент прекрасно слышит абонента AVAYA. Внутренняя связь на станции AVAYA работает нормально. Станцию AVAYA подключали в другой сети. Все работает нормально. Установили станцию обратно, по прошествии 2-3 часов после установки проблема появилась снова. Подскажите пожалуйста в чем может быть причина?
25.09.2018 09:13:39, Сергей Р.]]>
Здравствуйте, не нашел в доке как почистить лог netvisu на наблюдающей станции по аналогии с increset. Подскажите пожалуйста, если кто знает.
09.08.2018 16:28:07, fedoseevka.]]>
Добрый день,
Есть такая схема:
Meridian M1 ===(E1)===OXE===(ISVPN E1)===Alcatel 4200
||
||
||
(E1)
||
||
||
ГТС
Если абонент меридиана звонит абоненту Alcatel 4200, то не слышно КПВ. У нас на сети ГТС утверждают, что КПВ должна генерировать та станция, на которую звонят.
ГТС->OXE->4200 КПВ есть
OXE->4200 КПВ есть
Трейс между 4200 и ОХЕ при входящем звонке Meridian->4200 (7111 абонент Meridian, 3037 Абонент 4200)
____________________________________________________________
| (681500:000002) 1016: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 67 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 62 99
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 97 -> T2 : B channel 23 exclusive
| IE:[1e] PROGRESS_ID (l=2) 81 83
| IE:[6c] CALLING_NUMBER (l=6) -> 01 81 Num : 7111
| IE:[70] CALLED_NUMBER (l=5) -> c1 Num : 3037
| IE:[7e] USER_USER (l=17) 00 SUU ISVPN
| SOUS_EI [1] ISVPN (l=14) :
| 01 node number = 1
| 80 entity = 0
| 10 name = 0 num = 1 state = 0 p_cat = 0'
| MCDU_orig : '7111'
| DROITS: rappel text intrus
| 0 0 1
| [a1] Sending complete
|____________________________________________________________
____________________________________________________________
| (681501:000004) Physical-Event :
| long: 23 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 1 type a5
| tei: 0 >>>> message received : CALL PROC (02) Call ref : e2 99
|____________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 97 -> T2 : B channel 23 exclusive
|____________________________________________________________
____________________________________________________________
| (681503:000005) Physical-Event :
| long: 48 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 1 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : e2 99
|____________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 85 82
| IE:[7e] USER_USER (l=24) 00 SUU ISVPN
| SOUS_EI [2] ISVPN (l=21) :
| 8d node number = 13
| 31 name = 1 num = 1 state = 0 p_cat = 1
| Name : 'User4200'
| MCDU_orig : '3037'
| c0 operation = 0 ??? iden = 0 (
| DROITS: rappel text intrus
| 0 0 1
|____________________________________________________________
Трейс между ОХЕ и Меридиан при входящем звонке Meridian->4200 (7111 абонент Meridian, 3037 Абонент 4200)
| (686917:000002) Physical-Event :
| long: 47 desti: 0 source: 0 cryst: 1 cpl: 4 us: 0 term: 1 type a5
| tei: 0 >>>> message received : SETUP [05] Call ref : 71 dd
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 9e -> T2 : B channel 30 exclusive
| IE:[1e] PROGRESS_ID (l=2) 81 83
| IE:[6c] CALLING_NUMBER (l=6) -> 01 80 Num : 7111
| IE:[70] CALLED_NUMBER (l=5) -> 81 Num : 3037
|____________________________________________________________
____________________________________________________________
| (686917:000003) 1016: Send_IO1 (link-nbr=13, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 1 cpl: 4 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : SETUP ACK [0d] Call ref : f1 dd
|____________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 9e -> T2 : B channel 30 exclusive
|____________________________________________________________
____________________________________________________________
| (686918:000004) 1016: Send_IO1 (link-nbr=13, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 1 cpl: 4 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : CALL PROC (02) Call ref : f1 dd
|____________________________________________________________
____________________________________________________________
| (686920:000005) 1016: Send_IO1 (link-nbr=13, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 1 cpl: 4 us: 8 term: 1 type a5
| tei: 0 <<<< message sent : ALERT (01) Call ref : f1 dd
|____________________________________________________________
Как расшифровать вот это сообщение:
IE:[1e] PROGRESS_ID (l=2) 85 82
Я так понимаю что Meridian не умеет генерировать КПВ локально, а ОХЕ в свою очередь не присылает Meridian-у PROGRESS indicator с указанием что тон КПВ может генерировать она.
Кто как решал эту проблему?
На анлишде видел вариант с включением Preannouncement на 4200, но может есть ещё варианты
27.12.2017 17:51:37, Prost.]]>
Собрал себе 2 тестовых станции в корпусах MR1( CS+GD+MIX4/4/8) пусть будет N22 и MR3 (CS+GD+GA+MIX4/4/8+T2) нода N23.Обе одного релиза R8.0-g1.302-6-e-ru-c80s1, соединены между собой и боевой нодой N2 (железо ACT R11.1-l1.301-28-b-ru-c7 через INT-IP3 и PRA по следующей схеме:
N2----E1-ABC-F---------------------------N22(test)------------------------------!
! !
! !
! !
!-----IP-ABC-F(VPN overflow)--N23(test)--IP-ABC-F(VPN overflow)--!
все 3 станции в одноранговой сети, сидят в одном ethernet коммутаторе.
Поднято IP ( родные алкателевские телефоны подключены в каждую из 3-х станций,
SIP также, звонки бегают в любую строну без проблем, в любых сочетаниях. Но вылез неприятный баг.
При перезагрузке N23, которая смотрит 2-мя IP ABC-F vpn в сторону N2 и N22, на боевой N2 входят в ступор все цифровики, стоящие в
плате 2 19 (тип UA), при этом на ней нет никаких событий на эту тему, кроме падения линка N2N23:
26/12/17 20:41:23 001002M|019/00/0/001|=3:2867=PH:Hybrid Access (23 1 Main) goes down
26/12/17 20:41:23 001002M|2-23 |=2:2826=PH:Local link [2 23] is down
26/12/17 20:41:23 001002M|019/00/0/001|=3:2867=PH:Hybrid Access (23 1 Main) goes down
26/12/17 20:41:23 001002M|019/00/0/001|=3:2865=PH:PLL 0 is down on Hybrid Access (23 1 Main)
26/12/17 20:41:23 001002M|---/--/-/---|=2:2872=PH:Remote link [23 22] is down
26/12/17 20:41:23 001002M|---/--/-/---|=3:2832=PH:Node 23 is unreachable
сама плата с цифровиками:
(102)xb001002> listerm 2 19
Tue Dec 26 20:41:45 AST 2017
-------------------------------------------------------------------------
|Coupler: 2 19 Logic type: CPL_UA Board:UA32 State: IN SERVICE |
|-------------------------------------------------------------------------|
| Cry:Cpl:ac:term| neqt | typ term | dir nb | Out of service cause |
|-------------------------------------------------------------------------|
| 2 19 0 0 | 01277 | 4035(MR2_3 | 9400 | A C I X T U P B Y . |
| 2 19 0 1 | 01278 | 4029 | 9401 | A C I X T U P B Y . |
| 2 19 0 2 | 01279 | 4039 | 9402 | A C I X T U P B Y . |
| 2 19 0 3 | 01280 | 4039 | 9403 | A C I X T U P B Y . |
| 2 19 0 4 | 01281 | 4039 | 9404 | A C I X T U P B Y . |
| 2 19 0 5 | 01282 | 4039 | 9405 | A C I X T U P B Y . |
| 2 19 0 6 | 01283 | 4039 | 9406 | A C I X T U P B Y . |
| 2 19 0 7 | 01284 | 4039 | 9407 | A C I X T U P B Y . |
| 2 19 0 8 | 01285 | 4029 | 9408 | A C I X T U P B Y . |
| 2 19 0 9 | 01286 | 4039 | 9409 | A C I X T U P B Y . |
| 2 19 0 10 | 01287 | 4039 | 9410 | A C I X T U P B Y . |
| 2 19 0 11 | 01288 | 4039 | 9411 | A C I X T U P B Y . |
| 2 19 0 12 | 01289 | 4039 | 9412 | A C I X T U P B Y . |
| 2 19 0 13 | 01290 | 4035(MR2_3 | 9413 | A C I X T U P B Y . |
| 2 19 0 14 | 01291 | 4039 | 9414 | A C I X T U P B Y . |
| 2 19 0 15 | 01292 | 8039 | 9415 | A C I X T U P B Y . |
| 2 19 0 16 | 01293 | 4029 | 9416 | A C I X T U P B Y . |
| 2 19 0 17 | 01294 | 4029 | 9417 | A C I X T U P B Y . |
| 2 19 0 18 | 01295 | 4029 | 9418 | A C I X T U P B Y . |
| 2 19 0 19 | 01296 | 4029 | 9419 | A C I X T U P B Y . |
| 2 19 0 20 | 01297 | 4039 | 9420 | A C I X T U P B Y . |
| 2 19 0 21 | 01298 | 4039 | 9421 | A C I X T U P B Y . |
| 2 19 0 22 | 01299 | 4039 | 9422 | A C I X T U P B Y . |
| 2 19 0 23 | 01300 | 4029 | 9423 | A C I X T U P B Y . |
| 2 19 0 24 | 01301 | 4029 | 9424 | A C I X T U P B Y . |
| 2 19 0 25 | 01302 | 4039 | 9425 | A C I X T U P B Y . |
| 2 19 0 26 | 01303 | 4029 | 9426 | A C I X T U P B Y . |
| 2 19 0 27 | 01304 | 4020(LE_3G | 9427 | A C I X T U P B Y . |
| 2 19 0 28 | 01305 | 4029 | 9428 | A C I X T U P B Y . |
| 2 19 0 29 | 01306 | 4039 | 9429 | A C I X T U P B Y . |
| 2 19 0 30 | 01307 | 4039 | 9430 | A C I X T U P B Y . |
| 2 19 0 31 | 01308 | 4039 | 9431 | A C I X T U P B Y . |
|-------------------------------------------------------------------------|
| (A: att_mserv|S: hs smooth), C: hs_defich, I: hs_isolauto, X: hs_isolman|
| T: hs_terdef U: hs_usdef, P: hs_errparite, B: hs_bascul, Y: hs_cristisol|
-------------------------------------------------------------------------
| Nombre total de terminaux hors service : 32 |
| Nombre total de terminaux en service : 0 |
|-------------------------------------------------------------------------|
На остальных шельфах и платах с цифровиками ноды 2 нет никаких проблем. Помогает рестарт платы 2 19 (UA).
По закону подлости именно на этой плате подключены все директора и их секретари. Пока думаю пересадить плату в другой свободный слот рядом. Хотя может вовсе не в этом дело. Подскажите пожалуйста что и где можно подкрутить?
26.12.2017 22:12:23, fedoseevka.]]>
Есть корпоративная сеть АТС (более 50 АТС) подключены в единую сеть по IP сети по гибридному линку.
Архитектура подключения - звезда. Одна центральная АТС и все остальные к ней подключены по гибридному линку по IP сети, такая вот однородная сеть. Всё работает, но тут незадача одна из АТСок при исходящем звонке по гибридному линку на любую из АТС кроме центральной обрывается разговор на 50 секунде. При звонке на центральную АТС всё хорошо, вызов не обрывается.
Это уже не первый косяк на сети связанный с гибридным линком. До этого всё работало много лет, и вдруг стали обрываться исходящие звонки по гибридному линку на одной АТС. Трэйс t3 не дал ни каких зацепок. По трэйсу на обе конечные АТС приходит разъединение как будто извне. Куда копать не знаю, может кто что подскажет? Версия ПО R10.1.1-j2.603-20-i-ru-c82
Буду благодарен за любую идею
29.11.2017 15:01:13, Aleksandr M.]]>
Доброго дня!
Господа, вопрос такого плана:
Имеем парк станций OXE F540136d и G150335 порядка 40 шт.
Для исходящей связи на шлюзе M2(F540136D) имеется 2 оператора: Ростелеком (100 TG) и Мегафон (110 TG)
Выход на внешние сети в данный момент работает через префикс ARS префикс "9" - через Ростелеком и через ARS префикс "6" на Мегафон (только на мегафоновские номера 8999).
Данная схема не совсем удобна по причине того что абоненты при наличии подключенного межгорода (выход на 9) зачастую этим и пользуются.
Подскажите можно ли привязать две транкгруппы с соответствующими NPD и дискриминаторами к одному ARS префиксу, в моем случае 9?
04.09.2017 11:39:02, tolixanklg.]]>
Возникла проблема. На одной из многих АТС корпоративной сети перестали ходить звонки на другие АТС по гибридному линку. Нет ни входящих ни исходящих. Остальная связь работает без проблем, выход на город по Е1, внутри АТС всё нормально. АТС OmniPCX Media Gateway. Hybrid link в апе, на АТС ни каких изменений не делалось пропала связь неожиданно, на следующий день появилась на несколько часов и опять пропала. Сначало подумал что глюк с GA, бывает на Media Gateway иногда такое, перезагрузишь и проблема пропадает. Перезагрузил всю АТС, не помогло. Работало много лет без проблем. Может кто подскажет где копать, может глюк какой?
АТС подключена по гибридному линку не напрямую к центральной АТС а транзитом. Между центральной АТС и транзитной АТС связь в норме. На проблемной АТС по трэйсу t3 сетапа нет и канал на транк группе не занимается, на транзитной АТС занимается 2 канала и по t3 сетап есть, но потом пишет но роут то дестинейшэн. На проблемной АТС снял такой трэйс, при входящем вызове от центральной АТС через транзитную -
(12)oxe_cs2> tuner km
(12)oxe_cs2> tuner clear-traces
(12)oxe_cs2> tuner +cpu +cpl
(12)oxe_cs2> actdbg hybr=on
Fri Aug 11 17:41:44 AST 2017
(12)oxe_cs2> tuner hybrid=on
(12)oxe_cs2> mtracer -a
Traces Analyser activated
mtracer started ...
(874771:000001) MTRACER host (7.12.0.6, oxe_cs2), version: R9.0-h1.301-31-ru-c80s1
(874771:000001) MTRACER num: 017, time: 2017/08/11 17:42:23, loss: 0%
____________________________________________________________
| (874922:000012) Concatenated-Physical-Event :
| long: 623 desti: 0 source: 233 cryst: 19 cpl: 0 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP [05] Call ref : 00 c1
|
| CONCATENATION OF 3 SEGMENTED MESSAGES
|____________________________________________________________
|
| [a1] Sending complete
| IE:[04] BEARER_CAPABILITY (l=2) a8 80
| IE:[18] CHANNEL (l=1) a8 -> T2 : No B channel
| IE:[1c] FACILITY (l=235)
| [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=40):
| Invoke Ident. : 2ee0 (12000)
| OP: ECMA RO_CALLING_NAME (0)
| [30] Sequence (l=28)
| [80] Name presentation allowed (l=6) 'Centel'
| [a6] Sequence of Ecma extension (l=18)
| [30] Sequence (l=16)
| [06] Object id. (l=7) 2b 0c 02 88 52 b6 73
| [30] Sequence (l=5)
| [80] Context specific (l=1) 00
| [81] Context specific (l=0)
| [a1] INVOKE (l=95):
| Invoke Ident. : 0001 (1)
| OP: ALCATEL RO_CLASSMARKS (1)
| [30] Sequence (l=82)
| [80] Feature identifier (l=5) 06 44 c0 1f 00
| [82] Cug (l=1) 05
| [83] SubNetwork number (l=1) 00
| [84] Trunk identity (l=3) 31 32 32
| [ab] Sequence of Project data (l=62)
| [30] Sequence (l=25)
| OP :RO_CLASSMARKS_SUPPLEMENTARY_INFO_1 (134622099)
| [30] Sequence (l=19)
| [80] Trunk group feature (l=5) 06 00 28 00 80
| [81] Trunk group type (l=1) 06
| [83] Current entity (l=1) 01
| [84] Initial kind of call (l=1) 11
| [85] Context specific (l=1) 00
| [30] Sequence (l=22)
| OP :RO_SERVER_ACCESS_INFO (134622099)
| [30] Sequence (l=16)
| [80] Language (l=1) 01
| [81] type of set (l=1) 00
| [84] Feature identifier 2 (l=5) 00 80 21 00 5e
| [86] Priority of call (l=1) 00
| [30] Sequence (l=9)
| OP :RO_AUTOMATED_ATTENDANT (134622099)
| [30] Sequence (l=3)
| [80] Context specific (l=1) 00
| [a1] INVOKE (l=57):
| Invoke Ident. : 000f (15)
| OP: ALCATEL RO_DIVERTING_LEG_INFORMATION2 (15)
| [30] Sequence (l=44)
| [0a] Diversion reason (l=1) 01
| [a0] Number UnScreened (presentation allowed) (l=10)
| [80] Party Number (unknown) (l=8) '70003559'
| [81] Redirecting name (l=4) 'test'
| [ab] Sequence of Project data (l=21)
| [30] Sequence (l=19)
| OP :RO_UTF8_NAME_EXTENSION (134622099)
| [30] Sequence (l=13)
| [80] UTF8 Type (l=1) 01
| [81] UTF8 Name : (l=8) d1 82 d0 b5 d1 81 d1 82
| [a1] INVOKE (l=23):
| Invoke Ident. : 1b9d (7069)
| OP: ALCATEL RO_DIVERTING_LEG_INFO_CSTA (7069)
| [30] Sequence (l=8)
| [82] Initial Called Number (l=6) 'aa1111'
| IE:[1c] FACILITY (l=92)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=34):
| [80] Source Entity (l=1) Any_type_PTNX
| [a1] Source Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10258'
| [82] Destination Entity (l=1) Any_type_PTNX
| [a3] Destination Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10212'
| [a1] INVOKE (l=28):
| Invoke Ident. : 1b78 (7032)
| OP: ALCATEL RO_VPN_NODE_LIST (7032)
| [30] Sequence of (l=13)
| [30] Sequence (l=3)
| [02] Node (l=1) 3a
| [30] Sequence (l=6)
| [02] Node (l=1) 0c
| [01] Barre (l=1) 01 True
| [a1] INVOKE (l=23):
| Invoke Ident. : 1b75 (7029)
| OP: ALCATEL RO_VPN_DDI_NUMBER (7029)
| [40] QSIGInformationElement (l=8)
| IE:[04] BEARER_CAPABILITY (l=3) 90 90 a3
| IE:[32] EI_PARTY_CATEGORY (l=1) 80
| IE:[1c] FACILITY (l=58)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=34):
| [80] Source Entity (l=1) Any_type_PTNX
| [a1] Source Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10258'
| [82] Destination Entity (l=1) Any_type_PTNX
| [a3] Destination Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10212'
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=16):
| Invoke Ident. : 1b7e (7038)
| OP: ALCATEL RO_VPN_COST (7038)
| [02] Integer (l=1) 00
| IE:[27] NOTIF_INDI (l=48)
| 83 : discriminator for notif. extention
| [30] Sequence (l=45)
| OP :ALCATEL CHARGING_INFO (112)
| [30] Sequence (l=35)
| [12] Numeric string (l=8) 37 30 30 30 33 35 35 39
| [80] Context specific (l=2) 05 00
| [81] Context specific (l=1) 00
| [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
| IE:[27] NOTIF_INDI (l=19)
| 83 : discriminator for notif. extention
| [30] Sequence (l=16)
| OP : 1b77 (7031)
| [30] Sequence (l=5)
| [04] Octet string (l=0)
| [02] Integer (l=1) 00
| IE:[27] NOTIF_INDI (l=14)
| 83 : discriminator for notif. extention
| [30] Sequence (l=11)
| OP : 1b7d (7037)
| [05] ARG NULL (l=0)
| IE:[27] NOTIF_INDI (l=31)
| 83 : discriminator for notif. extention
| [30] Sequence (l=28)
| OP : 1b8d (7053)
| [30] Sequence (l=17)
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| [30] Sequence (l=9)
| [02] Integer (l=1) 1e
| [02] Integer (l=1) 00
| [02] Integer (l=1) 00
| IE:[6c] CALLING_NUMBER (l=12) -> 21 81 Num : 4957874500
| IE:[70] CALLED_NUMBER (l=9) -> 80 Num : 70122203
| [95] Locking shift. codeset : 5
| IE:[31] EI_TRANSIT_COUNTER (l=1) 81
| [97] Locking shift. codeset : 7
| IE:[01] EI_ROUTAGE (l=6) e5 01 0a e6 01 02
|____________________________________________________________
____________________________________________________________
| (874922:000014) 1187: Send_IO1 (link-nbr=0, sapi=0, tei=0) :
| long: 21 desti: 0 source: 11 cryst: 19 cpl: 0 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CALL PROC (02) Call ref : 80 c1
|____________________________________________________________
|
| IE:[18] CHANNEL (l=1) a8 -> T2 : No B channel
|____________________________________________________________
____________________________________________________________
| (874922:000015) 1187: Send_IO1 (link-nbr=0, sapi=0, tei=0) :
| long: 114 desti: 0 source: 11 cryst: 19 cpl: 0 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : PROGRESS (03) Call ref : 80 c1
|____________________________________________________________
|
| IE:[1c] FACILITY (l=90)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=34):
| [80] Source Entity (l=1) Any_type_PTNX
| [a1] Source Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10212'
| [82] Destination Entity (l=1) Any_type_PTNX
| [a3] Destination Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10258'
| [a2] RESULT (l=51):
| Invoke Ident. : 1b75 (7029)
| [30] Sequence (l=45)
| OP : ALCATEL RO_VPN_DDI_NUMBER (7029)
| [30] Sequence (l=34)
| [80] VPN Local Number (l=8) '70129999'
| [81] VPN DDI Number (l=8) '70129999'
| [aa] Project Data (l=12)
| OP :RO_VPN_DDI_EXTENSION (134622099)
| [30] Sequence (l=6)
| [80] IP Address (l=4) 07 0c 00 11
| IE:[1e] PROGRESS_ID (l=2) 80 88
|____________________________________________________________
____________________________________________________________
| (874924:000018) Concatenated-Physical-Event :
| long: 144 desti: 0 source: 229 cryst: 19 cpl: 0 us: 0 term: 0 type a5
| tei: 0 >>>> message received : FACILITY [62] Call ref : 00 c1
|____________________________________________________________
|
| IE:[1c] FACILITY (l=58)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=34):
| [80] Source Entity (l=1) Any_type_PTNX
| [a1] Source Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10258'
| [82] Destination Entity (l=1) Any_type_PTNX
| [a3] Destination Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10212'
| [a1] INVOKE (l=19):
| Invoke Ident. : 1b7d (7037)
| OP: ALCATEL RO_VPN_SYNCHRO (7037)
| [30] Sequence (l=4)
| [03] Bit string (l=2) 00 80
| IE:[1c] FACILITY (l=64)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=34):
| [80] Source Entity (l=1) Any_type_PTNX
| [a1] Source Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10258'
| [82] Destination Entity (l=1) Any_type_PTNX
| [a3] Destination Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10212'
| [8b] Interpretation APDU (l=1): DISCARD (0)
| [a1] INVOKE (l=22):
| Invoke Ident. : 1b6e (7022)
| OP: ALCATEL RO_COMPRESSION (7022)
| [30] Sequence (l=7)
| [03] Compression type (l=2) LIOE_IP_NOT G723
| [02] Nb Compression (l=1) 01
|____________________________________________________________
____________________________________________________________
| (874983:000021) Concatenated-Physical-Event :
| long: 78 desti: 0 source: 224 cryst: 19 cpl: 0 us: 0 term: 0 type a5
| tei: 0 >>>> message received : FACILITY [62] Call ref : 00 c1
|____________________________________________________________
|
| IE:[1c] FACILITY (l=58)
| [91] Discriminator of supplementary service applications
| [aa] NFE (l=34):
| [80] Source Entity (l=1) Any_type_PTNX
| [a1] Source Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10258'
| [82] Destination Entity (l=1) Any_type_PTNX
| [a3] Destination Entity address (l=12)
| [a5] Party Number (private) (l=10)
| [0a] Type of num (l=1) 00
| [12] Num (l=5) '10212'
| [a1] INVOKE (l=19):
| Invoke Ident. : 1b7d (7037)
| OP: ALCATEL RO_VPN_SYNCHRO (7037)
| [30] Sequence (l=4)
| [03] Bit string (l=2) 00 00
|____________________________________________________________
____________________________________________________________
| (874983:000023) Concatenated-Physical-Event :
| long: 23 desti: 0 source: 230 cryst: 19 cpl: 0 us: 0 term: 0 type a5
| tei: 0 >>>> message received : RELEASE [4d] Call ref : 00 c1
|____________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
|____________________________________________________________
____________________________________________________________
| (874983:000024) 1187: Send_IO1 (link-nbr=0, sapi=0, tei=0) :
| long: 23 desti: 0 source: 11 cryst: 19 cpl: 0 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : REL COMP [5a] Call ref : 80 c1
|____________________________________________________________
|
| IE:[08] CAUSE (l=3) 80 90 80 -> [90] NORMAL CALL CLEARING
|____________________________________________________________
Видно что номер приходит, но до абонента почему то не доходит.
IE:[6c] CALLING_NUMBER (l=12) -> 21 81 Num : 4957874500
| IE:[70] CALLED_NUMBER (l=9) -> 80 Num : 70122203
Уже голову себе сломал.
Может кто чего подскажет?
14.08.2017 16:25:10, Aleksandr M.]]>
Гибридный линк настроен по IP. Звонки. Транзит. Всё работает.
Не получается сделать кнопку супервижен на аппарат другой станции. В префиксах нетворк номером прописанl.
В инцидентах пишет Cnnisd:
Cmisd connection problenm
Netw. mgmt unrechable nidre
От чего не читается НОД? Скпротаж всё красиво рисует.
06.06.2017 11:57:53, JKS.]]>
Ситуация такая! есть центральный узел, к нему по Hybrid link' у подключаются побочные ноды (около 20)
Пытаюсь настроить очередной узел, по аналогии с остальными, Гибридный узел подниматься отказывается.
Вроде как все манипуляции проделывал по несколько раз, удалял, создавал по новой с обеих сторон, но проблема остается, туннельный адрес не пингуется!!, линк в down.
Помогите кто чем сможет, спасибо!
28.12.2016 15:34:17, Juventiec.]]>
Здравствуйте. Не могу разобраться в простой вроде проблеме. Она заключается в следующем. Решил на сети станций, подключенных по ABC-F "причесать" пустые(свободные) номера и для целей статистики выделить к примеру 13-ю connect category в которой проставил все нолики. На основной (транзитной) OXE с 11-м релизом все работает как надо, при звонке с внутренней нумерации на номер с 13-й коннект категорией станция проговаривает , что "доступ к услуге невозможен" и при звонке из города этот номер не звонит. А вот например на если позвонить на другие OXE где я повесил на пустые номера с 13-й категорией (отредактированную с одними нулями) то эти номера звонят, и из города на него можно позвонить. Проверил категорию ABC-F линка, стоит по дефолту 18 Trunk Categ, в которой стоит 5-я connect cat. В настройках 13-й concat естественно нолик стоит. Вот и не пойму, это транзитная OXE не смотрит на коннект категорию на нижестоящих OXE или те не так работают. В сетке зоопарк от 3-го до 11-го релизов.
09.12.2016 09:32:35, fedoseevka.]]>
При вводе команды bascul на релизах, начиная с 9.0, отваливаются временно линки, причём trkstat 2000 показывает все каналы свободными, а в suproutage линки не поднимаются минут 15.В чём может быть причина?
В релизе 6.0, кажется, такого не встречал. Может что-то я начал криво настраивать?
23.11.2015 15:46:42, JKS.]]>
Куча станций связана ABCF-линками по потокам E1.
Столкнулся с непонятным инцидентом, на работу станций вроде не влияет, но неприятное ощущение остаётся.
На одном линке по порядку выскакивыют три инцидента:
2813=PH: incident X25: diag=18052
2839=PH:PLL 0 is down on access (указан один из потоков соединения между станциями, всегда один и тот же)
3770=Func.Err.T=1
секунд через 10 пишет, что доступен.
Методом замены каналов и проводов, определилась сторона и плата. Замена её ни к чему не привела.
Не подскажете, с чем можетт быть связана данная ситуация?
27.07.2015 13:34:10, JKS.]]>
Добрый день, коллеги.
Сколько динамических линков можно включить в один узел R11 (AS)? И в какой ТС это описано? А то ни в Product Limits, ни в обычной доке я этого не нашел.
Помню, в одной из старых тем упоминалось 4 для кристалла и 8 для AS.
01.10.2014 11:14:08, Seller_V.]]>
Добрый день.
Включаю новый узлы в сеть ABC-F. Поднимаю статический гибридный линк, делаю cleanbroad по сети. После этого в X25/Nodes of the network должны появиться все узлы сети? И как скоро?
Просто у меня не появляются даже иногда после аудита с ближайшего узла.
Какова правильная процедура?
19.08.2014 22:46:39, Seller_V.]]>
Здравствуйте, коллеги. Подскажите, в чём может быть проблема:
2 АТС Alcatel OXE соединены в сеть. В качестве канала связи – Е1.
На АТС1 есть несколько аналоговых абонентов. Работают нормально. Все исходящие, входящие вызовы из города и внутри АТС успешны. При входящих звонках от абонента АТС2 – сброс примерно после секунды тона КПВ. Транзитные звонки город – АТС2 (автооператор) – абонент АТС1 успешны.
Звонки на остальные полторы тысячи абонентов АТС1 с АТС2 успешны. На тех абонентов, о которых идёт речь, звонки с АТС2 тоже сначала проходили успешно.
Перезагрузка порта или платы не помогает, звонки с АТС2 восстанавливаются только после удаления пользователя и создания его вновь на том же порту с теми же настройками.
В АТС1 перед отправкой disconnect в сторону АТС2 в терминал вываливается следующий лог ошибки:
(669344:000020) Application-exception no 14, thd 1006, PC=network_partner(int, string40 &, string40 &, unsigned char), eqt=1080, serv=0
(669344:000021) * Backtrace: 0x08b7eca2:146271394 EBP 0x0183664c --> init_ptaff_Deur(int, string40 &, string40 &, unsigned char) (+966) 37%
(669344:000022) * Backtrace: 0x08c48e58:147099224 EBP 0x01836ac8 --> init_nom_appelant(int, evenement, uastring40 &) (+432) 72%
(669344:000023) * Backtrace: 0x08c49150:147099984 EBP 0x01836bd0 --> init_message_super(short, AAABS_abpqmcdu_TA1D, AAABS_abpqmcdu_TA1D, int, evenement, unsigned char) (+416) 21%
(669344:000024) * Backtrace: 0x08c4a701:147105537 EBP 0x01836d8c --> send_evt_super(short, short, int, evenement, unsigned char) (+357) 39%
(669344:000025) * Backtrace: 0x08c4ac97:147106967 EBP 0x01836df0 --> chtousup(short, int, short) (+207) 95%
(669344:000026) * Backtrace: 0x08c4b33f:147108671 EBP 0x01836e18 --> su_mono_normal(short, int) (+87) 83%
(669344:000027) * Backtrace: 0x08c4b46b:147108971 EBP 0x01836e38 --> su_nomul(short) (+283) 74%
(669344:000028) * Backtrace: 0x08a4f24d:145027661 EBP 0x01836e58 --> sonloc_again(void) (+317) 78%
(669344:000029) * Backtrace: 0x08a4f2dd:145027805 EBP 0x01836e68 --> sui_sonloc(void) (+57) 95%
(669344:000030) * Backtrace: 0x08a4f347:145027911 EBP 0x01836e70 --> av_sonloc(void) (+103) 95%
(669344:000031) * Backtrace: 0x08a4f3ce:145028046 EBP 0x01836e90 --> sonloc(unsigned char) (+130) 98%
(669344:000032) * Backtrace: 0x08a4f3da:145028058 EBP 0x01836e9c --> sonloc(void) (+10) 83%
(669344:000033) * Backtrace: 0x08a4f3f5:145028085 EBP 0x01836ea8 --> sonloc_rpo(void) (+25) 89%
(669344:000034) * Backtrace: 0x093b0761:154863457 EBP 0x01836eb0 --> real_main (+2613) 83%
(669344:000035) GS=00000000 FS=00000000 ES=0000002b DS=0000002b
(669344:000036) EDI=01836522 ESI=01836646 EBP=0183664c ESP0=00000000
(669344:000037) EBX=00000014 EDX=018364e0 ECX=206f6e20 EAX=00000000
(669344:000038) EIP=083af61b CS=00000023 ESP3=01836540 EFLAGS=00010212
(669344:000039) B(38286:001) Eqt=01080 Emi=02709 {32002, 00039, 0x8a4f3dc} wait=0x000000,0x000000
(669344:000040) B(38286:002) Eqt=02709 Emi=00000 {00000, 05903, 0x8874220} wait=0x000000,0x000000
(669344:000041) B(38246:009) Eqt=02709 Emi=02709 {00000, 00002, 0x87a2b64} wait=0x8870af0,0x8843324
(669344:000042) B(38246:011) Eqt=02709 Emi=01954 {32004, 00108, 0x88432a8} wait=0x883b9e4,0x8843324
(669344:000043) B(37982:018) Eqt=01954 Emi=02709 {32004, 05898, 0x89c83dc} wait=0x89c9354,0x875f268
(669344:000044) Restarting at PC=real_main, with stack=0x01837ff8:25395192
Можно ли его как-то интерпретировать? eqt 1080 - телефон, на который делаем вызов.
23.07.2014 13:24:28, Константин Антонов.]]>
Здравствуйте. Я в недоумении.
Смотрю номерной план центральной станции в ABCF звезде, и вижу, что примерно два десятка номеров встречаются дважды (как локальный внутр. номер и Speed Dial, как Network Number и SD, как SD и другой SD). Как так могло выйти? Какие грабли будут при аудите?
25.06.2014 18:41:21, Seller_V.]]>
Упал Hybrid Link на одной из АТС в сети.
На АТС до этого ни чего ни делал, конфигурацию не менял.
Даже не подходил.
hybvisu all
Mon Jun 2 11:34:06 MSK 2014
List of hybrid links of node 23
Hybrid link 2000 (2300) to node 0 (PERMANENT)
---------------------------------------------
List of accesses
+----+---------------------------------+-------------------------+-----+
| | Main signalling support | Stby signalling support | Nb |
| Nb | GPA State Position Support | GPA State Support | trk |
+----+---------------------------------+-------------------------+-----+
| 1 | ON DOWN (19, 0, 0) IP | | 0 |
+----+---------------------------------+-------------------------+-----+
oxe_cs1> lookvpn -test
Mon Jun 2 11:36:08 MSK 2014
***************************************************************************
VPN is ALLOWED
* nodes 0 -- 23 (netw 7 -- netw 7) cost 1 mandatory q0 : Y q1 : Y
Checking trunk groups corresponding to local hop to node 0 ( 0 -- 23)
+ Trunk group 99 : name = CA state : FREE
trk_type T2 next_trk_grp = -1 variant ISDN
nb_chif_uti = 0 specificity : IP
x25 ok. vpnRate = 100 immTrkForVpn = 1
Public NPD 9 Incoming DID -1
Private NPD 0 Incoming DID -1
WARNING : another NPD can be used (depends on the byte3 of the called number)
Verify which NPD is used on arrival with looknumin
***************************************************************************
Table of vpn numbers for the local node
Index | State | Eqt<-> | NPD | VPN Local Nber | Ext.Transl. | VPN DDI Nber |SDA trad.
_____ | _____ | ______ | ___ | _______________|_____________|______________|_________
0 | Free | None | 49 | 70239999 | 70239999,+/+0364,/,23 | 70239999,+/+0364,/,23 | -1
_____ | _____ | ______ | ___ | _______________|_____________|______________|_________
***************************************************************************
External Call Back Translator Tables
1) beginning_of_number = DEF nb_digits_to_suppr = 0 number_to_add = 98
***************************************************************************
Table of distant vpn numbers
70009999 Tsl_Distant_VPN_Number RLN 99
---------------------------------------
Rout List ARS 99
1) trk_grp=99 nb_deleted_digits=0 inserted_digits = vpnCostLimit=0 (ie. 70009999)
***************************************************************************
Value of VPN synchronisation timer --> T_VPN_SYNCHRO = 300
***************************************************************************
(23)oxe_cs1> lookvpn -config
Mon Jun 2 11:36:40 MSK 2014
***************************************************************************
Hops tables
* nodes 0 -- 23 (netw 7 -- netw 7) cost 1 mandatory q0:Y q1:Y, ip G729
***************************************************************************
Table of vpn numbers for the local node
Index | State | Eqt<-> | NPD | VPN Local Nber (VPN system boolean is set)
_____ | _____ | ______ | ___ | _______________ (VPN software protection is set)
0 | Free | None | 49 | 70239999 (installation's number : )
_____ | _____ | ______ | ___ | _______________
***************************************************************************
DDI Translation Tables
EXT = 7023999903645 --> INT = 70239999
***************************************************************************
External Call Back Translator Tables
1) beginning_of_number = DEF nb_digits_to_suppr = 0 number_to_add = 98
***************************************************************************
Table of distant vpn numbers
70009999 Tsl_Distant_VPN_Number RLN 99
---------------------------------------
Rout List ARS 99
1) trk_grp=99 nb_deleted_digits=0 inserted_digits = vpnCostLimit=0
--> trunk group 99: local TG ;
| name = CA state : FREE
| trk_type T2 next_trk_grp = -1 variant ISDN
| network_number = 7 B_chanel_choice = 1 network_mode = 0
| nb_chif_uti = 0 x25used = 1 specificity : IP
| vpnRate = 100 vpnCostLimit = 0 immTrkForVpn = 1
| ip_qual_prof = Profile #1 compression_type = G729
| H323 gateway board = INTIPA (2-1-0)
| -> 32 compressors enabled
| -> IPv4 : 7.23.0.18
Станции друг друга пингуют.
конфигурация как у всех АТС в сети.
Где рыть, что смотреть ещё?
02.06.2014 14:30:53, Aleksandr M.]]>
Имеется такая схема город----OXE2(R10.0-j1.410-49-a-ru-c7)---стык ABCF по E1---OXE3
ОХЕ3 пока в дауне, сдох блок питания.Проблема вот в чем.Если позвонить из города (хоть с мобилы хоть с фиксы) на нумерацию упавшей ОХЕ3, то будет идти КПВ, вместо занятости.Так раньше и было , когда на охе2 стоял софт 7.1. Если падал поток на охе3, то при звонке на ее нумерацию из города было занято, а мобилка вроде писала сеть недоступна .Осенью я обновил эту транзитную охе2 до десятой версии.Теперь идет кпв вместо занятости.на ОХЕ2 прописано звонить на ОХe3 как routing number.Соответсвенно , если удалить его, тогда начинает вроде работать как надо, при звонках с фиксы, но с мобилки опсос голосом говорит- неправильно набран номер.Но это и понятно, так как в трассировке 2-я нода при удалении роутингового префикса на нумерацию 3-й ноды отсылает cause invalid number.Подскажите пожалуйста где подкрутить настройки, чтобы при падении линка ABC-F на конечные станции 2-я нода(она же транзитная) отдавала в город правильный cause вместо КПВ при входящих звонках из города на нумерацию упавшей станции (типа destination out of order)?Если набирать на OXE2 не через город а по внутрянке OXE-OXE , то как и обычно, рисуется NETWORK LINK O/S на дисплее цифровика. Спасибо.
Ниже трасссировка входящего звонка с мобилки на OXE3, которая полностью выключена (сдох БП в WM1), при этом идет КПВ
============================================================
(102)xa001002> mtracer -a 890xxxxxxxx
Traces Analyser activated
mtracer started ...
(986834:000001) MTRACER host (, xa001002), version: R10.0-j1.410-49-a-ru-c7
(986834:000001) MTRACER num: 090, time: 2014/05/22 21:47:48, loss: 0%
____________________________________________________________
| (986896:000002) Concatenated-Physical-Event :
| long: 53 desti: 0 source: 0 cryst: 3 cpl: 15 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP [05] Call ref : 44 33
| X SENDING COMPLETE
|____________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 83 -> T2 : B channel 3 exclusive
| IE:[6c] CALLING_NUMBER (l=13) -> 00 81 Num : 890xxxxxxxx
| IE:[70] CALLED_NUMBER (l=7) -> c1 Num : 4XXXXX
|____________________________________________________________
____________________________________________________________
| (986896:000003) 1094: Send_IO1 (link-nbr=0, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 3 cpl: 15 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CALL PROC (02) Call ref : c4 33
|____________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 83 -> T2 : B channel 3 exclusive
|____________________________________________________________
____________________________________________________________
| (986896:000004) 1094: Send_IO1 (link-nbr=0, sapi=0, tei=0) :
| long: 22 desti: 0 source: 15 cryst: 3 cpl: 15 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : ALERT (01) Call ref : c4 33
|____________________________________________________________
|
| IE:[1e] PROGRESS_ID (l=2) 81 88
|____________________________________________________________
23.05.2014 01:37:31, fedoseevka.]]>
Здравствуйте!
Небольшая предыстория: есть два узла (номера 3 и 7). ПО на них разное, на 3-м версия релиза 11, на 7-м - версия 10. Насколько я понял из обсуждаемых на форуме вопросов, проблем в части синхронизации основных настроек возникнуть не должно. На 3-м узле наиболее полная информация о сети (наибольшее число пользователей, большая масса префиксов, в т.ч. с других узлов сети). Узел 7 обслуживает небольшую область. Он внедрялся последним. Подрядчики (по их словам), во время установки столкнулись с какими-то сложностями из-за включенного броадкаста (то ли где-то, на другом узле, отвалился доступ в город, то ли еще что - внятно они объяснить не смогли). В результате броадкаст они выключили. Аудит тоже не проводили, а для того чтобы можно было звонить например на узел 3, создали Routing номера, типа "номера начинающиеся с 11, 12, 13, 14 звони на узел 3, он разберется". После этого (уже во время эксплуатации станций нами) на обоих узлах добавлялись/удалялись абоненты, изменялись другие параметры. В общем, в результате конфигурации на станциях полностью не соответствуют друг другу. И всё бы ничего, но однажды я со своей трубкой DECT прибыл в область 7-го узла и выяснил, что моя трубка не работает несмотря на правильные настройки в части PARI/PLI. Насколько я понял, это связано с тем, что нет моего Network номера на станции 7, смотрящего на узел 3 (домашний узел для моего телефона). В общем, с учетом этого, да и вообще с целью как-то упорядочить картину, было решено провести аудит.
С темой Аудит документации ознакомился. В голове много неясностей. Для начала решил опробовать режим симуляции. Аудит запустил на 7-м узле и первое что вызвало у меня сомнения - вопрос насчет Reference node.
1. Станция предлагает Reference building in the local node или Reference downloading over the network.
Поясните пожалуйста что здесь имеется в виду. Насколько я понял, что если я хочу, чтобы информация с 3-го узла заполнила локальную базу, то "опорный" (reference) узел должен быть 3-й. Так? Т.е. в этом вопросе я выбираю вариант 3?
2. Далее доходим до стадии выбора объектов. Часть объектов обозначены *, часть данного обозначения не имеет. Правильно ли я понял, что синхронизации будут подвергнуты именно те, что со звездой? Почему-то не удается изменить данный перечень. Например, объект 1 Numbering Plan по умолчанию без звезды. Я хочу ее добавить. Указываю в диалоге 1, но звезда не появляется. Аналогично, если хочу где-то снять *.
Можно ли править выбор объектов по умолчанию и как это сделать?
3. Непонятна и следующая стадия: Global Network или Only one node. Выбрал Only one node, понимая, что хочу данные брать только с удаленного узла 3, а не со всех оставшихся узлов сети.
4. При следующем выборе узла пробовал указывать 7 (помня, что ранее выбрал 3), но получал нулевой результат. После выбора в данном пункте 3 получил кое-какие данные, которые опять не вызвали вопросы.
Вот, например, кусок
2401 : automatic insertion
25 : automatic update
31 : automatic update
32 : automatic update
22 : automatic update
26 : defined as a routing prefix on node 7
18722 : automatic insertion
1290 : automatic insertion
1193 : automatic deletion
Правильно ли я понимаю, что на локальном узле (7), после поступления информации с узла 3 будут выполнены: автоматическое создание префикса 2401,1290,..., обновлены 25, 31, 32 и т.д., автоматически удален 1193, а префикс 26 в связи с конфликтом нужно будет править вручную?
Спасибо большое!
13.04.2014 13:48:50, Vladimir Shushkov.]]>