Проверил сообщения на консоли standby-платы при отключении сетевого линка на основной. Полный вывод приводить не стал, т.к. в основной массе сообщения связаны с перезагрузкой, остановкой сервисов и т.д. В приведенном выводе команду twin давал я сам, до отключения сети на основной плате. Однако следующая команда ioctl cmd UART_OFF была введена не мной.
Код
(1)gu_20> twin
Thu Aug 20 21:11:02 AST 2015
Usage : twin [Redundancy Cpu Enable (y/n)]
Role and CPU positions:
Role of the CPU : STAND BY
CPU position : 20
CPU address : 10.197.133.1
Twin CPU position : 06
Twin CPU address : 10.197.133.2
Redundancy State:
Duplicated configuration : YES
Wished sig. transfer mode : ethernet
Used sig. transfer mode : ethernet
Transmission CPU-CPU : READY
monitel redundancy : READY
memloader redundancy : READY
All applications redundancy : READY
(1)gu_20> ioctl cmd UART_OFF
ioctl cmd UART_OFF
Problem in mailsys : see /DHS3dyn/incid/incpbm file
Problem in mailsys : see /DHS3dyn/incid/incpbm file
Problem in mailsys : see /DHS3dyn/incid/incpbm file
Problem in mailsys : see /DHS3dyn/incid/incpbm file
20/08/15 21:11:41 000001S|000/00/-/---|=1:2347=Reset of stand by CPU
Broadcast message from root Thu Aug 20 21:11:41 2015...
The system is going down for reboot NOW !!
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal Stopping role: /etc/rc.d/rc(1): Stopping role:
[ OK ] Shutting down TEL services : F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
100 S root 1 0 0 69 0 - 263 20:37 ? 00:00:03 init
040 S root 2 1 0 68 0 - 0 20:37 ? 00:00:00 [keventd]
040 S root 3 0 0 78 19 - 0 20:37 ? 00:00:00 [ksoftirqd_CPU0]
040 S root 4 0 0 69 0 - 0 20:37 ? 00:00:00 [kswapd]
040 S root 5 0 0 69 0 - 0 20:37 ? 00:00:00 [bdflush]
040 S root 6 0 0 69 0 - 0 20:37 ? 00:00:00 [kupdated]
040 S root 60 1 0 69 0 - 0 20:37 ? 00:00:00 [khubd]
040 S root 246 1 0 68 0 - 270 20:38 ? 00:00:00 monit -c /etc/monit_oxe.conf -l syslog -d 60
040 D root 377 1 0 60 0 - 0 20:38 ? 00:00:00 [kdb_hpthread]
040 S root 395 1 0 73 0 - 266 20:38 ? 00:00:08 throttled
140 S root 400 1 0 85 -12 - 253 20:38 ? 00:00:00 watchdogd
040 S root 581 1 0 68 0 - 309 20:38 ? 00:00:00 [netadmind]
140 S root 593 1 0 69 0 - 3185 20:38 ? 00:00:00 httpd -DHAVE_PHP5 -DHAVE_PROXY -DHAVE_SSL -DHAVE_ACCESS -DHAVE_ACTIONS -DHAVE_AL
040 S root 602 1 0 69 0 - 288 20:38 ? 00:00:00 syslogd -m 0
140 S root 611 1 0 69 0 - 290 20:38 ? 00:00:00 klogd -k /boot/System.map-2.4.17-ll-dhs3
140 S httpd 620 593 0 69 0 - 3208 20:38 ? 00:00:00 [httpd]
140 S httpd 621 593 0 69 0 - 3208 20:38 ? 00:00:00 [httpd]
040 S daemon 628 1 0 69 0 - 269 20:38 ? 00:00:00 [atd]
140 S root 642 1 0 68 0 - 452 20:38 ? 00:00:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
040 S root 655 1 0 69 0 - 512 20:38 ? 00:00:00 crond
040 S root 675 1 0 99 0 - 0 20:38 ? 00:00:00 [#__svtimer_]
040 D root 676 675 0 98 0 - 0 20:38 ? 00:00:00 [__svtimer__]
040 D root 677 675 0 99 0 - 0 20:38 ? 00:00:00 [__svtimer__]
100 S root 695 1 0 69 0 - 255 20:38 ? 00:00:00 /usr/bin/teedhs3 -f /tmpd/RUNTEL.log -s 10000 -n 4
140 R root 707 1 0 76 -12 - 65945 - 20:38 ? 00:00:00 /DHS3bin/servers/dhs3_init -m -l /tmpd/DHS3-INIT.log -f /DHS3bin/com/DHS3_SCRIPT
100 S mtcl 924 707 0 99 -12 - 68378 20:38 ? 00:00:00 /DHS3bin/servers/cmisd
100 S mtcl 925 707 0 63 -12 - 471 20:38 ? 00:00:00 /DHS3bin/servers/sqlsrv -f
140 S mtcl 927 924 0 63 -12 - 68378 20:38 ? 00:00:00 /DHS3bin/servers/cmisd
040 S mtcl 928 924 0 63 -12 - 68378 20:38 ? 00:00:00 /DHS3bin/servers/cmisd
100 S mtcl 930 707 0 63 -12 - 73528 20:39 ? 00:00:00 /DHS3bin/servers/remad -nolock
100 S mtcl 943 707 0 99 -12 - 68140 20:39 ? 00:00:00 [#mailsys]
140 S mtcl 944 943 0 65 -11 - 68140 20:39 ? 00:00:00 [mailsys]
040 S mtcl 945 943 0 24 -12 - 68140 20:39 ? 00:00:00 [mailsys]
040 S mtcl 946 943 0 65 -10 - 68140 20:39 ? 00:00:00 [mailsys]
040 S mtcl 947 943 0 63 -12 - 68140 20:39 ? 00:00:00 [mailsys]
100 S mtcl 948 707 0 63 -12 - 336 20:39 ? 00:00:00 /DHS3bin/incid/gwLinux
040 S mtcl 952 943 0 65 -11 - 68140 20:39 ? 00:00:00 [mailsys]
040 S mtcl 953 943 0 63 -12 - 68140 20:39 ? 00:00:00 [mailsys]
040 S mtcl 954 943 0 65 -11 - 68140 20:39 ? 00:00:00 [mailsys]
100 S root 1016 707 0 99 -12 - 680 20:39 ? 00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
140 S root 1018 1016 0 63 -12 - 680 20:39 ? 00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
040 S root 1021 1016 0 71 4 - 680 20:39 ? 00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
040 S root 1022 1016 0 71 4 - 680 20:39 ? 00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
040 S root 1027 1016 0 71 4 - 680 20:39 ? 00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
140 S root 1036 1 0 99 -12 - 0 20:39 ? 00:00:00 [#MONITELmod]
040 S root 1037 1036 0 99 -12 - 0 20:39 ? 00:00:00 [MONITELmod]
040 S root 1038 1 0 88 -12 - 0 20:39 ? 00:00:00 [MONITELmod]
100 S mtcl 1061 707 0 63 -12 - 67927 20:40 ? 00:00:00 /DHS3bin/servers/btracer
100 S mtcl 1062 707 0 63 -12 - 337 20:40 ? 00:00:00 /DHS3bin/servers/blackbox
100 S mtcl 1063 707 0 63 -12 - 949 20:40 ? 00:00:00 /DHS3bin/oneshot/mtcl/mtracer
100 S root 1064 707 0 99 -12 - 350 20:40 ? 00:00:00 [#io2chd]
100 S root 1065 707 0 63 -12 - 67932 20:40 ? 00:00:00 [servapp]
100 S mtcl 1066 707 0 62 -12 - 67965 20:40 ? 00:00:00 /DHS3bin/servers/dectobsproc
040 S root 1075 1064 0 63 -12 - 350 20:40 ? 00:00:00 [io2chd]
040 S root 1076 1064 0 63 -12 - 350 20:40 ? 00:00:00 [io2chd]
000 S root 1077 1 0 99 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 S root 1080 1077 0 85 -6 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 D root 1081 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 D root 1082 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 D root 1083 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 D root 1084 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 D root 1085 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 D root 1086 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 S root 1087 1077 0 86 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 S root 1088 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
040 S root 1089 1077 0 85 -12 - 78163 20:40 ? 00:00:00 /DHS3bin/tel/TEL
100 S mtcl 1098 707 0 99 -12 - 68084 20:40 ? 00:00:00 /DHS3bin/servers/download
100 S root 1099 707 0 99 -12 - 67948 20:40 ? 00:00:00 /DHS3bin/servers/memloader -main
100 S mtcl 1100 707 0 63 -12 - 2414 20:40 ? 00:00:00 /DHS3bin/servers/io1n_mgr -m
100 S root 1101 707 0 99 -12 - 68195 20:40 ? 00:00:00 [#iplink]
100 S root 1102 707 0 99 -12 - 67945 20:40 ? 00:00:00 [#BTlink]
140 S root 1111 1099 0 63 -12 - 67948 20:40 ? 00:00:00 /DHS3bin/servers/memloader -main
140 S mtcl 1112 1098 0 63 -12 - 68084 20:40 ? 00:00:00 /DHS3bin/servers/download
140 S root 1113 1102 0 63 -12 - 67945 20:40 ? 00:00:00 [BTlink]
040 S mtcl 1114 1098 0 63 -12 - 68084 20:40 ? 00:00:00 /DHS3bin/servers/download
140 S root 1115 1101 0 87 -12 - 68195 20:40 ? 00:00:00 [iplink]
040 S root 1117 1101 0 98 -12 - 68195 20:40 ? 00:00:00 [iplink]
040 S mtcl 1120 1098 0 63 -12 - 68084 20:40 ? 00:00:00 /DHS3bin/servers/download
140 S root 1121 1 0 99 -12 - 0 20:40 ? 00:00:00 [#MON25mod]
040 S root 1124 1121 0 80 -12 - 0 20:40 ? 00:00:00 [MON25mod]
040 S root 1125 1 0 81 (020365:000022) Stop all
(020365:000023) SUPERVISOR -- Supervisor_Number=1640 Param0=13 Param1=10121 Param2=68 Param3=-1
(020365:000024) SUPERVISOR -- Stops the applicative actor
(020365:000025) monitel saves blackbox state at shutdown time
20/08/15 21:11:44 000001S|---/--/-/---|=1:2077=CPU was halted due to a shutdown
Thu Aug 20 21:11:43 AST 2015
(020365:000026) ***************************
(020365:000027) ** ACTOR DIS25 SHUTDOWN **
(020365:000028) ***************************
(020365:000029) Thread Appli shutdown
(020365:000030) Thread IPrcv shutdown
(020365:000031) Thread fluxIP shutdown
(020365:000032) Thread AckIP shutdown
(020365:000033) Thread Dis25 shutdown
(020365:000034) ***************************
(020365:000035) ** DEMANDE DE STOP X25 **
(020365:000036) ***************************
Command "IP_LINK" (pid 1101) exited with status 1.
SMART смотрел, но вроде не нашел показателей темературы. Проверю сегодня еще раз...
По поводу внешних датчиков, абсолютно согласен, уже давно начальству говорил о необходимости оборудования серверных такими датчиками. Но, к сожалению, у нас все упирается в организационно-финансовые моменты: "не по проекту", "нет денег по такой-то статье" и т.д. Так что приходится обходиться встроенными в оборудование датчиками.
А насчет hdd не совсем понял. Это что, утилита такая есть?
Сегодня в журнале инцидентов одной из станций обнаружил сообщения о превышении температуры CPU и HDD на обеих платах. Выяснилось, что повышение температуры было связано с отказом блока кондиционера. Сразу возник вопрос, есть ли возможность проактивного мониторинга данной информации. Проверил опрос станции по SNMP всей ветки .1.3.6.1 - к сожалению, ничего похожего на показания температуры не нашел. Следующая надежда - утилиты на самой станции, типа lm-sensors. Тоже ничего.
Подскажите пожалуйста: 1. Может быть есть ли какие-либо утилиты в составе ОС станции, позволяющие производить опрос сенсоров температуры? 2. Если изначально таковых утилит нет, нет ли опыта установки из rpm-пакетов указанного ПО? Насколько мне известно, ОС станции построена на базе Mandrake Linux. Утилита rpm в составе ОС имеется. Наверняка можно подобрать бинарный пакет того же lm-sensors, с помощью которого можно собирать много полезной информации.
Большое спасибо!
Взаимодействие CPU через внешний Ethernet, Странная перезагрузка
Погодите-ка, что-то какая-то путаница в обсуждении началась
Цитата
error пишет: что мы должны указывать на плате INTIP ролевой адрес который при переключении процов скачет с одного интерфейса на другой а конкретном случае в одного коммутатора на другой. в результате чего получаем ролевой адрес дернулся и плата INTIP перезагрузилась
Как вдруг мы с IP адресов CPU переключились на INTIP. Насколько я понимаю, для INTIP понятия ролевого адреса, который кочует с одной платы на другую, не существует. В нашем случае на каждой INTIP висит свой IP адрес intip1 и intip2, доступы обеих плат добавлены в состав одной транк-группы. После умирания одной из плат INTIP в ходе установления вызовов CPU начинает передавать ip адрес второй CPU платы.
Как правильно подметил vad, у нас используются ABCF через гибридные линки с VPN overflow.
Насчет разных ролевых адресов на процессорах внутри одной полки - данная конфигурация кажется очень сомнительной. А с ARP таблицами ситуация кажется не такой страшной: возьмем к примеру роутер, через который станция общается, например, с другими узлами. Изначально в его ARP кэше есть запись, что для адреса ipcpu использовать mac aaaa.aaaa.aaaa. Произошел сбой, работа перешла на второй проц. Теперь адресу ipcpu соответствует mac bbbb.bbbb.bbbb, но на роутере пока еще хранится старая запись. В статической среде конфигурации по умолчанию действительно придется ждать долго (насколько я помню, у cisco по дефолту arp записи хранятся 4 часа). Но, во-первых, arp timeout можно уменьшить минут до 5-10. Во-вторых, в том случае если ip-адресом источнка пакетов уходящих со станции является не реальный адрес CPU, а ролевой, то после первого же полученного от станции пакета маршрутизатор обновит свой arp кэш. Именно это поведение arp таблиц лежит в основе атак Man-in-the-middle. Если же, все-таки ролевой адрес используется только на приеме, а все исходящие пакеты уходят с реального адреса CPU, тогда действительно ситуация не очень хорошая, так как придется выжидать весь таймаут. Нарывались на похожую ситуацию с МСЭ Cisco ASA.
error пишет: правильно это когда два коммутатора собираются в стек для таких целей а по сути получается два коммутатора живут сами по себе c одинаковыми настройками
Не могу согласиться. Конечно, со стеком всегда проще иметь дело, особенно, когда функционала резервирования не заложено в устройство, подключаемое к сети. Однако не всегда есть техническая возможность использования стека. В нашем случае, есть станция и два нестекируемых коммутатора Cisco 6509 без возможности включения VSS (а-ля стек). Функционал подключения к двум коммутаторам описан (хоть и достаточно скудно) в документации. Есть даже картинка, где процессоры и платы разнесены по разным коммутаторам. Соответственно, не стоит отталкиваться от того, что правильно подключать только в стек. В нашей ситуации физически станция подключена правильно, в соответствии с документацией.
Цитата
Андрей пишет: Как выглядит лог перезагрузки резервного процессора, начиная с момента потери им связи с активным процессором ?
Цитата
error пишет: что у вас там показывает excvisu
Не снял эту информацию во время прошлых проверок. В ближайшее время протестирую отработку перехода еще раз и выложу данные сведения.
P.S. Закрались определенные сомнения насчет сигнального линка. Может быть имеет смысл вернуть его на C1? В описании механизма IP Redundancy насторожила фраза что-то вроде того, что когда основной CPU в течение некоторого временного промежутка не видит специальных фреймов от резервного CPU, он дает команду переключения на резерв. Как он дает команду? По какому каналу если сигналинг передается по тому же ethernet?
Нет, на данной станции нет. Но есть еще одна станция, на которой тоже запланировали аналогичные работы. Вот на ней установлена IO2N.
P.S. Обратил внимание, что в netadmin есть возможность настройки ethernet redundancy. В документации описание этого функционала что-то найти не смог. Может нужно включить эту опцию?
Взаимодействие CPU через внешний Ethernet, Странная перезагрузка
Сигналинг включен через Ethernet. Перешли с C1 на Ethernet в связи с тем, что ранее сыпались инциденты о переполнении C1 линка.
Код
Usage : twin [Redundancy Cpu Enable (y/n)]
Role and CPU positions:
Role of the CPU : MAIN
CPU position : 06
CPU address : 10.197.133.2
Twin CPU position : 20
Twin CPU address : 10.197.133.1
Redundancy State:
Duplicated configuration : YES
Wished sig. transfer mode : ethernet
Used sig. transfer mode : ethernet
Transmission CPU-CPU : READY
Telephony redundancy : READY
monitel redundancy : READY
memloader redundancy : READY
All applications redundancy : READY
lanpbxbuild отсутствует
Вывод netadmin -m
Код
Your system has the private network number 0 and the site number 1.
Private IP addressing space: no
Restricted internet accesses: no
Accept ICMP redirect: no
Low dynamic ports range configuration : 10000 - 10499
There is no VLan configuration. No frame will be 802.1q-tagged.
The ethernet redundancy is not supported on this CPU type
node name : node000001
internal name resolver activated : yes
Ethernet interface setup
========================
Netmask : 255.255.255.0
==============================================================================
| Machine type | Local interface | Name | Address |
==============================================================================
| local | Ethernet | gr_06 | 10.197.133.2 |
| local main | Ethernet | gr_main | 10.197.133.3 |
| router | Ethernet | router | 10.197.133.254 |
| local | IP/X25 tunnel | x000001_tun | 172.30.253.1 |
==============================================================================
<return> to continue.
CPU redundancy setup
====================
Netmask : 255.255.255.0
==============================================================================
| Machine type | Local interface | Name | Address |
==============================================================================
| local | Ethernet | gr_20 | 10.197.133.1 |
| local main | Ethernet | gr_main | 10.197.133.3 |
==============================================================================
Только что обратил внимание на строчку в выводе netadmin
Код
The ethernet redundancy is not supported on this CPU type
С целью повышения отказоустойчивости OXE были выполнены работы по настройке/включению IP Redundancy. Первоначально, имеющиеся в составе станции платы CPU7-2 (2шт) и INTIP2 (2шт) были включены в один неуправляемый коммутатор, который являлся единой точкой отказа. В ходе работ было проведено раздельное подключение указанных плат в разные коммутаторы ядра Cisco Catalyst 6509 (CPU7-2 и INTIP в один коммутатор, оставшиеся CPU7-2 и INTIP в другой коммутатор) При этом были выполнены рекомендации документации Alcatel в части отключения embedded Ethernet на платах CPU7-2 с целью корректной отработки Spanning-tree.
Код
(1)gu_06> ethctl
Thresholds configuration :
broadcast frames : disabled.
total frames : disabled.
bandwidth : disabled.
scan interval : 500 (ms).
Embedded Ethernet configuration :
jumper : disabled.
xilinx : enabled.
-> state : disabled.
External Ethernet configuration :
link config : auto.
link state : 100Mb full.
В состав IP транк-группы, используемой для построения ABC туннелей включены ресурсы обеих плат INTIP Включен механизм IP Redundancy
Код
(1)gu_06> cmdcpl 0 13 MNGT
Sat Aug 8 16:46:36 AST 2015
Del to exit tool
You have selected a board with type : INTIPA
execution from 'MNGT'
(00,13)
INTIP Management :
(00,13) - Board is INTIP-A
(00,13)
- Crystal number : 0 (Management)
(00,13) : 255 (given by S400/401 switches)
(00,13) - Coupleur number : 13 (Management)
(00,13) - Recovery Mode : Normal
(00,13)
- @ MAC : 00 : 80 : 9F : 5C : F7 : A9
(00,13) - @ IP : 10.197.133.5
(00,13)
- Voip port : 32512 [7f00]
(00,13)
- Default DSCP : 0x0B
(00,13)
- Ethernet interface is configured to Auto Negociation (Half and Full duplex)
(00,13) - Link state is 100MBps / Full duplex
(00,13)
- IP Redondancy activated
(00,13) - @IP CPU1 : 10:197:133:2
(00,13) - @IP CPU2 : 10:197:133:1
(00,13) - PING emitted every 20 seconds
(00,13) - Traffic check every 3x20 seconds
(00,13)
- Framing G729 = 20ms
(00,13) - Framing G723.1 = 30ms
(00,13) - Framing G711 = 20ms
(00,13) 000000EB-0030CFA9: End of command execution
Normal exit.
Выполнена проверка переключения сервисов телефонии на резервные компоненты при потере связи с коммутаторами ЛВС: 1. При выключении линка между ЛВС и используемой в заданный момент времени платы INTIP происходит разрыв установленных соединений между данной УАТС и другими УАТС Отделения. За достаточно короткое время работа переводится на другую плату INTIP, после чего станция готова к отработке межстанционных вызовов. При этом потеря линка основной платы приводит к ее перезагрузке. До тех пор пока линк не поднят, плата находится в состоянии INIT 1 RUN. Резюме: переключение на резерв осуществляется штатно, в приемлемые временные рамки;
2. При выключении линка между ЛВС и используемой в заданный момент времени процессорной платой CPU7-2 происходит разрыв установленных соединений между данной УАТС и другими УАТС Отделения. При этом, резервный процессор, не видя основную плату, уходит в перезагрузку. Так как перезагрузка CPU выполняется достаточно длительное время (порядка 10-15 минут), в течение всего этого времени недоступны никакие телефонные сервисы. Данное поведение кажется весьма странным.
Подскажите пожалуйста, является ли штатным поведение резервного CPU, при котором он перезагружается при отсутствии связи с основным узлом? Почему этого не происходит при работоспособном embedded Ethernet линке?
На самом деле описанную задачу нужно выполнить на двух станциях. На станциях установлены INTIP2. Одна станция работает на 8-релизе, на плате установлено 2 GIP4-4 дочерних модуля. Вторая станция работает на 11-м релизе, на плате установлен 1 дочерний модуль GIP4-4. Насколько я понял, возможные проблемы могут быть связаны с недостатком кодеков?
Подскажите пожалуйста насчет использования внешнего источника для Music on Hold. Есть задача проигрывания нестандартной мелодии Alcatel на удержании. На вопрос техподдержке относительно конвертации своего wav-файла в moh-файл, понятный УАТС, получил ответ, что делать это можно только с помощью специальной программы, за которую нужно выложить круглую сумму (несколько сотен евро). Было предложено использовать external music. Соответственно имеются следующие вопросы: 1. Действительно ли единственный выход - использование external music, так как без специального софта файл проприетарного формата получить не получится? 2. В документации указано, что external music нужно подавать на 9-й пин платы CPU. Не совсем понятно, куда физически нужно подключить external music, с учетом того, что CPU расшит на CBRMA. Нужно разбирать CBRMA и подключать пару проводов с передаваемым звуком куда-то внутрь CBRMA-бокса? 3. Правильно ли я понимаю, что имея ПК со звуковой платой, на станцию нужно заводить не линейный выход платы, а выход для подключения акустики?
Подскажите пожалуйста, можно ли как-то использовать плату INTIP не имея коннектора 100BaseT для нее? Плата имеется, а вот указанного коннектора, к сожалению, нет. Не знаю, как устроен указанный коннектор, но думается, что если он представляет собой пассивное устройство, то может быть можно в разъем станции вместо указанного коннектора подключить разъем для платы eZ32 (коих в у нас избыток) и далее расшить кабель от этого разъема на сетевую розетку. Знать бы только распиновку разъема для INTIP.
Приношу свои извинения за странный вопрос.
Спасибо!
Использование ресурсов INTIP несколькими транк-группами
Дмитрий, прошу прощения, не очень понял. Т.е. если просто в доступе ABC ТГ прописать 111111111111111000000000000000, а в доступе новой IP H323 ТГ наоборот 000000000000000111111111111111, то по умолчанию это работать не будет? Нужно еще кодеки настраивать?
Использование ресурсов INTIP несколькими транк-группами
Есть OXE с одной INTIP платой, которая используется для связи по ABCF-IP с другими OXE. Все ресурсы (тайм-слоты) платы выделены именно для этой цели. Имеется лицензия на IP транки в кол-ве 30 штук. Т.е в настоящий момент все лицензии уходят на созданную единственную транк-группу.
Появилась задача создания еще одной IP транк-группы. Возможно ли "откусить" заданное кол-во тайм-слотов от ABCF-IP транк группы для создания второй ТГ, чтобы не нарушить лицензионные ограничения? Будут ли работать обе транк-группы в рамках одной платы? Т.е. получается, что чисто гипотетически я могу в рамках текущей лицензии создать 30 IP ТГ по одному тайм слоту?
