Коллеги, удалось-таки добиться чтобы Cisco C40 слал G711A кодек. Оказалось настройка этого режима производится через экспериментальные настройки специальной API командой. Но, к сожалению, проблему это не решило. Теперь и станция и Cisco C40 договариваются об использовании G711A, но как и прежде в большинстве случаев, когда снимаешь трубку со стороны Cisco C40 при звонке с УАТС на станции продолжаются КПВ, тогда как Cisco считает, что канал уже установлен.
Говорю "в большинстве случаев", так как при непрерывных попытках совершения звонков со стороны УАТС, примерно в 10% вызов все-таки устанавливается двусторонний. Какой-то зависимости, когда это происходит выявить не удалось.
При запуске t3 в случае неуспеха станция не обнаруживает сообщение CONNECT, тогда как сниффер Wireshark показывает наличие этого пакета. Вот вывод t3 при неуспехе:
Убедился, что с наличием двух INTIP плат это не связано (проверял, отправляя в перезагрузку одну из плат и убеждался, что при оставшейся одной рабочей проблема сохраняется).
На коммутаторе, куда подключена Cisco C40, настроил мониторный порт и стал исследовать проблему глубже, путем анализа пакетов в Wireshark.
Удалось выяснить следующую закономерность. Вероятнее всего проблема не связана с форматом самого CONNECT пакета. После получения CONNECT станция и Cisco обмениваются еще несколькими служебными пакетами типа terminalCapabilitySet, masterSlaveDetermination, openLogicalChannel, а также их подтверждениями - соответствующими Ack пакетами.
В случае успешного вызова последовательность пакетов имеет вид
В случае неуспеха -
Как видно из приведенных скриншотов, почему-то происходит объединение нескольких TCP сегментов в 1. Очень похоже на TCP Offload. Причем, можно заметить, что объединение происходит с обеих сторон, т.е. УАТС тоже причастна к преступлению. В этом случае, при дальнейшем разборе последовательности пакетов видно, как Cisco начинает слать RTP поток, а станция перидически отвечает ICMP пакетом Destination unreachable - Port Unreachable.
Username пишет: Смысл зацикливаться на alaw to ulaw conversion? Из приведенного описания видно, что C40 поддерживает:
•G.711 •G.722 •G.722.1 •G.729AB •64 kbps and 128 kbps AAC-LD, mono and stereo
Может это для Cisco C60. Вот, например, по другой ссылке G729 нет.
Тем более, что УАТС отправляет 3 кодека в SETUP - G723, G729, G711.
Насчет G722 в документации написано, что этот кодек поддерживается не в полном режиме. Точно не помню, но вроде как только для Endpoint. Поправьте если я не прав.
О проблеме выбора платы INTIP и кодеках, В сообщений SETUP указан адрес соседней платы, изменить типа кодека
error пишет: сигнализация ДА т.е. с 10.0.0.1 (если 0-13 имеет это IP)
так в том-то и дело, что почему-то несмотря на то, что доступ прописан для платы 0-13, по факту в SETUP идет отправка адреса платы 0-17. Почему так может быть?
Цитата
error пишет: Цитата Vladimir Shushkov пишет: Правильно ли я понимаю что речь идет о настройке alaw to ulaw conversion
именно так
а вот по преобразованию A в u подрядчик ответил - цитирую:
Код
A-Law to Mu-law conversion
This attribute allows the 4400 operating in A law to be connected to Mu law switch. This is done with a T1 loop interface (DPT1 board) which converts the voice coding law. All incoming or outgoing T1 calls must go via the DPT1 board.
Procedure:
• Create two T1 CCS trunk groups, looped back one onto the other (cabling of an access on the other),
• Set the Reserved attribute to YES (Shelves/boards/Digital accesses)in one of the digital access of the DPT1,
• Set the T0 Mu Law attribute to YES,
• Manage the numbering so that calls going to or coming from the T1 go through the T1 looped back trunk group (there are different ways and the choice belongs to the installation technician according to the state of the corresponding installation (abbreviated number, DID number...).
The T1 boards correspond to DPT1 for OmniPCX Enterprise and PRA -T1 for OmniPCX Office. In the second case, 2 PRA-T1s are required.
Требуется специальная плата, чтобы это работало.
Т.е. что, реально нужна плата и без нее никак, механизм не заработает?
Спасибо!
О проблеме выбора платы INTIP и кодеках, В сообщений SETUP указан адрес соседней платы, изменить типа кодека
Да в том-то и дело, что Cisco C40 это не какой-то CUCM/CUCME или классический циско роутер, где возможности настройки достаточно гибкие. Здесь все настройки в веб-нитерфейсе - это адрес режим работы (direct или через гейткипер), адрес гейткипера и непосредственно номер телефона самой Cisco C40. Остальные параметры относятся к различным аналоговым портам, имеющимся на борту (всякие коэффициенты усиления и т.д.)
Поэтому убрать мусор настройками циски, видимо, не получится. Остается надеяться на настройки УАТС.
Уважаемый error! Я понимаю, что звонки идут с intip. Вопрос в том, что если в станции две платы intip 0-13 и 0-17, например с ip адресами 10.0.0.1 и 10.0.0.2 соответственно. Когда я создаю ТГ типа IP и добавляю в нее доступ 0-13-0, не должно ли это означать, что в SETUP сообщениях в качестве адреса должен указываться 10.0.0.1? Можно ли это настроить? Или же станция сама случайным образом выбирает адрес какой из плат ей отправить и это никак не настраивается? Даже в этом случае у нас наверное должны были бы светиться вызовы и с платы 0-13 примерно в 50% случаев, но у нас всегда указывается адрес второй платы.
В ссылке, которую Вы дали, есть ссылка на параметр alaw to ulaw. Правильно ли я понимаю что речь идет о настройке alaw to ulaw conversion на которую я уже обращал внимание, но пока не трогал?
Спасибо!
О проблеме выбора платы INTIP и кодеках, В сообщений SETUP указан адрес соседней платы, изменить типа кодека
Имеется следующая проблема - не удается связать по H323 УАТС и аппаратный кодек Cisco C40, к которому по аналогу подключена система аудиоконференцсвязи. На УАТС настройки все выполнил согласно документации - создал ячейку сокращенного набора типа IP, где прописал IP циски, создал транк-группу, привязал ее к незадействованному доступу одной из плат INTIP. При звонке со станции вызов проходит на циску, однако когда на ней (циске) снимаешь трубку, то с точки зрения циски вызов кажется установленным, а на станции продолжает идти КПВ. Иногда, примерно 1 из 10 случаев, соединение устанавливается с двух сторон, но на телефоне УАТС слышны жуткие трески. По трассировкам полученным с помощью t3 видно, что когда не устанавливается двухсторонней связи, на УАТС не приходит CONNECT, однако согласно дампам, собранным Wireshark-ом видно, что CONNECT циска все же отправляет, просто он не распознается станцией по каким-то причинам.
Так как станция по умолчанию работает на кодеке G723, а Cisco C40 поддерживает кодеки G711 и G722, нами выполнены следующие настройки на станции: 1. Включен режим задействования нескольких кодеков Multicompression (раздел документации IP PCX Networks -> Direct RTP in network -> Coding Configuration -> Multi-Algorithms). В результате станция в SETUP сообщений отправляет 2 поддерживаемых кодека – G723 и G729. 2. В созданной для взаимодействия транк-группе на УАТС 150 типа IP указан тип кодека G711.
В результате станция в SETUP отправляет 3 кодека G723, G729, G711.
Подозреваю, что проблема кроется в типе компандирования. Станция работает с A-law. Однако логах циски везде фигурирует u-law. Настроек по изменению u- на A- на циске не нашел (это не роутер, имеется только очень бедный веб-интерфейс).
Обратился в тех.поддержку. Посоветовали включить u- конкретно для доступа, к которому привязана транк-группа. Соответственно в настройке
Код
shelf>board>digital access > Mu Law for BEARER CAP
поставил YES и перезагрузил плату. Никаких положительных сдвигов.
В ходе снятия трассировки, обратил внимание, что в SETUP сообщении, которое посылает станция, указан IP адрес другой INTIP платы, также имеющейся в этой станции и используемой для межстанционного гибридного линка, т.е. созданная ТГ для взаимодействия с циско привязана к доступу 0-13-1, а в SETUP указан IP платы 0-17 (гибридный линк для отказоустойчивости использует два доступа 0-13-0 и 0-17-0).
Соответственно, вопросы: 1. Почему в SETUP отправляется адрес не своей с точки зрения ТГ адрес? Можно ли как-то прибить (закрепить) адрес за ТГ? 2. Действительно ли указанная настройка доступа позволяет задать тип компандирования для доступа, отличный от общего на УАТС? 3. Если поменять глобально тип компандирования на всех узлах с A на u (в курсе, что в Европе он не используется), скажется ли это на качестве связи с ТфОП, к которому подключены по потокам E1?
Уважительно прошу Вашей помощи, так как уже сломал мозг с этой проблемой интеграции.
Большое спасибо!
Интеграция OXE с подсистемой конференц-связи Radvision, Настроить взаимодействие УАТС и ВКС
Здесь отметил для себя следующую странность - пакет со станции отправляется с первой платы INTIP, т.е. с адреса 10.197.133.13. Именно эта плата привязана с IP транк-группе. Тем не менее в теле SETUP сообщения периодически всплывает адрес 2-й платы INTIP, а иногда первой. Такое чувство, что станция чередует платы. Нормально ли это?? Согласно сниферу Connect приходит всегда на адрес первой платы. Вот только почему станция его не видит?
Следующий момент. На терминал с Netmeeting звонок уходит и связь нормально устанавливается. Вот вывод t3
Здесь также фигурирует адрес 2-й платы, но тем не менее связь нормально устанавливается. Голосовые пакеты уже ходят между NM и 2-й платой, тогда как сами контрольные сообщения задействуют 1-ю плату.
Есть подозрения на несовместимость кодеков. В сообщениях SETUP ясно видно, что станция пытается использоваться кодек G723, который не поддерживается терминалом ВКС. В его настройках есть выбор между G711, G729, G722 и G728. Мне казалось логичной картина, когда несогласование по кодекам должно просто препятствовать установлению соединения. Может ли несогласование кодеков приводить в указанной картине, когда станция не принимает CONNECT?
Есть ли еще какие-то варианты, почему станция может не видеть CONNECTа? Может формат или версия не те?
Спасибо!
Интеграция OXE с подсистемой конференц-связи Radvision, Настроить взаимодействие УАТС и ВКС
Окончательно запутался в проблеме после небольшого исследования. Видимо проблема носит комплексный характер. Во-первых, дополню немного картину. На самом деле на УАТС установлено 2 INTIP платы. Транк-группа 300 типа IP с префиксом захвата C300 используется как для построения гибридных линков с другими УАТС, так и для моих испытаний с ВКС. Во-вторых, ГК в настройках по умолчанию был установлен режим роутера для Q931 и H245. Изменил на Direct Mode (не знаю, критично ли это). В-третьих, для эксперимента поднял еще на своем ПК Netmeeting с регистрацией на указанном ГК.
Телефонные номера: 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 | +--------------------------------------------------------------------------------------------------------+
Интеграция OXE с подсистемой конференц-связи Radvision, Настроить взаимодействие УАТС и ВКС
Vad спасибо большое за развернутый ответ. Певрый блин комом. На УАТС прописал speed dial префикс для одного из клиентов вкс. Клиент представляет собой подобие писюка. Ip задан статически. Клиент настроен на регистрацию своего номера в гк вкс. В этой конфигурации звонок со станции не проходит, получаю сигнал занято. Проверил netmeeting ом - тоже отбой. Снифер показал, что после установления соединения клиент посылает admission request на гк и гк отвечает admission reject. Видимо на гк нужно прописывать станцию в качестве клиента. Попробовал на клиенте указать работу без гк. Звонок с netmeeting на ip клиента проходит нормально. Со станции какая-то странность, звонок идёт, на клиенте вкс снимаю трубку, вижу на клиенте что связь установлена, но на телефоне продолжается установление связи - длинные гудки.
Интеграция OXE с подсистемой конференц-связи Radvision, Настроить взаимодействие УАТС и ВКС
Помогите пожалуйста в следующем вопросе. К сожалению, не силен в настройках УАТС, поэтому уповаю на вашу помощь. Задача следующая. Имеется УАТС oxe с 11м релизом и лицензиями на h323 транк. Имеется система аудио видеоконференции Radvision работающая на базе h323. Система вкс в настоящий момент изолирована, все клиенты локальны. Поставлена задача связать УАТС и вкс таким образом чтобы при звонке из УАТС на заданные номера вызов проходил в вкс на заданных абонентов.
В составе вкс имеется gatekeeper. В настройках можно прописать шлюз и другой гейткипер. Хочу поинтересоваться об общем порядке настройки данной схемы. Сам вижу так: 1. На УАТС создать speed dial префиксы типа ip с адресом гейткипер вкс. 2. На гейткипере прописать новый шлюз для заданного диапазона адресов.
Есть сомнения по поводу настройки УАТС в качестве шлюза.не нужно ли на ней поднимать тоже гейткипер?
Поправьте пожалуйста меня если я ошибаюсь с общим порядком или вы видите более правильный вариант.
Уважаемый Vad! Спасибо за отклик! Ошибся с названием устройства. На самом деле приставка называется omnitouch 4125. На телефонном аппарате два варианта настройки разъёма - наушники и гарнитура hands free. По умолчанию установлена наушники. В этом режиме работает динамик и микрофон аппарата в режиме громкой связи. Когда подключаю приставку и оставляю настройки в режиме по умолчанию она естественно не работает так как в режиме громкой связи будут использоваться динамик и микрофон аппарата. При изменении настройки на гарнитуру происходит переключение на внешний разъём и приставка нормально работает. Кнопкой динамик переключить режим не удаётся ни в ходе разговора,ни в оффлайн режиме.
К сожалению, наше руководство не хочет вдаваться в эти технические детали переключения, поэтому постоянно перед конференций приходится договариваться чтобы попасть в кабинет руководства и вручную изменять эту настройку. Кроме того, после возникшей проблемы с микрофоном хотелось хотя бы переключить динамик и микрофон на телефонные однако как это сделать не прерывая связь с учетом того что кнопкой динамик это не сделать, не знаю.
На цифровых и ip аппаратах есть такая настройка в разделе меню-настройки-телефон-разъём. Вопрос-можно ли каким-то образом производить переключение с гарнитуры на наушники удаленно, средствами станции? Можно ли это переключение выполнять на горячую, т.е когда связь уже установлена? Вчера в ходе конференц-связи у руководства полетел микрофон на приставке omnisound, подключенной к цифровику. Вариантов типа подойти, разорвать связь и перенастроить телефон не было. Конференция так и прошла в режиме слушания. Не хотелось бы чтобы это повторилось.
Спасибо!
Получение тикетов о локальных вызовах, Способы получения и ПО
Файл вроде как появляется каждый час. Да, вроде у нашей версии Барсума есть такая возможность (забирать из каталога). Т.е. будем иметь информацию о локальных вызовах с задержкой в 1 час. Лучше, конечно, чем ничего. Подрядчики сообщили, что в новом барсуме имеется некий адаптер (программный) который вытягивает со станции данные тикеты с настраиваемой периодичностью. Чего он вытягивает в этом случае - непонятно, ведь если речь идет о TAX-файлах, то это значит, что этот адаптер также не сможет обеспечить близкую к realtime информацию.
Получение тикетов о локальных вызовах, Способы получения и ПО
Коллеги, спасибо большое за информацию и бурную дискуссию!
Ну, хорошо, тикеты ABC и Local на COM-порт станция не выдает. Встает вопрос как их со станции забрать? Есть ли какие-то программные решения для их вытягивания и обработки кроме Барсума? Вами упоминался такой софт как Комендант. Он это может делать? Барсум уж слишком недешев сейчас. Нам предложили его обновить с версии 7.5 до 10-й с включением опции вытягивания тикетов со станции ну уж очень за неприлично круглую сумму. Спасибо!
На имеющихся станциях OXE типа Crystal используем источники питания Efore Epos Compact и Efore Epos Pomo. Не знаю, использует ли кто-нибудь из Вас подобные решения, но со своей стороны хочу отметить минус - данные устройства не мониторятся по SNMP/Syslog. Считаю, что с учетом наличия единственного источника питания вопрос его мониторинга является достаточно серьезным. Хочу поинтересоваться, какие решения используете Вы? Мониторите ли состояние Ваших систем питания УАТС?
