По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! На IP-телефонах Cisco, которые зарегистрированы на Cisco Unified Communications Manager (CUCM) , можно просматривать статусные сообщения о состоянии телефона и сетевую статистику в реальном времени. Эта информация доступна с самого телефона и может быть полезна при траблшутинге системы.
/p>
Для доступа к статусным сообщениям нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и затем нажать Status Messages (Сообщения о состоянии). Сообщение отображается вместе со временем его появления.
Сообщение Описание
BootP server used Информационное сообщение, телефон получил IP адрес через BootP сервер, а не через DHCP сервер
File auth error Произошла ошибка, когда телефон пытался проверить подписанный файл. Это сообщение содержит имя файла, с которым возникла проблема. Вероятная проблема – файл поврежден, необходимо удалить и добавить заново телефон через Cisco Unified Communications Manager Administration tool. Либо это проблема с CTL файлом и в этом случае нужно запустить CTL клиент и обновить CTL файл, убедившись, что в него включены необходимые TFTP серверы.
CFG file not found Именной файл конфигурации и файл конфигурации по умолчанию не был найден на TFTP сервере. Файл конфигурации для определенного телефона создается при добавлении телефона в базу данных CUCM. Если телефон не был добавлен в базу данных, то TFTP-сервер генерирует ответ CFG File Not Found.
CFG TFTP Size Error Конфигурационный файл слишком большой для файловой системы телефона. Нужно перезагрузить телефон.
Checksum Error Скачанный файл ПО поврежден. Необходимо скачать новую копию файла прошивки телефона и поместить его в каталог TFTP.
DHCP timeout DHCP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DHCP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DHCP сервер (проверить его конфигурацию).
DNS timeout DNS сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DNS сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DNS сервер (проверить его конфигурацию).
DNS unknown host DNS не смог разрешить имя TFTP сервера или CUCM. Необходимо убедиться, что имена хостов TFTP сервера или CUCM настроены правильно в DNS или использовать IP-адреса вместо имен хостов.
Duplicate IP Другое устройство уже использует IP адрес, который присвоен телефону. Если телефону присвоен статический адрес, то нужно проверить, что ни у какого другого устройства нет такого же адреса, а если используется DHCP, то следует проверить конфигурацию DHCP сервера.
Error update locale Один или более файлов локализаций не был найден в директории TFTP или файл оказался не валидным, и локализация не была изменена. Необходимо убедиться что следующие файлы находятся в поддиректориях TFTP сервера: tones.xml, glyphs.xml, dictionary.xml, kate.xml
IP address released Телефон остается в режиме ожидания пока не включится питание или пока DHCP адрес не будет сброшен.
Load ID incorrect Load ID программного обеспечения неправильного типа. Нужно проверить Load ID, назначенный телефону (во вкладке Device - Phone) и убедиться, что он введен правильно.
Load rejected HC Загруженное приложение несовместимо с аппаратным обеспечением телефона. Эта ошибка возникает, когда происходит попытка установить на телефоне версию ПО, которое не поддерживает аппаратные изменения на этом телефоне.
No default router В DHCP или статической конфигурации не указан default router. Если телефон имеет статические адреса, то необходимо проверить что default router был указан, а если используется DHCP, то нужно проверить его конфигурацию.
No DNS server IP В DHCP или статической конфигурации не указан адрес DNS сервер. Нужно проверить что он указан на телефоне или на DHCP сервера.
Programming error Произошла ошибка во время программирования телефона. Нужно попробовать перезагрузить телефон и если проблема не устранится, то обратиться в службу техподдержки Cisco.
XmlDefault.cnf.xml, or .cnf.xml corresponding to the phone device name Информационное сообщение с указанием имени конфигурационного файла.
TFTP access error TFTP сервер указывает на директорию, которая не существует. Необходимо проверить что у DHCP сервера или телефона правильно указан адрес TFTP.
TFTP file not found Запрашиваемый файл (.bin) не найден в директории TFTP. Нужно проверить, что Load ID присвоен телефону (во вкладке Device - Phone) и что директория TFTTP сервера содержит .bin файл с этим идентификатором загрузки в качестве имени.
TFTP server not authorized Указанный TFTP-сервер не может быть найден в CTL телефона. Это может быть по нескольким причинам: DHCP-сервер настроен неправильно и не обслуживает правильный адрес сервера TFTP, если телефон использует статический IP-адрес, телефон может быть настроен с неправильным адресом сервера TFTP или если адрес сервера TFTP верен, может возникнуть проблема с файлом CTL (в этом случае нужно запустить CTL клиент и обновить CTL файл).
TFTP timeout TFTP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между TFTP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам TFTP сервер (проверить его конфигурацию).
Теперь рассмотрим меню сетевой статистики. Чтобы попасть в него нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и Netwkork Statistics (Статистика сети).
Там можно увидеть следующие поля
Поле Описание
Rcv (Rx Frames) Количество пакетов, полученных телефоном
Xmt Frames (Tx Frames) Количество пакетов, отправленных телефоном
REr (Rx Broadcasts) Количество broadcast пакетов, полученных телефонном
BCast Количество broadcast пакетов, отправленных телефонном
Phone Initialized Сколько времени прошло с момента инициализации телефона
Elapsed Time Сколько времени прошло с момента перезагрузки телефона
Port 1 Состояние PC порта телефона (скорость и дуплекс)
Port 2 Состояние Network порта
Мы продолжаем постигать основы важнейшего протокола, использующегося в IP телефонии и в сегодняшней статье рассмотрим основные сценарии установления соединения, а также работу основных компонентов протокола SIP. Протокол SIP имеет 3 стандартных сценария установления соединения, которые отличаются наличием и участием тех или и иных устройств.
Пример №1
Установление соединения между User Agent’ами, когда в сети отсутствуют всякого рода серверы. Простейшим примером является сеанс связи, в котором принимают участие только два пользователя. Терминальное оконечное оборудование называется UA (User Agent), когда одновременно совмещает в себе функции UAС (User Agent Client) - клиента и UAS (User Agent Server) - сервера. В данном случае сценарий установления соединения будет выглядеть так: .
Абонент A снимает телефонную трубку и набирает номер Абонента B, тем самым генерируя запрос INVITE , который содержит описание сеанса связи.
Устройство абонента B отвечает сообщением 100 Trying , которое означает, что запрос находится в обработке.
После обработки запроса устройство абонента B уведомляет его о входящем вызове, а в сторону абонента A отвечает сообщением 180 Ringing, что соответствует контролю посылки вызова.
Абонент B снимает телефонную трубку, отвечая сообщением 200 OK, означающее успешную обработку запроса.
Устройство абонента A прекращает прием контроля посылки вызова и посылает подтверждение ACK, означающее прием ответа на запрос INVITE.
Между абонентами устанавливается разговорная фаза. Происходит передача голосового трафика по протоколу RTP (Real-Time Transfer Protocol).
Важно отметить, что SIP не участвует в непосредственной передаче голоса, а лишь предоставляет условия и способы согласования открытия неких каналов обмена на основе других протоколов, в данном случае - RTP.
Абонент A кладет телефонную трубку, тем самым инициируя завершение передачи голосового потока. Устройство абонента A генерирует запрос Bye, в сторону устройства абонента B.
Устройство абонента B отвечает сообщением 200 OK, означающем успешную обработку запроса Bye.
Терминальное оконечное оборудование абонентов A и B возвращается в исходное состояние.
Однако, данный сценарий установления соединения является самым примитивным, можно даже сказать частным. Обычно в сети присутствует SIP прокси сервер, который принимает и обрабатывает запросы от пользователей и выполняет, соответствующие этим запросам, действия.
Пример №2
Рассмотрим сценарий установления соединения между двумя пользователями.
В данном случае задачу поиска и приглашения абонента выполняет Прокси сервер, вызывающему пользователю необходимо знать только постоянный номер вызываемого абонента. Отметим, что функции прокси сервера выполняет офисная телефонная станция
Как видно из рисунка, процесс установления и разъединения соединения происходит аналогично первому сценарию, только в качестве посредника при передаче сообщений протокола SIP выступает SIP Proxy.
Пример №3
Допустим, что в сети имеется множество пользователей, число которых постоянно пополняется. Они могут менять свое фактическое положение, ставить переадресацию (redirection) на другой номер, проводить конференц – звонки и др. Для предоставления подобных сервисов требуется наличие в сети соответствующих серверов, поддерживающих ту или иную функцию.
Сервер регистрации (Registration Server) для аутентификации и авторизации пользователей.
Сервер определения местоположения (Allocation Server) для определения реального местонахождения пользователей.
Сервер переадресации (Redirect Server) для перенаправления звонков на другие номера, в случае если пользователь настроил данную функцию.
Сервер регистрации это логический элемент и обычно его функции выполняет SIP Proxy, такие совмещенные сервера называют Registar. SIP Proxy может также выполнять функции серверов определения местоположения и переадресации, такое совмещение полезно в плане масштабируемости сети.
Приведем пример, когда сеть содержит некий комбинированный SIP Proxy, который поддерживает все функции, описанные выше. Допустим, что новый, еще не зарегистрированный пользователь A,вызывает пользователя B, который уже прошел процедуру авторизации.
Новый User Agent A посылает серверу сообщение REGISTER , которое инициирует процесс регистрации.
Т.к User Agent A ещё не зарегистрирован, то сервер Registar отвечает сообщением 401 Unauthorized
Тогда User Agent A посылает серверу сообщение REGISTER + login, содержащее логин и пароль.
Сервер Registar отвечает сообщением 200 OK, на этом процесс регистрации закончен. Теперь пользователь А авторизован на сервере и может совершать звонки.
User Agent A инициирует установление связи с пользователем B сообщением INVITE.
На данном этапе включаются функции серверов определения местоположения и переадресации, сервер отвечает сообщением 302 Moved Temporarily, означающее, что вызываемый абонент временно сменил местоположение и содержащее его новые данные для установления соединения.
User Agent A отвечает сообщением ACK, которое означает прием ответа от Redirect сервера на запрос INVITE.
Далее User Agent A инициирует новое установление соединения напрямую к пользователю B, в соответствии с полученными данными.
Как видно из рисунка дальнейший процесс соединения происходит аналогично сценарию 1.
В следующей статье мы подробно рассмотрим основные модификации протокола SIP для взаимодействия с традиционными телефонными сетями, использующими сигнализацию ОКС-7.
В предыдущей статье мы рассмотрели необходимость перераспределения маршрутов, а также рассмотрели некоторые примеры конфигурации. Эта статья основана на предыдущей конфигурации и рассматривает возможность фильтрации маршрутов с помощью карт маршрутов.
В частности, в предыдущем примере показано взаимное перераспределение маршрутов между EIGRP и OSPF, где все маршруты были перераспределены между двумя автономными системами. Однако некоторые сценарии проектирования могут потребовать, чтобы мы предотвратили перераспределение каждого отдельного маршрута. Один из способов сделать эту фильтрацию - использовать карту маршрутов.
Для справки, вот топология, с которой мы работаем:
Кроме того, с нашей текущей конфигурацией перераспределения маршрутов таблица IP-маршрутизации на роутере OFF1 выглядит следующим образом:
Скажем, по какой-то причине мы не хотим, чтобы сеть 192.168.2.0 /24 была перераспределена из EIGRP в OSPF. Один из способов сделать эту фильтрацию - использовать карту маршрутов, которая ссылается на список управления доступом (ACL).
Во-первых, давайте перейдем к роутеру CENTR и создадим ACL, который соответствует сети, которую мы хотим отфильтровать.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config) access-list 1 permit 192.168.2.0 0.0.0.255
Обратите внимание на использование ключевого слова permit в ACL. В этом контексте слово permit одно из ключевых среди match, notallow. Далее мы будем ссылаться на этот ACL в карте маршрутов, и это карта маршрутов, расскажет, что мы хотим запретить этой сети быть перераспределенной. Вот как мы можем создать эту карту маршрута:
CENTR (config)# route-map LAB deny 10
CENTR (config-route-map) # match ip address 1
CENTR (config-route-map) #exit
CENTR (config)# route-map LAB permit 20
CENTR (config-route-map) exit
CENTR (config)#
Обратите внимание, что у нас есть два оператора route-map с порядковыми номерами 10 и 20. Как и в ACL, route-map обрабатываются сверху вниз. В этом примере мы хотим запретить сеть 192.168.2.0 / 24 с порядковым номером 10. Затем, чтобы разрешить перераспределение всего остального трафика, мы создаем инструкцию route-map с порядковым номером 20. Обратите внимание, что в отличие от предыдущего оператора route-map (который содержал ключевое слово deny), этот оператор route-map содержит ключевое слово permit. В результате, без необходимости указывать условие соответствия, мы сопоставляем (и разрешаем) все остальные маршруты.
Далее, давайте применим нашу карту маршрута к команде redistribute в нашем процессе маршрутизации OSPF на роутере CENTR. В настоящее время команда redistribute для процесса маршрутизации OSPF выглядит следующим образом: edistribute eigrp 1 metric-type 1 subnets
То, что мы хотим сделать - это переписать эту команду, добавив ссылку на нашу недавно созданную карту маршрутов.
CENTR (config)# router ospf 1
CENTR (config-router)# redistribute eigrp 1 metric-type 1 subnets route-map LAB
CENTR (config-router)#end
CENTR#
Теперь давайте вернемся к роутеру OFF1 и посмотрим, исчезла ли сеть 192.168.2.0/24 из таблицы IP-маршрутизации.
Все отлично! Маршрут 192.168.2.0/24 был успешно отфильтрован. В следующей статье мы рассмотрим, как можно устранить неполадки с перераспределением маршрутов.