Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru
Не соответствия в протоколах - могут быть (всякие fast Start и т.п.)
Несоответствия кодеков - стоит устранять - для начала включите "мультиалгоритм для компрессоров" на стороне ОХЕ.
То, что задействуются разные платы - это нормально. Неоднократно писал - есть сигнализация - идет по той плате что указана в транковой группе, есть RTP (голос) - здесь могут задействоваться разные платы.
08.07.2016 08:48:26, vad.]]>
При звонке на ВКС действительно не вижу в t3 сообщения CONNECT, несмотря на то, что сниффер, запущенный в сети показывает, что Connect приходит
____________________________________________________________
| (725527:000699) 1059: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 110 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 1e 2d
|____________________________________________________________
|
| [9f] Non-locking shift. codeset : 7
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7
| IE:[05] EI_IP_INFOS (l=9) -> G723 Ece 1 Vad 1 Profil 2, IPv4 :10.69.133.26.
| [9f] Non-locking shift. codeset : 7
| IE:[07] EI_IP_QOS (l=3) b8 a0 00
| [9f] Non-locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=30)
| -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0
| -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96
| -> Port RTP = 32668, IPv4 : 10. 197. 133. 14.
| -> Port RTCP SR = 32669, IPv4 : 10. 197. 133. 14.
| -> Port RTCP RR = 32669, IPv4 : 10. 197. 133. 14.
| -> Port Fax = 32668, IPv4 : 10. 197. 133. 14.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a8 83 81 -> T2 : No B channel
| IE:[28] DISPLAY (l=11) `SHUSHKOV V.`
| IE:[6c] CALLING_NUMBER (l=6) -> 01 81 Num : 1473
| IE:[70] CALLED_NUMBER (l=2) -> 81 Num : 1
| IE:[7d] HLC (l=2) 91 81
|____________________________________________________________
____________________________________________________________
| (725528:000701) Concatenated-Physical-Event :
| long: 21 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP ACK [0d] Call ref : 9e 2d
|____________________________________________________________
|
| IE:[18] CHANNEL (l=1) a8 -> T2 : No B channel
|____________________________________________________________
(725528:000702) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
____________________________________________________________
| (725528:000703) 1059: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 24 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : INFORMATION [7b] Call ref : 1e 2d
|____________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=4) -> 81 Num : 570
|____________________________________________________________
____________________________________________________________
| (725529:000705) Concatenated-Physical-Event :
| long: 23 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 9e 2d
|____________________________________________________________
|
| [97] Locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=2)
| -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
| -> Transm_Bande=0 detection_Q23=1
|____________________________________________________________
(725529:000706) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(725529:000707) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
____________________________________________________________
| (725546:000713) 1059: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 22 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 1e 2d
|____________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________
Здесь отметил для себя следующую странность - пакет со станции отправляется с первой платы INTIP, т.е. с адреса 10.197.133.13. Именно эта плата привязана с IP транк-группе. Тем не менее в теле SETUP сообщения периодически всплывает адрес 2-й платы INTIP, а иногда первой. Такое чувство, что станция чередует платы. Нормально ли это?? Согласно сниферу Connect приходит всегда на адрес первой платы. Вот только почему станция его не видит?
Следующий момент. На терминал с Netmeeting звонок уходит и связь нормально устанавливается. Вот вывод t3
____________________________________________________________
| (730116:000044) 1059: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 110 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : SETUP [05] Call ref : 1e 37
|____________________________________________________________
|
| [9f] Non-locking shift. codeset : 7
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7
| IE:[05] EI_IP_INFOS (l=9) -> G723 Ece 1 Vad 1 Profil 2, IPv4 :10.5.128.208.
| [9f] Non-locking shift. codeset : 7
| IE:[07] EI_IP_QOS (l=3) b8 a0 00
| [9f] Non-locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=30)
| -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0
| -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96
| -> Port RTP = 32572, IPv4 : 10. 197. 133. 14.
| -> Port RTCP SR = 32573, IPv4 : 10. 197. 133. 14.
| -> Port RTCP RR = 32573, IPv4 : 10. 197. 133. 14.
| -> Port Fax = 32572, IPv4 : 10. 197. 133. 14.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a8 83 81 -> T2 : No B channel
| IE:[28] DISPLAY (l=11) `SHUSHKOV V.`
| IE:[6c] CALLING_NUMBER (l=6) -> 01 81 Num : 1473
| IE:[70] CALLED_NUMBER (l=2) -> 81 Num : 1
| IE:[7d] HLC (l=2) 91 81
|____________________________________________________________
____________________________________________________________
| (730117:000046) Concatenated-Physical-Event :
| long: 21 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP ACK [0d] Call ref : 9e 37
|____________________________________________________________
|
| IE:[18] CHANNEL (l=1) a8 -> T2 : No B channel
|____________________________________________________________
(730117:000047) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
____________________________________________________________
| (730117:000048) 1059: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 24 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : INFORMATION [7b] Call ref : 1e 37
|____________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=4) -> 81 Num : 571
|____________________________________________________________
____________________________________________________________
| (730119:000050) Concatenated-Physical-Event :
| long: 23 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 9e 37
|____________________________________________________________
|
| [97] Locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=2)
| -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
| -> Transm_Bande=0 detection_Q23=1
|____________________________________________________________
(730119:000051) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730119:000052) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000056) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000057) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000058) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000059) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000060) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000061) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000062) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000063) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000064) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000065) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000066) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730167:000067) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
____________________________________________________________
| (730170:000068) Concatenated-Physical-Event :
| long: 45 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CONNECT (07) Call ref : 9e 37
|____________________________________________________________
|
| IE:[28] DISPLAY (l=17) `Vladimir Shushkov`
| [97] Locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G723 Ece 0 Vad 0
| IE:[0a] EI_RTP_INFO (l=2)
| -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
| -> Transm_Bande=0 detection_Q23=1
|____________________________________________________________
____________________________________________________________
| (730170:000069) Concatenated-Physical-Event :
| long: 54 desti: 0 source: 0 cryst: 0 cpl: 17 us: 0 term: 0 type a5
| tei: 0 >>>> message received : FACILITY [62] Call ref : 9e 37
|____________________________________________________________
|
| [97] Locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G723 Ece 0 Vad 0
| IE:[0a] EI_RTP_INFO (l=30)
| -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
| -> Transm_Bande=0 detection_Q23=1
| -> Port RTP = 49580, IPv4 : 10. 5. 128. 208.
| -> Port RTCP SR = 49581, IPv4 : 10. 5. 128. 208.
| -> Port RTCP RR = 49581, IPv4 : 10. 5. 128. 208.
| -> Port Fax = 0, IPv4 : 0. 0. 0. 0.
|____________________________________________________________
(730170:000070) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730170:000071) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
(730170:000072) CPL_CPU_MSG_DEBUG_CPL ipcSend error: -7
____________________________________________________________
| (730170:000073) 1059: Send_IO1 (link-nbr=17, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 0 cpl: 17 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CONNECT ACK (0f) Call ref : 1e 37
|____________________________________________________________
Здесь также фигурирует адрес 2-й платы, но тем не менее связь нормально устанавливается. Голосовые пакеты уже ходят между NM и 2-й платой, тогда как сами контрольные сообщения задействуют 1-ю плату.
Есть подозрения на несовместимость кодеков. В сообщениях SETUP ясно видно, что станция пытается использоваться кодек G723, который не поддерживается терминалом ВКС. В его настройках есть выбор между G711, G729, G722 и G728. Мне казалось логичной картина, когда несогласование по кодекам должно просто препятствовать установлению соединения. Может ли несогласование кодеков приводить в указанной картине, когда станция не принимает CONNECT?
Есть ли еще какие-то варианты, почему станция может не видеть CONNECTа? Может формат или версия не те?
Спасибо!
06.07.2016 20:16:34, Vladimir Shushkov.]]>
Окончательно запутался в проблеме после небольшого исследования.
Видимо проблема носит комплексный характер.
Во-первых, дополню немного картину. На самом деле на УАТС установлено 2 INTIP платы.
Транк-группа 300 типа IP с префиксом захвата C300 используется как для построения гибридных линков с другими УАТС, так и для моих испытаний с ВКС.
Во-вторых, ГК в настройках по умолчанию был установлен режим роутера для Q931 и H245. Изменил на Direct Mode (не знаю, критично ли это). В-третьих, для эксперимента поднял еще на своем ПК Netmeeting с регистрацией на указанном ГК.
Использую следующую адресацию:
10.197.133.13 - INTIP1
10.197.133.14 - INTIP2
10.69.133.57 - ГК
10.69.133.26 - терминал ВКС
10.5.128.208 - Netmeeting (NM)
Телефонные номера:
1473 - номер на УАТС
1570 - номер ВКС
1571 - номер NM
На УАТС настроил 2 ячейки сокращенного набора на терминал ВКС и на машину с NM.
+-Review/Modify: Direct SpdDl No. Pref.------------------------------------------------------------------+
| X |
| Node Number (reserved) : 3 X |
| Instance (reserved) : 1 X |
| Instance (reserved) : 1 X |
| Direct Speed Dial No. Prefix : 1570 X |
| X |
| Call Number : C3001570 X |
| Directory name : 1570 X |
| Directory First Name : -------------------- X |
| UTF-8 Directory Name : ------------------------------------------- |
| UTF-8 Directory First Name : ------------------------------------------- |
| Call Restrictions - Barring + False X |
| Overfl.Dir.Spd Dl.No. Pref. : -------- X |
| Auto.Attendant Calling Right : 0 X |
| Call Type + IP X |
| Timed Forward.Dir.Spd.Dl.No. : -------- X |
| Range Number : 255 X |
| Can be Called/Dialed By Name + YES X |
| Displayed Name : VKS1 X |
| External DISA Dir.No. : -------- X |
| Phone book Name (Dial by name) : VKS1 X |
| Phone book First Name : -------- X |
| IP Address : 10.69.133.26 X |
| X |
+--------------------------------------------------------------------------------------------------------+
+-Review/Modify: Direct SpdDl No. Pref.------------------------------------------------------------------+
| X |
| Node Number (reserved) : 3 X |
| Instance (reserved) : 1 X |
| Instance (reserved) : 1 X |
| Direct Speed Dial No. Prefix : 1571 X |
| X |
| Call Number : C3001571 X |
| Directory name : VKS2 X |
| Directory First Name : -------------------- X |
| UTF-8 Directory Name : ------------------------------------------- |
| UTF-8 Directory First Name : ------------------------------------------- |
| Call Restrictions - Barring + False X |
| Overfl.Dir.Spd Dl.No. Pref. : -------- X |
| Auto.Attendant Calling Right : 0 X |
| Call Type + IP X |
| Timed Forward.Dir.Spd.Dl.No. : -------- X |
| Range Number : 255 X |
| Can be Called/Dialed By Name + YES X |
| Displayed Name : VKS2 X |
| External DISA Dir.No. : -------- X |
| Phone book Name (Dial by name) : VKS2 X |
| Phone book First Name : -------- X |
| IP Address : 10.5.128.208 X |
| X |
+--------------------------------------------------------------------------------------------------------+
06.07.2016 20:04:24, Vladimir Shushkov.]]>
Если у вас гейткипер не только для резолвинга номеров в адреса возможно будет интересно на станции настроить работу VoIP через гейткипер.
Тут правда могут быть нюансы если VoIP плата одна, а звонить надо не только на вкс.
По поводу звонков - Н323 хорошо смотрится трассировкой t3 - там практически ISDN вид. Если у вас продолжается КПВ при вызове вкс - с той стороны не приходит Connect скорее всего.
04.07.2016 06:52:13, vad.]]>
Vad спасибо большое за развернутый ответ. Певрый блин комом. На УАТС прописал speed dial префикс для одного из клиентов вкс. Клиент представляет собой подобие писюка. Ip задан статически. Клиент настроен на регистрацию своего номера в гк вкс. В этой конфигурации звонок со станции не проходит, получаю сигнал занято. Проверил netmeeting ом - тоже отбой. Снифер показал, что после установления соединения клиент посылает admission request на гк и гк отвечает admission reject. Видимо на гк нужно прописывать станцию в качестве клиента.
Попробовал на клиенте указать работу без гк. Звонок с netmeeting на ip клиента проходит нормально. Со станции какая-то странность, звонок идёт, на клиенте вкс снимаю трубку, вижу на клиенте что связь установлена, но на телефоне продолжается установление связи - длинные гудки.
01.07.2016 16:46:08, Vladimir Shushkov.]]>
Поэтому в вашем случае для звонков туда - можете просто создать Н323 транковую группу и ячейки сокращенного набора IP. Естественно отправляем не на адрес гейткипера, а на адрес шлюза в вкс. Обычно это разные адреса (например в станции ОХЕ - гейткипером был бы адрес процессора, а адресом IP шлюза является адрес VoIP платы).
01.07.2016 14:09:50, vad.]]>
Первое - в общем (не трогая нюансы) - гейткипер ни имеет особого отношения к организации собственно IP вызовов. Это просто устройство, которое знает какой номер (например телефон) каким IP адресом на данный момент обладает. Нужен тогда - когда у вас например внешние IP устройства, на которые надо звонить - это какой-то софт, стоящий на компах, получающих IP адрес по DHCP (динамически).
Для звонков между ВКС и станцией особого смысла для станции в нем нет.
Поясню на примере.
Работаем без гейткипера:
- создаем Н323 транковую группу;
- для звонков на другие устройства (вкс, другие IP станции) - создаем ячейки с типом IP, где указываем IP адрес устройста.
Работаем с гейткипером:
- указываем IP адрес гейткипера;
- создаем транковую группу Н323;
- в VoIP плате указываем номер гейткипера - привязываем к ней Е164 лист (говорим какие номера живут у нас - мы будем регистрироваться на гейткипере);
- звоним через ячейки сокращенного набора обычные (не IP).
В первом случае звонки отправляются на указанный адрес, во втором - сначала станция спросит у гейткипера на какой IP адрес надо звонить, а потом сама туда позвонит.
Гейткипер на станции нужен - если им хотим пользоваться, а другого нет. Сторонние гейткиперы (сервер/софт) удобнее, там кроме автоматической регистрации - можно прописывать ручками у каких абонентов какие адреса, какими кодеками предпочтительней пользоваться.
01.07.2016 14:05:44, vad.]]>
Здравствуйте!
Помогите пожалуйста в следующем вопросе. К сожалению, не силен в настройках УАТС, поэтому уповаю на вашу помощь. Задача следующая. Имеется УАТС oxe с 11м релизом и лицензиями на h323 транк. Имеется система аудио видеоконференции Radvision работающая на базе h323. Система вкс в настоящий момент изолирована, все клиенты локальны. Поставлена задача связать УАТС и вкс таким образом чтобы при звонке из УАТС на заданные номера вызов проходил в вкс на заданных абонентов.
В составе вкс имеется gatekeeper. В настройках можно прописать шлюз и другой гейткипер.
Хочу поинтересоваться об общем порядке настройки данной схемы. Сам вижу так:
1. На УАТС создать speed dial префиксы типа ip с адресом гейткипер вкс.
2. На гейткипере прописать новый шлюз для заданного диапазона адресов.
Есть сомнения по поводу настройки УАТС в качестве шлюза.не нужно ли на ней поднимать тоже гейткипер?
Поправьте пожалуйста меня если я ошибаюсь с общим порядком или вы видите более правильный вариант.
Спасибо!
01.07.2016 13:45:57, Vladimir Shushkov.]]>