- Главная
- /
- Статья
Руководство по развертыванию миграции
Структурированный процесс миграции с локальной версии Cisco Unified CM на облачный Webex Calling с использованием методологии PPDIO. Это связано с важными аспектами проектирования такие как выбор региона, тарифные планы, службы экстренной помощи и запись разговоров. Этот процесс также подробно описывает лицензирование, подготовку пользователей, систему единого входа в систему и готовность сети для обеспечения бесперебойной и бесперебойной работы эффективный переход.
Прежде чем начать
Это руководство предназначено для групп или отдельных лиц, имеющих опыт настройки и администрирования Cisco Unified Communications Manager (Unified CM) и конечных точек Cisco, включая настольные IP-телефоны, видеоустройства и программные клиенты Jabber. В этом документе есть ссылки на справочную документацию по продукту и вспомогательную документацию.
В этом документе основное внимание уделяется переходу только от Unified CM Webex Calling многопользовательской версии к многопользовательской среде. Используемый Webex Callingв этом документе термин всегда относится к Webex Calling многопользовательской среде.
Прежде чем начать переход с Webex Calling версии Unified CM на, необходимо иметь полное представление о Webex Calling решении и его соответствующих компонентах. Для успешной миграции необходимо ознакомиться с Webex Calling архитектурой, моделями обслуживания, вариантами развертывания и сопутствующими функциями, чтобы правильно сопоставить существующие Unified CM рабочие нагрузки и разработать эффективный план перехода.
Тщательное понимание следующих Webex Calling компонентов необходимо для формирования эффективной стратегии перехода и операционной готовности.
-
Центр управления
-
Подготовка каталогов и пользователей
-
Webex Callingплатформа
-
поддерживаемые конечные точки вызова
-
Варианты подключения к PSTN
-
Webex Callingтарифный план и управление номерами
-
Функции безопасности и соответствия требованиям.
Дополнительные сведения см. в разделе Предпочтительная архитектура Cisco дляWebex Calling.
В этом руководстве будут описаны инструменты и процессы, которые следует использовать на протяжении всего переходного периода. Однако переход от локальных звонков к новой облачной платформе для звонков может потребовать значительных усилийWebex Calling, связанных с потенциальными деловыми, техническими и сложными проблемами. Unified CM Чтобы решить эти проблемы, Cisco предлагает несколько различных вариантов, которые помогут вам в вашем путешествии. Важно ознакомиться с информацией в разделе Корпоративные облачные вызовы — миграция звонков и понять, как каждый из них может помочь вам в миграции.
-
Инструменты миграции Webex: бесплатные инструменты самообслуживания, встроенные в Control Hub для упрощения перехода на Webex Calling
-
Сертифицированные поставщики миграции: проверенные Cisco поставщики программного обеспечения и инструментов, разработавшие решения по миграции, помогающие партнерам и клиентам Webex в сложных и крупных миграциях. Эти решения могут помочь упростить, управлять и ускорить переход на Webex Calling
-
Webex Setup Assist: сервис миграции под руководством Cisco, который предоставляет клиентам и партнерам рекомендации по Webex Calling развертыванию и настройке, необходимых для успешного переноса Unified CM пользователей и сервисов в. Webex Calling
Обзор
По мере роста числа облачных сервисов для совместной работы все больше клиентов хотят перенести существующие рабочие нагрузки для совместной работы в облако, учитывая обещания снизить совокупную стоимость владения, упростить управление, непрерывное предоставление функций, увеличить масштабируемость и превосходную надежность, присущие облачным сервисам. Поскольку заказчики хотят перейти с локальных сервисов на облачные сервисы для совместной работы, им важно понять, что влечет за собой переход и какие шаги необходимо предпринять для этого перехода.
Цель этого документа — предоставить рекомендации по развертыванию для клиентов, которые специально хотят перейти с локальной среды на Unified CM Webex Calling облако. В этом руководстве по развертыванию предполагается, что читатель имеет базовое представление о переходе между Unified CM вызовами, в том числе о томWebex Calling, какие изменения произойдут при этом переходе и в чем разница при переносе рабочей нагрузки по вызовам из локальной среды в облако. Прежде чем продолжить, убедитесь, что вы ознакомились с информацией, представленной на карте Transition, и ознакомлены с ней. В этом документе с картой перехода представлена информация об изменениях и отличиях этого перехода.
Как показано на рис. Локальная архитектура совместной работы: управление вызовами и удаленный доступ, типичное локальное развертывание включает в себя различные компоненты инфраструктуры совместной работы в сети, платформу управления вызовами, периферийную платформу, аппаратные и программные конечные точки, а в некоторых случаях даже платформы для конференций и планирования. В архитектуре Cisco это будет включать Unified CM управление вызовами, Expressway для удаленного доступа и периферийных услуг для бизнеса (B2B), сервер собраний Cisco и Cisco Meeting Management для локальных конференций, Unity Connection для голосовых сообщений, а также аппаратное обеспечение для пользователей (телефоны Cisco IP, настольные и комнатные видеосистемы Cisco) и программное обеспечение (Cisco Jabber) конечные точки на основе IP. Эти компоненты могут незначительно отличаться в некоторых средах, но это отправная точка перехода, описанного в остальной части этого документа.
Архитектура, показанная на рис. Локальная архитектура совместной работы: управление вызовами и удаленный доступ, основана на предпочтительной архитектуре (PA) для локальных развертываний Cisco Collaboration Enterprise. Дополнительные сведения о корпоративной локальной среде см. в разделе Предпочтительные архитектуры Cisco для совместной работы.
Ранее: в таблице компонентов локальной инфраструктуры вызовов перечислены ключевые элементы локальной архитектуры до перехода в облако. Webex Calling
| Продукт | Описание |
|---|---|
| Unified CM | Локальное управление вызовами, предоставляющее услуги регистрации устройств и маршрутизации вызовов |
| Cisco Expressway-C/E | Периферийная инфраструктура, обеспечивающая мобильную связь Remote Access (MRA) и бизнес-функции (B2B), позволяющие удаленным конечным точкам безопасно подключаться к удаленным конечным точкам из-за пределов организации. Expressway развертывается попарно, чтобы обеспечить обход внешних конечных точек через брандмауэр . |
| Сервер конференций Cisco (CMS), система управления совещаниями Cisco (CMM) и пакет управления телеприсутствием Cisco (TMS) | Локальная инфраструктура голосовых, видео- и веб-конференций, обеспечивающая многоточечные совещания, управление совещаниями и планирование. [Необязательно] |
| Cisco Unity Connection | Локальная платформа голосовых сообщений, предоставляющая возможности голосовой почты и единой системы обмена сообщениями . [Необязательно] |
| Стол Cisco, зал Cisco, плата Cisco, IP-телефоны Cisco и Cisco Jabber | Устройства на основе IP, зарегистрированные Unified CM и обеспечивающие возможность голосовых и видеозвонков |
Как показано на рисунке «Решение о переходе»: локальные звонки Webex Calling, клиенты, у которых есть локальное управление вызовами с помощью Unified CM настольных и видеоIP-адресов, могут выбрать вариант перехода на облачную архитектуру. Webex Calling
Решение должно быть принято на основе функциональных требований заказчика. Клиентам, предъявляющим следующие требования, следует тщательно обдумать это, прежде чем принимать это решение, и в конечном итоге они могут решить сохранить управление вызовами в локальной среде:
- Модели телефонов, не поддерживаемые Webex Calling
- Сложные или многочисленные интеграции с другими локальными системами или решениями, особенно в тех случаях, когда воспроизвести эти интеграции с ними Webex Calling сложно или нет эквивалентных альтернативных решений
- Сложная телефонная схема, очень детализированные классы обслуживания или и то, и другое
- Ограниченный, ограниченный или ненадежный доступ в Интернет
- Строгие правила конфиденциальности и владения данными
- Соответствие требованиям к записи и хранению медиафайлов локально или в стране
- Интеграция со сторонними организациями без жизнеспособной альтернативной интеграции Webex Calling
- Интеграция контакт-центров, при которой контакт-центр еще не перешел в облако .
Этот документ предназначен для клиентов, использующих Unified CM систему управления вызовами, которые хотят понять общие шаги, соображения и требования, связанные с Webex Calling развертыванием, как описано в следующем разделе.
Основные компоненты
Целевая архитектура этой миграции включает несколько новых компонентов. Сюда входят Webex Calling сервис для облачных звонков, приложение Webex, Cisco Directory Connector для интеграции идентификационных данных и локальный шлюз (LGW) для доступа к PSTN, а также интеграция звонков из локальной среды в облако. Планы Cisco Calling или подключенные к облаку PSTN (CCP), предоставляемые партнером Cloud Connect, являются дополнительными вариантами доступа к PSTN. Webex Calling
Как показано на рисунке после: Webex Calling Архитектура, новые компоненты (коннектор каталоговWebex Calling, локальный шлюз и шлюз Survivability) добавлены в существующее локальное развертывание.
После: в таблице компонентов инфраструктуры облачных вызовов перечислены новые элементы архитектуры после перехода на Webex.
| Продукт | Описание |
|---|---|
| Webex Calling | Облачная служба вызовов, предоставляемая на платформе Webex и обеспечивающая регистрацию конечных точек и маршрутизацию вызовов |
| Коннектор каталогов Cisco | Приложение Windows, работающее на доменном компьютере под управлением Windows, обеспечивает
синхронизацию идентификационных данных между локальным корпоративным хранилищем Active Directory и хранилищем идентификационных данных организации
Webex. Для клиентов, переходящих с локальной среды Active Directory на Entra ID, при интеграции идентификационных данных с Webex вместо Cisco Directory Connector используется приложение Entra ID Wizard. |
| Локальный шлюз | Локальный шлюз служит мостом между локальной сетью унифицированных коммуникаций клиента и облаком. Webex Calling Его можно развернуть локально или разместить у партнера. Он обеспечивает доступ к PSTN для зарегистрированных в облаке конечных точек, а также обеспечивает интеграцию вызовов между Unified CM зарегистрированными конечными точками и конечными точками, зарегистрированными в облаке. Cisco IOSМаршрутизатор с интегрированными сервисами -XE (серии ISR 1100 и 4000), Cisco Catalyst серии 8200/8300, программное обеспечение Cisco Catalyst 8000V Edge и различные сертифицированные сторонние пограничные контроллеры сеансов (SBC) можно использовать в качестве LGW для поэтапной миграции. |
| Шлюз обеспечения отказоустойчивости | Survivability Gateway (SGW) — это шлюз локальной сети на базе IOS-XE, который предоставляет резервные услуги вызова локальным конечным точкам во время сбоев в сети. Webex Calling |
| План звонков Cisco, Cloud Connect для Webex Calling | Cisco Calling Plan и Cloud Connect for Webex Calling — это облачные варианты доступа конечных точек к PSTN. Webex Calling Доступ к PSTN обеспечивается поставщиком облачных PSTN и не требует локального оборудования. |
| Приложение Webex | Клиентское приложение, работающее на настольной ОС (Windows, Mac) или мобильной ОС (Android, iOS) и зарегистрированное непосредственно на платформе для Webex Calling обеспечения функциональности звонков. |
Обзор процесса PPDIO
Процесс PPDIO означает подготовку, планирование, проектирование, внедрение и оптимизацию. Это структурированная методология Cisco, которая направляет проекты от первоначальной оценки до постоянного совершенствования, обеспечивая эффективное и успешное развертывание или миграцию.
Общее описание PPDIO
-
Подготовьтесь: оцените текущую среду, определите требования и объедините усилия заинтересованных сторон для создания прочной основы.
-
План: разработайте подробные планы проекта, включая сроки, ресурсы и стратегии снижения рисков.
-
Проектирование: разработайте целевое решение с учетом деловых и технических потребностей.
-
Внедрение: выполните развертывание или миграцию в соответствии с проектом, подтвердив функциональность и производительность.
-
Оптимизация: непрерывное улучшение решения после внедрения путем мониторинга производительности, уточнения конфигураций и использования инструментов автоматизации и интеграции.
Использование PPDIO для миграции проектов Unified CM Webex Calling
При переходе от Unified CM к Webex Calling процессу PPDIO предоставляется четкая дорожная карта, обеспечивающая плавный и эффективный переход:
Подготовьтесь
-
Оцените существующую Unified CM среду и готовность к миграции
-
Соберите подробные данные о пользователях, устройствах, сети и зависимостях
-
Собирайте сведения о местоположении, включая адрес экстренного реагирования, количество пользователей, доступ в Интернет, доступ к PSTN
-
Определите риски и определите объем проекта, чтобы объединить усилия всех заинтересованных сторон.
Планируйте
-
Создайте комплексный план миграции с расписанием пакетной обработки, распределением ресурсов и сроками
-
Определите такие задачи, как обновление микропрограммного обеспечения устройства, предоставление лицензий и адаптация пользователей
-
Координируйте периоды миграции с Cisco и партнерами, чтобы свести к минимуму перебои в работе .
Проектирование
-
Сопоставьте текущие Unified CM конфигурации, тарифные планы и профили пользователей с Webex Calling эквивалентами
-
Спроектируйте Webex Calling среду, включая стратегию PSTN (промежуточную и окончательную), местоположения, роли пользователей и точки интеграции, такие как локальный шлюз (CUBE) и синхронизация каталогов
-
Спланируйте сценарии сосуществования, предполагающие Unified CM одновременную Webex Calling работу во время миграции.
Внедрите
-
Используйте инструменты миграции Control Hub вместе со сторонними инструментами для изменения режима микропрограммного обеспечения устройства, настройки функций и миграции пользователей
-
Используйте массовые операции и выделение ресурсов с помощью API Webex для оптимизации крупномасштабных миграций и конфигураций
-
Выполните предоставление лицензий, регистрацию устройств и обновление конфигурации
-
Подтвердите успешность миграции с помощью тестирования и операционной проверки.
Оптимизируйте
-
Постоянно контролируйте Webex Calling производительность и пользовательский интерфейс
-
Уточняйте конфигурации и рабочие процессы на основе операционных данных и отзывов
-
Используйте возможности автоматизации и интеграции для повышения эффективности и масштабируемости
-
При необходимости выведите из эксплуатации устаревшие Unified CM компоненты и обеспечьте постоянную поддержку операций второго дня.
Этот усовершенствованный подход PPDIO обеспечивает контролируемую, прозрачную и эффективную миграцию Unified CM на систему с использованием инструментовWebex Calling, API и партнерской экосистемы Cisco для обеспечения непрерывности бизнеса и расширения возможностей совместной работы.
Циклы обратной связи PDIO
Общий обзор, показанный на рисунке «Итерации» при выполнении PPDIO, иллюстрирует единственный цикл обратной связи от фазы оптимизации до фазы подготовки. Это означает, что после первоначального внедрения существует постоянная возможность постоянного улучшения. Каждый цикл оптимизации позволяет выявить новые требования или области, нуждающиеся в улучшении, которые могут быть решены в рамках последующих проектов или инициатив. В свою очередь, каждый из этих отдельных проектов соответствует установленному жизненному циклу PPDIO (подготовка, планирование, проектирование, внедрение, оптимизация). Такой итеративный подход обеспечивает соответствие системы меняющимся бизнес-целям и технологическим достижениям, а также способствует формированию культуры постоянного совершенствования и адаптации.
В ходе выполнения процесса PPDIO результаты, полученные на более поздних этапах, обычно требуют пересмотра и, возможно, пересмотра решений, принятых на более ранних стадиях. Например, проблемы, возникшие на этапе внедрения, такие как выявление неясностей в дизайне или недостающих деталей, могут свидетельствовать о том, что некоторые аспекты не были полностью учтены на этапе проектирования. В таких случаях возникает необходимость вернуться к соответствующему предыдущему этапу, чтобы решить эти проблемы, прежде чем продолжить. Этот итеративный механизм обратной связи, показанный на рисунке Unified CMпри помощи процесса PPDIO, обеспечивает тщательную проверку и доработку решения, что в конечном итоге способствует более надежному и эффективному развертыванию.
При переходе от Unified CM к каждому этапу процесса PPDIO информацияWebex Calling, собранная в существующей среде, может в значительной степени воспользоваться информацией, собранной в существующей Unified CM среде. Например, из текущей Unified CM конфигурации можно извлечь исчерпывающий перечень пользователей, телефонных номеров, функций вызовов и компонентов абонентской группы. Эти данные дополняют информацию, предоставленную непосредственно заинтересованными сторонами, и помогают оптимизировать планирование и проектирование. Использование соответствующих инструментов для автоматизации извлечения и анализа данных не только повышает точность, но и ускоряет весь процесс. Используя результаты существующего развертывания, переход на него Webex Calling можно осуществить более эффективно, чем при традиционном внедрении с нуля, но при этом следует придерживаться структурированной методологии PPDIO. Этот процесс показан на рисунке Unified CM с помощью процесса PPDIO.
Подход к миграции
Планируя переход с локальной среды на локальную среду Unified CMWebex Calling, вам необходимо определить, как вы подойдете к этому путешествию. Сначала вам нужно решить, будет ли миграция осуществляться мгновенно (все сразу) или поэтапно (перенос групп пользователей/устройств в течение длительного периода).
При мгновенной миграции все ваши пользователи и устройства будут перемещены быстрее всего. С помощью этого метода вы переместите всех пользователей и устройства из локальной среды в одно и Unified CM Webex Calling то же время. По сути, это единое окно миграции для всех пользователей и устройств. После завершения миграции все ваши пользователи и устройства будут подключены к Webex Calling платформе, а всю Unified CM инфраструктуру можно будет вывести из эксплуатации. Однако многие организации не могут использовать этот подход из-за масштабов и масштабов развертывания Calling.
Второй подход — поэтапная миграция. Большинство организаций будут использовать этот подход , поскольку он обеспечивает более эффективный контроль, управление и масштабирование по мере миграции. Кроме того, он лучше подходит для крупных развертываний и/или развертываний унифицированных коммуникаций в нескольких регионах. Поэтому в данном документе основное внимание уделяется поэтапному подходу с двумя этапами перехода.
Как показано на рисунке ниже. Поэтапный переход на новые вызовы: гибридные и облачные технологии, первый этап перехода (этап 1) предполагает совместное развертывание со средами двойных вызовов. На этом этапе некоторые пользователи, устройства и программные клиенты переходят на локальную систему управления вызовами, Webex Calling а другие все еще используют Unified CM локальную систему управления вызовами. На заключительном этапе перехода (этап 2) создается полностью облачная среда для звонков, в которой все пользователи, устройства и программные клиенты полностью переведены на платформу. Webex Calling
Время, необходимое организации для полного перехода на облачную связь, зависит от текущего развертывания. В некоторых случаях организация может осуществить первоначальный переход и в течение длительного периода времени (месяцы или даже годы) оставаться в фазе совместного управления вызовами (фаза 1), в то время как в других случаях организация может полностью перейти на Webex Calling (этап 2) за очень короткий период (недели или месяцы). Данный документ призван охватить оба этапа (этап 1 — сосуществование и этап 2 — полный переход).
Вполне возможно, что некоторые организации могут работать по принципу сосуществования и использовать систему двойного управления вызовами на неопределенный срок, не планируя полностью переходить на облачные вызовы.
Второе соображение заключается в том, как вы будете переводить пользователей, устройства и программные клиенты из локального управления вызовами на облачную систему управления вызовами. Рекомендуемый подход — трехэтапный переход . На рисунке «Рекомендуемый трехфазный переход» ниже этот подход разбит на три этапа.
Предварительный перенос: на этом этапе основное внимание уделяется подготовке Webex и Unified CM сред к миграции. Речь идет не о конкретном планировании или конфигурациях, а о выполнении действий, которые можно выполнить сейчас и до начала любого проекта по Webex Calling миграции. Цель состоит в том, чтобы заложить основу этих двух сред для подготовки к миграции.
Подготовка к миграции: на этом этапе начинается подготовка к Webex Calling миграции. Здесь необходимо пересмотреть и обновить деловые и технические требования. Не просто меняйте то, что используется в настоящее время, но Unified CM и пересмотрите деловые и технические требования, которые нужны вашей компании сегодня и в будущем, используя возможности этих технологий. Webex Calling Кроме того, на этом этапе вы завершите проектирование, планирование конфигурации и планирование/график миграции.
Миграция (развертывание и вывод из эксплуатации). На этом этапе происходит фактическая миграция пользователей, устройств, телефонных номеров и программных клиентов. Как указывалось выше, этот этап может быть завершен для всех одновременно (мгновенное отключение) или за несколько периодов изменений (поэтапное отключение). Планы внедрения, обучение и коммуникация для конечных пользователей крайне важны, чтобы ваши пользователи знали об изменениях, о том, как использовать новую платформу для звонков и когда они произойдут. Последний шаг — вывести из эксплуатации всю локальную инфраструктуру унифицированных коммуникаций , которая больше не используется.
На этапе, предшествующем миграции, есть мероприятия (обязательные, рекомендуемые и необязательные), над которыми можно приступить немедленно. Рекомендуется выполнить их раньше, чем позже, желательно до начала проекта. Выполнение некоторых задач может занять больше времени, поэтому их выполнение раньше поможет упростить фактический проект миграции.
На рисунке, приведенном ниже, представлены пять конкретных категорий мероприятий, связанных с Webex Calling миграцией.
Подготовьте
Деловые и технические требования
При планировании перехода с на этап планирования важно тщательно изучить технические и бизнес-требования. Этот шаг обеспечивает соответствие миграции операционным целям и техническим возможностям вашей организации и минимизирует риски и сбои.
Почему сбор требований важен:
-
Соответствует бизнес-целям: понимание потребностей бизнеса помогает адаптировать миграцию к ключевым рабочим процессам, удобству работы пользователей и планам роста.
-
Обеспечивает техническую совместимость: раннее определение технических требований предотвращает проблемы интеграции с существующей инфраструктурой, сетью и конечными точками.
-
Упрощает планирование ресурсов: четкие требования помогают точно оценить сроки, затраты и необходимые ресурсы.
-
Снижает риски: раннее обнаружение потенциальных проблем позволяет принимать упреждающие решения, сокращая время простоя и перерывы в обслуживании.
Требования к бизнесу
Типичные бизнес-требования включают в себя:
-
Количество пользователей и мест, которые необходимо перенести
-
Желаемые функции и сервисы (например, маршрутизация вызовов, голосовая почта, конференц-связь, автосекретари, очереди вызовов)
-
Политики соответствия требованиям и безопасности
-
Бюджетные ограничения и ожидаемые затраты
-
Потребности в обучении и поддержке пользователей
-
Сроки миграции и аспекты обеспечения непрерывности бизнеса.
Сбор необходимых функций и сервисов — важнейший шаг для обеспечения соответствия новой системы потребностям бизнеса. При сборе этих требований важно не только учитывать текущие настройки, но и попытаться собрать фактические требования от коммерческих организаций, которые будут использовать систему. В противном случае существует риск того, что план основан на нетекущих предположениях. Обязательно ознакомьтесь с дополнительными или улучшенными функциями, которые могут отсутствовать в Интернете, например, облачные вызовы, расширенные очереди вызовов и. Это помогает использовать все преимущества облачной платформы.
При оценке текущей конфигурации важно учитывать, что не все существующие настройки могут остаться необходимыми из-за меняющихся требований на протяжении всего жизненного цикла системы. Основное внимание следует уделить выявлению и сохранению только тех конфигураций, которые соответствуют текущим и будущим потребностям развертывания.
Сосредоточьтесь больше на том, что вам нужно, чем на том, что у вас есть.
При переходе на новую облачную коммуникационную систему крайне важно учитывать соблюдение нормативных требований и правил безопасности, Webex Calling чтобы обеспечить соответствие новой облачной коммуникационной системы правовым, нормативным и организационным стандартам.
-
Соответствие нормативным требованиям: организации должны проверять соответствие отраслевым нормам, таким как GDPR, HIPAA или SOX, требованиям конфиденциальности, хранению и обработке данных, а также страновым требованиям в отношении хранения данных, обхода платных дорог и местонахождения СМИ.
-
Безопасность данных: обеспечение шифрования голосовых и сигнальных данных как при передаче, так и при хранении для защиты от перехвата или несанкционированного доступа.
-
Контроль доступа: определение и обеспечение аутентификации пользователей, авторизации и доступа на основе ролей для предотвращения несанкционированного использования коммуникационных ресурсов.
-
Аудит и мониторинг: внедрение средств регистрации и мониторинга для отслеживания доступа и использования в целях аудита соответствия требованиям и расследования инцидентов безопасности.
-
Согласование политик: согласование миграции с существующими корпоративными политиками безопасности, включая безопасность конечных точек, сегментацию сети и планы реагирования на инциденты.
-
Обеспечение безопасности поставщиков: оценка сертификатов безопасности и сертификатов соответствия Cisco для обеспечения надежности.
Соблюдение этих политик соответствия требованиям и безопасности на этапе планирования помогает снизить риски, избежать судебных санкций и сохранить целостность и конфиденциальность сообщений во время и после миграции.
Потребности в обучении и поддержке пользователей являются важными компонентами перехода от компании к системе, обеспечивающей плавный переход на новую систему и адаптацию пользователей к новым условиям. Ключевые соображения включают в себя следующее:
-
Программы обучения: разработка индивидуальных учебных занятий для различных групп пользователей (конечных пользователей, администраторов, сотрудников службы поддержки) для ознакомления их с функциями, пользовательскими интерфейсами и новыми рабочими процессами.
-
Документация: предоставьте понятные и доступные руководства пользователя, ответы на часто задаваемые вопросы и краткие справочные материалы, включая ресурсы «Что нового и что нового», а также пошаговые инструкции «До» и «После» (в формате видео или краткого руководства), чтобы помочь пользователям адаптироваться к обновленному интерфейсу после миграции.
-
Управление изменениями: заблаговременно сообщайте об изменениях, чтобы оправдать ожидания пользователей и снизить сопротивление.
-
Структура поддержки: создайте специальную группу поддержки или создайте систему эскалации для оперативного решения проблем пользователей во время и после миграции.
-
Непрерывное обучение: планируйте постоянное обновление обучения по мере появления новых функций или обновлений .
-
Механизмы обратной связи: внедрите каналы, позволяющие пользователям сообщать о проблемах и оставлять отзывы для улучшения процессов обучения и поддержки.
Удовлетворение этих потребностей в обучении и поддержке на этапе планирования помогает свести к минимуму перебои, повысить доверие пользователей и максимально использовать преимущества перехода на.
Технические требования
Для успешного перехода на сайт необходимо собрать и задокументировать несколько ключевых технических требований, включая следующие сведения:
-
Готовность сети и пропускная способность
Комплексная оценка сети крайне важна для обеспечения того, чтобы существующая инфраструктура могла поддерживать новую Webex Calling среду. Сюда входят:
-
Анализ полосы пропускания: оценка текущего и прогнозируемого использования полосы пропускания для обработки трафика голосовой связи, видео и данных без перегрузок.
-
Качество обслуживания (QoS): внедрение политик QoS для приоритизации голосового трафика и минимизации задержек, дрожания и потери пакетов.
-
Подключение к глобальной сети и Интернету: проверка соответствия каналов WAN и подключений к Интернету требованиям для облачных вызовов, включая возможности резервирования и аварийного переключения.
-
Настройка брандмауэра и NAT: обеспечение того, чтобы настройки брандмауэра и NAT разрешали передачу необходимых сигналов и медиатрафика.
-
-
Интеграция с существующей системой
Полная интеграция с существующими бизнес-системами необходима для удобства пользователей и непрерывности рабочего процесса:
-
Службы каталогов: оценка интеграции с корпоративным каталогом для автоматической подготовки и аутентификации пользователей.
-
CRM и бизнес-приложения: определение точек интеграции с системами управления взаимоотношениями с клиентами и другими критически важными для бизнеса приложениями.
-
Взаимодействие устаревших АТС: планирование стратегий совместного использования или поэтапной миграции в случае сохранения устаревших телефонных систем во время перехода.
-
-
Совместимость конечных точек и выделение ресурсов
Все конечные точки, включая настольные телефоны, софтфоны и мобильные устройства, должны быть проверены на совместимость:
-
Поддержка устройств: подтверждение поддержки существующих IP-телефонов и устройств или определение необходимых заменителей.
-
Процессы выделения ресурсов: создание автоматизированных или упрощенных методов выделения ресурсов для эффективного подключения конечных точек.
-
Обновления микропрограммного обеспечения и программного обеспечения: планирование необходимых обновлений для обеспечения совместимости и безопасности.
-
-
Конфигурации безопасности и стандарты шифрования
Безопасность имеет первостепенное значение в облачных коммуникациях:
-
Шифрование: комплексное шифрование сигналов и медиапотоков в соответствии с передовыми практиками Cisco в области безопасности.
-
Аутентификация и контроль доступа: внедрение механизмов безопасной аутентификации (таких как SSO, многофакторная аутентификация) и детального контроля доступа пользователей.
-
Соответствие требованиям: обеспечение соответствия решения соответствующим нормативным и отраслевым стандартам (например, GDPR, HIPAA).
-
Мониторинг безопасности: интеграция с инструментами SIEM и настройка оповещений о потенциальных инцидентах безопасности.
-
| Требование | Ключевые соображения |
|---|---|
| Готовность сети и пропускная способность | Пропускная способность, QoS, WAN/Интернет, брандмауэр/NAT |
| Интеграция с существующими системами | Справочник, CRM, АТС, электронная почта/календарь |
| Совместимость конечных точек и выделение ресурсов | Поддержка устройств, выделение ресурсов, обновление микропрограммного обеспечения |
| Конфигурации безопасности и шифрование | Шифрование, аутентификация, соответствие требованиям, мониторинг безопасности |
| Обучение пользователей и управление изменениями | Программы обучения, документация, информирование об изменениях |
| Переносимость номеров и тарифный план | Перенос и перенос номеров, перевод телефонных планов |
| Интеграция со сторонними производителями | Пейджинг, контакт-центр, факс, аналоговые устройства |
Готовность сети и требования
Готовность сети имеет решающее значение для успешного перехода на любое облачное решение для звонков, например. Плохое планирование сети может привести к ухудшению качества звонков, прекращению вызовов и недовольству пользователей. Перед переходом на сеть клиентам необходимо провести оценку сети. Рекомендуется подтвердить доступность полосы пропускания сети для ожидаемого объема вызовов, убедиться в соблюдении требований к качеству обслуживания (QoS) и понять, какие порты необходимо открыть в пограничных брандмауэрах.
Надежное сетевое подключение с достаточным качеством обслуживания (пропускная способность, потеря пакетов, RTT) — это базовое требование для обеспечения наилучшего комплексного пользовательского интерфейса для всех конечных точек, клиентов и приложений, поддерживающих голосовую и видеосвязь.
Клиенты и партнеры могут использовать другие варианты подключения, выходящие за рамки OTT (OTT), которые позволяют оптимизировать подключение, в том числе к Connect. Webex Edge Дополнительные сведения о конструкции Webex Edge Connect см. в разделе Предпочтительная архитектура Cisco для Webex Edge Connect для Webex Meetings многопользовательских вызовов и выделенных инстансов.
Клиенты могут использовать программу CScan для оценки сети, которая позволяет получить информацию о качестве сети клиента, количестве возможных вызовов, задержках и т. д. Дополнительные сведения об инструменте CScan см. в разделе Использование CScan для проверки Webex Calling качества сети.
Чтобы убедиться, что сеть готова к миграции, ознакомьтесь со следующим контрольным списком:
-
Планирование полосы пропускания
Рассчитайте количество одновременных вызовов для каждого сайта, чтобы обеспечить достаточную пропускную способность восходящего и исходящего трафика, а также запас трафика для других критически важных для бизнеса трафика и будущего роста.
В таблице расчета полосы пропускания типов Webex Calling вызовов указаны типы вызовов, доступные при развертывании, а также кодек и максимальная полоса пропускания, необходимая для каждого типа вызова. Как показано в таблице расчета полосы пропускания типов Webex Calling вызовов, требуемую полосу пропускания аудиовызовов для каждого типа вызова можно рассчитать по следующей общей формуле:
Ожидаемое количество одновременных вызовов * Полоса пропускания на один звонок на основе кодека = требуемая пропускная способность сети.
Таблица 2. Webex Calling Расчеты полосы пропускания типа вызова типы звонков Кодек — пропускная способность Расчет полосы пропускания /Настольный телефон -> OPUS — 70 кбит/с Количество одновременных вызовов * 70 кбит/с = требуемая пропускная способность сети /Настольный телефон -> Настольный телефон OPUS — 70 кбит/с Количество одновременных вызовов * 70 кбит/с = требуемая пропускная способность сети /Настольный телефон -> PSTN через LGW G.711 — 80 кбит/с Количество одновременных вызовов * 80 кбит/с = требуемая пропускная способность сети /Настольный телефон -> PSTN через облачный PSTN (например План звонков Cisco) G.711 — 80 кбит/с Количество одновременных вызовов * 80 кбит/с = требуемая пропускная способность сети /Настольный телефон -> Предприятие через LGW G.722 — 80 кбит/с Количество одновременных вызовов * 80 кбит/с = требуемая пропускная способность сети /Настольный телефон -> голосовая почта OPUS — 70 кбит/с Количество одновременных вызовов * 70 кбит/с = требуемая пропускная способность сети Суммируя требуемую одновременно пропускную способность сети для каждого типа вызова, можно определить общую потенциальную потребность в полосе пропускания для конкретного сайта.
Все телефонные линии всегда привязаны к SBC доступа. Чтобы определить требуемую пропускную способность Интернета в любом конкретном месте, необходимо учитывать не только межлокационные вызовы, но и внутрилокальные вызовы, а также звонки на локальный шлюз в этом месте и обратно. Например, для внутрисайтового вызова между двумя телефонами MPP потребуется полнодуплексный доступ в Интернет со скоростью до 2 x 70 кбит/с.
В таблице примеров расчета Webex Calling полосы пропускания показан пример полного расчета полосы пропускания при условии, что все устройства находятся на одном сайте.
Таблица 3. Webex Calling Примеры расчета полосы пропускания типы звонков количество одновременных вызовов Общая пропускная способность Приложение Webex/Настольный телефон → Приложение Webex 15 2* 15* 70 кбит/с = 2100 кбит/с Приложение Webex/Настольный телефон → Настольный телефон 15 2* 15* 70 кбит/с = 2100 кбит/с Приложение Webex/настольный телефон → PSTN через LGW 50 2* 50* 80 кбит/с = 8 000 кбит/с Приложение Webex/настольный телефон → PSTN через Cloud Connect для Webex Calling 0 0* 80 Кбит/с Приложение Webex/настольный телефон → Корпоративный через LGW 15 2* 15* 80 кбит/с = 2400 кбит/с Приложение Webex/настольный телефон → Голосовая почта Webex Calling 5 5* 70 кбит/с = 350 кбит/с Общее количество звонков/пропускная способность 100 звонков 14 950 кбит/с/14,95 Мбит/с -
Все значения полосы пропускания в приведенных выше таблицах относятся к пропускной способности IP. Пропускная способность канала выше в зависимости от инкапсуляций WAN.
-
Полоса пропускания в приведенных выше таблицах предназначена для аудиозвонков. Что касается пропускной способности видеозвонков, приложение Webex и телефоны MPP 8845/65 поддерживают видео H.264 с максимальным разрешением 720p при максимальной пропускной способности 1500 кбит/с на вызов. Однако объем полосы пропускания, потребляемой в любой момент во время вызова, будет колебаться в зависимости от переменной скорости передачи данных, присущей видеосвязи.
-
-
Качество обслуживания (QoS)
Внедрите политики QoS в своей локальной среде, чтобы приоритизировать трафик в реальном времени и обеспечить поддержание QoS на коммутаторах, маршрутизаторах и брандмауэрах.
-
Целевые показатели по задержкам, джиттеру и потере пакетов
Для оптимального качества голоса при звонках по сети OTT и через Интернет рекомендуются следующие пороговые значения:
-
Задержка — менее 100 мс в одну сторону
-
Джиттер — менее 10 мс
-
Потеря пакетов — 0,5% или меньше.
-
-
Межсетевой экран и NAT
Убедитесь, что брандмауэр настроен на пропускание трафика, как указано в статье, доступной в разделе Справочная информация по порту. Webex Calling Кроме того, разрешите доступ к доменам и диапазонам IP-адресов, перечисленным в том же руководстве, и избегайте использования протокола SIP ALG, поскольку он мешает передаче сигналов SIP. Следует избегать медиатрафика через прокси-серверы.
-
DNS и NTP
Обеспечьте надлежащее DNS-разрешение доменов и надежные NTP-серверы для синхронизации часов устройств для проверки и регистрации сертификатов TLS.
-
Планирование аварийного переключения
Рассмотрите существующие подключения поставщиков к данным (MPLS, SD-WAN и т. д.) и, как правило, планируйте прямой доступ в Интернет в каждом месте развертывания. Планируйте использование резервных интернет-каналов там, где требуется высокая доступность. Поскольку вы будете пользоваться облачными сервисами, основным требованием является надежное подключение к Интернету с достаточной пропускной способностью. Вам следует пересмотреть этот переход, если подключение к Интернету в офисах вашей организации, как правило, не отличается надежностью, низкой задержкой и достаточной пропускной способностью входящего и исходящего трафика.
-
Выживаемость сайта
Надежность сайта гарантирует, что ваш бизнес всегда доступен даже в случае разрыва сетевого соединения. Site Survivability использует шлюз в вашей локальной сети для обеспечения резервной службы вызова на локальные конечные точки в ситуациях, когда сетевое соединение прерывается. Если бизнес-требования требуют постоянных звонков в случае сбоя в сети , оцените возможность обеспечения отказоустойчивости сайта с помощью локального шлюза SGW. Дополнительные сведения о проверке работоспособности сайта см. в разделе «Надежность сайта» для. Webex Calling
Настройте унифицированную связь с облаком
Cloud Connected UC (CCUC) — это облачное решение для управления и аналитики, предназначенное для централизованного мониторинга, администрирования и анализа развертываний как в локальной среде (например), так и в облаке (). Unified CM Оно служит связующим звеном между традиционными локальными средами и облачными сервисами Cisco, оказывая поддержку организациям на всех этапах миграции.
Во время перехода на систему CCUC играет важную роль в оптимизации процесса миграции, содействуя сбору исчерпывающих данных из существующего развертывания унифицированных коммуникаций. CCUC помогает в решении ключевых задач перехода, таких как перенос устройств, функций и контактов пользователей, а также автоматизация обновления микропрограммного обеспечения для поддерживаемых IP-телефонов. Обеспечивая централизованный контроль и управление, CCUC помогает обеспечить более плавную и эффективную миграцию.
Cisco настоятельно рекомендует развертывать и развертывать CCUC на ранних этапах переходного проекта, в идеале до или на этапе подготовки. Это позволит получить аналитические данные и возможности, необходимые для тщательной оценки, инвентаризации и планирования последующих действий по миграции, а также для начала перехода к гибридным возможностям и будущего.
Оценка текущей среды
Ключевым видом деятельности при планировании миграции является оценка текущей локальной среды и ее развертывания. Это позволяет понять, к каким потенциальным изменениям могут потребоваться для успешного перехода. Это также позволяет оценить ключевые элементы платформы по сравнению с существующим локальным развертыванием. Вы можете использовать эту информацию, чтобы определить, какие конкретные задачи необходимо выполнить в связи с переходом и какие изменения вы хотите внести в соответствии со своими деловыми и техническими требованиями и сценариями использования.
В рамках этой работы важно рассмотреть следующие аспекты.
Лицензирование
Понимание текущей структуры лицензирования существующего развертывания имеет ключевое значение при подготовке к переходу на. Проведите оценку лицензий в следующих областях существующего локального решения Cisco.
-
Платформа
Возможность полностью сформулировать, какие лицензии в настоящее время лицензированы на вашей базовой платформе, будет иметь решающее значение, если вы совместно с командой по работе с клиентами или партнером определите наилучший путь к гибкому лицензированию. Лицензирование осуществляется с использованием гибкого лицензирования. Дополнительные сведения о гибком лицензировании см. в гибком плане Cisco для совместной работы.
-
Пользователи и устройства
Определите, какая категория лицензий требуется вашим существующим пользователям и устройствам. Это позволит определить, какой тип лицензии необходим пользователям и устройствам. Предлагается несколько типов лицензий, включая лицензии Professional и Standard для пользователей и лицензии Professional и Common Area для рабочих пространств. Дополнительные сведения о лицензировании устройств см. в техническом описании, доступном в разделе Лицензирование устройств.
-
Локальный шлюз
Если для этого перехода требуется Cisco Unified Border Element (CUBE) для доступа к PSTN, следует также рассмотреть возможность лицензирования CUBE. Вопросы лицензирования CUBE рассматриваются далее в этом документе.
Местоположения/сайты
При планировании перехода следует учитывать количество и типы сайтов (крупные центральные, региональные, филиальные и т. д.) в существующем развертывании. Полное понимание существующих мест развертывания поможет стратегически спланировать успешный переход, особенно когда речь идет о том, какие сайты следует перенести и в каком порядке. Подробное понимание требований к тарифным планам (нумерация, режимы набора номера, классы ограничений и т. д.), возможности подключения к сети сайта и пропускной способности (Интернет, глобальная сеть, локальная сеть), а также доступ к PSTN (локальный или централизованный, IP или TDM) для каждого сайта будет иметь решающее значение при принятии решений о миграции. Дополнительные сведения об общих моделях развертывания и основных соображениях см. в информации о моделях развертывания для совместной работы, доступной в Collaboration SRND.
Еще одним важным фактором при переходе на развертывание является доступность местоположения. Возможности, подписки и устройства доступны в зависимости от того, где находится развертывание. Дополнительные сведения о географической доступности см. в разделе Где доступен Webex? .
Наконец, важно понять, какое влияние переход на другие сервисы для совместной работы окажет на другие сервисы для совместной работы. Исходя из цели данного документа, общее предположение заключается в том, что для сохранения существующих сервисов совместной работы, выходящих за рамки рабочей нагрузки по вызовам, ожидается переход к гибридному развертыванию фазы 1, о котором говорилось выше. Примеры сервисов для совместной работы, для которых может потребоваться гибридное развертывание, включают локальный контакт-центр, который еще не перенесен в контакт-центр Webex, и тесную интеграцию с такими системами, как пейджинговые системы и биллинговые системы. Дополнительные сведения о переносе дополнительных рабочих нагрузок и сервисов для совместной работы см. в разделе Переход к совместной работе.
Инвентаризация существующих устройств/клиентов
Перед началом перехода важно провести инвентаризацию существующих аппаратных и программных конечных точек. Наличие полного списка типов и моделей устройств, версий аппаратного обеспечения, типов и количества программных клиентских ОС позволит вам правильно спланировать перевод устройств и смягчить последствия для тех устройств, которые невозможно перевести на облачные вызовы. Инвентаризацию следует использовать для определения устройств, подлежащих замене, и устройств, подлежащих замене до перехода.
Настольные телефоны
Для настольных аудио- и видеотелефонов поддерживаются только настольные телефоны серий 6800, 7800, 8800 и 9800. Это подмножество телефонов Cisco IP, которые поддерживаются с. С некоторыми моделями и версиями телефонов 6800, 7800 и 8800 нельзя использовать их. Дополнительные сведения о поддерживаемых моделях и версиях оборудования см. в разделе Поддерживаемые устройства для. Webex Calling
IP-телефоны Cisco серии 6800 нельзя обновить с корпоративной микропрограммы на многоплатформенную микропрограмму (MPP), которая необходима для. Поэтому любые телефоны 6800, на которых установлено корпоративное микропрограммное обеспечение, необходимо заменить моделью 6800 MPP или другой поддерживаемой моделью телефона.
IP-телефоны Cisco серий 7800 и 8800 должны быть обновлены до микропрограммного обеспечения многоплатформенных телефонов (MPP) перед их переходом и регистрацией. Чтобы определить, какие модели и версии оборудования 7800 и 8800 поддерживают микропрограммное обеспечение MPP, см. раздел Преобразование IP-телефонов Cisco серий 7800 и 8800 между корпоративными микропрограммами и микропрограммами MPP.
Продажи моделей 8845, 8865 и 8865NR закончились, и их не рекомендуется переносить.
Старые версии телефонов серии 8800 (8811, 8841, 8851, 8851NR, 8861) использовать не рекомендуется. Webex Calling Телефоны с аппаратной версией VID 14 или более ранней версии будут зарегистрированы, но из-за аппаратного обеспечения могут возникнуть некоторые проблемы с производительностью.
Настольные телефоны серии 9800 работают под управлением PhoneOS, которая поддерживает как регистрацию, так и регистрацию. Таким образом, на эти телефоны можно перейти без обновления прошивки.
Все остальные IP-телефоны необходимо заменить телефонами серий 6800, 7800, 8800 или 9800, поддерживаемыми в. Webex Calling Дополнительные сведения о поддерживаемых IP-телефонах и настольных телефонах см. в статье Поддерживаемые устройства для Webex Calling.
Конечные точки видеосвязи
Персональные и комнатные видеоконечные точки, в том числе серии Cisco Board, Room и Desk, могут автоматически регистрироваться по протоколу SIP. Для любой из этих конечных точек, которым необходимо совершать аудио- и/или PSTN-вызовы, требуется лицензия на звонки:
-
Для общих устройств в конференц-залах, местах для встреч и т. д. требуется лицензия Professional Workspace или Workspace.
-
Для персонального устройства конечного пользователя требуется профессиональная или стандартная лицензия.
Определите, сколько конечных точек видеосвязи зарегистрировано и используется для аудиозвонков. Возможно, некоторые конечные точки видеосвязи можно использовать только для присоединения к совещаниям или видеозвонков по протоколу SIP. В любом случае до вывода серверов из эксплуатации конечных точек все равно необходимо перейти на конечные точки, однако это поможет определить, скольким из них понадобятся лицензии для продолжения телефонных звонков.
-
Когда видеоустройства будут перенесены с регистрации на, URI этих конечных точек изменится, поскольку теперь они зарегистрированы в облаке.
-
Модели телефонов 8845, 8865 и 8875 являются персональными видеотелефонами, которые поддерживаются с.
Программные клиенты
Это единственный поддерживаемый программный клиент, в отличие от Unified CM которого поддерживаются как приложение Webex, так и Jabber, и новый программный клиент по умолчанию для конечных пользователей.
В зависимости от режима (режимов) развертывания, реализованных в Jabber (режимы только мгновенного обмена мгновенными сообщениями, только по телефону и/или в режиме полной унифицированной связи), возможно, потребуется также рассмотреть возможность переноса рабочих нагрузок в сфере обмена сообщениями и/или собраниями с Jabber на. Они могут быть развернуты в режиме «только по телефону», если они будут использоваться в качестве клиента только для звонков, или в режиме «только для звонков», или в режиме «только для звонков» при работе с другими рабочими нагрузками, например Webex Suite Webex Messagingи/или Webex Meetings переходят в приложение с помощью звонков.
Это повышает удобство работы конечных пользователей, предоставляя функции искусственного интеллекта, такие как аудио/видеоаналитика, транскрипция звонков и другие. Дополнительные сведения см. на сайте https://www.webex.com/all-new-webex.
Прежде чем переводить пользователей на сайт, вам необходимо перенести их клиентов Jabber в. У вас есть два варианта завершения этого перехода.
-
Прежде чем перевести их на
-
Когда вы их перейдете на.
Чтобы облегчить первоначальный переход на режим, рекомендуется использовать вариант 1 и сначала переместить пользователей в режим со звонками. Это даст пользователям время ознакомиться с новым приложением, пока они все еще используют существующую локальную платформу для звонков. Как только вы будете готовы перевести пользователей, вы настроите их на регистрацию на облачной платформе для звонков.
Дополнительные сведения об этих двух вариантах см. в разделе Миграция: один или два шага? .
Полный список поддерживаемых устройств см. в разделе Поддерживаемые устройства для Webex Calling.
Проверьте соответствие устройства требованиям
Как упоминалось ранее, для телефонов серий 7800 и 8800 требуется другой тип микропрограммного обеспечения для телефонов серий 7800 и 8800. Unified CMНа телефонах установлена корпоративная микропрограмма, а на телефонах — микропрограмма для многоплатформенных телефонов (MPP). На этапе подготовки рекомендуется проверить, какие зарегистрированные телефоны могут быть обновлены до микропрограммы MPP. Это даст вам время заменить телефоны, не отвечающие требованиям, одной из поддерживаемых моделей телефонов или найти альтернативный тарифный план, например перевести пользователя только в приложение Webex.
Чтобы определить соответствие телефонов требованиям, Control Hub имеет встроенный инструмент под названием «Перенос телефона на». Webex Calling При использовании этого инструмента для проверки соответствия устройства требованиям выберите вариант «Миграция только лицензии на устройство».
Эта опция позволяет загрузить CSV-файл с телефонами, чтобы проверить соответствие требованиям каждого телефона. Выбрав этот вариант миграции, вы не добавите телефоны, так как вы все еще находитесь на стадии подготовки и пока не готовы к этому. Дополнительные сведения см. в разделе Перенос телефона в. Webex Calling
Возможно, что некоторые телефоны будут возвращены с кодом «Неизвестно». Обычно это связано с тем, что невозможность проверить некоторую информацию о телефоне в серверной системе. Для любых телефонов со статусом «Неизвестно» есть два способа проверить, могут ли они обновиться до микропрограммы MPP.
-
Проверьте каждый телефон вручную и проверьте модель и версию оборудования (PID VID)
Этикетка телефона 7800/8800 с информацией о модели и версии оборудования -
Используйте средство подготовки IP-телефонов Cisco
Загрузите инструмент с сайта https://github.com/joemar2/mpp_readiness_check.
Этот инструмент не является официальным инструментом Cisco и не поддерживается TAC. Он поддерживается всеми силами , но его можно использовать бесплатно.
Это средство необходимо запускать на локальном компьютере с доступом к серверам и IP-телефонам. Он имеет возможность разрешить доступ к Интернету на IP-телефонах, что рекомендуется и необходимо для получения наилучших результатов. Поэтому его следует использовать в нерабочее время, чтобы не мешать работе конечных пользователей. Выходные данные инструмента представляют собой отчет, в котором перечислены телефоны серий 7800 и 8800, подлежащие обновлению до микропрограммы MPP. Поскольку приложение имеет прямой доступ к телефону, оно может проверять неизвестные устройства, о которых сообщала утилита Control Hub.
Отчет о готовности инструмента Cisco к работе IP-телефонов
Пользователи
Одним из наиболее важных шагов по подготовке к успешной миграции является надлежащая подготовка пользователей. Вам необходимо правильно спланировать работу всех пользователей, даже если вы осуществляете поэтапную миграцию. Пользователи должны быть готовы к любому из следующих действий:
-
Развертывание с помощью вызова
-
Развертывание с помощью
-
Настройка сервисов для пользователя
-
Чтобы пользователи могли искать в каталоге (нажмите, чтобы позвонить, контактная информация пользователя, поиск в телефонном справочнике).
Рекомендуется указать всех пользователей до или в начале проекта. Сюда входят пользователи, которые все еще используют платформу Unified CM для звонков независимо от устройства вызова (IP-телефон, Jabber). По мере перехода пользователей на (и/или) вы будете обновлять их лицензии, чтобы предоставлять им необходимые услуги. Предоставляя возможность всем пользователям корпоративных звонков перед началом перехода, пользователь, перешедший на сайт или в, сможет искать в каталоге пользователя, который звонит корпоративным пользователям, который все еще подключен к Jabber и/или подключен к Jabber. Это позволяет перешедшим пользователям найти контактную информацию любого другого пользователя и позвонить ему с помощью поиска в каталоге.
На рисунке «Поиск по каталогу» показан пример поиска пользователем другого пользователя. Результаты поиска содержат контактную информацию пользователя и могут касаться пользователя, который все еще использует Jabber, или пользователя, перешедшего на сайт и/или.
Затем определите, на кого из существующих локальных пользователей будут переведены звонки. Если будет переведено все или большое количество пользователей, рекомендуется перемещать пользователей группами, чтобы проектная группа, ИТ-персонал и вспомогательный персонал могли справиться с переходом и любыми возникающими проблемами. Вам также следует выделить некоторое время на предоставление исходной информации и проведение учебных занятий для подготовки пользователей к такому переходу. Группировать пользователей, меняющих друг друга, можно по целому ряду критериев, включая местоположение или место назначения пользователей на сайте , отделы пользователей и даже типы пользователей (работники умственного труда, руководители, мобильные сотрудники и т. д.).
Например, если пользователи, участвующие в развертывании, разделены на три основных сайта: Нью-Йорк (Нью-Йорк), Сан-Франциско (SFC) и Research Triangle Park (RTP), план перехода пользователей может выглядеть так же, как план, описанный в таблице «План перехода пользователей по сайтам».
| Сайт/местоположение пользователя | Информация и учебные занятия, предшествующие переходу | Переходный период | Поддержка в постпереходный период |
|---|---|---|---|
| Нью-Йорк (1525 пользователей) | Неделя 1 апреля | 15 апреля — 27 апреля | Неделя с 29 апреля |
| SFO (1600 пользователей) | Неделя, начинающаяся 6 мая | 20 мая — 31 мая | Неделя с 3 июня |
| RTP (1275 пользователей) | Неделя с 3 июня | 17 июня — 28 июня | Неделя 1 июля |
Еще один важный фактор — объединение пользователей, зависимых друг от друга. Это может включать в себя, помимо прочего, следующее:
-
мониторинг BLF
-
Один и тот же летчик/группа охотников
-
Поделитесь строками
-
Входит в одну и ту же группу приема звонков
-
Использование одних и тех же номеров колл-парков
-
Домофон
-
Администратор/руководитель.
Вы можете просмотреть конфигурацию (графический интерфейс или экспорт) или использовать инструмент Migration Insights, чтобы определить группы пользователей с этими зависимостями.
Подключение к PSTN
получить доступ к PSTN можно тремя способами: тарифные планы Cisco, подключение к облаку (ранее подключенная к облаку PSTN) и локальная сеть PSTN (локальный шлюз). Однако одно местоположение, определенное в разделе PSTN, может быть присвоено только одному варианту PSTN.
Локальная сеть PSTN с локальным шлюзом (LGW) является важным компонентом стратегии перехода. Он обеспечивает связь между локальным развертыванием и/или PSTN и платформой. Поддерживает как Cisco, так и сертифицированные сторонние пограничные контроллеры сеансов (SBC), которые можно использовать в качестве локального шлюза. Последний список поддерживаемых SBC см. в разделе Список поддерживаемых SBC.
поддерживает до 250 одновременных вызовов с одного локального шлюза, основанного на регистрации, и более 250 одновременных вызовов с одного локального шлюза на основе сертификатов. Локальные шлюзы на основе сертификатов могут поддерживать до 6500 одновременных вызовов, но это зависит от типа подключения к локальному шлюзу ( по сети или по сети) и модели SBC, на которой развернут локальный шлюз. По сути, эти ограничения являются предельным количеством вызовов PSTN на основе локального шлюза и межсайтовых вызовов между конечными точками и конечными точками. Дополнительные сведения см. в разделе Начало работы с локальным шлюзом.
Любые вызовы, превышающие этот лимит, отклоняются с помощью номера 403 Forbidden. Команду show call active voice можно в любом случае запустить на локальном шлюзе, чтобы определить общее количество активных вызовов.
Плохое состояние сети между локальным шлюзом и SBC доступа может снизить производительность сигнального соединения и привести к еще большему снижению лимита одновременных вызовов. Односторонняя задержка между локальным шлюзом и центром обработки данных не должна превышать 100 мс, джиттер — менее 10 мс, а потеря пакетов — менее 0,5%.
Функции и использование функций
При оценке текущей среды важно определить и проанализировать, какие функции настроены. Кроме того, важно понять, как используются эти функции, чтобы можно было (повторно) определить бизнес-требования и технические требования к развертыванию.
Чтобы определить, какие функции настроены, проанализируйте конфигурацию. Это все статические данные, которые задаются при настройке функции или параметра в системе. Для выполнения этого анализа можно использовать следующие опции:
-
Просмотрите конфигурацию в графическом интерфейсе администратора
-
экспорт конфигурации -- массовый экспорт или AXL
-
инструмент анализа миграции (рекомендуется)
-
Инструменты сторонних партнеров Cisco (рекомендуется).
Для эффективного анализа использования функций необходимо изучить динамические системные данные, такие как использование, регистрация и количество звонков . Различные аналитические инструменты и панели управления позволяют анализировать эти показатели, обеспечивая всестороннее понимание производительности и емкости системы, что способствует принятию обоснованных решений во время миграции и оптимизации. Для выполнения этого типа анализа можно использовать следующие варианты:
-
Просмотр необработанных записей CDR
-
Обзор данных Unified CM RTMT
-
инструмент анализа миграции с использованием данных CDR
-
Обзор аналитики унифицированных коммуникаций, подключенных к облаку, в
-
Объем звонков
-
Зарегистрированные конечные точки
-
Местоположения (CAC)
-
Использование магистралей.
-
-
Инструменты сторонних партнеров Cisco.
Для этого анализа Cisco рекомендует начать с инструмента Webex Control Hub Migration Insights. Вы импортируете экспортируемый файл TAR и файлы Unified CM CDR (необязательно, но необходимы для анализа использования функций) в инструмент. Инструмент создаст следующие отчеты на основе CSV , которые можно использовать для начала анализа:
| Название отчета Описание отчета |
|---|
| ImportedDataBulk.csv
Все пользователи и устройства из Unified CM данных |
| DeviceEligibility.csv
Определяет устройства, на которые можно перенести Webex Calling (IP-телефоны, устройства Room OS, ATA и сторонние устройства) |
| DevicePoolNumbers.txt Список всех номеров в определенном пуле устройств |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Подробная информация об устройствах и пользователях, которые необходимо перенести вместе, в зависимости от общих линий связи, пилотной программы поиска, очереди вызовов, парка вызовов и конфигурации группы приема вызовов |
| HuntGroupMigrationInsight.csv Подробная информация о назначенных охотничьих линиях, группах линий и связанных агентах |
| SharedlineGroupMigrationReport.csv Обзор того, как телефонные номера (справочные номера) распределяются между пользователями |
| Название отчета Описание отчета |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Информация о праве на перенос устройств в зависимости от использования этой функции |
| FeatureUsageWithLastUsageDateReport.csv Количество использований: количество вызовов пилотных проектов по поиску и очереди вызовов, а также дата последнего использования |
| UserWorkspaceLastUsage.csv Дата последнего использования пользователей и рабочих пространств как для программных клиентов, так и для жестких телефонов |
| DIDUsageReport.csv Использование DID как для назначенных, так и для неназначенных DID |
Дополнительные сведения об отчетах Migration Insights см. в разделе Аналитика миграции .
Если после изучения информации, содержащейся в отчетах Migration Insights, вам понадобятся дополнительные сведения о функциях и использовании, Cisco рекомендует воспользоваться одним из инструментов миграции от сторонних партнеров Cisco и/или ознакомиться с конфигурациями в графическом интерфейсе пользователя или в данных экспорта конфигураций.
Интеграции Cisco: подключение к Unity UCCX UCCE
Голосовая почта — неотъемлемая часть предложения и встроенная в решение. Она не может быть интегрирована с локальными решениями голосовой почты, такими как Unity Connection или Unity Connection Express. Кроме того, не существует встроенного способа переноса существующих сообщений голосовой почты или приветствий, подключенных к Unity, в встроенную службу голосовой почты, доступную вместе с Unity. Некоторые инструменты миграции, разработанные сторонним партнером Cisco, позволяют переносить часть этих данных. Дополнительные сведения о голосовой почте см. в разделе Настройка параметров голосовой почты пользователя и управление ими. Webex Calling
также поддерживает общие почтовые ящики голосовой почты и факса. Дополнительные сведения см. в разделе Управление общей голосовой почтой и входящим факсом для. Webex Calling
имеет встроенную функцию автосекретаря, которая входит в базовую платформу. Эта функция позволяет переключать обработчики вызовов и функции автосекретаря в Unity Connection. Инструмент Control Hub Migrate Features Unified CM from поддерживает перенос конфигураций Unity Connection на автосекретарей. Дополнительные сведения об использовании этого инструмента см. в разделе Перенос устройств и функций с на. Unified CM Webex Calling
Запись разговоров
включает два варианта записи разговоров без дополнительной оплаты.
-
Запись звонков Webex
-
Dubber Go recording (партнерское предложение) — это интеграция между Dubber и Dubber, при которой все записанные носители надежно хранятся в облаке.
В таблице включенных опций записи перечислены некоторые ключевые особенности двух вариантов записи разговоров, которые доступны без дополнительной оплаты.
| Webex | Dubber Go |
|---|---|
| Доступно всем пользователям | Доступно всем пользователям |
| Неограниченное количество записей | Неограниченное количество записей |
| Срок хранения 1 год* | 30-дневный срок хранения |
| 100 ГБ хранилища на организацию | - |
| Сотрудники по соблюдению нормативных требований могут получать доступ к записям разговоров и управлять ими | - |
| API для управления записями | - |
Администраторы могут настраивать доступ пользователей к записям разговоров и управлять им
|
Только пользователи могут получать доступ к своим записям и управлять ими
|
Если вашей организации требуются дополнительные возможности записи, такие как запись разговоров по нормативным требованиям, более длительные сроки хранения, больший объем памяти, анализ ИИ и/или доступ администратора, существуют платные предложения или дополнения как от Cisco, так и от сторонних поставщиков звукозаписи. Дополнительные сведения о поставщиках звукозаписи, конфигурациях и дополнительных партнерских услугах см. в разделе Управление записью звонков для Webex Calling.
Интеграция со сторонними организациями
поддерживает множество сторонних интеграций, включая, помимо прочего, SBC для локальных шлюзов, IP-телефонов, домофонов, динамиков/пейджеров, ATA и т. д. В дополнение к этим сторонним устройствам Webex Calling поддерживает различные сторонние решения для поддержки клиентов, аналитики, записи, выставления счетов и т. д. Дополнительные сведения о сторонних решениях см. в Webex App Hub.
План
План проекта высокого уровня
При разработке высокоуровневого проектного плана перехода от к проекту важно четко определить этапы и этапы, соответствующие как бизнес-целям, так и техническим требованиям. План должен начинаться с этапа комплексной оценки, включая сбор подробных технических и бизнес-требований, а также выявление заинтересованных сторон и определение критериев успеха. Ключевые соображения включают распределение ресурсов, оценку сроков, управление рисками и коммуникационные стратегии, обеспечивающие информирование и вовлечение всех сторон в процесс миграции. Кроме того, план должен включать контрольные точки проверки, такие как пилотное тестирование и поэтапное развертывание, чтобы свести к минимуму перебои и внести коррективы на основе отзывов.
Примеры элементов, которые следует включить в план проекта:
-
Определение масштабов миграции (например, какие пользователи, устройства и функции будут перенесены)
-
Планирование учебных занятий для конечных пользователей и групп поддержки
-
Координация оценок готовности сети и
-
Планирование переходных мероприятий с использованием запасных вариантов. Также важно интегрировать проверки соответствия требованиям и безопасности, а также этапы поддержки и оптимизации после миграции.
Структурировав план проекта с учетом этих соображений, организации смогут лучше управлять сложностями, снижать риски и обеспечивать более плавный переход к проекту.
Миграционный путь — один или два шага?
требует от пользователей использования программного клиента для звонков. Поэтому, если кто-либо из пользователей все еще пользуется, у вас есть два варианта, когда их можно перенести. Можно выполнить одноэтапную миграцию пользователей или двухэтапную миграцию пользователей.
Вариант 1. Одноэтапная миграция пользователей
В ходе одноэтапной миграции пользователи переходят от пользователя к пользователю одновременно с переходом от пользователя Unified CM к другому. Этот вариант обычно предназначен для клиентов с небольшим количеством пользователей, которые могут одновременно перемещать программный клиент пользователя и службу телефонной связи. Этот тип миграции показан на рисунке, на который одновременно переходят пользователь в службу телефонной связи, программный клиент и телефон, приведенный ниже. При использовании этой опции пользователь одновременно выполнит следующее:
-
Службы телефонной связи перенесены с
-
Телефонные номера и добавочные номера перенесены с
-
Программный клиент, перешедший с Jabber на -, зарегистрируется в
-
Регистрация по телефону перенесена с на.
Это все еще может быть поэтапная миграция, при которой группы пользователей перемещаются в разное время, но при перемещении каждого пользователя все это происходит одновременно.
Вариант 2. Двухэтапная миграция пользователей
Другой подход — двухэтапная миграция. На этапе 1 пользователи переходят от услуг телефонной связи к сервисам телефонной связи, но продолжают пользоваться ими. Затем, на шаге 2, пользователи переходят из Unified CM в. Этот вариант рекомендуется для крупных клиентов, которые могут управлять изменениями конечных пользователей и хотят отделить смену программного клиента пользователя от смены службы вызова. Этот тип миграции показан на следующем рисунке: «Перенос программного клиента, а затем перенос службы вызовов, программного клиента и телефона» Webex Calling ниже.
Шаг 1
-
Программный клиент перешел с версии на — зарегистрируется в.
Шаг 2
-
Службы телефонной связи перешли от в.
-
Телефонные номера и добавочные номера переехали в.
-
регистрация перенесена с на.
-
Регистрация по телефону перенесена с на.
Это все еще может быть поэтапной миграцией, при которой группы пользователей перемещаются в разное время на обоих этапах.
Выбранный вами вариант зависит от того, как вы хотите управлять переходом пользователей в систему и. Рекомендуется использовать эту процедуру поэтапно (вариант 2). Это позволяет свести к минимуму изменения, внесенные конечным пользователем за один раз, и распределить усилия между различными частями проекта. Однако если вы предпочитаете, чтобы влияние на пользователей оказывалось только один раз, вам также подойдет вариант 1.
Если посмотреть на рекомендуемый маршрут (вариант 1), то на рисунке карты высокоуровневого перехода Jabber к приложению Webex ниже показан высокоуровневый переход на шаг 1.
На этом этапе пользователи переходят с Jabber на все свои службы телефонной связи. Однако платформа для звонков все еще работает, Unified CM и она будет регистрировать свои телефонные сервисы. Как показано на высокоуровневой карте перехода Jabber к Webex App, локальная инфраструктура не меняется и работает так же, как и Jabber. Единственное изменение заключается в том, что требуется подключение к сети.
Дополнительные сведения об этом переходе см. в разделе Карта перехода от Jabber к Webex и руководство по развертыванию в разделе Клиент на странице перехода к совместной работе.
Unified CMРисунок карты перехода на Webex Calling высокоуровневую карту — это высокоуровневый переход от в. Это второй шаг рекомендуемого путешествия.
Если вы решите использовать одноэтапный подход, это тоже применимо.
На этом этапе пользователи переходят в группы. На этом этапе пользователи начинают использовать для своих звонков услуги регистрации звонков и регистрации IP-телефонов.
Поскольку пользователи перемещаются группами, корпоративные пользователи во время перехода будут разделены между двумя платформами телефонной связи. Это состояние изображено Unified CMна рисунке с карты перехода на этап 1 к Webex Calling высокоуровневому переходу. На этом этапе необходимо спланировать управление вызовами между пользователями на двух платформах и маршрутизацию вызовов PSTN. При каждом переходе к группе пользователей необходимо будет обновлять тарифные планы и маршрутизацию вызовов, а также локальные шлюзы.
Как только все пользователи, программные клиенты и устройства будут переведены на (этап 2), всю локальную инфраструктуру UC можно будет удалить и вывести из эксплуатации.
Дизайн
Выбор региона
доступен по всему миру и поставляется из резервных центров обработки данных в нескольких регионах: США (Даллас, Чикаго), Канаде (Ванкувер, Торонто), Европе (Франкфурт, Амстердам), Великобритании (Лондон, Манчестер), Австралии (Мельбурн, Сидней), Японии (Токио, Осака), Саудовской Аравии (Эр-Рияд, Джидда) и Индии (Мумбаи, Ченнаи). POPS для СМИ предоставляют мультимедийные услуги для оптимизации времени передачи информации в оба конца. Например, сингапурский центр обработки данных используется для оптимизации времени передачи мультимедийных материалов туда и обратно для клиентов из азиатских стран, где время поездки туда и обратно в Австралию или Японию может оказаться неоптимальным. Центры обработки данных соединены мультигигабитной магистралью с полным резервированием. На рисунке центров обработки данных, распределенных по всему миру, показан обзор всех центров обработки данных. Последний список доступных центров обработки данных см. в разделе Местоположение центров обработки данных Webex Calling.
Каждый клиент обслуживается на одном из экземпляров. Вся информация об обеспечении этого клиента хранится в этом экземпляре, а сигнализация SIP всех конечных точек и локальных шлюзов, предоставленных этому клиенту, привязана к экземпляру, на котором работает клиент. Поскольку первоначальный выбор региона изменить сложно, важно учитывать все важные факторы в процессе принятия решений, ведущих к выбору региона. Чтобы избежать чрезмерных задержек с подачей сигнала в оба конца, важно на раннем этапе переходного процесса решить, какой экземпляр следует использовать. Cisco рекомендует выбрать инстанс, обеспечивающий наименьшее время передачи сигнала в обе стороны для наибольшего числа пользователей в развертывании.
Информацию о доступности по странам см. в разделе Где доступен Webex? .
Местоположения
Чтобы подготовиться к предоставлению мест, необходимо собрать необходимую информацию по всем целевым местам миграции. Сведения, необходимые для каждого местоположения, кратко изложены в разделе «Сведения для сбора по каждому местоположению».
| Информация | Комментарий |
|---|---|
| Диапазон (ы) расширения | В каждом адресе могут быть расширения, начинающиеся с разных цифр. Для
рулевого номера межсайтового набора номера следует оставить одну цифру (например, 8) и одну цифру для
рулевого номера PSTN (например, 9). Ни один из этих двух цифр не может начинаться ни с одной из этих цифр. Все диапазоны расширений во всех местоположениях должны иметь одинаковую длину. |
| Диапазон (ы) DID | - |
| Рулевая цифра PSTN | - |
| Код сайта | Все коды сайтов во всех местах должны быть уникальными и иметь одинаковую длину. |
| Основной номер | При создании местоположения необходимо предоставить два идентификатора DID. Один в качестве
основного номера (например, для присвоения службе автосекретаря), а другой — для
портала голосовой почты. Предоставьте один DID для номера голосовой почты. |
| Номер голосовой почты | |
| Количество лицензий | Необходимые лицензии по типам, включая стандартные лицензии, лицензии Professional, Workspace, список маршрутов, план исходящих звонков. |
| Одновременные звонки в час пик | Сумма одновременных вызовов между устройствами и между устройствами и локальным шлюзом (PSTN и вызовы на устройства). Необходим для определения требуемой пропускной способности доступа в Интернет. |
| Страна | - |
| Часовой пояс | - |
| Язык | - |
| Контактное лицо (имя, телефон, адрес электронной почты) | - |
| Адрес (почтовый адрес, город, штат, почтовый индекс) | - |
| Местонахождение конечных точек службы экстренной помощи, физическое место дислокации | Диспетчерское местоположение устройства, используемое для вызова экстренных служб, обычно включает следующее: адрес здания, адрес здания + номер этажа, адрес здания + номер квартиры или адрес здания + номер этажа + номер офиса/кубический номер. |
| Уникальное физическое сетевое местоположение служб экстренной помощи для каждого устройства | Физическое сетевое местоположение для экстренных вызовов обычно включает следующее: коммутатор/порт для проводных устройств, идентификаторы базовых наборов услуг (BSSID) точек доступа (AP) для беспроводных подключенных устройств и/или локальные IP-подсети для конечных устройств. |
PSTN
При проектировании развертывания у клиентов есть три основных варианта подключения к PSTN: планы Cisco Calling Plans (облачная служба PSTN, управляемая Cisco), поставщики подключенных к облаку PSTN (CCPP, где поставщики предоставляют услуги PSTN через облако) и локальные PSTN (где локальные шлюзы соединяют корпоративную сеть с PSTN). С введением транкинга PSTN для гибридных развертываний (дополнительные сведения см. в разделе Транкинг PSTN для гибридных Webex Calling развертываний в разделе Транкинг PSTN) организации получили дополнительную гибкость в своем подходе к миграции. Эта функция позволяет клиентам перенести свои PSTN на CCPP в начале перехода и начать переход на облачные PSTN для пользователей, одновременно используя CCPP для обслуживания обслуживания PSTN для пользователей, которые остаются в Cisco во время поэтапной миграции.
Этот гибридный подход позволяет организациям сначала перенести отдельные группы пользователей в облако без немедленного пересмотра всей телефонной среды. Однако это сопряжено с дополнительными сложностями и рисками, особенно в том, что касается адаптации существующей логики маршрутизации вызовов к поддержке новой архитектуры. Совместимость с устаревшими приложениями, такими как факс-серверы, контакт-центры или пейджинговые системы, также требует тщательного рассмотрения. Ключевые технические проблемы могут включать обеспечение беспрепятственного согласования сквозных кодеков и передачи сигналов DTMF (двухтональной многочастотной) в смешанной среде, а также проверку совместимости со специализированными функциями телефонии. Надлежащее планирование и тестирование необходимы для минимизации сбоев и обеспечения надежности голосовых услуг на протяжении всего процесса миграции. Кроме того, важно учитывать коммерческие соображения, поскольку для использования гибридной транкинговой сети требуется лицензия на использование, основанная на количестве одновременных вызовов между локальной средой и поставщиком PSTN, подключенным к облаку (CCPP).
В качестве альтернативы организации могут сохранить подключение к локальной сети PSTN на протяжении всего переходного периода. В этом сценарии переход на CCPP может быть осуществлен двумя способами: в виде единого скоординированного перехода для всех пользователей и местоположений после завершения миграции или поэтапно, при этом миграция PSTN будет осуществляться отдельно по мере перемещения пользователей. Такой подход может помочь упростить сосуществование и обеспечить непрерывность устаревших интеграций, но он сопряжен с рядом операционных сложностей. К ним относятся проблемы, связанные с переносом номеров, такие как необходимость точной координации заказов на номерные порты, потенциальные задержки и ограничения, налагаемые провайдером, такие как ограничение количества одновременных запросов на порты или ограничение на перенос подмножеств из большого количества блоков. Организации должны тщательно планировать стратегию перехода на PSTN с учетом этих логистических соображений, чтобы избежать перебоев в обслуживании и обеспечить бесперебойную миграцию.
На рисунке «Перенос на CCCP с самого начала и сохранение локального PSTN» показаны два варианта миграции PSTN, описанных выше. На рисунке слева показан сценарий, когда все локальные пользователи и приложения используют услуги PSTN, подключенные к облаку, через локальную магистраль и локальный шлюз, соединяющий локальную сеть, а на рисунке справа показан сценарий, когда существующая локальная PSTN остается на месте, а пользователи Webex Calling используют локальную PSTN через локальное шлюзовое соединение между локальными и. Во время перехода можно переключиться на использование PSTN, подключенной к облаку.
В обоих сценариях для звонков между локальной сетью и пользователем используется соединение через локальный шлюз. Соединение между локальной сетью и сетью должно быть спроектировано и рассчитано соответствующим образом с учетом ожидаемого количества одновременных вызовов и требуемой избыточности.
План набора
Для обеспечения бесперебойной совместимости в период миграции и во время миграции необходимо разработать и внедрить комплексную архитектуру телефонных планов на обеих платформах. Эта двухплатформенная схема абонентского плана обеспечивает согласованную маршрутизацию вызовов, перевод номеров и прозрачность функций, что позволяет пользователям любой системы общаться без ухудшения качества обслуживания или перебоев в работе пользователей на этапе сосуществования.
Локальный тарифный план в
В ходе перехода, чтобы обеспечить возможность сосуществования устройств, зарегистрированных на корпоративной телефонной карте Unified CM и в ней, необходимо внести изменения, чтобы обеспечить выполнение как минимум следующих требований:
-
+E.164, набор номера от до
-
Дозвон по добавочному номеру от до (внутри сайта, а также между сайтами, если диапазоны добавочных номеров уникальны)
-
Сокращенный межсайтовый набор номера от до
-
Принудительный внутрисетевой набор номера от 0 до
-
Обратный звонок из справочника пропущенных звонков в пункты назначения на
-
Вызовы PSTN с PSTN на PSTN, если во время перехода используется локальная PSTN для
-
Вызовы PSTN (если) во время перехода используется транкинг PSTN для гибридных развертываний для предоставления доступа к PSTN локальным пользователям через Cloud Connect для
-
Принудительное внутрисетевое подключение к
-
Дозвон по добавочному номеру от до (между сайтами).
Если какие-либо из вышеперечисленных привычек набора до перехода не поддерживались (например, не существовало сокращенного набора номера между сайтами), то их необязательно вводить во время перехода.
На рисунке «Передовые практики» показан передовой подход к использованию абонентской группы, описанный в разделе «Предпочтительная архитектура для корпоративных локальных развертываний Cisco Collaboration 12.x» (CVD). Основные характеристики этого подхода включают в себя:
-
Единый раздел для номеров каталогов +E.164
-
Базовая маршрутизация на основе шаблонов маршрутов +E.164
-
Нормализация всех привычек набора номера до +E.164 с использованием шаблонов трансляции
-
Использование шаблона перевода, вызывающего наследование пространства поиска (опция Использовать пространство поиска вызовов автора, заданное в шаблонах перевода).
Например, при наборе номера PSTN (9+1+10D) с устройства в SJC, оснащенного пространством поиска телефонных звонков SJCInternational, сначала будет сопоставлен шаблон перевода 9.1 [2-9] XX [2-9] XXXXXX, который нормализует номер вызываемой стороны до +E.164. Затем вторичный поиск снова использует то же самое пространство поиска вызовов SJCInternational (вызывая наследование пространства поиска), и строка +E.164 из 4 цифр будет совпадать либо с номером каталога +E.164 в разделе DN, либо с одним из шаблонов маршрута PSTN в разделе USPSTNNational или SJCPStnLocal. Сокращенные режимы набора номера внутри сайта и между сайтами реализованы с помощью переводов в разделах ESN и SJCToE164. В то время как раздел ESN является глобальным разделом (доступным для телефонов в любом месте), раздел SJCTOE164 доступен только для пользователей в местоположении SJC. Предполагается, что диапазоны расширений перекрываются.
Первый шаг к разрешению звонков от до — убедиться, что пункты назначения +E.164 маршрутизируются соответствующим образом. Этого можно добиться, добавив раздел в абонентскую группу, добавив в этот раздел схемы маршрутов +E.164 для всех пунктов назначения и, наконец, добавив эту секцию во все области поиска вызовов, представляющие классы обслуживания, к которым необходимо обеспечить доступ. Создание выделенного раздела необходимо для создания дифференцированного класса услуг для исходящих звонков. Чтобы избежать циклических вызовов, область поиска входящих вызовов в магистрали из локального шлюза не должна иметь доступа к разделу.
Как показано на рисунке +E.164 для Webex Calling маршрутизации в местоположение с диапазоном +E.164 DID +1 221 555 2XXX и кодом сайта 121, в раздел необходимо срочно добавить шаблон маршрута, соответствующий этому диапазону +E.164.
Если выбор локального шлюза для конкретного сайта не требуется, вместо использования списка маршрутов с локальной группой маршрутов в качестве места назначения для шаблонов маршрутов, указывающих на одну группу маршрутов, можно предоставить локальный шлюз в качестве единственного члена, а затем шаблоны маршрутов указывают на один список маршрутов, в котором эта группа маршрутов является только записью.
Чтобы обеспечить межсайтовый сокращенный набор номера на сайте, в раздел добавлен необходимый шаблон маршрута 8121.2XXX. Возможно, в разделе ESN уже существует схема нормализации набора номера 8121.2XXX, которая нормализует набор номера ESN до +E.164. В этом случае 8121.2XXX кажется излишним, но как только все DN-адреса в соответствующем месте будут перенесены на 8121.2XXX, шаблон перевода нормализации набора номера можно удалить, а затем шаблон маршрута 8121.2XXX позволит звонить по ESN даже пользователям, входящим только в этот диапазон.
При такой смене тарифного плана звонить на место назначения можно не только сокращенным междугородним набором номера и +E.164. Кроме того, международный и национальный набор телефонных номеров PSTN возможен благодаря тому, что эти режимы набора сначала нормализуются до +E.164 с помощью уже существующих шаблонов преобразования нормализации набора, а затем маршрутизируются, сопоставляя шаблон маршрута +E.164 в разделе.
Шаблон маршрута +E.164, соответствующий диапазону DID местоположения, можно обеспечить, пока все DID все еще находятся на хостинге. Алгоритм наилучшего сопоставления шаблонов совпадений, позволяющий при наборе номера, размещенного на сервере, лучше совпадать с указанным справочным номером +E.164 по сравнению с шаблоном маршрута +E.164 с подстановочными знаками, указывающим на него, так что вызовы будут передаваться на включенную линию, а не на которую отправляются.
тарифный план
Каждому входящему пользователю предоставляется добавочный номер и/или телефонный номер +E.164. Длина добавочного номера является фиксированным глобальным параметром: все расширения в развертывании имеют одинаковую длину. Дозвон по добавочному номеру можно использовать между пользователями как в пределах одного местоположения, так и между местоположениями. Сокращенный межсайтовый добавочный номер (в последнем случае) работает только в том случае, если набираемый добавочный номер уникален.
Если требуется сокращенный межсайтовый набор номеров между филиалами, но добавочные номера, назначенные в разных местах, совпадают, то необходимо составить план нумерации для конкретного предприятия, добавив к добавочным номерам код доступа (код сайта). Дополнительные сведения см. в разделе Предпочтительная архитектура для локальных развертываний Cisco Collaboration 15, обзор проектирования см. в разделе Предпочтительные архитектуры Cisco для совместной работы.
Длина добавочного номера, режим набора номера между точками, длина префикса для межлокационного набора и рулевая цифра в префиксе маршрутизации для межлокационного набора настраиваются в настройках службы вызовов в:
-
Длина префикса маршрутизации по местоположению: длина префикса, включая рулевой номер. Требуется только в том случае, если необходимо разработать корпоративный план нумерации в качестве альтернативного метода сокращенного набора телефонных номеров между точками предприятия.
-
Рулевая цифра в префиксе маршрутизации: рулевая цифра, обозначающая сокращенную корпоративную привычку звонить из одного места в другое. Следует избегать совпадений с первой цифрой любого местоположения и цифрами исходящего набора номера. Требуется только в том случае, если необходимо разработать корпоративный план нумерации в качестве альтернативного метода сокращенного набора телефонных номеров между точками предприятия.
-
Длина внутреннего добавочного номера: стандартная длина добавочных номеров. Может принимать любое значение от двух до десяти.
Если от локальной службы управления вызовами требуется набор номера с добавочного номера или номера со значимых корпоративных номеров (код управления, код сайта, добавочный номер), а локальная система управления вызовами отправляет добавочный номер в качестве идентификатора вызывающего абонента, обязательно задайте параметр Максимальная неизвестная длина добавочного номера в разделе Маршрутизация вызовов между локальными и локальными вызовами, чтобы входящие вызовы из локальной системы управления вызовами можно было правильно классифицировать как локальные вызовы. -
Разрешить набор дополнительных номеров между местоположениями: включите или отключите дополнительный набор между местоположениями. Эту опцию следует включать только в том случае, если все добавочные номера в организации уникальны. Если опция отключена, необходимо набирать важные корпоративные номера (код управления, код сайта, добавочный номер) или телефонные номера между отделениями .
Первые три параметра в основном используются при составлении тарифного плана для телефонов, позволяющего свести к минимуму время ожидания между цифрами при наборе номера без подключения к сети. Отклонения от этих глобальных настроек все еще возможны (например, можно указать добавочные номера другой длины), но в Control Hub появится предупреждающее сообщение, а для набора номера с телефонов может потребоваться заблокировать набор во избежание конфликтов в предварительно загруженной абонентской группе.
В примере нумерации в таблице Enterprise показан пример трех мест, в которых диапазоны добавочных номеров в двух населенных пунктах (NYC и RTP) идентичны. Создание корпоративной схемы нумерации, включающей в себя управляющую цифру 8 между сайтами, за которой следует трехзначный код сайта и четырехзначный добавочный номер, позволяет использовать сокращенный набор номеров между сайтами без дублирования.
| Сайт | Диапазон расширения | Код сайта | Ассортимент для предприятий |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
Чтобы обеспечить плавный переход, набор привычек набора номера для пользователей до и после перехода на них в идеале должен быть одинаковым. Чтобы подготовиться к переходу в каждое местоположение, необходимо задокументировать диапазоны DID и диапазоны добавочных номеров (или сокращенные привычки набора номера внутри сайта). На основе этой информации необходимо выбрать межсайтовую управляющую цифру.
В таблице Диапазоны удлинителей фиксированной длины приведен пример трех точек и диапазонов удлинителей фиксированной длины. Поскольку необходимо избегать совпадения режимов набора номера, важно убедиться, что в любом дополнительном диапазоне первая цифра диапазона не совпадает с рулевой цифрой при сокращенном наборе номера между узлами. Если, например, в качестве управляющей цифры для межсайтового набора номера выбрано значение 8, то ни один дополнительный диапазон ни на одном сайте не может начинаться с 8. Как правило, добавочные номера в данном месте совпадают с последними цифрами идентификаторов DID, присвоенных этому местоположению. Во избежание конфликтов первую цифру добавочного номера можно изменить. Например, если в каком-либо месте используются идентификаторы DID в диапазоне +1 408 555 8XXX, то вместо 8XXX в качестве диапазона расширений можно использовать 7XXX для расширений на этом сайте
| Сайт | Диапазон расширения | Расширения | Код сайта | Ассортимент для предприятий |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Семизначные строки набора, набранные на устройстве, использующем американскую абонентскую группу, совпадают с семизначным шаблоном для местного набора в предварительно загруженной телефонной группе США. Чтобы избежать совпадений между режимами набора номера внутри сети и за ее пределами (PSTN), в этом месте можно использовать обязательный внешний код доступа. Если существующая корпоративная схема нумерации и соответствующая сокращенная схема межсайтового набора совпадают с образцами национального набора, то при переходе на схему нумерации во избежание накладок ее можно также изменить на более длинную или более короткую форму. Самый простой способ добиться этого — добавить в схему нумерации дополнительную цифру. Новую более длинную схему межсайтового набора должны использовать только пользователи, на которые уже перешли. Все еще подключенные пользователи могут продолжать набирать семь цифр. В этом случае при использовании корпоративного телефонного плана необходимо обеспечить преобразование сокращенного семизначного набора номера от Unified CM до +E.164 или в сокращенный формат набора номера, используемый на. Это необходимо сделать перед отправкой вызова на локальный шлюз.
Пример такого изменения нумерации приведен в таблице «Переход на семизначный набор». В этом примере при сокращенном межсайтовом наборе используется управляющая цифра 8, затем двухзначный код сайта и четырехзначный добавочный номер. Чтобы избежать семизначного сокращенного межсайтового набора номеров для населенных пунктов, коды сайтов можно легко изменить на трехзначные, добавив произвольную цифру (в примере 8) к используемым двузначным кодам сайта, чтобы при межсайтовом звонке с телефонов использовалась рулевая цифра 8, затем добавочная цифра 8, старый двузначный код сайта и четырехзначный добавочный номер. Пользователям не нужно запоминать новые коды сайтов; им достаточно использовать префикс 88 в качестве префикса для межсайтового набора вместо 8.
| Сайт | Расширения | Код сайта | Корпоративный ассортимент | Код сайта | Корпоративный ассортимент |
| NYC | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
В сценарии с разными форматами корпоративных номеров и представлением корпоративных номеров в качестве информации о звонящих абонентах (например, звонки с устройств без DID) важно также обеспечить сопоставление различных форматов номеров для получения информации о вызывающих абонентах, чтобы обеспечить работоспособность обратного вызова. Такое сопоставление может быть достигнуто с помощью схемы трансформации вызывающих абонентов на магистральном канале между локальным шлюзом и локальным шлюзом.
Запись
Хорошо спроектированное решение для записи разговоров требует тщательного рассмотрения нескольких ключевых элементов дизайна, чтобы обеспечить его соответствие целям организации, нормативным требованиям и техническим ограничениям. Два наиболее важных решения связаны с выбором поставщика услуг и выбором региона. Возможно, оба решения придется адаптировать во всем мире и отменить в определенных местах в зависимости от потребностей бизнеса.
1. Выбор провайдера записи разговоров
Выбор подходящего поставщика услуг записи разговоров имеет важнейшее значение для достижения бизнес-целей и обеспечения согласованности функций в организации:
-
Выбор поставщика услуг по всему миру: организации обычно назначают основного поставщика услуг записи разговоров на глобальном уровне, обеспечивая единообразие набора функций, соответствие нормативным требованиям и поддержку во всех подразделениях
-
Переопределения, основанные на местоположении: в сценариях, когда определенные сайты или регионы имеют уникальные бизнес-потребности или нормативные требования, может возникнуть необходимость отменить выбор глобального поставщика и указать альтернативных поставщиков для этих регионов. Такая гибкость позволяет удовлетворить различные требования по соблюдению нормативных требований и локальные операционные потребности
-
Бизнес-требования: выбор поставщика должен основываться на оценке таких факторов бизнеса, как соответствие нормативным требованиям (например, MiFID II, HIPAA), обеспечение качества, разрешение споров или потребности в обучении
-
Доступность функций: поставщиков следует оценивать на основе их способности предоставлять необходимые функции, такие как мониторинг в реальном времени, возможности поиска и воспроизведения, шифрование, политики хранения, интеграция с аналитическими платформами и поддержка различных типов звонков (входящих, исходящих, внутренних).
2. Выбор региона
Определение региона, в котором хранятся и обрабатываются записи разговоров, имеет решающее значение для соответствия нормативным требованиям и производительности:
-
Выбор глобального региона: по умолчанию организации могут выбрать один регион для хранения записей разговоров, чтобы упростить управление и управление
-
Переопределение регионов, основанных на местоположении: в тех случаях, когда того требуют законы о хранении данных или корпоративные правила, может возникнуть необходимость отменить глобальные региональные настройки для определенных местоположений, обеспечив хранение и обработку записей разговоров в требуемых географических границах
-
Требования к резидентности данных: при проектировании должны учитываться международные и местные правила защиты данных (например, GDPR, CCPA или национальные требования), которые могут определять, где и как хранить записи разговоров.
Еще одним важным аспектом, на который следует обратить внимание при планировании и разработке решения для записи разговоров, является оценка требований к хранению данных. Точное прогнозирование потребностей в хранении данных необходимо для обеспечения достаточной емкости для поддержки текущих бизнес-операций, соблюдения нормативных требований и предотвращения перебоев в обслуживании.
При определении ожидаемого спроса на хранилище следует учитывать несколько ключевых параметров:
-
Количество записанных звонков: оцените ожидаемое количество звонков, которые будут записаны в течение заданного интервала времени (например, за день, неделю или месяц). Сюда входят не только внешние звонки, но и внутренние коммуникации, если того требуют деловая политика или нормативные требования
-
Средняя продолжительность разговора: рассчитайте типичную продолжительность записанных звонков, так как более длительные звонки будут занимать больше места на диске. При расчете также следует учитывать различия в продолжительности звонков в разных отделах или группах пользователей
-
Срок хранения: определите срок хранения записей, который часто определяется организационными политиками или внешними нормативными актами (например, отраслевыми стандартами соответствия). Более длительные сроки хранения повысят общие требования к хранению
-
Прогнозы роста. Рассмотрите ожидаемый рост количества звонков или расширение области записи, что может произойти в результате масштабирования бизнеса, введения новых нормативных требований или привлечения дополнительных пользователей или локаций.
Тщательно проанализировав эти параметры, организации смогут разработать надежную стратегию хранения данных, обеспечивающую масштабируемость, экономичность и соответствие нормативным требованиям своего решения для записи разговоров. Также рекомендуется регулярно пересматривать и корректировать распределение ресурсов хранения по мере изменения моделей использования.
Экстренный вызов
Любая телефонная служба, предлагающая услугу PSTN, обязательна для направления экстренного вызова в соответствующий диспетчерский центр. Кроме того, маршрутизация экстренных вызовов является неотъемлемой частью решения и включает поддержку всех национальных номеров экстренных служб в странах, оказывающих поддержку. Маршрутизация экстренного вызова зависит от определенного местоположения и способа доступа к PSTN в этом месте. Номера экстренных служб заранее определены и привязаны к стране, в которой работают пользователи и устройства.
Есть два способа доставки экстренных вызовов. Существует базовая служба маршрутизации экстренных вызовов и расширенная служба маршрутизации экстренных вызовов. Базовая служба маршрутизации экстренных вызовов будет использовать выбранный администратором номер для определения местоположения и маршрута вызова экстренных служб. Для основных вызовов экстренных вызовов обычно используется опция PSTN, установленная клиентом в указанном месте. Кроме того, имеется усовершенствованная маршрутизация экстренных вызовов, разработанная для систем в США и Канаде, где действуют нормативные требования, предусматривающие использование услуг национального провайдера для доставки экстренных вызовов в соответствующий диспетчерский центр.
Всем клиентам следует использовать как минимум базовую конфигурацию экстренных вызовов. Для базового вызова экстренных служб необходимо присвоить по крайней мере один принадлежащий клиенту номер +E.164 каждому населенному пункту, указанному в. При вызове основных экстренных служб каждое местоположение будет определяться почтовым адресом, по которому в экстренных случаях будут направлены полицейские, пожарные или скорая помощь. В большинстве случаев лучше всего использовать основной телефонный номер, обозначающий физическое местонахождение экстренной помощи. Как правило, присвоение адреса номеру +E.164 согласовывается с поставщиком услуг PSTN. На рисунках ниже показано назначение основного номера, который будет использоваться в качестве номера экстренного вызова в офисе Ричардсона.
В большинстве случаев в качестве адреса отправки на место достаточно адреса здания. Но если для конкретных пользователей или устройств требуются дополнительные сведения о местоположении, администратор может использовать описанную выше процедуру и присвоить этим устройствам определенный адрес или более точное место в адресе (например, этаж или помещение). В разделе «Управление пользователями» вкладка «Вызовы» позволяет пользователю и его устройствам использовать определенный номер для получения определенного адреса отправки. На следующих рисунках показано, как можно присвоить устройству определенный номер. Администратор отвечает за то, чтобы номеру, используемому устройством, был присвоен правильный адрес отправки. Назначение адреса обычно осуществляется провайдером PSTN в этом месте.
Для развертывания телефонных сетей в США, которые должны предоставлять усовершенствованные решения для экстренных вызовов, для маршрутизации экстренных вызовов используется интегрированная в систему RedSky Horizon Mobility. При использовании RedSky для маршрутизации вызовов администратор должен зарегистрировать учетную запись через Cisco и настроить соответствующую информацию в разделе Вызовы -> Настройки услуг, чтобы включить эту функцию. Как только служба RedSky будет включена на системном уровне, администратор включит службу RedSky на каждом уровне местоположения. Включение функции расширенного вызова экстренных вызовов в определенном месте активирует услугу для всех устройств, привязанных к этому местоположению. К устройствам, поддерживающим улучшенную экстренную связь, относятся телефоны Cisco MPP, телефоны Cisco PhoneOS и Cisco.
Есть две настройки для включения расширенного вызова экстренных вызовов в определенном месте. Для проверки правильности конфигурации RedSky для сопоставлений устройств и инфраструктуры следует использовать опцию «Разрешить RedSky получать информацию о сетевом подключении и тестовые вызовы». Эта настройка также позволяет совершать тестовые вызовы на номер 933 для проверки местоположения с помощью системы IVR RedSky для считывания местоположения звонящего. Хотя в этом документе не рассматривается конфигурация RedSky для отслеживания местоположения, администратору ВСЕГДА следует проверить определение местоположения, прежде чем активировать экстренные вызовы для маршрутизации на RedSky. После завершения тестирования и подтверждения его точности администратор перенаправит вызовы в RedSky, переключив маршрут экстренных вызовов на RedSky. Этот переключатель будет перенаправлять все экстренные вызовы о местоположении в RedSky для доставки в автоответчик, который определит местоположение.
Расширенные настройки экстренных вызовов также применимы к клиентам как в офисе, так и за его пределами. В локальной среде их можно отслеживать так же, как и настольные телефоны. Находясь вне офиса, пользователь сможет динамически определять свое местоположение непосредственно в нем. Дополнительные сведения об экстренных вызовах см. в разделе Расширенные возможности экстренного вызова.
Лицензирование
Существует несколько вариантов назначения лицензий пользователям.
Ручное назначение через
Администраторы вручную назначают лицензии отдельным пользователям через интерфейс.
Администраторы могут редактировать лицензии на услуги для отдельных пользователей и напрямую назначать лицензии на звонки.
Шаблоны автоматического назначения лицензий
Используйте шаблоны назначения лицензий для автоматического назначения лицензий пользователям на основе групповых или организационных настроек.
Автоматическое лицензирование можно осуществить с помощью синхронизации каталогов или обновления вручную, но пользователи должны иметь действительный телефонный номер в формате +E.164, а телефонные номера должны существовать в определенном месте до предоставления пользователям полномочий. Если условия не будут соблюдены (например, неправильный формат телефонного номера), лицензии не будут предоставлены.
Массовое назначение с помощью шаблона CSV
Загрузите CSV-файл с информацией о пользователе и назначениями лицензий, чтобы добавить или изменить сразу несколько пользователей.
Импорт CSV позволяет добавлять до 20 000 пользователей и назначать лицензии, но для лицензий требуются специальные поля, такие как номер телефона и добавочный номер.
Назначение на основе API
Используйте API для программного назначения лицензий и управления пользователями.
поддерживает операции API для управления пользователями и лицензиями (API People, SCIM 2.0 и Licenses), которые можно использовать для автоматизации выдачи лицензий. API лицензий позволяет одновременно назначать лицензии, телефонные номера и расширения.
| Метод назначения | Плюсы | Минусы |
|---|---|---|
| Вручную через | Просто для нескольких пользователей. Позволяет точно и детально контролировать выдачу лицензий. | Не масштабируется, отнимает много времени При ручном вводе подвержен человеческим ошибкам. |
| Шаблоны автоматических лицензий | масштабируемые Уменьшает количество ручных ошибок Может применяться как к новым, так и к существующим пользователям. | Требуются действительные телефонные номера и адреса. Более сложный в настройке Кроме того, требуется, чтобы на каждую группу пользователей приходились группы пользователей с эквивалентными лицензионными требованиями. |
| Массовая загрузка CSV-файлов | Эффективна для больших групп пользователей Позволяет одновременно назначать лицензии, телефонные номера и расширения. | Требует тщательного форматирования CSV Возможны ошибки, если телефонные номера или добавочные номера отсутствуют или неверны. |
| Назначение на основе API | Автоматизируется, гибко. Позволяет одновременно назначать лицензии, телефонные номера и расширения. | Требуются знания в области разработки и API. |
В таблице «Варианты предоставления пользователям» — сводка приведена сводная информация о вариантах подготовки пользователей, а также об их плюсах и минусах. Этот обзор помогает выбрать оптимальный метод назначения лицензий с учетом размера организации заказчика, возможностей автоматизации, процессов и требований к подготовке пользователей.
По возможности Cisco рекомендует назначать лицензии на звонки с использованием шаблонов лицензий. Для этого каждой группе пользователей требуется уникальный набор лицензий (например, Standard vs. (Professional) существует группа, состоящая из членов соответствующей группы. Как описано в разделах «Группы пользователей», группы пользователей можно создавать вручную или синхронизировать из корпоративного каталога. Возможна комбинация обоих подходов.
Пользователи, принадлежащие к нескольким группам, получают лицензии на выполнение всех заданий, применяемых ко всем группам. Это позволяет использовать специальные группы безопасности в каталоге предприятий для управления назначением лицензий, при этом конечное назначение лицензий пользователям контролируется объединением членов групп.
Дополнительные сведения см. в разделах Настройка автоматического назначения лицензий в Control Hub и Настройка шаблонов автоматического назначения лицензий для Webex Calling пользователей.
Лицензионные требования
В этом разделе рассматриваются только соответствующие лицензии. Другие типы лицензий (например, регистрация устройств Webex, обмен сообщениями, совещания) не рассматриваются. В процессе проектирования необходимо определить лицензионные требования. Необходимо рассчитать количество лицензий для следующих типов лицензий:
-
Стандарт: количество отдельных пользователей, которым требуются стандартные функции телефонии.
-
Профессионал: количество пользователей и рабочих мест, требующих расширенных функций телефонии. Виртуальные линии и групповая голосовая почта имеют право на получение каждой профессиональной лицензии в соотношении 1:1. Поэтому в редких случаях, когда количество необходимых виртуальных линий или групповых голосовых сообщений превышает количество пользователей и рабочих мест, требующих расширенных функций телефонии, необходимо учитывать дополнительные профессиональные лицензии.
-
Рабочее пространство для общего пользования: количество мест общего пользования или мест общего пользования, где требуется стандартная телефонная связь.
-
Служба поддержки клиентов: количество агентов и супервайзеров, которым требуются функции поддержки клиентов. Служба поддержки клиентов включает профессиональную лицензию.
-
Вызовы из списка маршрутов: количество необходимых вызовов PSTN, подключенных к облаку, между локальными пользователями и/или локальными специализированными сторонними приложениями.
-
Консоль сопровождающего: количество пользователей, которым требуется доступ к клиенту консоли сопровождающего.
-
План звонков Cisco (план исходящих вызовов): количество пользователей, которым требуется номер PSTN и/или доступ к исходящим вызовам PSTN для службы Cisco PSTN.
Для профессиональных рабочих пространств не существует специального типа лицензии. Для профессиональных рабочих пространств требуется лицензия Professional.
Рабочие места, работающие только на горячих столах, предоставляют услуги хоста и экстренные вызовы от хоста, работающего на горячих столах, и для их использования не требуется лицензия. Дополнительные сведения см. в разделе Добавление устройств, работающих только в режиме «горячий стол», и управление ими.
Чтобы определить необходимый тип лицензии для каждого пользователя и рабочего пространства на основе необходимых функций, см. раздел Функции, доступные по типам лицензий для Webex Calling.
Чтобы отличить функциональность очередей вызовов в сочетании с профессиональной лицензией от функций поддержки клиентов, см. в разделе Сравнение функций очереди Webex Calling вызовов и поддержки клиентов.
Подготовка пользователей
При подготовке пользователей в Webex доступно несколько вариантов, каждый из которых соответствует различным организационным потребностям и средам:
-
Ручное выделение ресурсов: администраторы могут добавлять отдельных пользователей и управлять ими непосредственно в системе. Этот метод прост, но лучше всего подходит для небольших организаций или ограниченного числа пользователей .
-
Массовое выделение ресурсов с помощью CSV-файлов. Для больших баз пользователей администраторы могут массово импортировать и обновлять пользователей, загружая туда файлы CSV. Это позволяет эффективно управлять тысячами пользователей одновременно.
-
Варианты синхронизации каталогов:
Directory Connector: это инструмент автоматической синхронизации, используемый в Microsoft Active Directory средах. Он синхронизирует учетные записи пользователей, группы и атрибуты по расписанию (ежечасно, ежедневно или еженедельно). Он поддерживает многодоменные настройки и Active Directory настройки с несколькими лесами и может синхронизировать изображения профиля и объекты комнат.
Приложение-мастер Entra ID (Azure AD): этот метод, разработанный для организаций, использующих Microsoft Entra ID (Azure AD), обеспечивает автоматическую синхронизацию учетных записей и атрибутов пользователей практически в реальном времени непосредственно с Entra ID в. Он полностью управляется и требует минимальной настройки.
Приложения SCIM 2.0. Для сред, отличных от Microsoft, или других поставщиков идентификационных данных, таких как Okta или Duo, приложения для синхронизации на основе SCIM позволяют автоматически выделять и удалять пользователей с помощью сопоставления атрибутов и синхронизации групп.
-
Unified CMсинхронизация пользователей: эта опция позволяет создавать учетные записи пользователей на основе существующих конечных пользователей путем синхронизации от до. Для этого необходимо, чтобы подключенные к облаку UC (CCUC) работали в локальных кластерах. Однако обычно рекомендуется синхронизировать пользователей из централизованного облачного каталога, такого как Entra ID, а не напрямую из него.
-
Предоставление API: для подготовки пользователей можно использовать общедоступные API (People, SCIM 2.0). Основным преимуществом использования API является возможность интеграции пользовательского обеспечения с другими корпоративными системами.
В этом обзоре и таблице представлены основные варианты подготовки пользователей, их преимущества и ограничения, которые помогут вам выбрать наилучший подход, отвечающий потребностям вашей организации.Таблица 6. Варианты подготовки пользователей для Метод выделения ресурсов Описание Плюсы Минусы Ручная Создавайте пользователей и управляйте ими по отдельности в Просто для нескольких пользователей; инфраструктура не требуется Не масштабируется; для многих пользователей требуется много времени Массовая обработка (CSV-файл) Массовый импорт/обновление пользователей через CSV-файл в Эффективно для групп; программирование не требуется Ручная подготовка CSV; менее динамичная Люди и API SCIM 2.0 Программное управление пользователями с помощью API Webex Гибкое; поддерживает автоматизацию и интеграцию Требуется разработка и инфраструктура Синхронизация каталогов Автоматическая синхронизация с приложениями AD, Entra ID, SCIM, Unified CM Автоматизирует жизненный цикл; поддерживает фильтрацию и картографирование Сложность настройки: некоторые из опций имеют ограниченные возможности или требуют инфраструктуры
Группы пользователей
Управление группами пользователей позволяет администраторам объединять пользователей в группы для эффективного массового управления лицензиями, настройками и ресурсами. Группы помогают упростить администрирование, применяя политики, лицензии и шаблоны настроек одновременно к нескольким пользователям, а не управляя пользователями по отдельности.
Управление группами пользователей дает ряд преимуществ, в том числе:
-
Упрощенное администрирование: управление лицензиями, настройками и политиками для нескольких пользователей одновременно.
-
Согласованность: применяйте одинаковые настройки и лицензии для всех пользователей в одной группе.
-
Масштабируемость: поддерживает до 250 000 участников в каждой группе.
-
Интеграция: синхронизация групп из Microsoft Entra ID (Azure AD) или Active Directory для автоматического управления пользователями и группами.
-
Гибкость: создание локальных групп или синхронизация групп безопасности; управление членством в группах вручную или с помощью файлов CSV.
-
Распределение ресурсов: управление доступом к встроенным приложениям и сервисам на основе членства в группах.
Основные варианты использования групп пользователей при выделении ресурсов:
-
Назначение лицензий: назначайте лицензии группам для автоматического предоставления членам группы таких услуг, как звонки, встречи, обмен сообщениями или гибридные услуги.
-
Шаблоны настроек: применяйте наборы сервисных настроек (например, обмен сообщениями, встречи, звонки) к группам для обеспечения единообразия пользовательского интерфейса.
-
Массовое управление пользователями: массовое добавление или удаление пользователей с помощью файлов CSV или синхронизации каталогов.
-
Автоматизация и интеграция: используйте API или синхронизацию каталогов для автоматического управления жизненным циклом пользователей и групп.
В следующей таблице перечислены различные варианты управления группами пользователей и управления группами в.
| Опция | Описание | Плюсы | Минусы |
|---|---|---|---|
| групповое обеспечение (группы) | Создавайте группы и управляйте ими непосредственно в. Добавляйте/удаляйте участников вручную или через CSV. | Полный контроль над членством в группе Немедленное применение лицензий и шаблонов Легко создавать и редактировать группы |
Требуется ручное обновление Риск ошибок при ручной загрузке CSV Нет автоматической синхронизации с внешними каталогами |
| Синхронизированные группы из Entra ID (Azure AD) или Active Directory | Автоматическая синхронизация групп безопасности и членства во внешних службах каталогов . | Автоматическая синхронизация сокращает объем ручной работы Обеспечивает согласованность с корпоративным каталогом Поддерживает крупные организации |
Невозможно изменить членство в группе в Задержка синхронизации до 12 часов Вложенные группы необходимо выбирать вручную |
| Группы и API SCIM 2.0 (группы) | Используйте группы или SCIM 2.0 API для программного управления группами и членством | Автоматизация и интеграция с другими системами Масштабируемость для больших или сложных сред |
Требует усилий по разработке Сложность зависит от использования API |
В то время как синхронизированные группы обеспечивают согласованность и предоставляют единую точку администрирования, возможен гибридный подход, сочетающий синхронизированные группы и группы (управляемые в центре управления или с помощью API). Так, например, группы для назначения лицензий могут быть синхронизированными группами, а отдельный набор групп можно использовать для назначения шаблонов пользователям и вызовам.
Такой комплексный подход к управлению группами пользователей позволяет организациям эффективно управлять пользовательскими лицензиями, настройками и политиками, обеспечивая согласованную и масштабируемую совместную работу.
Рекомендуемый подход при переходе с на
Основным источником данных для пользователей является база данных, содержащая информацию о конечных пользователях. Однако она, как правило, не является авторитетным источником для управления идентификационными данными пользователей и, что более важно, в конце переходного периода она будет закрыта и поэтому не будет использоваться в качестве надежного источника идентификационной информации в долгосрочной перспективе.
Cisco рекомендует использовать централизованный облачный каталог, такой как Microsoft Entra ID (Azure AD), в качестве единственного источника достоверной информации об идентификаторах пользователей. Синхронизация пользователей из Entra ID обеспечивает согласованность, упрощает управление и поддерживает возможности единого входа (SSO).
Чтобы убедиться, что все пользователи также присутствуют в Entra ID, организациям следует убедиться, что учетные записи пользователей соответствуют учетным записям в Entra ID. Это можно сделать, экспортировав списки пользователей из Entra ID и сравнив их со списками пользователей Entra ID.
Таким образом, рекомендуемый метод подготовки — синхронизация пользователей из Microsoft Entra ID (Azure AD) в Webex с помощью мастера Azure AD или приложений SCIM. Массовое выделение ресурсов вручную и в формате CSV доступно в качестве дополнительных методов, но для крупных организаций оно менее масштабируемо и более подвержено ошибкам. Обеспечение того, что Entra ID является достоверным источником и что в Entra ID присутствуют все пользователи, крайне важно для успешной миграции и обеспечения единообразия пользовательского опыта в разных средах.
Переход от локальной службы каталогов, например, к облачной службе каталоговActive Directory, такой как Entra ID (Azure ID), не зависит от передачи вызовов. Cisco рекомендует завершить переход на облачную службу каталогов, прежде чем начинать переход на вызовы.
Проектирование групп пользователей
После переноса корпоративного каталога из локального хранилища в облако соберите необходимые группы пользователей в соответствии с требованиями лицензий и шаблонов функций. Для каждого группового документа:
-
Имя группы: уникальное имя группы.
-
Лицензии: лицензии, которые должны быть отнесены к этой группе (если таковые имеются), и область действия (должны ли лицензии предоставляться существующим пользователям или только новым пользователям)
-
Шаблоны настроек: приложение Webex и шаблоны вызовов пользователей.
-
Синхронизация каталогов: будет ли эта группа синхронизироваться с корпоративным каталогом или это локальная группа Webex, созданная в Control Hub или через API.
-
Описание: как будет использоваться эта группа и какие пользователи должны входить в эту группу
Эти сведения будут использованы позже на этапе внедрения для создания локальных групп или групп в каталоге предприятий и управления членством пользователей в группах.
Система единого входа (SSO)
Cisco рекомендует использовать SSO для аутентификации пользователей. Использование SSO имеет ряд убедительных преимуществ, в том числе:
-
Упрощенная аутентификация пользователей: пользователи могут войти в систему один раз, используя свои корпоративные учетные данные (например, из Azure ID) для доступа к другим интегрированным приложениям и другим интегрированным приложениям, что устраняет необходимость в использовании нескольких паролей и сокращает количество запросов при входе в систему. Это повышает безопасность, гарантируя, что корпоративные пароли после аутентификации никогда не сохраняются и не передаются.
-
Упрощенное управление пользователями: автоматизирует создание, обновление и деактивацию учетных записей пользователей в зависимости от изменений в корпоративном каталоге, сокращая административные издержки и обеспечивая доступ только авторизованным пользователям.
-
Повышенная безопасность: система единого входа снижает усталость от паролей и риск взлома паролей за счет централизации аутентификации с помощью доверенных поставщиков идентификационных данных (IDP).
-
Простая интеграция многофакторной аутентификации (MFA): MFA можно легко поддерживать с помощью решения для управления доступом к идентификационным данным, такого как Cisco Duo, или с помощью поддержки IdP в многофакторной аутентификации.
Существует несколько вариантов внедрения единого входа в сервисы:
-
SSO на базе SAML 2.0: основной протокол, поддерживаемый для интеграции SSO и обеспечивающий безопасный обмен аутентификационной информацией между IdP и поставщиком услуг.
-
OpenID connect (OIDC): поддерживается в качестве альтернативного современного протокола аутентификации для интеграции SSO.
-
Webex identity: также поддерживается в качестве опции поставщика идентификационных данных.
SSO настраивается и управляется централизованно, поэтому требуется обмен метаданными между выбранным IdP и выбранным IdP.
После настройки SSO можно протестировать перед активацией, чтобы убедиться в правильной настройке.
Cisco поддерживает интеграцию с несколькими протестированными и часто используемыми IDP и системами управления идентификацией (IAM), включая, помимо прочего, следующее:
-
Cisco Duo
-
Окта
-
Microsoft Active DirectoryСлужбы федерации (ADFS)
-
Microsoft Azure
-
Ping Federate
-
Открыть AM
-
F5 BIG-IP.
Эти ВПЛ соответствуют стандартам SAML 2.0 или OpenID Connect и прошли проверку на совместимость с решениями Cisco для совместной работы.
Поддержка нескольких IdP
позволяет организациям настраивать систему единого входа с несколькими ВПЛ в сложных ИТ-средах, таких как слияния, поглощения или децентрализация ИТ-отделов, где разные группы используют разных ВПЛ. Поддержка нескольких IdP может быть реализована либо с помощью функции Multiple IdP, либо путем интеграции корпоративной системы IAM, такой как Cisco Duo.
поддержка нескольких поставщиков удостоверений (IdP) предназначена для нескольких ключевых случаев использования, когда организациям требуется гибкая и безопасная аутентификация в различных ИТ-средах:
1. Слияния и поглощения
Когда компании объединяются или приобретают другие, у них часто возникают отдельные ИТ-инфраструктуры и отдельные ВПЛ, которые не могут объединиться в федерацию. Поддержка нескольких IdP позволяет пользователям обеих организаций безопасно аутентифицироваться и сотрудничать без необходимости немедленно унифицировать свои системы идентификации.
2. Несколько независимых ИТ-отделов
Крупные организации или государственные учреждения могут иметь несколько независимых ИТ-отделов, каждый из которых управляет своим собственным ВПЛ. функция множественных IdP позволяет этим отделам поддерживать собственные системы аутентификации, обеспечивая при этом беспрепятственный доступ пользователей.
3. Различные группы пользователей или домены
Организации с разными группами пользователей (например, сотрудники или подрядчики) или несколькими доменами электронной почты могут настроить правила маршрутизации таким образом, чтобы запросы на аутентификацию направлялись соответствующему IdP в зависимости от принадлежности к домену или группе. Это обеспечивает дифференцированные политики доступа и средства управления безопасностью.
4. Поддержка различных протоколов аутентификации
поддерживает ВПЛ SAML и OpenID Connect (OIDC), что позволяет организациям интегрировать различные типы поставщиков идентификационных данных в соответствии с существующей инфраструктурой и требованиями безопасности.
5. Повышенная безопасность и соответствие нормативным требованиям
Предоставляя возможность нескольким ВПЛ, организации могут внедрить более надежные механизмы аутентификации, включая многофакторную аутентификацию (MFA), с помощью таких интеграций, как Duo, и применять согласованные политики безопасности для различных баз пользователей.
6. Упрощенный пользовательский интерфейс
Пользователи могут аутентифицироваться, используя свои учетные данные соответствующих ВПЛ, что обеспечивает унифицированный вход в систему, несмотря на сложность нескольких систем идентификации.
Хотя поддержка нескольких IdP обеспечивает гибкость, для поддержания последовательных политик безопасности и предотвращения потенциальных уязвимостей требуется тщательная координация действий групп безопасности и идентификации.
Двойная многофакторная аутентификация с системой SSO для
Duo Access Gateway (DAG) может аутентифицировать пользователей с помощью существующих локальных или облачных каталогов, таких как Active Directory (AD) и OpenLDAP. Он также поддерживает интеграцию с другими поставщиками удостоверений, такими как Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS и Shibboleth. Такая гибкость позволяет организациям использовать текущую инфраструктуру каталогов для Webex SSO с помощью Duo MFA .
Duo выступает в качестве надежного уровня аутентификации в дополнение к аутентификации основного каталога. Он выступает в роли поставщика идентификационных данных (IdP), используя SAML 2.0 для обеспечения двухфакторной аутентификации (2FA) перед предоставлением доступа. Duo оценивает контекст пользователя, устройства и сети в соответствии с настраиваемыми политиками, разрешающими или запрещающими доступ, что повышает безопасность не только имени пользователя и пароля. Duo также предоставляет гибкие средства управления политиками, например требование многофакторной аутентификации при каждом входе в систему для одних приложений и реже для других.
К преимуществам Cisco Duo относятся:
-
Повышенная безопасность: добавлена устойчивая к фишингу многофакторная аутентификация для защиты доступа и снижения риска взлома паролей.
-
Гибкие политики: позволяет детально контролировать требования к аутентификации для каждого приложения или группы пользователей.
-
Интеграция с существующими каталогами: поддерживает локальные AD, OpenLDAP, облачные каталоги и различных поставщиков SSO, сводя к минимуму изменения в инфраструктуре.
-
Удобство пользователя: поддержка технологии единого входа (SSO) позволяет снизить усталость от паролей, позволяя пользователям входить в систему один раз и безопасно получать доступ к нескольким ресурсам.
-
Надежные конечные точки: поддержка доверия к устройствам для клиентов в Windows и macOS, повышая уровень безопасности.
-
Самостоятельная регистрация: онлайн-регистрация и двусторонняя подсказка улучшают пользовательский интерфейс при настройке MFA.
Duo MFA и SSO позволяют использовать существующие каталоги, такие как OpenLDAP или Active Directory облачные поставщики идентификационных данных, для аутентификации пользователей. Роль Duo заключается в обеспечении надежного второго фактора аутентификации, основанного на политиках, интегрированного в SAML 2.0, повышающего безопасность и одновременно обеспечивающего удобство пользователей с помощью единого входа. К преимуществам относятся повышение уровня безопасности, гибкое применение политик, беспрепятственная интеграция и улучшение пользовательского опыта.
Cisco рекомендует внедрить SSO для пользователей. Для повышения безопасности рекомендуется интеграция с Cisco Duo.
Перед началом перехода на корпоративную стратегию IAM и SSO следует внедрить.
Функции
имеет полный набор основных функций, включенных в сервис. Сюда входит множество функций звонков корпоративного уровня, которые доступны уже много лет. Возможно, вы не увидите стопроцентного соотношения между функциями и функциями, однако, как показано на рисунке ниже, основные функции звонков доступны в.
Помимо множества пользовательских функций, имеет основные системные функции, включенные в платформу. К ним относятся такие функции, как автосекретари, очереди вызовов, парковка вызовов и т. д. Все доступные основные функции системы можно увидеть в разделе Сервис → Вызовы → Функции, как показано на Webex Calling рисунке Основные функции.
Автосекретарь
Автосекретарь позволяет круглосуточно автоматизировать обработку входящих вызовов, что позволяет эффективно обрабатывать звонки без необходимости отвечать на каждый звонок.
Автосекретарь отвечает на входящие звонки и предоставляет звонящему меню с опциями, указывающими, куда он хочет направить свой вызов. Это может быть адресовано человеку, ящику голосовой почты или службе телефонной связи (например, Очередь звонков). Звонящий использует клавиатуру телефона для ввода номера из меню автосекретаря.
Автосекретарь поддерживает следующие ключевые функции:
-
Рабочее расписание и расписание в нерабочее время
-
График праздничных дней
-
Опция меню набора номера, позволяющая клиентам направлять их туда, куда им нужно
-
Настройте приветствия
-
Опция набора по имени
-
Опции переадресации звонков
-
Аналитика и отчеты Control Hub.
Дополнительные сведения см. в разделе Управление автосекретарями.
Парк вызовов
Парковка вызовов позволяет пользователям легко отложить звонок, чтобы другой пользователь мог с легкостью ответить на звонок в тот момент, когда он сможет его принять. Это также позволяет пользователю, ответившему на исходный звонок, звонить или принимать другие звонки, пока звонок припаркован.
Доступны два типа парков вызовов:
-
Call Park direct — позволяет любому пользователю припарковать звонок на добавочный номер другого пользователя или на номер телефонного парка в соответствии с определением Администратора
-
Группа парковки вызовов — позволяет определенной группе пользователей автоматически парковать звонки в доступных местах парковки, определенных для группы. Этими пунктами назначения могут быть добавочные номера членов группы или номера телефонных парковок.
В зависимости от конфигурации и типа парковки пользователи могут принимать звонки, набирая *88+>, <extension of parked call>нажимая линейную клавишу, связанную с добавочным номером парка вызовов, или используя функциональную клавишу на своем IP-телефоне.
Доступна опция отзыва, позволяющая отозвать припаркованный звонок по истечении указанного периода времени пользователю, который припарковал звонок, или другому пользователю.
Дополнительные сведения см. в разделе Управление парком вызовов в Control Hub.
Перехват вызова
Функция приема вызовов позволяет администратору определить группу пользователей (участников), которые могут ответить на звонок на телефон другого участника. Это дает пользователю возможность отвечать на звонки, когда его товарищи по команде заняты и не могут ответить на входящий звонок.
Пользователи в группе должны находиться в одном и том же месте.
Для ответа на звонок пользователи могут использовать стационарный телефон или телефон.
-
:
-
Поддерживает визуальные и звуковые уведомления
-
Уведомление о входящих звонках
-
По факсу (наберите*98) или с уведомлением о приеме вызова
-
Уведомления о приеме вызовов для нескольких линий.
-
-
Настольные телефоны:
-
Уведомление о входящих звонках
-
Звуковые колокольчики и визуальные уведомления через светодиод телефона. 6821 поддерживает только звуковые сигналы
-
Если тип уведомления, выбранный в поле, не равен нулю
-
-
Уведомления о приеме вызовов только для основных линий.
-
Дополнительные сведения см. в разделе Настройка группы приема вызовов.
Очередь звонков
включает в себя очереди вызовов только голосовой связи как часть своих основных функций. Любой пользователь с лицензией Professional может быть частью очереди вызовов, агентом или супервизором. Эта функция позволяет пользователям эффективно взаимодействовать с клиентами. Очереди вызовов поддерживают ряд некоторых основных функций колл-центра, таких как голосовые очереди, обратный вызов, маршрутизация навыков или приоритетов, управление очередью агентов, аналитика, отчетность и т. д.
Интеграция Cisco Call for Microsoft Teams позволяет агентам получать доступ к вызовам и функциям очереди вызовов непосредственно из клиента Microsoft Teams.
Очереди вызовов поддерживают следующие ключевые функции:
-
Приветствия и сообщения (приветствие, утешение, шепот и т. д.)
-
Удерживайте музыку
-
Перезвоните
-
Правила маршрутизации очередей (обслуживание в ночное время, праздничные дни, пересылка)
-
Вход/выход из очереди агентов
-
Управление статусом очереди агентов
-
или поддержка по настольному телефону
-
Агент-супервайзер звонит монитору, тренеру, барже или перевозчику с помощью кодов доступа к объектам (FAC)
-
(доступ администратора) для:
-
управление очередями
-
Аналитика и отчетность по агентам и очередям
-
Управление очередями, агентами и супервизорами.
-
Дополнительные сведения см. в разделе Настройка очереди вызовов.
имеет дополнительную функцию Customer Assist, которая предоставляет дополнительные возможности очереди вызовов и повышает удобство работы агентов и супервизоров. Сравнение функций «Очередь вызовов» и «Помощь клиентам» см. в разделе Сравнение функций очереди Webex Calling вызовов и поддержки клиентов.
Охотничья группа
Hunt Groups позволяет маршрутизировать входящие звонки определенной группе пользователей по заранее заданной схеме маршрутизации вызовов. Это гарантирует, что нужная группа пользователей отвечает на вызовы или отправляет их на голосовую почту для ответа.
Одно из главных отличий между охотничьими группами и очередями вызовов заключается в том, что вызовы не ставятся в очередь в Охотничьи группы, поэтому, если в охотничьей группе нет пользователей, готовых ответить на звонок, звонок будет отключен, отправлен на голосовую почту или переадресован на другой номер (пользователя или услугу).
Дополнительные сведения см. в разделе Управление охотничьими группами в Control Hub.
Режимы работы
Функция «Режимы работы» позволяет компаниям эффективно направлять звонки различным адресатам (пользователям, голосовой почте, службам вызова, например очереди вызовов). Информация о том, куда и когда будет перенаправлен звонок, зависит от времени суток и дня недели, и любому пользователю может быть разрешено управлять этими режимами ( расписаниями) для управления изменениями в маршрутизации вызовов.
Например, звонки в очередь вызовов можно перенаправить в другую очередь вызовов, а агенты, работающие в другом часовом поясе, будут отвечать на звонки в нерабочее время, в рабочее время перенаправлять на местных агентов, а в праздничные дни — на голосовую почту для ответа после возвращения агентов в офис.
Авторизованный пользователь может переключаться между этими различными сценариями (режимами) переадресации вызовов, если ему необходимо изменить направление маршрутизации входящих вызовов на определенный период. Эти пользователи могут управлять режимами на своих телефонах 6800/7800/8800 MPP, 9800 или в Центре пользователей в разделе «Управление режимами».
Пейджинговая группа
Группы пейджинга позволяют пользователям совершать односторонний вызов для отправки аудиосообщения группе пользователей. Каждая группа может содержать до 75 целевых пользователей и/или рабочих пространств, с которыми можно связаться, набрав заранее определенный номер или добавочный номер.
Когда пользователь звонит в пейджинговую группу, одновременно звонит всем назначенным адресатам в группе, после чего звонящий может произнести свои сообщения и положить трубку, когда они закончат.
Дополнительные сведения см. в разделе Настройка пейджинговой группы в Control Hub.
Записи
поддерживает запись звонков, сделанных или полученных пользователем. Это может потребоваться для обеспечения качества, обеспечения безопасности или обучения. По умолчанию звонки записываются, но можно также использовать услуги других сторонних поставщиков звукозаписи, если требуются другие функции записи или требования соответствия нормативным требованиям.
При использовании в качестве платформы для записи все записанные звонки управляются внутри. Воспроизводить и скачивать записи могут полноправные администраторы, выполняющие роль уполномоченного по соблюдению нормативных требований. Без роли сотрудника по соблюдению нормативных требований администратор может удалять только записи.
Дополнительные сведения об этой функции и список записей сторонних производителей см. в разделе Управление записью разговоров для Webex Calling.
Охват одним номером
Охват одного номера позволяет звонить на телефонный номер пользователя на несколько устройств. Сюда могут входить другие настольные телефоны, а также мобильные телефоны. С этих устройств также можно звонить, а пользователи могут отправлять и принимать вызовы между ними.
Дополнительные сведения об этой функции и о том, как администратор настраивает ее, см. в разделе Настройка связи по единому номеру (офис в любом месте).
Дополнительные сведения о том, как пользователь может управлять этой функцией и настраивать ее для себя на Webex User Hub (портале), см. в разделе Настройка охвата одним номером (офис в любом месте).
Группа голосовой почты
Группы голосовой почты позволяют создать общий ящик голосовой почты, который можно присвоить пользователю или функции маршрутизации вызовов. Вот некоторые из причин, по которым может потребоваться группа голосовой почты:
-
Голосовая почта общего назначения для отдела или рабочей группы
-
Добавьте опцию голосовой почты автосекретарю или охотничьей группе
-
Для отправки переполненных вызовов из очереди вызовов
-
Пользователи, которым нужен только ящик голосовой почты.
Дополнительные сведения см. в разделе Управление общей голосовой почтой и входящим факсом для. Webex Calling
Консоль сопровождающего указана на странице Функции звонков в Webex, однако это дополнительная функция, для использования которой требуется приобрести лицензию на консоль оператора.
Дополнительные сведения см. в разделе Начало работы с консолью Attendant.
Сведения обо всех функциях, включая некоторые дополнительные, см. в разделе Функции, доступные по типам лицензий на Webex Calling.
Внедрить
Готовность сети
Первым шагом при переходе на Интернет является обеспечение надежного и безопасного подключения к Интернету между локальной сетью и облаком.
Поскольку большинство организаций подключаются к Интернету через один или несколько брандмауэров или устройств безопасности, важно убедиться, что требуемые потоки трафика поддерживаются.
Администраторы сети и системы безопасности должны понимать эти потоки с точки зрения:
-
Направление (входящие и исходящие)
-
Протоколы (например, SIP, TLS, SRTP, HTTPS)
-
Диапазоны IP-адресов, используемые сервисами
-
Номера портов, которые необходимо открыть или разрешить.
Это обеспечивает правильную настройку корпоративных брандмауэров, устройств NAT и другой сетевой инфраструктуры для приема трафика при соблюдении корпоративных политик безопасности.
Сведения о необходимых потоках, включая IP-адрес, порты и протоколы, см. в разделе Справочная информация по Webex Calling портам. Используйте эту информацию для настройки брандмауэра, прокси-серверов и другой сетевой инфраструктуры в существующем развертывании для обеспечения сетевых потоков.
Для таких облачных сервисов для совместной работы, как децентрализованное подключение к Интернету из каждого филиала или сайта, рекомендуется использовать такие облачные сервисы для совместной работы, как. Разрешая локальный выход трафика, эта модель:
-
Уменьшает задержку и дрожание в обе стороны, улучшая общее качество звонков
-
Эффективно масштабируется по мере того, как все больше пользователей и сайтов переходят на
-
Отлично работает с SD-WAN, которая позволяет динамически направлять сеансы в ближайшую точку входа в облако для обеспечения оптимальной производительности
- Позволяет отслеживать местоположение пользователей на основе их публичного IP-адреса, что помогает анализировать медиаканалы и устранять неполадки.
Кроме того, организации должны обеспечить достаточную пропускную способность Интернета на каждом сайте. Пропускную способность следует определять исходя из ожидаемого количества одновременных вызовов, выбранного кодека (например, Opus или G.711), а также затрат на передачу сигналов, ретрансляцию и рост трафика. Это соответствует этапу подготовки жизненного цикла PPDIO и создает прочную основу для миграции.
Первоначальная настройка
Подраздел «Первоначальная настройка» на этапе внедрения является основой для создания хорошо структурированной и управляемой облачной среды вызовов. На этом этапе решаются такие важные задачи, как создание организации, приобретение и распределение лицензий, проверка и регистрация доменов вашей компании для обеспечения надлежащего управления пользователями и их безопасности. Кроме того, он включает подготовку шаблонов лицензий для автоматизации присвоения лицензий пользователям, настройку системы единого входа (SSO) для упрощения аутентификации пользователей и повышения безопасности, а также корректировку настроек сервисов и клиентов в соответствии с политиками организации и потребностями пользователей. Выполнение этих первоначальных действий по настройке позволяет обеспечить надлежащую конфигурацию среды для обеспечения масштабируемости, безопасности и удобного пользовательского интерфейса, а также подготовить почву для последующих этапов развертывания и эксплуатации.
Верификация домена
Чтобы можно было идентифицировать пользователей, зарегистрированных на доменах электронной почты вашей компании, необходимо подтвердить ваши домены. Без проверки домена пользователи будут переведены в организацию потребителей, что усложнит управление пользователями в вашей компании. Проверка домена — обязательный шаг, позволяющий вашей организации привлекать таких пользователей и эффективно управлять ими.
Убедитесь, что все домены, связанные с адресами электронной почты ваших пользователей, проверены. Проверка домена не является эксклюзивной задачей; один и тот же домен можно проверить в нескольких организациях.
Дополнительные сведения об управлении доменами см. в разделе Управление доменами.
Запрашивайте (конвертируйте) существующих пользователей
После успешной проверки доменов вы можете приступить к регистрации пользователей, которые зарегистрировались для использования доменов электронной почты вашей компании, в вашей организации. Этот процесс объединяет всех пользователей в единую организационную структуру, обеспечивая централизованное управление и упрощенное администрирование. Заявив об этих пользователях, вы гарантируете, что ваша компания полностью контролирует учетные записи пользователей, что позволит вам эффективно назначать соответствующие лицензии, настраивать службы и оказывать необходимую поддержку. Такой унифицированный подход к управлению повышает безопасность, упрощает подготовку пользователей и обеспечивает постоянный доступ к услугам в вашей организации. Утверждение пользователей также предотвращает управление ими во внешних организациях или организациях потребителей, тем самым обеспечивая организационную целостность и контроль над ресурсами для совместной работы.
Дополнительные сведения о привлечении пользователей см. в разделе Заявка пользователей на участие в организации (преобразование) пользователей.
Настройте и протестируйте синхронизацию каталогов
Чтобы обеспечить удобное управление пользователями и группами, вы можете синхронизировать пользователей и группы из своего корпоративного каталога с помощью Microsoft Entra ID (ранее Azure AD) или Microsoft Active Directory (AD) в. Этот процесс обеспечивает постоянное сохранение идентификационных данных пользователей и членства в группах в вашей среде.
Для организаций, внедряющих поэтапное развертывание, крайне важно контролировать и ограничивать объем синхронизации во время первоначального развертывания. Это сводит к минимуму риск непреднамеренных изменений и позволяет проводить целенаправленное тестирование перед более широким внедрением.
Самый эффективный метод фильтрации синхронизируемых пользователей — использование членства в группах каталогов:
| 1 |
Создайте специальную группу синхронизации: в корпоративном каталоге (Microsoft Entra ID или AD) создайте группу безопасности, специально предназначенную для синхронизации (например, группу синхронизации). |
| 2 |
Заполните группу целевыми пользователями: добавьте в эту группу только тех пользователей, которых хотите синхронизировать (например, тестовую группу на пилотном этапе). Это позволяет жестко контролировать, кто участвует в процессе синхронизации. |
| 3 |
Настройте соглашение о синхронизации с помощью групповой фильтрации: при настройке соглашения о синхронизации в Directory Connector или Entra ID настройте область, включив в нее только пользователей, входящих в указанную группу.
|
| 4 |
При необходимости расширяйте группу. По мере перехода к более широким этапам развертывания просто добавляйте дополнительных пользователей или группы в группу синхронизации. Область синхронизации автоматически расширится и будет включать этих пользователей, что позволит осуществлять ее контролируемое и постепенное развертывание. Примеры этапов внедрения:
Ссылки: Синхронизируйте пользователей Entra ID с Control Hub |
Настройте и протестируйте систему единого входа (SSO)
Система единого входа (SSO) повышает безопасность и упрощает доступ пользователей, позволяя пользователям пройти однократную аутентификацию, используя свои корпоративные учетные данные, и получить беспрепятственный доступ к ним. поддерживает интеграцию SSO с ВПЛ, совместимыми с SAML 2.0, включая Microsoft Entra ID (ранее Azure AD), Active Directory федеративные решения (AD) и различных сторонних ВПЛ.
На этом этапе разработанная настройка SSO должна быть реализована и протестирована.
Ссылки:
Интеграция системы единого входа в центр управления
настройте систему единого входа для администрирования webex
Настройте систему единого входа с помощью Microsoft Entra ID
SSO с несколькими внутренне перемещенными лицами
Управляйте системой единого входа при интеграции в Control Hub
Приобретайте, предоставляйте и проверяйте лицензии
При первоначальной настройке важно приобрести, предоставить и проверить соответствующие лицензии для эффективного предоставления услуг и управления ими. Процесс закупки включает выбор типов лицензий в зависимости от ролей пользователей и рабочих нагрузок, таких как лицензии Professional, Standard и Workspace . Лицензии генерируются и предоставляются с помощью программных платформ Cisco или партнеров . После приобретения и предоставления лицензий необходимо проверить правильность количества лицензий. Этот процесс гарантирует, что в организации активированы и готовы к использованию при развертывании нужные лицензии.
При первоначальной настройке лицензирования важно настроить автоматическое лицензирование на уровне организации, чтобы упростить выдачу лицензий новым пользователям. Эта настройка позволяет автоматически выдавать лицензии при добавлении пользователей в организацию, устраняя необходимость в ручном назначении лицензий. При настройке автоматического лицензирования на уровне организации вы выбираете сервисы для назначения и определения области действия, например, выдача лицензий только будущим пользователям или включение существующих пользователей.
Однако если ваш план развертывания предусматривает автоматическое лицензирование на уровне групп , вы можете отказаться от назначения лицензий на уровне организации во избежание конфликтов или дублирования лицензий. При автоматическом лицензировании на уровне групп лицензии назначаются на основе членства в группе. Пользователи, входящие в несколько групп, получают лицензии по всем применимым групповым заданиям.
Настройка группового назначения лицензий должна быть выполнена после завершения синхронизации каталогов, чтобы синхронизированные группы существовали и их можно было использовать для назначения лицензий.
В частности, автоматическое назначение лицензий требует дополнительных сведений о подготовке, таких как местоположение пользователя и назначение номера телефона. Для автоматической активации лицензии рабочий телефонный номер пользователя должен быть в формате +E.164, предварительно предоставлен и привязан к действительному местоположению. Если эти условия не будут соблюдены, пользователю не будут предоставлены услуги автоматически, и может потребоваться ручное вмешательство.
Короче говоря, настройте автоматическое лицензирование на уровне организации для новых пользователей, если вы хотите распределять лицензии в широком масштабе по всей организации. Если вы предпочитаете более детальный контроль или у каждой группы разные требования к лицензированию, настройте автоматическое лицензирование на уровне группы и избегайте назначения лицензий на уровне организации, чтобы избежать дублирования и обеспечить надлежащее управление лицензиями.
Webex Callingнастройки сервиса
Очень важно провести всесторонний анализ и настройку глобальных настроек сервиса.
Для начала зайдите в раздел настроек и перейдите к нему. Внимательно изучите каждый настраиваемый параметр, включая, помимо прочего, внутреннюю конфигурацию набора номера, параметры экстренных вызовов, политики маршрутизации вызовов, управление голосовой почтой и настройки устройства по умолчанию.
Настройте эти глобальные параметры в соответствии с политиками и проектными решениями вашей организации.
Кроме того, настройте параметры и шаблоны пользователей и приложений.
Пилотная миграция
На этапе внедрения пилотная миграция является важнейшей вехой в подтверждении перехода от на. Этот пилотный проект предусматривает выделение на платформу репрезентативной подгруппы пользователей из одного или нескольких мест и обеспечение соответствия выбранной группы пользователей различным сценариям использования и организационным ролям. Параллельно с миграцией пользователей основные сервисы для совместной работы, включая голосовую почту, автосекретарей, очереди вызовов и поисковые группы, необходимо перевести на эквивалентные сервисы для обеспечения непрерывности бизнеса и функциональности обслуживания.
При пилотной миграции следует использовать ту же комбинацию инструментов, предоставленных Cisco, и утилит миграции сторонних производителей, которую планируется внедрить в более широкой организации, чтобы обеспечить тщательную проверку процессов, рабочих процессов автоматизации и точек интеграции в репрезентативных условиях.
Это пилотное развертывание преследует две основные цели: во-первых, проверить и усовершенствовать комплексные процессы перехода, включая рабочие процессы подготовки пользователей, процедуры миграции данных и конфигурации конечных точек; во-вторых, всесторонняя проверка функциональности перенесенных сервисов в реальных условиях эксплуатации.
Этот поэтапный подход позволяет проектной группе выявлять и устранять любые технические или процедурные проблемы в контролируемой среде, собирать отзывы пользователей о новой платформе, оценивать эффективность выбранных инструментов миграции и доверять методологии миграции, прежде чем приступить к более широкому организационному развертыванию.
Информация, полученная на этом пилотном этапе, помогает оптимизировать последующие волны миграции и обеспечить плавный переход с минимальными рисками для всего предприятия.
Закупите PSTN
Чтобы приобрести услуги PSTN, сначала выберите вариант подключения к PSTN во вкладке.
Если организация планирует временно или на неопределенный срок сохранить гибридное управление двойными вызовами (этап 1 на рисунке «Поэтапный переход на вызовы: гибрид и облако»), ей необходимо будет развернуть один или несколько локальных шлюзов для локальной сети PSTN, позволяющих звонить между конечными точками и конечными точками.
Если конечной целью является полный переход (этап 2) в облако, включая PSTN, то для PSTN потребуется либо план Cisco Calling, либо вариант Cloud Connect для PSTN.
Обратитесь к выбранному провайдеру, чтобы заказать и перенести телефонные номера перед их настройкой. Заказ телефонных номеров или отправка заказов на порты необходимы и возможны только для локальных PSTN и Cloud Connect для. Для тарифных планов Cisco Calling заказ и перенос заказов начинаются прямо из Control Hub сразу после создания местоположения, а также в странах, где доступен план Cisco Calling Plan. Дополнительные сведения о планах Cisco Calling см. в разделе Начало работы с планами Cisco.
В рамках внедрения PSTN убедитесь, что ваш провайдер включил входящие и исходящие услуги PSTN для вашего местоположения. Кроме того, проведите тестовые вызовы, чтобы убедиться, что вызовы правильно маршрутизируются через выбранное вами соединение PSTN.
Настройте местоположения
Перед добавлением пользователей и устройств необходимо указать места вызовов. Для каждого местоположения необходимо ввести действительный почтовый адрес. В США и Канаде этот адрес подтвержден и используется платформой для отправки информации о местоположении PIDF-LO для экстренных вызовов.
При настройке местоположений, использующих локальную сеть PSTN, необходимо соответствующим образом настроить локальные шлюзы. Во-первых, для каждого локального шлюза должны быть созданы магистраль и группа маршрутов, а затем группа маршрутов назначается в качестве выбранного PSTN для данного местоположения. Cisco настоятельно рекомендует всегда выбирать в качестве PSTN группу маршрутов, поскольку такой подход позволяет легко добавлять дополнительные магистрали в будущем, поддерживая масштабируемость и избыточность. Cisco также рекомендует включить поддержку двойной идентификации и P-Charge-Info на каждой магистрали PSTN, поскольку это упрощает идентификацию стороны, оплачиваемой за исходящие прямые или переадресованные вызовы. Если ваш поставщик услуг PSTN использует другой заголовок для выставления счетов, вы можете скопировать информацию из заголовка P-Charge-Info на локальном шлюзе в необходимый заголовок биллинга.
В местах, где в качестве опции PSTN используется Cloud Connect или план Cisco Calling Plan, просто выберите соответствующий вариант PSTN в качестве местоположения во время настройки. Если в локации используется Cloud Connect или локальная PSTN, вам необходимо добавить телефонные номера, заказанные на предыдущем шаге. Номера можно добавить как неактивные, если вы не хотите сразу включать их в маршрутизацию вызовов; эти номера можно активировать позже, когда они будут назначены пользователям или функциям.
Важно всегда устанавливать основной номер для каждого населенного пункта. Основной номер можно присвоить пользователю или функции, например автосекретарю. Чтобы включить голосовую почту на месте, обязательно задайте пилотный номер голосовой почты, также известный как номер голосового портала.
Дополнительные настройки мест вызова включают настройку данных экстренных вызовов, таких как номер обратного вызова, параметры уведомлений и расширенные функции экстренного вызова. Вам также следует просмотреть и настроить параметры записи, языковые предпочтения и конфигурации устройств в соответствии с требованиями каждого местоположения. Если в вашей организации используется сокращенная внутрисетевая телефонная связь между сайтами со значимыми корпоративными номерами, не забудьте указать уникальный код сайта для местоположения в настройках внутреннего набора. Наконец, если для внешнего набора требуется номер исходящего набора, обязательно задайте его в настройках внешнего набора. Когда цифра исходящего набора настроена, Cisco рекомендует включить принудительное применение цифр исходящего набора для обеспечения согласованности.
Интеграция с локальным управлением вызовами
Для интеграции с локальным управлением вызовами необходимо настроить магистральные каналы, группы маршрутов, корпоративные телефонные планы, а также параметры местоположения и глобальные настройки. Начните с настройки магистралей и локальных шлюзов, предназначенных для подключения к локальной системе управления вызовами; этот шаг необходим только в том случае, если необходимы выделенные магистральные каналы. Если существующих магистралей и групп маршрутов достаточно для развертывания, их можно повторно использовать для локального соединения без дополнительной настройки.
После создания транков и групп маршрутов перейдите к созданию корпоративных телефонных планов и назначьте соответствующую группу маршрутов в качестве места назначения для каждой абонентской группы. Если интеграция включает несколько локальных систем управления вызовами, подключенных по разным магистральным каналам, потребуется несколько телефонных планов. Важно обеспечить, чтобы эти телефонные планы содержали только шаблоны, необходимые для маршрутизации вызовов на локальные адресаты.
Если в вашем развертывании требуется поддержка маршрутизации по неизвестным добавочным номерам, эту функцию следует включить на уровне местоположения. Кроме того, если активирована маршрутизация по неизвестным добавочным номерам, вы должны указать максимальную длину неизвестного номера в разделе Маршрутизация вызовов между помещениями и в настройках служб вызова в. Это обеспечивает бесперебойную маршрутизацию вызовов и правильную обработку сценариев набора на основе добавочных номеров в интегрированной среде.
Перенос пользователей в пакетном режиме
При переносе пользователей из одного пользователя в другой вы, возможно, не сможете перемещать всех пользователей одновременно. Это может быть вызвано множеством причин, включая, помимо прочего, количество сайтов или пользователей, время, необходимое для одновременного перехода сайта и/или группы пользователей, ограниченность ИТ-ресурсов или ресурсов сайта для поддержки окна изменений, продолжительность окна изменений, сложность изменений и т. д.
При поэтапном переносе пользователей очень важно определить, каких пользователей необходимо перенести вместе в один пакет. Основная цель заключается в совместном переносе пользователей, которые зависят друг от друга в том, что касается сервисов и функций звонков. Вы хотите убедиться, что все их функции вызовов (например, очереди вызовов) полностью работают так же, как и до перехода.
Даже если вы внедрите взаимодействие вызовов между локальными шлюзами и с ними, вы не сможете разделить общие службы или функции в этом соединении. Поэтому вам необходимо определить зависимости между пользователями, рассмотрев такие функции , как:
-
Мониторинг других пользователей с помощью BLF
-
В одном и том же охотничьем пилоте, очереди вызовов и т. д.
-
Общие линии
-
Использование функции приема вызовов
-
Использование одних и тех же номеров колл-парков
-
Домофон
-
Исполнитель/администратор.
В качестве примера можно привести пользователя, входящего в группу Hunt, в которую осуществляется переход. Этот пользователь перейдет в охотничью группу и вместе со всеми остальными членами охотничьей группы. Таким образом, после перехода Охотничья группа и ее члены смогут успешно отвечать на звонки на новой платформе.
Это становится еще более сложным, когда пользователи подключаются к разным группам пользователей и используют разные сервисы и функции звонков. Для этого потребуется перевести несколько групп пользователей и одну службу вызова одновременно.
Используйте результаты работы инструмента Migration Insights или стороннего инструмента, который вы использовали на этапе подготовки, чтобы определить, каких пользователей и функции следует сгруппировать. Эти выходные данные следовало использовать при разработке плана миграции. Они помогут вам понять, как вы будете группировать пользователей и функции, требующие перехода.
Ключевые шаги при переходе группы пользователей:
-
Определение пользователей для совместной миграции
-
Убедитесь, что все пользователи вошли
-
Убедитесь, что все TN для пользователей существуют в
-
Проверьте правильный формат телефонного номера в каталоге
-
Убедитесь, что шаблон лицензирования и настроек для групп пользователей настроен правильно
-
Проверка или настройка всех служб и функций вызовов для группы пользователей (до или во время перехода, в зависимости от обстоятельств)
-
В корпоративном справочнике добавьте пользователей в группу пользователей с разрешенными вызовами
-
Используйте инструменты — инструменты переноса пользователей и функций и/или сторонние инструменты
-
После перехода отключите/удалите справочный номер пользователя/устройства и включите функции и службы.
После миграции группы пользователей протестируйте подгруппу пользователей, чтобы убедиться, что все их функции и службы вызовов работают правильно. Если функции вызовов, такие как очередь вызовов, группы поиска и т. д., передаются этой группе пользователей, проверьте работоспособность этих служб вызовов.
Рабочие пространства
Под рабочим пространством понимается общее место (например, конференц-зал, место для переговоров или рабочий стол), где можно назначать устройства, добавочные номера и пользователей. В отличие от традиционных телефонов Unifed CM, рабочие места — это:
-
Ориентация на местоположение: привязана к физическому пространству.
-
Гибкость в использовании: может быть установлено одно или несколько устройств (настольные телефоны, платы и т. д.).
Как только рабочие пространства будут определены как часть перехода, их можно добавить в раздел «Устройства». Каждому рабочему пространству необходимо назначить устройство, и если оно уже естьUnified CM, его необходимо перезагрузить или повторно подготовить. Такие функции, как голосовая почта, переадресация вызовов и прием вызовов, можно включать или отключать, а также применять правила в отношении видеозвонков, парковки вызовов и мобильности по мере необходимости. Протестируйте каждое рабочее пространство, совершая внутренние и внешние звонки, тестируя функции видео, конференц-связи и мобильности. Наконец, расскажите пользователям о любых процедурах, применимых к устройствам рабочего пространства и бронированиям.
Дополнительные сведения о рабочих пространствах см. в разделе Рабочие пространства.
Подготовительные устройства
Телефоны, на которые в настоящее время зарегистрированы, необходимо будет перенести на них в рамках перехода на облачные технологии. Чтобы максимально упростить миграцию и свести к минимуму вероятность сбоев, Cisco рекомендует перенести физические сайты или отделы одновременно. Однако из-за зависимостей функций может потребоваться пакетный перенос пользователей. Дополнительные сведения см. в разделе Пакетная миграция пользователей.
Все поддерживаемые телефоны, с которых вы хотите перейти, необходимо настроить в качестве пользователя или рабочего пространства, а физический телефон необходимо перенастроить для регистрации на нем. Кроме того, микропрограммное обеспечение телефонов серий 7800 и 8800 необходимо обновить с корпоративной микропрограммы до микропрограммы для многоплатформенных телефонов (MPP). Этот процесс включает загрузку переходного микропрограммного обеспечения перед загрузкой микропрограммы MPP, необходимой для регистрации. Для этого также требуется соответствующая миграционная лицензия. За последние несколько лет компания Cisco усовершенствовала этот процесс, чтобы упростить обновление телефонов Enterprise с микропрограммным обеспечением до микропрограммного обеспечения MPP. Дополнительные сведения о шагах по обновлению микропрограммного обеспечения см. в разделе Преобразование IP-телефонов Cisco серий 7800 и 8800 между корпоративным микропрограммным обеспечением и микропрограммным обеспечением MPP.
В дополнение к шагам, описанным в этой статье, имеется встроенный инструмент «Перенос телефона на»Webex Calling, который можно использовать для переноса телефонов 7800 и 8800 с корпоративной микропрограммы на MPP. Этот инструмент также позволяет добавлять телефоны и назначать их соответствующим пользователям или рабочим пространствам. Дополнительные сведения об использовании инструмента см. в разделе Перенос телефона.
На любые телефоны серии 9800, зарегистрированные с вышеуказанным требованием, перенос микропрограммного обеспечения не распространяется. Эти телефоны работают под управлением PhoneOS, которая поддерживается как и. Чтобы перевести эти телефоны на них, вам необходимо добавить ихWebex Calling, назначить пользователю или рабочему пространству, а затем восстановить заводские настройки телефонов. Последовательность загрузки PhoneOS при регистрации на рисунке ниже показывает последовательность загрузки PhoneOS и то, как телефон будет зарегистрирован после добавления в систему, даже если телефон все еще включен и/или используются опции DHCP (пример 150).
поддерживает сброс настроек устройств PhoneOS к заводским настройкам, чтобы обеспечить подключение к ним с помощью Zero-Touch. Администраторы могут удаленно восстановить заводские настройки телефонов 9800 и 8875 на страницах администрирования CUCM, что устраняет необходимость в физическом доступе к телефонам, к которым можно подключить телефоны. Эта функция поддерживается пакетами устройств с 9 сентября 2025 года:
-
CUCM v15 — диспетчер унифицированных коммуникаций версии 15
-
CUCM v14 — диспетчер унифицированных коммуникаций версии 14.
Дополнительные сведения о процессе регистрации серии 9800 см. в разделе Процесс регистрации.
В дополнение к IP-телефонам Cisco может потребоваться предоставление других устройств, таких как аналоговые телефонные адаптеры (ATA), беспроводные телефоны (Wi-Fi, DECT), видеоустройства, голосовые шлюзы и сторонние устройства и телефоны. Для многих из этих устройств, как в случае с IP-телефонами, нет способа обновления микропрограммного обеспечения для перехода с корпоративной микропрограммы на облачную микропрограмму. Поэтому вы предоставите каждое из этих устройств в Control Hub. На некоторые из них нельзя перенести, и их придется заменить эквивалентную модель (например, ATA (191/192) и другие потребуют ручной реконфигурации и/или изменений в программном обеспечении.
- Голосовые шлюзы. Сведения о переносе локального шлюза см. в разделе Перенос локального шлюза.
-
Аналоговый телефонный адаптер (ATA). Чтобы начать работу с Cisco ATA 191 и 192, см. Cisco ATA.
-
Беспроводной телефон с Wi-Fi. Сведения об интеграции беспроводных телефонов 840 и 860 см. в разделе Интеграция беспроводного телефона Webex .
-
Беспроводные телефоны DECT. Чтобы начать работу с новой серией Cisco IP DECT 6800, см. раздел Cisco IP DECT.
Дополнительные сведения о Cisco IP DECT 6800 см. в руководстве по развертыванию
-
Устройства и телефоны сторонних производителей. Обсудите с сторонними поставщиками требования к устройствам/телефонам и процесс их переноса или замены в службу поддержки.
Настройте функции
Любые необходимые функции вызовов необходимо подготовить до или во время перехода. Как уже говорилось в разделе «Пакетная миграция пользователей», функции вызовов необходимо настраивать и переносить при переходе пользователей, которые их используют.
Подробнее о том, как настроить каждую из функций, см. в соответствующих справочных статьях по настройке.
-
Автосекретари. Сведения об управлении автосекретарями см. в разделе Автосекретари
-
Парковка вызовов. Информацию об управлении парком вызовов см. в разделе Парковка вызовов
-
Перехват вызовов. Сведения о настройке группы приема вызовов см. в разделе Перехват звонков
-
Очереди вызовов. Сведения о настройке очереди вызовов см. в разделе Очередь вызовов
-
Охотничьи группы. Сведения об управлении охотничьими группами см. в разделе Управление охотничьими группами
-
Режимы работы. Сведения о маршрутизации вызовов на основе рабочих режимов см. в разделе Маршрутизация вызовов на основе рабочих режимов
-
Пейджинговые группы. Сведения о настройке пейджинговой группы см. в разделе Настройка пейджинговой группы
-
Записи. Информацию об управлении записями звонков см. в разделе Управление записями
-
Охват одного номера. Сведения о настройке охвата одним номером (в любом офисе) см. в разделе Настройка одного номера
Приемочное тестирование
Приемочное тестирование гарантирует, что перенесенная среда отвечает функциональным требованиям, работает должным образом и обеспечивает удобство работы пользователей во всех рабочих процессах связи. Этот процесс проверки многогранен и охватывает все: от подготовки пользователей и назначения номеров до операционной эффективности расширенных функций вызовов.
В этом разделе приведены примеры и ключевые аспекты, которые следует учитывать при приемочном тестировании, однако он не является исчерпывающим или исчерпывающим контрольным списком.
Подготовка пользователей и присвоение номеров
Основополагающим аспектом приемочного тестирования является проверка точности и полноты подготовки всех пользователей. Для этого необходимо провести тщательное сравнение каталога source () и вновь созданной базы пользователей, чтобы убедиться, что каждая учетная запись пользователя и связанные с ней атрибуты, такие как добавочные номера и назначения прямого входящего вызова (DID), были перенесены правильно. Полнота выделения ресурсов имеет решающее значение не только для обеспечения работоспособности в первый день, но и для текущего администрирования и поддержки.
Проверка назначения номера включает подтверждение того, что каждому пользователю присвоен правильный добавочный номер и внешний номер, а также правильность маршрутизации этих номеров как во внутренних (внутрисетевых), так и во внешних (PSTN) потоках вызовов. Очень важно проверить, нет ли совпадений, пропущенных назначений или неправильных конфигураций, которые могут привести к ошибкам маршрутизации вызовов или перебоям в обслуживании.
Потоки вызовов PSTN и представление идентификатора вызывающего абонента
Надежная процедура приемочного тестирования должна включать комплексную проверку потоков вызовов PSTN. Сюда входят сценарии как входящих, так и исходящих вызовов. В случае входящих вызовов PSTN группа тестирования должна подтвердить, что звонки доставляются на предполагаемые конечные точки, будь то отдельные пользователи, очереди вызовов, охотничьи группы или автосекретари. Исходящие вызовы PSTN должны выполняться успешно, уделяя особое внимание правильной доставке и представлению идентификационных данных вызывающего абонента. Для этого необходимо обеспечить отображение правильного имени и номера вызывающего абонента внешним получателям в соответствии с организационными политиками и нормативными требованиями.
Тестирование также должно учитывать сценарии аварийного переключения, такие как обработка недоступных конечных точек или сбои в работе сети. Это помогает убедиться, что резервные механизмы и альтернативная маршрутизация работают правильно, обеспечивая непрерывность и надежность обслуживания.
Потоки вызовов внутри сети
Внутренние или внутрисетевые потоки вызовов составляют основу корпоративной связи. Приемочное тестирование в этой области позволяет проверить правильность маршрутизации вызовов между пользователями в организации, а такие функции, как передача, удержание, переадресация и проведение конференций, работают по назначению. Должны быть подтверждены целостность телефонных планов , возможность соединения между добавочными номерами и поддержка организационных политик обработки вызовов.
Обработка вызовов пользователей и проверка функций
Важным аспектом приемочного тестирования является проверка того, как пользователи обрабатывают звонки с помощью настольных телефонов и поддерживаемых настольных телефонов. Этот процесс направлен на подтверждение интуитивности и надежности повседневных рабочих процессов звонков и беспрепятственного доступа пользователей к основным функциям, необходимым для выполнения их ролей. Тестирование должно оценить, с какой легкостью пользователи могут звонить и принимать звонки, управлять функциями удержания и возобновления вызова, а также выполнять переводы вслепую и по консультациям. Также важно убедиться, что переадресация вызовов, проведение конференций и другие расширенные функции, такие как парковка, прием вызовов или активация режима «Не беспокоить», доступны и работают без сбоев.
Опыт следует оценить на предмет ясности и оперативности реагирования, учитывая, как пользователи взаимодействуют с историей звонков, голосовой почтой и интегрированными каталогами. Дополнительное внимание следует уделить возможности перемещения активных вызовов между устройствами и эффективному использованию элементов управления входящими вызовами в приложении или на физических телефонах. Конечная цель заключается в том, чтобы после миграции конечные пользователи были стабильными, эффективными и полностью отвечали коммуникационным потребностям организации.
Очереди вызовов: опыт работы агентов и супервизоров
Очереди вызовов часто используются для обработки сценариев больших объемов входящих вызовов. Приемочное тестирование здесь сосредоточено на нескольких аспектах. Во-первых, необходимо убедиться, что вызовы распределяются между агентами в соответствии с настроенной логикой очереди, например циклическим переходом, самым длительным временем простоя или одновременным звонком. Представление вызовов в очереди на настольных компьютерах агентов необходимо изучить на предмет ясности и простоты использования, чтобы агенты могли эффективно принимать, удерживать и пересылать вызовы.
Руководителям следует оценить работу настольного компьютера с точки зрения таких функций, как мониторинг в реальном времени, отправка звонков, аналитика или анализ производительности очередей. Сюда входит, помимо прочего, проверка информационных панелей и инструментов отчетности, которые предоставляют действенные данные о распределении звонков, активности агентов и метриках очередей.
Охотничьи группы: распределение звонков
Охотничьи группы — ключевой механизм распределения звонков заранее определенным группам пользователей. Приемочное тестирование должно подтвердить, что звонки направляются членам группы на основе настроенного алгоритма поиска и что сценарии переполнения, переадресации и отсутствия ответа обрабатываются в соответствии с планом. Для обеспечения стабильности работы и удовлетворенности пользователей крайне важно обеспечить соответствие поведения членов групп и маршрутизации вызовов ранее установленным стандартам.
Автосекретари: объявления и операции с меню
Автосекретари представляют собой передовую линию автоматизированной обработки вызовов. Тестирование должно охватывать воспроизведение объявлений, точность записанных приветствий и правильную работу деревьев меню. Выбранное меню должно надежно направлять абонентов на соответствующие отделы, отдельные лица или внешние номера. Тестирование также должно включать недействительные сценарии или сценарии ожидания, чтобы убедиться, что звонящие получают четкие инструкции или перенаправляются по назначению.
Работа с голосовой почтой
Наконец, функциональность голосовой почты имеет решающее значение для удобства пользователей. Приемочные испытания должны подтвердить, что ящики голосовой почты правильно назначены и доступны как внутри организации, так и удаленно. Необходимо подтвердить возможность записи, извлечения сообщений и управления ими, а также рассылки уведомлений.
Оптимизировать
Миграция PSTN в Cloud Connect для
После того как все конечные точки и пользователи будут перенесены в облако, единственной целью вызова станет Unified CM выполнение функций транзита между шлюзами PSTN и через локальный шлюз. Устранение шлюзов PSTN и локального шлюза за счет использования Cloud Connect в качестве доступа к PSTN для всех Webex Calling пользователей дает ряд преимуществ, включая снижение затрат и повышение надежности. Чтобы перевести локальный доступ к PSTN в Cloud Connect для, выполните следующие действия:
-
Cloud Connect для выбора партнера.
Ознакомьтесь со списком партнеров Cloud Connect и выберите одного из доступных партнеров в регионе вашей организации.
-
Cloud Connect для проверки.
Перед переключением доступа к PSTN для локаций на Cloud Connect необходимо проверить и подтвердить подключение к PSTN через выбранного партнера Cloud Connect. Для этого необходимо предоставить тестовое местоположение, а некоторым тестовым пользователям — в этом тестовом месте. Затем доступ к PSTN в этом тестовом месте предоставляется партнеру Cloud Connect, а затем проверяется подключение к PSTN с помощью тестовых телефонов. После успешной проверки тестовое место может быть выведено из эксплуатации.
-
Перенос номеров.
Чтобы подготовиться к подключению к Cloud Connect, необходимо оформить заказ на портирование всех номеров, которые в настоящее время присвоены магистрали PSTN и заканчиваются на ней. Все номера необходимо перенести партнеру Cloud Connect. Чтобы обеспечить доступность между точками, необходимо портировать все номера из всех местоположений одновременно .
-
Перейдите к партнеру Cloud Connect.
На момент отключения доступ к PSTN во всех местах должен быть предоставлен поставщику подключенных к облаку PSTN, а также проверить входящее и исходящее подключение.
Как описано в разделе PSTN главы, посвященной проектированию, клиенты также могут перенести свой доступ к PSTN в Cloud Connect в начале перехода, используя транкинг PSTN для гибридных развертываний. Дополнительные сведения см. в разделе Транкинг PSTN для гибридных развертываний. Webex Calling В этом случае во время перехода доступ к PSTN осуществляется через локальный шлюз, а после перевода всех пользователей на PSTN не требуется никаких дополнительных этапов миграции, связанных с PSTN, кроме вывода из эксплуатации и использования локальных шлюзов.
Оптимизация локальной инфраструктуры
После перевода всех пользователей и перевода всех конечных точек на облачную регистрацию (или вывод из эксплуатации) обновите соответствующую локальную инфраструктуру уже сейчас, когда облачные вызовы уже используются. Обновления инфраструктуры включают следующее:
-
Удалите локальные DNS SRV записи управления вызовами и обмена сообщениями с локальных DNS-серверов, включая cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Эти записи SRV больше не нужны для обнаружения клиентских сервисов.
-
Удалите DNS SRV записи, связанные с периферией, из общедоступной системы DNS, включая collab_edge. _tls. <domain>. Эти записи SRV больше не нужны для обнаружения периферийных сервисов для совместной работы в службе поддержки клиентов.
-
Обновите все соответствующие области DHCP, чтобы удалить адреса серверов TFTP/Boot в вариантах 66 и 150 . Эти области больше не нужны для обнаружения и загрузки конфигурации управления вызовами конечных точек.
-
Обновите или удалите соответствующие точки вызова в локальном шлюзе/кубе, которые маршрутизируют входящие и исходящие вызовы. Unified CM Эти конечные точки вызова больше не нужны для локальной маршрутизации вызовов.
-
Удалите или удалите все виртуальные машины и/или серверы узлов кластера. При необходимости перепрофилируйте вычислительные ресурсы и оборудование . Эти ресурсы больше не нужны для управления вызовами и периферийных служб.
-
Удалите или удалите все виртуальные машины и/или серверы узлов кластера. При необходимости перепрофилируйте вычислительные ресурсы и оборудование . Эти ресурсы больше не нужны для голосовой почты и служб единой системы обмена сообщениями.
-
Очистка: после переноса доступа PSTN к подключенной к облаку PSTN магистрали PSTN, шлюзы PSTN и локальный шлюз могут быть выведены из эксплуатации.
-
В любом существующем локальном решении E911 удалите все места или номера, куда вы перешли, и после завершения полного перехода удалите виртуальные машины или серверы приложений. При необходимости перепрофилируйте вычислительные ресурсы и оборудование . Эти ресурсы больше не нужны для экстренных вызовов и служб определения местоположения.
-
Во избежание сбоев в маршрутизации вызовов и обеспечения приоритетного доступа всех служб CSS к облачному пути одних и тех же DNS следует размещать доменные имена, принадлежащие мигрировавшим пользователям.
-
Всякий раз, когда происходят изменения, обновляйте физическое диспетчеризируемое местоположение и сетевой элемент в Horizon Mobility . Типичные действия, требующие обновления:
-
Замена сетевого коммутатора
-
Замена беспроводной точки доступа
-
Изменения области DHCP
-
Физические изменения в здании (если речь идет о кабинном/офисном помещении)
-
Физическое расширение или сжатие офисных помещений в здании.
-
Используйте аналитику и устранение неполадок
предоставляет комплексные возможности аналитики и устранения неполадок, помогающие визуализировать и отслеживать развертывание. К ним относятся аналитика качества медиафайлов, подробной истории звонков, очереди вызовов, поисковой группы и автосекретаря. Пример аналитики качества мультимедиа показан на рисунке «Аналитика качества мультимедиа».
В разделе «Устранение неполадок» каждый сделанный звонок можно просмотреть с подробной информацией об основных проблемах с качеством мультимедиа и сигналами, которые помогут точно определить проблемы с медиафайлами, а также неудачные вызовы, как показано на рисунке «Устранение неполадок с качеством мультимедиа».
Устранение неполадок также можно интегрировать с другими продуктами Cisco, такими как коммутаторы ThousandEyes и Meraki, что обеспечивает еще более широкие возможности интеграции в Control Hub. Дополнительные сведения об использовании Webex Callingаналитики и устранении неполадок см. в разделе Устранение неполадок вызовов в Control Hub Webex Calling.
Прежде чем начать
Это руководство предназначено для групп или отдельных лиц, имеющих опыт настройки и администрирования Cisco Unified Communications Manager (Unified CM) и конечных точек Cisco, включая настольные IP-телефоны, видеоустройства и программные клиенты Jabber. В этом документе есть ссылки на справочную документацию по продукту и вспомогательную документацию.
В этом документе основное внимание уделяется переходу только от Unified CM Webex Calling многопользовательской версии к многопользовательской среде. Используемый Webex Callingв этом документе термин всегда относится к Webex Calling многопользовательской среде.
Прежде чем начать переход с Webex Calling версии Unified CM на, необходимо иметь полное представление о Webex Calling решении и его соответствующих компонентах. Для успешной миграции необходимо ознакомиться с Webex Calling архитектурой, моделями обслуживания, вариантами развертывания и сопутствующими функциями, чтобы правильно сопоставить существующие Unified CM рабочие нагрузки и разработать эффективный план перехода.
Тщательное понимание следующих Webex Calling компонентов необходимо для формирования эффективной стратегии перехода и операционной готовности.
-
Центр управления
-
Подготовка каталогов и пользователей
-
Webex Callingплатформа
-
поддерживаемые конечные точки вызова
-
Варианты подключения к PSTN
-
Webex Callingтарифный план и управление номерами
-
Функции безопасности и соответствия требованиям.
Дополнительные сведения см. в разделе Предпочтительная архитектура Cisco дляWebex Calling.
В этом руководстве будут описаны инструменты и процессы, которые следует использовать на протяжении всего переходного периода. Однако переход от локальных звонков к новой облачной платформе для звонков может потребовать значительных усилийWebex Calling, связанных с потенциальными деловыми, техническими и сложными проблемами. Unified CM Чтобы решить эти проблемы, Cisco предлагает несколько различных вариантов, которые помогут вам в вашем путешествии. Важно ознакомиться с информацией в разделе Корпоративные облачные вызовы — миграция звонков и понять, как каждый из них может помочь вам в миграции.
-
Инструменты миграции Webex: бесплатные инструменты самообслуживания, встроенные в Control Hub для упрощения перехода на Webex Calling
-
Сертифицированные поставщики миграции: проверенные Cisco поставщики программного обеспечения и инструментов, разработавшие решения по миграции, помогающие партнерам и клиентам Webex в сложных и крупных миграциях. Эти решения могут помочь упростить, управлять и ускорить переход на Webex Calling
-
Webex Setup Assist: сервис миграции под руководством Cisco, который предоставляет клиентам и партнерам рекомендации по Webex Calling развертыванию и настройке, необходимых для успешного переноса Unified CM пользователей и сервисов в. Webex Calling
Обзор
По мере роста числа облачных сервисов для совместной работы все больше клиентов хотят перенести существующие рабочие нагрузки для совместной работы в облако, учитывая обещания снизить совокупную стоимость владения, упростить управление, непрерывное предоставление функций, увеличить масштабируемость и превосходную надежность, присущие облачным сервисам. Поскольку заказчики хотят перейти с локальных сервисов на облачные сервисы для совместной работы, им важно понять, что влечет за собой переход и какие шаги необходимо предпринять для этого перехода.
Цель этого документа — предоставить рекомендации по развертыванию для клиентов, которые специально хотят перейти с локальной среды на Unified CM Webex Calling облако. В этом руководстве по развертыванию предполагается, что читатель имеет базовое представление о переходе между Unified CM вызовами, в том числе о томWebex Calling, какие изменения произойдут при этом переходе и в чем разница при переносе рабочей нагрузки по вызовам из локальной среды в облако. Прежде чем продолжить, убедитесь, что вы ознакомились с информацией, представленной на карте Transition, и ознакомлены с ней. В этом документе с картой перехода представлена информация об изменениях и отличиях этого перехода.
Как показано на рис. Локальная архитектура совместной работы: управление вызовами и удаленный доступ, типичное локальное развертывание включает в себя различные компоненты инфраструктуры совместной работы в сети, платформу управления вызовами, периферийную платформу, аппаратные и программные конечные точки, а в некоторых случаях даже платформы для конференций и планирования. В архитектуре Cisco это будет включать Unified CM управление вызовами, Expressway для удаленного доступа и периферийных услуг для бизнеса (B2B), сервер собраний Cisco и Cisco Meeting Management для локальных конференций, Unity Connection для голосовых сообщений, а также аппаратное обеспечение для пользователей (телефоны Cisco IP, настольные и комнатные видеосистемы Cisco) и программное обеспечение (Cisco Jabber) конечные точки на основе IP. Эти компоненты могут незначительно отличаться в некоторых средах, но это отправная точка перехода, описанного в остальной части этого документа.
Архитектура, показанная на рис. Локальная архитектура совместной работы: управление вызовами и удаленный доступ, основана на предпочтительной архитектуре (PA) для локальных развертываний Cisco Collaboration Enterprise. Дополнительные сведения о корпоративной локальной среде см. в разделе Предпочтительные архитектуры Cisco для совместной работы.
Ранее: в таблице компонентов локальной инфраструктуры вызовов перечислены ключевые элементы локальной архитектуры до перехода в облако. Webex Calling
| Продукт | Описание |
|---|---|
| Unified CM | Локальное управление вызовами, предоставляющее услуги регистрации устройств и маршрутизации вызовов |
| Cisco Expressway-C/E | Периферийная инфраструктура, обеспечивающая мобильную связь Remote Access (MRA) и бизнес-функции (B2B), позволяющие удаленным конечным точкам безопасно подключаться к удаленным конечным точкам из-за пределов организации. Expressway развертывается попарно, чтобы обеспечить обход внешних конечных точек через брандмауэр . |
| Сервер конференций Cisco (CMS), система управления совещаниями Cisco (CMM) и пакет управления телеприсутствием Cisco (TMS) | Локальная инфраструктура голосовых, видео- и веб-конференций, обеспечивающая многоточечные совещания, управление совещаниями и планирование. [Необязательно] |
| Cisco Unity Connection | Локальная платформа голосовых сообщений, предоставляющая возможности голосовой почты и единой системы обмена сообщениями . [Необязательно] |
| Стол Cisco, зал Cisco, плата Cisco, IP-телефоны Cisco и Cisco Jabber | Устройства на основе IP, зарегистрированные Unified CM и обеспечивающие возможность голосовых и видеозвонков |
Как показано на рисунке «Решение о переходе»: локальные звонки Webex Calling, клиенты, у которых есть локальное управление вызовами с помощью Unified CM настольных и видеоIP-адресов, могут выбрать вариант перехода на облачную архитектуру. Webex Calling
Решение должно быть принято на основе функциональных требований заказчика. Клиентам, предъявляющим следующие требования, следует тщательно обдумать это, прежде чем принимать это решение, и в конечном итоге они могут решить сохранить управление вызовами в локальной среде:
- Модели телефонов, не поддерживаемые Webex Calling
- Сложные или многочисленные интеграции с другими локальными системами или решениями, особенно в тех случаях, когда воспроизвести эти интеграции с ними Webex Calling сложно или нет эквивалентных альтернативных решений
- Сложная телефонная схема, очень детализированные классы обслуживания или и то, и другое
- Ограниченный, ограниченный или ненадежный доступ в Интернет
- Строгие правила конфиденциальности и владения данными
- Соответствие требованиям к записи и хранению медиафайлов локально или в стране
- Интеграция со сторонними организациями без жизнеспособной альтернативной интеграции Webex Calling
- Интеграция контакт-центров, при которой контакт-центр еще не перешел в облако .
Этот документ предназначен для клиентов, использующих Unified CM систему управления вызовами, которые хотят понять общие шаги, соображения и требования, связанные с Webex Calling развертыванием, как описано в следующем разделе.
Основные компоненты
Целевая архитектура этой миграции включает несколько новых компонентов. Сюда входят Webex Calling сервис для облачных звонков, приложение Webex, Cisco Directory Connector для интеграции идентификационных данных и локальный шлюз (LGW) для доступа к PSTN, а также интеграция звонков из локальной среды в облако. Планы Cisco Calling или подключенные к облаку PSTN (CCP), предоставляемые партнером Cloud Connect, являются дополнительными вариантами доступа к PSTN. Webex Calling
Как показано на рисунке после: Webex Calling Архитектура, новые компоненты (коннектор каталоговWebex Calling, локальный шлюз и шлюз Survivability) добавлены в существующее локальное развертывание.
После: в таблице компонентов инфраструктуры облачных вызовов перечислены новые элементы архитектуры после перехода на Webex.
| Продукт | Описание |
|---|---|
| Webex Calling | Облачная служба вызовов, предоставляемая на платформе Webex и обеспечивающая регистрацию конечных точек и маршрутизацию вызовов |
| Коннектор каталогов Cisco | Приложение Windows, работающее на доменном компьютере под управлением Windows, обеспечивает
синхронизацию идентификационных данных между локальным корпоративным хранилищем Active Directory и хранилищем идентификационных данных организации
Webex. Для клиентов, переходящих с локальной среды Active Directory на Entra ID, при интеграции идентификационных данных с Webex вместо Cisco Directory Connector используется приложение Entra ID Wizard. |
| Локальный шлюз | Локальный шлюз служит мостом между локальной сетью унифицированных коммуникаций клиента и облаком. Webex Calling Его можно развернуть локально или разместить у партнера. Он обеспечивает доступ к PSTN для зарегистрированных в облаке конечных точек, а также обеспечивает интеграцию вызовов между Unified CM зарегистрированными конечными точками и конечными точками, зарегистрированными в облаке. Cisco IOSМаршрутизатор с интегрированными сервисами -XE (серии ISR 1100 и 4000), Cisco Catalyst серии 8200/8300, программное обеспечение Cisco Catalyst 8000V Edge и различные сертифицированные сторонние пограничные контроллеры сеансов (SBC) можно использовать в качестве LGW для поэтапной миграции. |
| Шлюз обеспечения отказоустойчивости | Survivability Gateway (SGW) — это шлюз локальной сети на базе IOS-XE, который предоставляет резервные услуги вызова локальным конечным точкам во время сбоев в сети. Webex Calling |
| План звонков Cisco, Cloud Connect для Webex Calling | Cisco Calling Plan и Cloud Connect for Webex Calling — это облачные варианты доступа конечных точек к PSTN. Webex Calling Доступ к PSTN обеспечивается поставщиком облачных PSTN и не требует локального оборудования. |
| Приложение Webex | Клиентское приложение, работающее на настольной ОС (Windows, Mac) или мобильной ОС (Android, iOS) и зарегистрированное непосредственно на платформе для Webex Calling обеспечения функциональности звонков. |
Обзор процесса PPDIO
Процесс PPDIO означает подготовку, планирование, проектирование, внедрение и оптимизацию. Это структурированная методология Cisco, которая направляет проекты от первоначальной оценки до постоянного совершенствования, обеспечивая эффективное и успешное развертывание или миграцию.
Общее описание PPDIO
-
Подготовьтесь: оцените текущую среду, определите требования и объедините усилия заинтересованных сторон для создания прочной основы.
-
План: разработайте подробные планы проекта, включая сроки, ресурсы и стратегии снижения рисков.
-
Проектирование: разработайте целевое решение с учетом деловых и технических потребностей.
-
Внедрение: выполните развертывание или миграцию в соответствии с проектом, подтвердив функциональность и производительность.
-
Оптимизация: непрерывное улучшение решения после внедрения путем мониторинга производительности, уточнения конфигураций и использования инструментов автоматизации и интеграции.
Использование PPDIO для миграции проектов Unified CM Webex Calling
При переходе от Unified CM к Webex Calling процессу PPDIO предоставляется четкая дорожная карта, обеспечивающая плавный и эффективный переход:
Подготовьтесь
-
Оцените существующую Unified CM среду и готовность к миграции
-
Соберите подробные данные о пользователях, устройствах, сети и зависимостях
-
Собирайте сведения о местоположении, включая адрес экстренного реагирования, количество пользователей, доступ в Интернет, доступ к PSTN
-
Определите риски и определите объем проекта, чтобы объединить усилия всех заинтересованных сторон.
Планируйте
-
Создайте комплексный план миграции с расписанием пакетной обработки, распределением ресурсов и сроками
-
Определите такие задачи, как обновление микропрограммного обеспечения устройства, предоставление лицензий и адаптация пользователей
-
Координируйте периоды миграции с Cisco и партнерами, чтобы свести к минимуму перебои в работе .
Проектирование
-
Сопоставьте текущие Unified CM конфигурации, тарифные планы и профили пользователей с Webex Calling эквивалентами
-
Спроектируйте Webex Calling среду, включая стратегию PSTN (промежуточную и окончательную), местоположения, роли пользователей и точки интеграции, такие как локальный шлюз (CUBE) и синхронизация каталогов
-
Спланируйте сценарии сосуществования, предполагающие Unified CM одновременную Webex Calling работу во время миграции.
Внедрите
-
Используйте инструменты миграции Control Hub вместе со сторонними инструментами для изменения режима микропрограммного обеспечения устройства, настройки функций и миграции пользователей
-
Используйте массовые операции и выделение ресурсов с помощью API Webex для оптимизации крупномасштабных миграций и конфигураций
-
Выполните предоставление лицензий, регистрацию устройств и обновление конфигурации
-
Подтвердите успешность миграции с помощью тестирования и операционной проверки.
Оптимизируйте
-
Постоянно контролируйте Webex Calling производительность и пользовательский интерфейс
-
Уточняйте конфигурации и рабочие процессы на основе операционных данных и отзывов
-
Используйте возможности автоматизации и интеграции для повышения эффективности и масштабируемости
-
При необходимости выведите из эксплуатации устаревшие Unified CM компоненты и обеспечьте постоянную поддержку операций второго дня.
Этот усовершенствованный подход PPDIO обеспечивает контролируемую, прозрачную и эффективную миграцию Unified CM на систему с использованием инструментовWebex Calling, API и партнерской экосистемы Cisco для обеспечения непрерывности бизнеса и расширения возможностей совместной работы.
Циклы обратной связи PDIO
Общий обзор, показанный на рисунке «Итерации» при выполнении PPDIO, иллюстрирует единственный цикл обратной связи от фазы оптимизации до фазы подготовки. Это означает, что после первоначального внедрения существует постоянная возможность постоянного улучшения. Каждый цикл оптимизации позволяет выявить новые требования или области, нуждающиеся в улучшении, которые могут быть решены в рамках последующих проектов или инициатив. В свою очередь, каждый из этих отдельных проектов соответствует установленному жизненному циклу PPDIO (подготовка, планирование, проектирование, внедрение, оптимизация). Такой итеративный подход обеспечивает соответствие системы меняющимся бизнес-целям и технологическим достижениям, а также способствует формированию культуры постоянного совершенствования и адаптации.
В ходе выполнения процесса PPDIO результаты, полученные на более поздних этапах, обычно требуют пересмотра и, возможно, пересмотра решений, принятых на более ранних стадиях. Например, проблемы, возникшие на этапе внедрения, такие как выявление неясностей в дизайне или недостающих деталей, могут свидетельствовать о том, что некоторые аспекты не были полностью учтены на этапе проектирования. В таких случаях возникает необходимость вернуться к соответствующему предыдущему этапу, чтобы решить эти проблемы, прежде чем продолжить. Этот итеративный механизм обратной связи, показанный на рисунке Unified CMпри помощи процесса PPDIO, обеспечивает тщательную проверку и доработку решения, что в конечном итоге способствует более надежному и эффективному развертыванию.
При переходе от Unified CM к каждому этапу процесса PPDIO информацияWebex Calling, собранная в существующей среде, может в значительной степени воспользоваться информацией, собранной в существующей Unified CM среде. Например, из текущей Unified CM конфигурации можно извлечь исчерпывающий перечень пользователей, телефонных номеров, функций вызовов и компонентов абонентской группы. Эти данные дополняют информацию, предоставленную непосредственно заинтересованными сторонами, и помогают оптимизировать планирование и проектирование. Использование соответствующих инструментов для автоматизации извлечения и анализа данных не только повышает точность, но и ускоряет весь процесс. Используя результаты существующего развертывания, переход на него Webex Calling можно осуществить более эффективно, чем при традиционном внедрении с нуля, но при этом следует придерживаться структурированной методологии PPDIO. Этот процесс показан на рисунке Unified CM с помощью процесса PPDIO.
Подход к миграции
Планируя переход с локальной среды на локальную среду Unified CMWebex Calling, вам необходимо определить, как вы подойдете к этому путешествию. Сначала вам нужно решить, будет ли миграция осуществляться мгновенно (все сразу) или поэтапно (перенос групп пользователей/устройств в течение длительного периода).
При мгновенной миграции все ваши пользователи и устройства будут перемещены быстрее всего. С помощью этого метода вы переместите всех пользователей и устройства из локальной среды в одно и Unified CM Webex Calling то же время. По сути, это единое окно миграции для всех пользователей и устройств. После завершения миграции все ваши пользователи и устройства будут подключены к Webex Calling платформе, а всю Unified CM инфраструктуру можно будет вывести из эксплуатации. Однако многие организации не могут использовать этот подход из-за масштабов и масштабов развертывания Calling.
Второй подход — поэтапная миграция. Большинство организаций будут использовать этот подход , поскольку он обеспечивает более эффективный контроль, управление и масштабирование по мере миграции. Кроме того, он лучше подходит для крупных развертываний и/или развертываний унифицированных коммуникаций в нескольких регионах. Поэтому в данном документе основное внимание уделяется поэтапному подходу с двумя этапами перехода.
Как показано на рисунке ниже. Поэтапный переход на новые вызовы: гибридные и облачные технологии, первый этап перехода (этап 1) предполагает совместное развертывание со средами двойных вызовов. На этом этапе некоторые пользователи, устройства и программные клиенты переходят на локальную систему управления вызовами, Webex Calling а другие все еще используют Unified CM локальную систему управления вызовами. На заключительном этапе перехода (этап 2) создается полностью облачная среда для звонков, в которой все пользователи, устройства и программные клиенты полностью переведены на платформу. Webex Calling
Время, необходимое организации для полного перехода на облачную связь, зависит от текущего развертывания. В некоторых случаях организация может осуществить первоначальный переход и в течение длительного периода времени (месяцы или даже годы) оставаться в фазе совместного управления вызовами (фаза 1), в то время как в других случаях организация может полностью перейти на Webex Calling (этап 2) за очень короткий период (недели или месяцы). Данный документ призван охватить оба этапа (этап 1 — сосуществование и этап 2 — полный переход).
Вполне возможно, что некоторые организации могут работать по принципу сосуществования и использовать систему двойного управления вызовами на неопределенный срок, не планируя полностью переходить на облачные вызовы.
Второе соображение заключается в том, как вы будете переводить пользователей, устройства и программные клиенты из локального управления вызовами на облачную систему управления вызовами. Рекомендуемый подход — трехэтапный переход . На рисунке «Рекомендуемый трехфазный переход» ниже этот подход разбит на три этапа.
Предварительный перенос: на этом этапе основное внимание уделяется подготовке Webex и Unified CM сред к миграции. Речь идет не о конкретном планировании или конфигурациях, а о выполнении действий, которые можно выполнить сейчас и до начала любого проекта по Webex Calling миграции. Цель состоит в том, чтобы заложить основу этих двух сред для подготовки к миграции.
Подготовка к миграции: на этом этапе начинается подготовка к Webex Calling миграции. Здесь необходимо пересмотреть и обновить деловые и технические требования. Не просто меняйте то, что используется в настоящее время, но Unified CM и пересмотрите деловые и технические требования, которые нужны вашей компании сегодня и в будущем, используя возможности этих технологий. Webex Calling Кроме того, на этом этапе вы завершите проектирование, планирование конфигурации и планирование/график миграции.
Миграция (развертывание и вывод из эксплуатации). На этом этапе происходит фактическая миграция пользователей, устройств, телефонных номеров и программных клиентов. Как указывалось выше, этот этап может быть завершен для всех одновременно (мгновенное отключение) или за несколько периодов изменений (поэтапное отключение). Планы внедрения, обучение и коммуникация для конечных пользователей крайне важны, чтобы ваши пользователи знали об изменениях, о том, как использовать новую платформу для звонков и когда они произойдут. Последний шаг — вывести из эксплуатации всю локальную инфраструктуру унифицированных коммуникаций , которая больше не используется.
На этапе, предшествующем миграции, есть мероприятия (обязательные, рекомендуемые и необязательные), над которыми можно приступить немедленно. Рекомендуется выполнить их раньше, чем позже, желательно до начала проекта. Выполнение некоторых задач может занять больше времени, поэтому их выполнение раньше поможет упростить фактический проект миграции.
На рисунке, приведенном ниже, представлены пять конкретных категорий мероприятий, связанных с Webex Calling миграцией.
Подготовьте
Деловые и технические требования
При планировании перехода с на этап планирования важно тщательно изучить технические и бизнес-требования. Этот шаг обеспечивает соответствие миграции операционным целям и техническим возможностям вашей организации и минимизирует риски и сбои.
Почему сбор требований важен:
-
Соответствует бизнес-целям: понимание потребностей бизнеса помогает адаптировать миграцию к ключевым рабочим процессам, удобству работы пользователей и планам роста.
-
Обеспечивает техническую совместимость: раннее определение технических требований предотвращает проблемы интеграции с существующей инфраструктурой, сетью и конечными точками.
-
Упрощает планирование ресурсов: четкие требования помогают точно оценить сроки, затраты и необходимые ресурсы.
-
Снижает риски: раннее обнаружение потенциальных проблем позволяет принимать упреждающие решения, сокращая время простоя и перерывы в обслуживании.
Требования к бизнесу
Типичные бизнес-требования включают в себя:
-
Количество пользователей и мест, которые необходимо перенести
-
Желаемые функции и сервисы (например, маршрутизация вызовов, голосовая почта, конференц-связь, автосекретари, очереди вызовов)
-
Политики соответствия требованиям и безопасности
-
Бюджетные ограничения и ожидаемые затраты
-
Потребности в обучении и поддержке пользователей
-
Сроки миграции и аспекты обеспечения непрерывности бизнеса.
Сбор необходимых функций и сервисов — важнейший шаг для обеспечения соответствия новой системы потребностям бизнеса. При сборе этих требований важно не только учитывать текущие настройки, но и попытаться собрать фактические требования от коммерческих организаций, которые будут использовать систему. В противном случае существует риск того, что план основан на нетекущих предположениях. Обязательно ознакомьтесь с дополнительными или улучшенными функциями, которые могут отсутствовать в Интернете, например, облачные вызовы, расширенные очереди вызовов и. Это помогает использовать все преимущества облачной платформы.
При оценке текущей конфигурации важно учитывать, что не все существующие настройки могут остаться необходимыми из-за меняющихся требований на протяжении всего жизненного цикла системы. Основное внимание следует уделить выявлению и сохранению только тех конфигураций, которые соответствуют текущим и будущим потребностям развертывания.
Сосредоточьтесь больше на том, что вам нужно, чем на том, что у вас есть.
При переходе на новую облачную коммуникационную систему крайне важно учитывать соблюдение нормативных требований и правил безопасности, Webex Calling чтобы обеспечить соответствие новой облачной коммуникационной системы правовым, нормативным и организационным стандартам.
-
Соответствие нормативным требованиям: организации должны проверять соответствие отраслевым нормам, таким как GDPR, HIPAA или SOX, требованиям конфиденциальности, хранению и обработке данных, а также страновым требованиям в отношении хранения данных, обхода платных дорог и местонахождения СМИ.
-
Безопасность данных: обеспечение шифрования голосовых и сигнальных данных как при передаче, так и при хранении для защиты от перехвата или несанкционированного доступа.
-
Контроль доступа: определение и обеспечение аутентификации пользователей, авторизации и доступа на основе ролей для предотвращения несанкционированного использования коммуникационных ресурсов.
-
Аудит и мониторинг: внедрение средств регистрации и мониторинга для отслеживания доступа и использования в целях аудита соответствия требованиям и расследования инцидентов безопасности.
-
Согласование политик: согласование миграции с существующими корпоративными политиками безопасности, включая безопасность конечных точек, сегментацию сети и планы реагирования на инциденты.
-
Обеспечение безопасности поставщиков: оценка сертификатов безопасности и сертификатов соответствия Cisco для обеспечения надежности.
Соблюдение этих политик соответствия требованиям и безопасности на этапе планирования помогает снизить риски, избежать судебных санкций и сохранить целостность и конфиденциальность сообщений во время и после миграции.
Потребности в обучении и поддержке пользователей являются важными компонентами перехода от компании к системе, обеспечивающей плавный переход на новую систему и адаптацию пользователей к новым условиям. Ключевые соображения включают в себя следующее:
-
Программы обучения: разработка индивидуальных учебных занятий для различных групп пользователей (конечных пользователей, администраторов, сотрудников службы поддержки) для ознакомления их с функциями, пользовательскими интерфейсами и новыми рабочими процессами.
-
Документация: предоставьте понятные и доступные руководства пользователя, ответы на часто задаваемые вопросы и краткие справочные материалы, включая ресурсы «Что нового и что нового», а также пошаговые инструкции «До» и «После» (в формате видео или краткого руководства), чтобы помочь пользователям адаптироваться к обновленному интерфейсу после миграции.
-
Управление изменениями: заблаговременно сообщайте об изменениях, чтобы оправдать ожидания пользователей и снизить сопротивление.
-
Структура поддержки: создайте специальную группу поддержки или создайте систему эскалации для оперативного решения проблем пользователей во время и после миграции.
-
Непрерывное обучение: планируйте постоянное обновление обучения по мере появления новых функций или обновлений .
-
Механизмы обратной связи: внедрите каналы, позволяющие пользователям сообщать о проблемах и оставлять отзывы для улучшения процессов обучения и поддержки.
Удовлетворение этих потребностей в обучении и поддержке на этапе планирования помогает свести к минимуму перебои, повысить доверие пользователей и максимально использовать преимущества перехода на.
Технические требования
Для успешного перехода на сайт необходимо собрать и задокументировать несколько ключевых технических требований, включая следующие сведения:
-
Готовность сети и пропускная способность
Комплексная оценка сети крайне важна для обеспечения того, чтобы существующая инфраструктура могла поддерживать новую Webex Calling среду. Сюда входят:
-
Анализ полосы пропускания: оценка текущего и прогнозируемого использования полосы пропускания для обработки трафика голосовой связи, видео и данных без перегрузок.
-
Качество обслуживания (QoS): внедрение политик QoS для приоритизации голосового трафика и минимизации задержек, дрожания и потери пакетов.
-
Подключение к глобальной сети и Интернету: проверка соответствия каналов WAN и подключений к Интернету требованиям для облачных вызовов, включая возможности резервирования и аварийного переключения.
-
Настройка брандмауэра и NAT: обеспечение того, чтобы настройки брандмауэра и NAT разрешали передачу необходимых сигналов и медиатрафика.
-
-
Интеграция с существующей системой
Полная интеграция с существующими бизнес-системами необходима для удобства пользователей и непрерывности рабочего процесса:
-
Службы каталогов: оценка интеграции с корпоративным каталогом для автоматической подготовки и аутентификации пользователей.
-
CRM и бизнес-приложения: определение точек интеграции с системами управления взаимоотношениями с клиентами и другими критически важными для бизнеса приложениями.
-
Взаимодействие устаревших АТС: планирование стратегий совместного использования или поэтапной миграции в случае сохранения устаревших телефонных систем во время перехода.
-
-
Совместимость конечных точек и выделение ресурсов
Все конечные точки, включая настольные телефоны, софтфоны и мобильные устройства, должны быть проверены на совместимость:
-
Поддержка устройств: подтверждение поддержки существующих IP-телефонов и устройств или определение необходимых заменителей.
-
Процессы выделения ресурсов: создание автоматизированных или упрощенных методов выделения ресурсов для эффективного подключения конечных точек.
-
Обновления микропрограммного обеспечения и программного обеспечения: планирование необходимых обновлений для обеспечения совместимости и безопасности.
-
-
Конфигурации безопасности и стандарты шифрования
Безопасность имеет первостепенное значение в облачных коммуникациях:
-
Шифрование: комплексное шифрование сигналов и медиапотоков в соответствии с передовыми практиками Cisco в области безопасности.
-
Аутентификация и контроль доступа: внедрение механизмов безопасной аутентификации (таких как SSO, многофакторная аутентификация) и детального контроля доступа пользователей.
-
Соответствие требованиям: обеспечение соответствия решения соответствующим нормативным и отраслевым стандартам (например, GDPR, HIPAA).
-
Мониторинг безопасности: интеграция с инструментами SIEM и настройка оповещений о потенциальных инцидентах безопасности.
-
| Требование | Ключевые соображения |
|---|---|
| Готовность сети и пропускная способность | Пропускная способность, QoS, WAN/Интернет, брандмауэр/NAT |
| Интеграция с существующими системами | Справочник, CRM, АТС, электронная почта/календарь |
| Совместимость конечных точек и выделение ресурсов | Поддержка устройств, выделение ресурсов, обновление микропрограммного обеспечения |
| Конфигурации безопасности и шифрование | Шифрование, аутентификация, соответствие требованиям, мониторинг безопасности |
| Обучение пользователей и управление изменениями | Программы обучения, документация, информирование об изменениях |
| Переносимость номеров и тарифный план | Перенос и перенос номеров, перевод телефонных планов |
| Интеграция со сторонними производителями | Пейджинг, контакт-центр, факс, аналоговые устройства |
Готовность сети и требования
Готовность сети имеет решающее значение для успешного перехода на любое облачное решение для звонков, например. Плохое планирование сети может привести к ухудшению качества звонков, прекращению вызовов и недовольству пользователей. Перед переходом на сеть клиентам необходимо провести оценку сети. Рекомендуется подтвердить доступность полосы пропускания сети для ожидаемого объема вызовов, убедиться в соблюдении требований к качеству обслуживания (QoS) и понять, какие порты необходимо открыть в пограничных брандмауэрах.
Надежное сетевое подключение с достаточным качеством обслуживания (пропускная способность, потеря пакетов, RTT) — это базовое требование для обеспечения наилучшего комплексного пользовательского интерфейса для всех конечных точек, клиентов и приложений, поддерживающих голосовую и видеосвязь.
Клиенты и партнеры могут использовать другие варианты подключения, выходящие за рамки OTT (OTT), которые позволяют оптимизировать подключение, в том числе к Connect. Webex Edge Дополнительные сведения о конструкции Webex Edge Connect см. в разделе Предпочтительная архитектура Cisco для Webex Edge Connect для Webex Meetings многопользовательских вызовов и выделенных инстансов.
Клиенты могут использовать программу CScan для оценки сети, которая позволяет получить информацию о качестве сети клиента, количестве возможных вызовов, задержках и т. д. Дополнительные сведения об инструменте CScan см. в разделе Использование CScan для проверки Webex Calling качества сети.
Чтобы убедиться, что сеть готова к миграции, ознакомьтесь со следующим контрольным списком:
-
Планирование полосы пропускания
Рассчитайте количество одновременных вызовов для каждого сайта, чтобы обеспечить достаточную пропускную способность восходящего и исходящего трафика, а также запас трафика для других критически важных для бизнеса трафика и будущего роста.
В таблице расчета полосы пропускания типов Webex Calling вызовов указаны типы вызовов, доступные при развертывании, а также кодек и максимальная полоса пропускания, необходимая для каждого типа вызова. Как показано в таблице расчета полосы пропускания типов Webex Calling вызовов, требуемую полосу пропускания аудиовызовов для каждого типа вызова можно рассчитать по следующей общей формуле:
Ожидаемое количество одновременных вызовов * Полоса пропускания на один звонок на основе кодека = требуемая пропускная способность сети.
Таблица 2. Webex Calling Расчеты полосы пропускания типа вызова типы звонков Кодек — пропускная способность Расчет полосы пропускания /Настольный телефон -> OPUS — 70 кбит/с Количество одновременных вызовов * 70 кбит/с = требуемая пропускная способность сети /Настольный телефон -> Настольный телефон OPUS — 70 кбит/с Количество одновременных вызовов * 70 кбит/с = требуемая пропускная способность сети /Настольный телефон -> PSTN через LGW G.711 — 80 кбит/с Количество одновременных вызовов * 80 кбит/с = требуемая пропускная способность сети /Настольный телефон -> PSTN через облачный PSTN (например План звонков Cisco) G.711 — 80 кбит/с Количество одновременных вызовов * 80 кбит/с = требуемая пропускная способность сети /Настольный телефон -> Предприятие через LGW G.722 — 80 кбит/с Количество одновременных вызовов * 80 кбит/с = требуемая пропускная способность сети /Настольный телефон -> голосовая почта OPUS — 70 кбит/с Количество одновременных вызовов * 70 кбит/с = требуемая пропускная способность сети Суммируя требуемую одновременно пропускную способность сети для каждого типа вызова, можно определить общую потенциальную потребность в полосе пропускания для конкретного сайта.
Все телефонные линии всегда привязаны к SBC доступа. Чтобы определить требуемую пропускную способность Интернета в любом конкретном месте, необходимо учитывать не только межлокационные вызовы, но и внутрилокальные вызовы, а также звонки на локальный шлюз в этом месте и обратно. Например, для внутрисайтового вызова между двумя телефонами MPP потребуется полнодуплексный доступ в Интернет со скоростью до 2 x 70 кбит/с.
В таблице примеров расчета Webex Calling полосы пропускания показан пример полного расчета полосы пропускания при условии, что все устройства находятся на одном сайте.
Таблица 3. Webex Calling Примеры расчета полосы пропускания типы звонков количество одновременных вызовов Общая пропускная способность Приложение Webex/Настольный телефон → Приложение Webex 15 2* 15* 70 кбит/с = 2100 кбит/с Приложение Webex/Настольный телефон → Настольный телефон 15 2* 15* 70 кбит/с = 2100 кбит/с Приложение Webex/настольный телефон → PSTN через LGW 50 2* 50* 80 кбит/с = 8 000 кбит/с Приложение Webex/настольный телефон → PSTN через Cloud Connect для Webex Calling 0 0* 80 Кбит/с Приложение Webex/настольный телефон → Корпоративный через LGW 15 2* 15* 80 кбит/с = 2400 кбит/с Приложение Webex/настольный телефон → Голосовая почта Webex Calling 5 5* 70 кбит/с = 350 кбит/с Общее количество звонков/пропускная способность 100 звонков 14 950 кбит/с/14,95 Мбит/с -
Все значения полосы пропускания в приведенных выше таблицах относятся к пропускной способности IP. Пропускная способность канала выше в зависимости от инкапсуляций WAN.
-
Полоса пропускания в приведенных выше таблицах предназначена для аудиозвонков. Что касается пропускной способности видеозвонков, приложение Webex и телефоны MPP 8845/65 поддерживают видео H.264 с максимальным разрешением 720p при максимальной пропускной способности 1500 кбит/с на вызов. Однако объем полосы пропускания, потребляемой в любой момент во время вызова, будет колебаться в зависимости от переменной скорости передачи данных, присущей видеосвязи.
-
-
Качество обслуживания (QoS)
Внедрите политики QoS в своей локальной среде, чтобы приоритизировать трафик в реальном времени и обеспечить поддержание QoS на коммутаторах, маршрутизаторах и брандмауэрах.
-
Целевые показатели по задержкам, джиттеру и потере пакетов
Для оптимального качества голоса при звонках по сети OTT и через Интернет рекомендуются следующие пороговые значения:
-
Задержка — менее 100 мс в одну сторону
-
Джиттер — менее 10 мс
-
Потеря пакетов — 0,5% или меньше.
-
-
Межсетевой экран и NAT
Убедитесь, что брандмауэр настроен на пропускание трафика, как указано в статье, доступной в разделе Справочная информация по порту. Webex Calling Кроме того, разрешите доступ к доменам и диапазонам IP-адресов, перечисленным в том же руководстве, и избегайте использования протокола SIP ALG, поскольку он мешает передаче сигналов SIP. Следует избегать медиатрафика через прокси-серверы.
-
DNS и NTP
Обеспечьте надлежащее DNS-разрешение доменов и надежные NTP-серверы для синхронизации часов устройств для проверки и регистрации сертификатов TLS.
-
Планирование аварийного переключения
Рассмотрите существующие подключения поставщиков к данным (MPLS, SD-WAN и т. д.) и, как правило, планируйте прямой доступ в Интернет в каждом месте развертывания. Планируйте использование резервных интернет-каналов там, где требуется высокая доступность. Поскольку вы будете пользоваться облачными сервисами, основным требованием является надежное подключение к Интернету с достаточной пропускной способностью. Вам следует пересмотреть этот переход, если подключение к Интернету в офисах вашей организации, как правило, не отличается надежностью, низкой задержкой и достаточной пропускной способностью входящего и исходящего трафика.
-
Выживаемость сайта
Надежность сайта гарантирует, что ваш бизнес всегда доступен даже в случае разрыва сетевого соединения. Site Survivability использует шлюз в вашей локальной сети для обеспечения резервной службы вызова на локальные конечные точки в ситуациях, когда сетевое соединение прерывается. Если бизнес-требования требуют постоянных звонков в случае сбоя в сети , оцените возможность обеспечения отказоустойчивости сайта с помощью локального шлюза SGW. Дополнительные сведения о проверке работоспособности сайта см. в разделе «Надежность сайта» для. Webex Calling
Настройте унифицированную связь с облаком
Cloud Connected UC (CCUC) — это облачное решение для управления и аналитики, предназначенное для централизованного мониторинга, администрирования и анализа развертываний как в локальной среде (например), так и в облаке (). Unified CM Оно служит связующим звеном между традиционными локальными средами и облачными сервисами Cisco, оказывая поддержку организациям на всех этапах миграции.
Во время перехода на систему CCUC играет важную роль в оптимизации процесса миграции, содействуя сбору исчерпывающих данных из существующего развертывания унифицированных коммуникаций. CCUC помогает в решении ключевых задач перехода, таких как перенос устройств, функций и контактов пользователей, а также автоматизация обновления микропрограммного обеспечения для поддерживаемых IP-телефонов. Обеспечивая централизованный контроль и управление, CCUC помогает обеспечить более плавную и эффективную миграцию.
Cisco настоятельно рекомендует развертывать и развертывать CCUC на ранних этапах переходного проекта, в идеале до или на этапе подготовки. Это позволит получить аналитические данные и возможности, необходимые для тщательной оценки, инвентаризации и планирования последующих действий по миграции, а также для начала перехода к гибридным возможностям и будущего.
Оценка текущей среды
Ключевым видом деятельности при планировании миграции является оценка текущей локальной среды и ее развертывания. Это позволяет понять, к каким потенциальным изменениям могут потребоваться для успешного перехода. Это также позволяет оценить ключевые элементы платформы по сравнению с существующим локальным развертыванием. Вы можете использовать эту информацию, чтобы определить, какие конкретные задачи необходимо выполнить в связи с переходом и какие изменения вы хотите внести в соответствии со своими деловыми и техническими требованиями и сценариями использования.
В рамках этой работы важно рассмотреть следующие аспекты.
Лицензирование
Понимание текущей структуры лицензирования существующего развертывания имеет ключевое значение при подготовке к переходу на. Проведите оценку лицензий в следующих областях существующего локального решения Cisco.
-
Платформа
Возможность полностью сформулировать, какие лицензии в настоящее время лицензированы на вашей базовой платформе, будет иметь решающее значение, если вы совместно с командой по работе с клиентами или партнером определите наилучший путь к гибкому лицензированию. Лицензирование осуществляется с использованием гибкого лицензирования. Дополнительные сведения о гибком лицензировании см. в гибком плане Cisco для совместной работы.
-
Пользователи и устройства
Определите, какая категория лицензий требуется вашим существующим пользователям и устройствам. Это позволит определить, какой тип лицензии необходим пользователям и устройствам. Предлагается несколько типов лицензий, включая лицензии Professional и Standard для пользователей и лицензии Professional и Common Area для рабочих пространств. Дополнительные сведения о лицензировании устройств см. в техническом описании, доступном в разделе Лицензирование устройств.
-
Локальный шлюз
Если для этого перехода требуется Cisco Unified Border Element (CUBE) для доступа к PSTN, следует также рассмотреть возможность лицензирования CUBE. Вопросы лицензирования CUBE рассматриваются далее в этом документе.
Местоположения/сайты
При планировании перехода следует учитывать количество и типы сайтов (крупные центральные, региональные, филиальные и т. д.) в существующем развертывании. Полное понимание существующих мест развертывания поможет стратегически спланировать успешный переход, особенно когда речь идет о том, какие сайты следует перенести и в каком порядке. Подробное понимание требований к тарифным планам (нумерация, режимы набора номера, классы ограничений и т. д.), возможности подключения к сети сайта и пропускной способности (Интернет, глобальная сеть, локальная сеть), а также доступ к PSTN (локальный или централизованный, IP или TDM) для каждого сайта будет иметь решающее значение при принятии решений о миграции. Дополнительные сведения об общих моделях развертывания и основных соображениях см. в информации о моделях развертывания для совместной работы, доступной в Collaboration SRND.
Еще одним важным фактором при переходе на развертывание является доступность местоположения. Возможности, подписки и устройства доступны в зависимости от того, где находится развертывание. Дополнительные сведения о географической доступности см. в разделе Где доступен Webex? .
Наконец, важно понять, какое влияние переход на другие сервисы для совместной работы окажет на другие сервисы для совместной работы. Исходя из цели данного документа, общее предположение заключается в том, что для сохранения существующих сервисов совместной работы, выходящих за рамки рабочей нагрузки по вызовам, ожидается переход к гибридному развертыванию фазы 1, о котором говорилось выше. Примеры сервисов для совместной работы, для которых может потребоваться гибридное развертывание, включают локальный контакт-центр, который еще не перенесен в контакт-центр Webex, и тесную интеграцию с такими системами, как пейджинговые системы и биллинговые системы. Дополнительные сведения о переносе дополнительных рабочих нагрузок и сервисов для совместной работы см. в разделе Переход к совместной работе.
Инвентаризация существующих устройств/клиентов
Перед началом перехода важно провести инвентаризацию существующих аппаратных и программных конечных точек. Наличие полного списка типов и моделей устройств, версий аппаратного обеспечения, типов и количества программных клиентских ОС позволит вам правильно спланировать перевод устройств и смягчить последствия для тех устройств, которые невозможно перевести на облачные вызовы. Инвентаризацию следует использовать для определения устройств, подлежащих замене, и устройств, подлежащих замене до перехода.
Настольные телефоны
Для настольных аудио- и видеотелефонов поддерживаются только настольные телефоны серий 6800, 7800, 8800 и 9800. Это подмножество телефонов Cisco IP, которые поддерживаются с. С некоторыми моделями и версиями телефонов 6800, 7800 и 8800 нельзя использовать их. Дополнительные сведения о поддерживаемых моделях и версиях оборудования см. в разделе Поддерживаемые устройства для. Webex Calling
IP-телефоны Cisco серии 6800 нельзя обновить с корпоративной микропрограммы на многоплатформенную микропрограмму (MPP), которая необходима для. Поэтому любые телефоны 6800, на которых установлено корпоративное микропрограммное обеспечение, необходимо заменить моделью 6800 MPP или другой поддерживаемой моделью телефона.
IP-телефоны Cisco серий 7800 и 8800 должны быть обновлены до микропрограммного обеспечения многоплатформенных телефонов (MPP) перед их переходом и регистрацией. Чтобы определить, какие модели и версии оборудования 7800 и 8800 поддерживают микропрограммное обеспечение MPP, см. раздел Преобразование IP-телефонов Cisco серий 7800 и 8800 между корпоративными микропрограммами и микропрограммами MPP.
Продажи моделей 8845, 8865 и 8865NR закончились, и их не рекомендуется переносить.
Старые версии телефонов серии 8800 (8811, 8841, 8851, 8851NR, 8861) использовать не рекомендуется. Webex Calling Телефоны с аппаратной версией VID 14 или более ранней версии будут зарегистрированы, но из-за аппаратного обеспечения могут возникнуть некоторые проблемы с производительностью.
Настольные телефоны серии 9800 работают под управлением PhoneOS, которая поддерживает как регистрацию, так и регистрацию. Таким образом, на эти телефоны можно перейти без обновления прошивки.
Все остальные IP-телефоны необходимо заменить телефонами серий 6800, 7800, 8800 или 9800, поддерживаемыми в. Webex Calling Дополнительные сведения о поддерживаемых IP-телефонах и настольных телефонах см. в статье Поддерживаемые устройства для Webex Calling.
Конечные точки видеосвязи
Персональные и комнатные видеоконечные точки, в том числе серии Cisco Board, Room и Desk, могут автоматически регистрироваться по протоколу SIP. Для любой из этих конечных точек, которым необходимо совершать аудио- и/или PSTN-вызовы, требуется лицензия на звонки:
-
Для общих устройств в конференц-залах, местах для встреч и т. д. требуется лицензия Professional Workspace или Workspace.
-
Для персонального устройства конечного пользователя требуется профессиональная или стандартная лицензия.
Определите, сколько конечных точек видеосвязи зарегистрировано и используется для аудиозвонков. Возможно, некоторые конечные точки видеосвязи можно использовать только для присоединения к совещаниям или видеозвонков по протоколу SIP. В любом случае до вывода серверов из эксплуатации конечных точек все равно необходимо перейти на конечные точки, однако это поможет определить, скольким из них понадобятся лицензии для продолжения телефонных звонков.
-
Когда видеоустройства будут перенесены с регистрации на, URI этих конечных точек изменится, поскольку теперь они зарегистрированы в облаке.
-
Модели телефонов 8845, 8865 и 8875 являются персональными видеотелефонами, которые поддерживаются с.
Программные клиенты
Это единственный поддерживаемый программный клиент, в отличие от Unified CM которого поддерживаются как приложение Webex, так и Jabber, и новый программный клиент по умолчанию для конечных пользователей.
В зависимости от режима (режимов) развертывания, реализованных в Jabber (режимы только мгновенного обмена мгновенными сообщениями, только по телефону и/или в режиме полной унифицированной связи), возможно, потребуется также рассмотреть возможность переноса рабочих нагрузок в сфере обмена сообщениями и/или собраниями с Jabber на. Они могут быть развернуты в режиме «только по телефону», если они будут использоваться в качестве клиента только для звонков, или в режиме «только для звонков», или в режиме «только для звонков» при работе с другими рабочими нагрузками, например Webex Suite Webex Messagingи/или Webex Meetings переходят в приложение с помощью звонков.
Это повышает удобство работы конечных пользователей, предоставляя функции искусственного интеллекта, такие как аудио/видеоаналитика, транскрипция звонков и другие. Дополнительные сведения см. на сайте https://www.webex.com/all-new-webex.
Прежде чем переводить пользователей на сайт, вам необходимо перенести их клиентов Jabber в. У вас есть два варианта завершения этого перехода.
-
Прежде чем перевести их на
-
Когда вы их перейдете на.
Чтобы облегчить первоначальный переход на режим, рекомендуется использовать вариант 1 и сначала переместить пользователей в режим со звонками. Это даст пользователям время ознакомиться с новым приложением, пока они все еще используют существующую локальную платформу для звонков. Как только вы будете готовы перевести пользователей, вы настроите их на регистрацию на облачной платформе для звонков.
Дополнительные сведения об этих двух вариантах см. в разделе Миграция: один или два шага? .
Полный список поддерживаемых устройств см. в разделе Поддерживаемые устройства для Webex Calling.
Проверьте соответствие устройства требованиям
Как упоминалось ранее, для телефонов серий 7800 и 8800 требуется другой тип микропрограммного обеспечения для телефонов серий 7800 и 8800. Unified CMНа телефонах установлена корпоративная микропрограмма, а на телефонах — микропрограмма для многоплатформенных телефонов (MPP). На этапе подготовки рекомендуется проверить, какие зарегистрированные телефоны могут быть обновлены до микропрограммы MPP. Это даст вам время заменить телефоны, не отвечающие требованиям, одной из поддерживаемых моделей телефонов или найти альтернативный тарифный план, например перевести пользователя только в приложение Webex.
Чтобы определить соответствие телефонов требованиям, Control Hub имеет встроенный инструмент под названием «Перенос телефона на». Webex Calling При использовании этого инструмента для проверки соответствия устройства требованиям выберите вариант «Миграция только лицензии на устройство».
Эта опция позволяет загрузить CSV-файл с телефонами, чтобы проверить соответствие требованиям каждого телефона. Выбрав этот вариант миграции, вы не добавите телефоны, так как вы все еще находитесь на стадии подготовки и пока не готовы к этому. Дополнительные сведения см. в разделе Перенос телефона в. Webex Calling
Возможно, что некоторые телефоны будут возвращены с кодом «Неизвестно». Обычно это связано с тем, что невозможность проверить некоторую информацию о телефоне в серверной системе. Для любых телефонов со статусом «Неизвестно» есть два способа проверить, могут ли они обновиться до микропрограммы MPP.
-
Проверьте каждый телефон вручную и проверьте модель и версию оборудования (PID VID)
Этикетка телефона 7800/8800 с информацией о модели и версии оборудования -
Используйте средство подготовки IP-телефонов Cisco
Загрузите инструмент с сайта https://github.com/joemar2/mpp_readiness_check.
Этот инструмент не является официальным инструментом Cisco и не поддерживается TAC. Он поддерживается всеми силами , но его можно использовать бесплатно.
Это средство необходимо запускать на локальном компьютере с доступом к серверам и IP-телефонам. Он имеет возможность разрешить доступ к Интернету на IP-телефонах, что рекомендуется и необходимо для получения наилучших результатов. Поэтому его следует использовать в нерабочее время, чтобы не мешать работе конечных пользователей. Выходные данные инструмента представляют собой отчет, в котором перечислены телефоны серий 7800 и 8800, подлежащие обновлению до микропрограммы MPP. Поскольку приложение имеет прямой доступ к телефону, оно может проверять неизвестные устройства, о которых сообщала утилита Control Hub.
Отчет о готовности инструмента Cisco к работе IP-телефонов
Пользователи
Одним из наиболее важных шагов по подготовке к успешной миграции является надлежащая подготовка пользователей. Вам необходимо правильно спланировать работу всех пользователей, даже если вы осуществляете поэтапную миграцию. Пользователи должны быть готовы к любому из следующих действий:
-
Развертывание с помощью вызова
-
Развертывание с помощью
-
Настройка сервисов для пользователя
-
Чтобы пользователи могли искать в каталоге (нажмите, чтобы позвонить, контактная информация пользователя, поиск в телефонном справочнике).
Рекомендуется указать всех пользователей до или в начале проекта. Сюда входят пользователи, которые все еще используют платформу Unified CM для звонков независимо от устройства вызова (IP-телефон, Jabber). По мере перехода пользователей на (и/или) вы будете обновлять их лицензии, чтобы предоставлять им необходимые услуги. Предоставляя возможность всем пользователям корпоративных звонков перед началом перехода, пользователь, перешедший на сайт или в, сможет искать в каталоге пользователя, который звонит корпоративным пользователям, который все еще подключен к Jabber и/или подключен к Jabber. Это позволяет перешедшим пользователям найти контактную информацию любого другого пользователя и позвонить ему с помощью поиска в каталоге.
На рисунке «Поиск по каталогу» показан пример поиска пользователем другого пользователя. Результаты поиска содержат контактную информацию пользователя и могут касаться пользователя, который все еще использует Jabber, или пользователя, перешедшего на сайт и/или.
Затем определите, на кого из существующих локальных пользователей будут переведены звонки. Если будет переведено все или большое количество пользователей, рекомендуется перемещать пользователей группами, чтобы проектная группа, ИТ-персонал и вспомогательный персонал могли справиться с переходом и любыми возникающими проблемами. Вам также следует выделить некоторое время на предоставление исходной информации и проведение учебных занятий для подготовки пользователей к такому переходу. Группировать пользователей, меняющих друг друга, можно по целому ряду критериев, включая местоположение или место назначения пользователей на сайте , отделы пользователей и даже типы пользователей (работники умственного труда, руководители, мобильные сотрудники и т. д.).
Например, если пользователи, участвующие в развертывании, разделены на три основных сайта: Нью-Йорк (Нью-Йорк), Сан-Франциско (SFC) и Research Triangle Park (RTP), план перехода пользователей может выглядеть так же, как план, описанный в таблице «План перехода пользователей по сайтам».
| Сайт/местоположение пользователя | Информация и учебные занятия, предшествующие переходу | Переходный период | Поддержка в постпереходный период |
|---|---|---|---|
| Нью-Йорк (1525 пользователей) | Неделя 1 апреля | 15 апреля — 27 апреля | Неделя с 29 апреля |
| SFO (1600 пользователей) | Неделя, начинающаяся 6 мая | 20 мая — 31 мая | Неделя с 3 июня |
| RTP (1275 пользователей) | Неделя с 3 июня | 17 июня — 28 июня | Неделя 1 июля |
Еще один важный фактор — объединение пользователей, зависимых друг от друга. Это может включать в себя, помимо прочего, следующее:
-
мониторинг BLF
-
Один и тот же летчик/группа охотников
-
Поделитесь строками
-
Входит в одну и ту же группу приема звонков
-
Использование одних и тех же номеров колл-парков
-
Домофон
-
Администратор/руководитель.
Вы можете просмотреть конфигурацию (графический интерфейс или экспорт) или использовать инструмент Migration Insights, чтобы определить группы пользователей с этими зависимостями.
Подключение к PSTN
получить доступ к PSTN можно тремя способами: тарифные планы Cisco, подключение к облаку (ранее подключенная к облаку PSTN) и локальная сеть PSTN (локальный шлюз). Однако одно местоположение, определенное в разделе PSTN, может быть присвоено только одному варианту PSTN.
Локальная сеть PSTN с локальным шлюзом (LGW) является важным компонентом стратегии перехода. Он обеспечивает связь между локальным развертыванием и/или PSTN и платформой. Поддерживает как Cisco, так и сертифицированные сторонние пограничные контроллеры сеансов (SBC), которые можно использовать в качестве локального шлюза. Последний список поддерживаемых SBC см. в разделе Список поддерживаемых SBC.
поддерживает до 250 одновременных вызовов с одного локального шлюза, основанного на регистрации, и более 250 одновременных вызовов с одного локального шлюза на основе сертификатов. Локальные шлюзы на основе сертификатов могут поддерживать до 6500 одновременных вызовов, но это зависит от типа подключения к локальному шлюзу ( по сети или по сети) и модели SBC, на которой развернут локальный шлюз. По сути, эти ограничения являются предельным количеством вызовов PSTN на основе локального шлюза и межсайтовых вызовов между конечными точками и конечными точками. Дополнительные сведения см. в разделе Начало работы с локальным шлюзом.
Любые вызовы, превышающие этот лимит, отклоняются с помощью номера 403 Forbidden. Команду show call active voice можно в любом случае запустить на локальном шлюзе, чтобы определить общее количество активных вызовов.
Плохое состояние сети между локальным шлюзом и SBC доступа может снизить производительность сигнального соединения и привести к еще большему снижению лимита одновременных вызовов. Односторонняя задержка между локальным шлюзом и центром обработки данных не должна превышать 100 мс, джиттер — менее 10 мс, а потеря пакетов — менее 0,5%.
Функции и использование функций
При оценке текущей среды важно определить и проанализировать, какие функции настроены. Кроме того, важно понять, как используются эти функции, чтобы можно было (повторно) определить бизнес-требования и технические требования к развертыванию.
Чтобы определить, какие функции настроены, проанализируйте конфигурацию. Это все статические данные, которые задаются при настройке функции или параметра в системе. Для выполнения этого анализа можно использовать следующие опции:
-
Просмотрите конфигурацию в графическом интерфейсе администратора
-
экспорт конфигурации -- массовый экспорт или AXL
-
инструмент анализа миграции (рекомендуется)
-
Инструменты сторонних партнеров Cisco (рекомендуется).
Для эффективного анализа использования функций необходимо изучить динамические системные данные, такие как использование, регистрация и количество звонков . Различные аналитические инструменты и панели управления позволяют анализировать эти показатели, обеспечивая всестороннее понимание производительности и емкости системы, что способствует принятию обоснованных решений во время миграции и оптимизации. Для выполнения этого типа анализа можно использовать следующие варианты:
-
Просмотр необработанных записей CDR
-
Обзор данных Unified CM RTMT
-
инструмент анализа миграции с использованием данных CDR
-
Обзор аналитики унифицированных коммуникаций, подключенных к облаку, в
-
Объем звонков
-
Зарегистрированные конечные точки
-
Местоположения (CAC)
-
Использование магистралей.
-
-
Инструменты сторонних партнеров Cisco.
Для этого анализа Cisco рекомендует начать с инструмента Webex Control Hub Migration Insights. Вы импортируете экспортируемый файл TAR и файлы Unified CM CDR (необязательно, но необходимы для анализа использования функций) в инструмент. Инструмент создаст следующие отчеты на основе CSV , которые можно использовать для начала анализа:
| Название отчета Описание отчета |
|---|
| ImportedDataBulk.csv
Все пользователи и устройства из Unified CM данных |
| DeviceEligibility.csv
Определяет устройства, на которые можно перенести Webex Calling (IP-телефоны, устройства Room OS, ATA и сторонние устройства) |
| DevicePoolNumbers.txt Список всех номеров в определенном пуле устройств |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Подробная информация об устройствах и пользователях, которые необходимо перенести вместе, в зависимости от общих линий связи, пилотной программы поиска, очереди вызовов, парка вызовов и конфигурации группы приема вызовов |
| HuntGroupMigrationInsight.csv Подробная информация о назначенных охотничьих линиях, группах линий и связанных агентах |
| SharedlineGroupMigrationReport.csv Обзор того, как телефонные номера (справочные номера) распределяются между пользователями |
| Название отчета Описание отчета |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Информация о праве на перенос устройств в зависимости от использования этой функции |
| FeatureUsageWithLastUsageDateReport.csv Количество использований: количество вызовов пилотных проектов по поиску и очереди вызовов, а также дата последнего использования |
| UserWorkspaceLastUsage.csv Дата последнего использования пользователей и рабочих пространств как для программных клиентов, так и для жестких телефонов |
| DIDUsageReport.csv Использование DID как для назначенных, так и для неназначенных DID |
Дополнительные сведения об отчетах Migration Insights см. в разделе Аналитика миграции .
Если после изучения информации, содержащейся в отчетах Migration Insights, вам понадобятся дополнительные сведения о функциях и использовании, Cisco рекомендует воспользоваться одним из инструментов миграции от сторонних партнеров Cisco и/или ознакомиться с конфигурациями в графическом интерфейсе пользователя или в данных экспорта конфигураций.
Интеграции Cisco: подключение к Unity UCCX UCCE
Голосовая почта — неотъемлемая часть предложения и встроенная в решение. Она не может быть интегрирована с локальными решениями голосовой почты, такими как Unity Connection или Unity Connection Express. Кроме того, не существует встроенного способа переноса существующих сообщений голосовой почты или приветствий, подключенных к Unity, в встроенную службу голосовой почты, доступную вместе с Unity. Некоторые инструменты миграции, разработанные сторонним партнером Cisco, позволяют переносить часть этих данных. Дополнительные сведения о голосовой почте см. в разделе Настройка параметров голосовой почты пользователя и управление ими. Webex Calling
также поддерживает общие почтовые ящики голосовой почты и факса. Дополнительные сведения см. в разделе Управление общей голосовой почтой и входящим факсом для. Webex Calling
имеет встроенную функцию автосекретаря, которая входит в базовую платформу. Эта функция позволяет переключать обработчики вызовов и функции автосекретаря в Unity Connection. Инструмент Control Hub Migrate Features Unified CM from поддерживает перенос конфигураций Unity Connection на автосекретарей. Дополнительные сведения об использовании этого инструмента см. в разделе Перенос устройств и функций с на. Unified CM Webex Calling
Запись разговоров
включает два варианта записи разговоров без дополнительной оплаты.
-
Запись звонков Webex
-
Dubber Go recording (партнерское предложение) — это интеграция между Dubber и Dubber, при которой все записанные носители надежно хранятся в облаке.
В таблице включенных опций записи перечислены некоторые ключевые особенности двух вариантов записи разговоров, которые доступны без дополнительной оплаты.
| Webex | Dubber Go |
|---|---|
| Доступно всем пользователям | Доступно всем пользователям |
| Неограниченное количество записей | Неограниченное количество записей |
| Срок хранения 1 год* | 30-дневный срок хранения |
| 100 ГБ хранилища на организацию | - |
| Сотрудники по соблюдению нормативных требований могут получать доступ к записям разговоров и управлять ими | - |
| API для управления записями | - |
Администраторы могут настраивать доступ пользователей к записям разговоров и управлять им
|
Только пользователи могут получать доступ к своим записям и управлять ими
|
Если вашей организации требуются дополнительные возможности записи, такие как запись разговоров по нормативным требованиям, более длительные сроки хранения, больший объем памяти, анализ ИИ и/или доступ администратора, существуют платные предложения или дополнения как от Cisco, так и от сторонних поставщиков звукозаписи. Дополнительные сведения о поставщиках звукозаписи, конфигурациях и дополнительных партнерских услугах см. в разделе Управление записью звонков для Webex Calling.
Интеграция со сторонними организациями
поддерживает множество сторонних интеграций, включая, помимо прочего, SBC для локальных шлюзов, IP-телефонов, домофонов, динамиков/пейджеров, ATA и т. д. В дополнение к этим сторонним устройствам Webex Calling поддерживает различные сторонние решения для поддержки клиентов, аналитики, записи, выставления счетов и т. д. Дополнительные сведения о сторонних решениях см. в Webex App Hub.
План
План проекта высокого уровня
При разработке высокоуровневого проектного плана перехода от к проекту важно четко определить этапы и этапы, соответствующие как бизнес-целям, так и техническим требованиям. План должен начинаться с этапа комплексной оценки, включая сбор подробных технических и бизнес-требований, а также выявление заинтересованных сторон и определение критериев успеха. Ключевые соображения включают распределение ресурсов, оценку сроков, управление рисками и коммуникационные стратегии, обеспечивающие информирование и вовлечение всех сторон в процесс миграции. Кроме того, план должен включать контрольные точки проверки, такие как пилотное тестирование и поэтапное развертывание, чтобы свести к минимуму перебои и внести коррективы на основе отзывов.
Примеры элементов, которые следует включить в план проекта:
-
Определение масштабов миграции (например, какие пользователи, устройства и функции будут перенесены)
-
Планирование учебных занятий для конечных пользователей и групп поддержки
-
Координация оценок готовности сети и
-
Планирование переходных мероприятий с использованием запасных вариантов. Также важно интегрировать проверки соответствия требованиям и безопасности, а также этапы поддержки и оптимизации после миграции.
Структурировав план проекта с учетом этих соображений, организации смогут лучше управлять сложностями, снижать риски и обеспечивать более плавный переход к проекту.
Миграционный путь — один или два шага?
требует от пользователей использования программного клиента для звонков. Поэтому, если кто-либо из пользователей все еще пользуется, у вас есть два варианта, когда их можно перенести. Можно выполнить одноэтапную миграцию пользователей или двухэтапную миграцию пользователей.
Вариант 1. Одноэтапная миграция пользователей
В ходе одноэтапной миграции пользователи переходят от пользователя к пользователю одновременно с переходом от пользователя Unified CM к другому. Этот вариант обычно предназначен для клиентов с небольшим количеством пользователей, которые могут одновременно перемещать программный клиент пользователя и службу телефонной связи. Этот тип миграции показан на рисунке, на который одновременно переходят пользователь в службу телефонной связи, программный клиент и телефон, приведенный ниже. При использовании этой опции пользователь одновременно выполнит следующее:
-
Службы телефонной связи перенесены с
-
Телефонные номера и добавочные номера перенесены с
-
Программный клиент, перешедший с Jabber на -, зарегистрируется в
-
Регистрация по телефону перенесена с на.
Это все еще может быть поэтапная миграция, при которой группы пользователей перемещаются в разное время, но при перемещении каждого пользователя все это происходит одновременно.
Вариант 2. Двухэтапная миграция пользователей
Другой подход — двухэтапная миграция. На этапе 1 пользователи переходят от услуг телефонной связи к сервисам телефонной связи, но продолжают пользоваться ими. Затем, на шаге 2, пользователи переходят из Unified CM в. Этот вариант рекомендуется для крупных клиентов, которые могут управлять изменениями конечных пользователей и хотят отделить смену программного клиента пользователя от смены службы вызова. Этот тип миграции показан на следующем рисунке: «Перенос программного клиента, а затем перенос службы вызовов, программного клиента и телефона» Webex Calling ниже.
Шаг 1
-
Программный клиент перешел с версии на — зарегистрируется в.
Шаг 2
-
Службы телефонной связи перешли от в.
-
Телефонные номера и добавочные номера переехали в.
-
регистрация перенесена с на.
-
Регистрация по телефону перенесена с на.
Это все еще может быть поэтапной миграцией, при которой группы пользователей перемещаются в разное время на обоих этапах.
Выбранный вами вариант зависит от того, как вы хотите управлять переходом пользователей в систему и. Рекомендуется использовать эту процедуру поэтапно (вариант 2). Это позволяет свести к минимуму изменения, внесенные конечным пользователем за один раз, и распределить усилия между различными частями проекта. Однако если вы предпочитаете, чтобы влияние на пользователей оказывалось только один раз, вам также подойдет вариант 1.
Если посмотреть на рекомендуемый маршрут (вариант 1), то на рисунке карты высокоуровневого перехода Jabber к приложению Webex ниже показан высокоуровневый переход на шаг 1.
На этом этапе пользователи переходят с Jabber на все свои службы телефонной связи. Однако платформа для звонков все еще работает, Unified CM и она будет регистрировать свои телефонные сервисы. Как показано на высокоуровневой карте перехода Jabber к Webex App, локальная инфраструктура не меняется и работает так же, как и Jabber. Единственное изменение заключается в том, что требуется подключение к сети.
Дополнительные сведения об этом переходе см. в разделе Карта перехода от Jabber к Webex и руководство по развертыванию в разделе Клиент на странице перехода к совместной работе.
Unified CMРисунок карты перехода на Webex Calling высокоуровневую карту — это высокоуровневый переход от в. Это второй шаг рекомендуемого путешествия.
Если вы решите использовать одноэтапный подход, это тоже применимо.
На этом этапе пользователи переходят в группы. На этом этапе пользователи начинают использовать для своих звонков услуги регистрации звонков и регистрации IP-телефонов.
Поскольку пользователи перемещаются группами, корпоративные пользователи во время перехода будут разделены между двумя платформами телефонной связи. Это состояние изображено Unified CMна рисунке с карты перехода на этап 1 к Webex Calling высокоуровневому переходу. На этом этапе необходимо спланировать управление вызовами между пользователями на двух платформах и маршрутизацию вызовов PSTN. При каждом переходе к группе пользователей необходимо будет обновлять тарифные планы и маршрутизацию вызовов, а также локальные шлюзы.
Как только все пользователи, программные клиенты и устройства будут переведены на (этап 2), всю локальную инфраструктуру UC можно будет удалить и вывести из эксплуатации.
Дизайн
Выбор региона
доступен по всему миру и поставляется из резервных центров обработки данных в нескольких регионах: США (Даллас, Чикаго), Канаде (Ванкувер, Торонто), Европе (Франкфурт, Амстердам), Великобритании (Лондон, Манчестер), Австралии (Мельбурн, Сидней), Японии (Токио, Осака), Саудовской Аравии (Эр-Рияд, Джидда) и Индии (Мумбаи, Ченнаи). POPS для СМИ предоставляют мультимедийные услуги для оптимизации времени передачи информации в оба конца. Например, сингапурский центр обработки данных используется для оптимизации времени передачи мультимедийных материалов туда и обратно для клиентов из азиатских стран, где время поездки туда и обратно в Австралию или Японию может оказаться неоптимальным. Центры обработки данных соединены мультигигабитной магистралью с полным резервированием. На рисунке центров обработки данных, распределенных по всему миру, показан обзор всех центров обработки данных. Последний список доступных центров обработки данных см. в разделе Местоположение центров обработки данных Webex Calling.
Каждый клиент обслуживается на одном из экземпляров. Вся информация об обеспечении этого клиента хранится в этом экземпляре, а сигнализация SIP всех конечных точек и локальных шлюзов, предоставленных этому клиенту, привязана к экземпляру, на котором работает клиент. Поскольку первоначальный выбор региона изменить сложно, важно учитывать все важные факторы в процессе принятия решений, ведущих к выбору региона. Чтобы избежать чрезмерных задержек с подачей сигнала в оба конца, важно на раннем этапе переходного процесса решить, какой экземпляр следует использовать. Cisco рекомендует выбрать инстанс, обеспечивающий наименьшее время передачи сигнала в обе стороны для наибольшего числа пользователей в развертывании.
Информацию о доступности по странам см. в разделе Где доступен Webex? .
Местоположения
Чтобы подготовиться к предоставлению мест, необходимо собрать необходимую информацию по всем целевым местам миграции. Сведения, необходимые для каждого местоположения, кратко изложены в разделе «Сведения для сбора по каждому местоположению».
| Информация | Комментарий |
|---|---|
| Диапазон (ы) расширения | В каждом адресе могут быть расширения, начинающиеся с разных цифр. Для
рулевого номера межсайтового набора номера следует оставить одну цифру (например, 8) и одну цифру для
рулевого номера PSTN (например, 9). Ни один из этих двух цифр не может начинаться ни с одной из этих цифр. Все диапазоны расширений во всех местоположениях должны иметь одинаковую длину. |
| Диапазон (ы) DID | - |
| Рулевая цифра PSTN | - |
| Код сайта | Все коды сайтов во всех местах должны быть уникальными и иметь одинаковую длину. |
| Основной номер | При создании местоположения необходимо предоставить два идентификатора DID. Один в качестве
основного номера (например, для присвоения службе автосекретаря), а другой — для
портала голосовой почты. Предоставьте один DID для номера голосовой почты. |
| Номер голосовой почты | |
| Количество лицензий | Необходимые лицензии по типам, включая стандартные лицензии, лицензии Professional, Workspace, список маршрутов, план исходящих звонков. |
| Одновременные звонки в час пик | Сумма одновременных вызовов между устройствами и между устройствами и локальным шлюзом (PSTN и вызовы на устройства). Необходим для определения требуемой пропускной способности доступа в Интернет. |
| Страна | - |
| Часовой пояс | - |
| Язык | - |
| Контактное лицо (имя, телефон, адрес электронной почты) | - |
| Адрес (почтовый адрес, город, штат, почтовый индекс) | - |
| Местонахождение конечных точек службы экстренной помощи, физическое место дислокации | Диспетчерское местоположение устройства, используемое для вызова экстренных служб, обычно включает следующее: адрес здания, адрес здания + номер этажа, адрес здания + номер квартиры или адрес здания + номер этажа + номер офиса/кубический номер. |
| Уникальное физическое сетевое местоположение служб экстренной помощи для каждого устройства | Физическое сетевое местоположение для экстренных вызовов обычно включает следующее: коммутатор/порт для проводных устройств, идентификаторы базовых наборов услуг (BSSID) точек доступа (AP) для беспроводных подключенных устройств и/или локальные IP-подсети для конечных устройств. |
PSTN
При проектировании развертывания у клиентов есть три основных варианта подключения к PSTN: планы Cisco Calling Plans (облачная служба PSTN, управляемая Cisco), поставщики подключенных к облаку PSTN (CCPP, где поставщики предоставляют услуги PSTN через облако) и локальные PSTN (где локальные шлюзы соединяют корпоративную сеть с PSTN). С введением транкинга PSTN для гибридных развертываний (дополнительные сведения см. в разделе Транкинг PSTN для гибридных Webex Calling развертываний в разделе Транкинг PSTN) организации получили дополнительную гибкость в своем подходе к миграции. Эта функция позволяет клиентам перенести свои PSTN на CCPP в начале перехода и начать переход на облачные PSTN для пользователей, одновременно используя CCPP для обслуживания обслуживания PSTN для пользователей, которые остаются в Cisco во время поэтапной миграции.
Этот гибридный подход позволяет организациям сначала перенести отдельные группы пользователей в облако без немедленного пересмотра всей телефонной среды. Однако это сопряжено с дополнительными сложностями и рисками, особенно в том, что касается адаптации существующей логики маршрутизации вызовов к поддержке новой архитектуры. Совместимость с устаревшими приложениями, такими как факс-серверы, контакт-центры или пейджинговые системы, также требует тщательного рассмотрения. Ключевые технические проблемы могут включать обеспечение беспрепятственного согласования сквозных кодеков и передачи сигналов DTMF (двухтональной многочастотной) в смешанной среде, а также проверку совместимости со специализированными функциями телефонии. Надлежащее планирование и тестирование необходимы для минимизации сбоев и обеспечения надежности голосовых услуг на протяжении всего процесса миграции. Кроме того, важно учитывать коммерческие соображения, поскольку для использования гибридной транкинговой сети требуется лицензия на использование, основанная на количестве одновременных вызовов между локальной средой и поставщиком PSTN, подключенным к облаку (CCPP).
В качестве альтернативы организации могут сохранить подключение к локальной сети PSTN на протяжении всего переходного периода. В этом сценарии переход на CCPP может быть осуществлен двумя способами: в виде единого скоординированного перехода для всех пользователей и местоположений после завершения миграции или поэтапно, при этом миграция PSTN будет осуществляться отдельно по мере перемещения пользователей. Такой подход может помочь упростить сосуществование и обеспечить непрерывность устаревших интеграций, но он сопряжен с рядом операционных сложностей. К ним относятся проблемы, связанные с переносом номеров, такие как необходимость точной координации заказов на номерные порты, потенциальные задержки и ограничения, налагаемые провайдером, такие как ограничение количества одновременных запросов на порты или ограничение на перенос подмножеств из большого количества блоков. Организации должны тщательно планировать стратегию перехода на PSTN с учетом этих логистических соображений, чтобы избежать перебоев в обслуживании и обеспечить бесперебойную миграцию.
На рисунке «Перенос на CCCP с самого начала и сохранение локального PSTN» показаны два варианта миграции PSTN, описанных выше. На рисунке слева показан сценарий, когда все локальные пользователи и приложения используют услуги PSTN, подключенные к облаку, через локальную магистраль и локальный шлюз, соединяющий локальную сеть, а на рисунке справа показан сценарий, когда существующая локальная PSTN остается на месте, а пользователи Webex Calling используют локальную PSTN через локальное шлюзовое соединение между локальными и. Во время перехода можно переключиться на использование PSTN, подключенной к облаку.
В обоих сценариях для звонков между локальной сетью и пользователем используется соединение через локальный шлюз. Соединение между локальной сетью и сетью должно быть спроектировано и рассчитано соответствующим образом с учетом ожидаемого количества одновременных вызовов и требуемой избыточности.
План набора
Для обеспечения бесперебойной совместимости в период миграции и во время миграции необходимо разработать и внедрить комплексную архитектуру телефонных планов на обеих платформах. Эта двухплатформенная схема абонентского плана обеспечивает согласованную маршрутизацию вызовов, перевод номеров и прозрачность функций, что позволяет пользователям любой системы общаться без ухудшения качества обслуживания или перебоев в работе пользователей на этапе сосуществования.
Локальный тарифный план в
В ходе перехода, чтобы обеспечить возможность сосуществования устройств, зарегистрированных на корпоративной телефонной карте Unified CM и в ней, необходимо внести изменения, чтобы обеспечить выполнение как минимум следующих требований:
-
+E.164, набор номера от до
-
Дозвон по добавочному номеру от до (внутри сайта, а также между сайтами, если диапазоны добавочных номеров уникальны)
-
Сокращенный межсайтовый набор номера от до
-
Принудительный внутрисетевой набор номера от 0 до
-
Обратный звонок из справочника пропущенных звонков в пункты назначения на
-
Вызовы PSTN с PSTN на PSTN, если во время перехода используется локальная PSTN для
-
Вызовы PSTN (если) во время перехода используется транкинг PSTN для гибридных развертываний для предоставления доступа к PSTN локальным пользователям через Cloud Connect для
-
Принудительное внутрисетевое подключение к
-
Дозвон по добавочному номеру от до (между сайтами).
Если какие-либо из вышеперечисленных привычек набора до перехода не поддерживались (например, не существовало сокращенного набора номера между сайтами), то их необязательно вводить во время перехода.
На рисунке «Передовые практики» показан передовой подход к использованию абонентской группы, описанный в разделе «Предпочтительная архитектура для корпоративных локальных развертываний Cisco Collaboration 12.x» (CVD). Основные характеристики этого подхода включают в себя:
-
Единый раздел для номеров каталогов +E.164
-
Базовая маршрутизация на основе шаблонов маршрутов +E.164
-
Нормализация всех привычек набора номера до +E.164 с использованием шаблонов трансляции
-
Использование шаблона перевода, вызывающего наследование пространства поиска (опция Использовать пространство поиска вызовов автора, заданное в шаблонах перевода).
Например, при наборе номера PSTN (9+1+10D) с устройства в SJC, оснащенного пространством поиска телефонных звонков SJCInternational, сначала будет сопоставлен шаблон перевода 9.1 [2-9] XX [2-9] XXXXXX, который нормализует номер вызываемой стороны до +E.164. Затем вторичный поиск снова использует то же самое пространство поиска вызовов SJCInternational (вызывая наследование пространства поиска), и строка +E.164 из 4 цифр будет совпадать либо с номером каталога +E.164 в разделе DN, либо с одним из шаблонов маршрута PSTN в разделе USPSTNNational или SJCPStnLocal. Сокращенные режимы набора номера внутри сайта и между сайтами реализованы с помощью переводов в разделах ESN и SJCToE164. В то время как раздел ESN является глобальным разделом (доступным для телефонов в любом месте), раздел SJCTOE164 доступен только для пользователей в местоположении SJC. Предполагается, что диапазоны расширений перекрываются.
Первый шаг к разрешению звонков от до — убедиться, что пункты назначения +E.164 маршрутизируются соответствующим образом. Этого можно добиться, добавив раздел в абонентскую группу, добавив в этот раздел схемы маршрутов +E.164 для всех пунктов назначения и, наконец, добавив эту секцию во все области поиска вызовов, представляющие классы обслуживания, к которым необходимо обеспечить доступ. Создание выделенного раздела необходимо для создания дифференцированного класса услуг для исходящих звонков. Чтобы избежать циклических вызовов, область поиска входящих вызовов в магистрали из локального шлюза не должна иметь доступа к разделу.
Как показано на рисунке +E.164 для Webex Calling маршрутизации в местоположение с диапазоном +E.164 DID +1 221 555 2XXX и кодом сайта 121, в раздел необходимо срочно добавить шаблон маршрута, соответствующий этому диапазону +E.164.
Если выбор локального шлюза для конкретного сайта не требуется, вместо использования списка маршрутов с локальной группой маршрутов в качестве места назначения для шаблонов маршрутов, указывающих на одну группу маршрутов, можно предоставить локальный шлюз в качестве единственного члена, а затем шаблоны маршрутов указывают на один список маршрутов, в котором эта группа маршрутов является только записью.
Чтобы обеспечить межсайтовый сокращенный набор номера на сайте, в раздел добавлен необходимый шаблон маршрута 8121.2XXX. Возможно, в разделе ESN уже существует схема нормализации набора номера 8121.2XXX, которая нормализует набор номера ESN до +E.164. В этом случае 8121.2XXX кажется излишним, но как только все DN-адреса в соответствующем месте будут перенесены на 8121.2XXX, шаблон перевода нормализации набора номера можно удалить, а затем шаблон маршрута 8121.2XXX позволит звонить по ESN даже пользователям, входящим только в этот диапазон.
При такой смене тарифного плана звонить на место назначения можно не только сокращенным междугородним набором номера и +E.164. Кроме того, международный и национальный набор телефонных номеров PSTN возможен благодаря тому, что эти режимы набора сначала нормализуются до +E.164 с помощью уже существующих шаблонов преобразования нормализации набора, а затем маршрутизируются, сопоставляя шаблон маршрута +E.164 в разделе.
Шаблон маршрута +E.164, соответствующий диапазону DID местоположения, можно обеспечить, пока все DID все еще находятся на хостинге. Алгоритм наилучшего сопоставления шаблонов совпадений, позволяющий при наборе номера, размещенного на сервере, лучше совпадать с указанным справочным номером +E.164 по сравнению с шаблоном маршрута +E.164 с подстановочными знаками, указывающим на него, так что вызовы будут передаваться на включенную линию, а не на которую отправляются.
тарифный план
Каждому входящему пользователю предоставляется добавочный номер и/или телефонный номер +E.164. Длина добавочного номера является фиксированным глобальным параметром: все расширения в развертывании имеют одинаковую длину. Дозвон по добавочному номеру можно использовать между пользователями как в пределах одного местоположения, так и между местоположениями. Сокращенный межсайтовый добавочный номер (в последнем случае) работает только в том случае, если набираемый добавочный номер уникален.
Если требуется сокращенный межсайтовый набор номеров между филиалами, но добавочные номера, назначенные в разных местах, совпадают, то необходимо составить план нумерации для конкретного предприятия, добавив к добавочным номерам код доступа (код сайта). Дополнительные сведения см. в разделе Предпочтительная архитектура для локальных развертываний Cisco Collaboration 15, обзор проектирования см. в разделе Предпочтительные архитектуры Cisco для совместной работы.
Длина добавочного номера, режим набора номера между точками, длина префикса для межлокационного набора и рулевая цифра в префиксе маршрутизации для межлокационного набора настраиваются в настройках службы вызовов в:
-
Длина префикса маршрутизации по местоположению: длина префикса, включая рулевой номер. Требуется только в том случае, если необходимо разработать корпоративный план нумерации в качестве альтернативного метода сокращенного набора телефонных номеров между точками предприятия.
-
Рулевая цифра в префиксе маршрутизации: рулевая цифра, обозначающая сокращенную корпоративную привычку звонить из одного места в другое. Следует избегать совпадений с первой цифрой любого местоположения и цифрами исходящего набора номера. Требуется только в том случае, если необходимо разработать корпоративный план нумерации в качестве альтернативного метода сокращенного набора телефонных номеров между точками предприятия.
-
Длина внутреннего добавочного номера: стандартная длина добавочных номеров. Может принимать любое значение от двух до десяти.
Если от локальной службы управления вызовами требуется набор номера с добавочного номера или номера со значимых корпоративных номеров (код управления, код сайта, добавочный номер), а локальная система управления вызовами отправляет добавочный номер в качестве идентификатора вызывающего абонента, обязательно задайте параметр Максимальная неизвестная длина добавочного номера в разделе Маршрутизация вызовов между локальными и локальными вызовами, чтобы входящие вызовы из локальной системы управления вызовами можно было правильно классифицировать как локальные вызовы. -
Разрешить набор дополнительных номеров между местоположениями: включите или отключите дополнительный набор между местоположениями. Эту опцию следует включать только в том случае, если все добавочные номера в организации уникальны. Если опция отключена, необходимо набирать важные корпоративные номера (код управления, код сайта, добавочный номер) или телефонные номера между отделениями .
Первые три параметра в основном используются при составлении тарифного плана для телефонов, позволяющего свести к минимуму время ожидания между цифрами при наборе номера без подключения к сети. Отклонения от этих глобальных настроек все еще возможны (например, можно указать добавочные номера другой длины), но в Control Hub появится предупреждающее сообщение, а для набора номера с телефонов может потребоваться заблокировать набор во избежание конфликтов в предварительно загруженной абонентской группе.
В примере нумерации в таблице Enterprise показан пример трех мест, в которых диапазоны добавочных номеров в двух населенных пунктах (NYC и RTP) идентичны. Создание корпоративной схемы нумерации, включающей в себя управляющую цифру 8 между сайтами, за которой следует трехзначный код сайта и четырехзначный добавочный номер, позволяет использовать сокращенный набор номеров между сайтами без дублирования.
| Сайт | Диапазон расширения | Код сайта | Ассортимент для предприятий |
|---|---|---|---|
| NYC | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
Чтобы обеспечить плавный переход, набор привычек набора номера для пользователей до и после перехода на них в идеале должен быть одинаковым. Чтобы подготовиться к переходу в каждое местоположение, необходимо задокументировать диапазоны DID и диапазоны добавочных номеров (или сокращенные привычки набора номера внутри сайта). На основе этой информации необходимо выбрать межсайтовую управляющую цифру.
В таблице Диапазоны удлинителей фиксированной длины приведен пример трех точек и диапазонов удлинителей фиксированной длины. Поскольку необходимо избегать совпадения режимов набора номера, важно убедиться, что в любом дополнительном диапазоне первая цифра диапазона не совпадает с рулевой цифрой при сокращенном наборе номера между узлами. Если, например, в качестве управляющей цифры для межсайтового набора номера выбрано значение 8, то ни один дополнительный диапазон ни на одном сайте не может начинаться с 8. Как правило, добавочные номера в данном месте совпадают с последними цифрами идентификаторов DID, присвоенных этому местоположению. Во избежание конфликтов первую цифру добавочного номера можно изменить. Например, если в каком-либо месте используются идентификаторы DID в диапазоне +1 408 555 8XXX, то вместо 8XXX в качестве диапазона расширений можно использовать 7XXX для расширений на этом сайте
| Сайт | Диапазон расширения | Расширения | Код сайта | Ассортимент для предприятий |
|---|---|---|---|---|
| NYC | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Семизначные строки набора, набранные на устройстве, использующем американскую абонентскую группу, совпадают с семизначным шаблоном для местного набора в предварительно загруженной телефонной группе США. Чтобы избежать совпадений между режимами набора номера внутри сети и за ее пределами (PSTN), в этом месте можно использовать обязательный внешний код доступа. Если существующая корпоративная схема нумерации и соответствующая сокращенная схема межсайтового набора совпадают с образцами национального набора, то при переходе на схему нумерации во избежание накладок ее можно также изменить на более длинную или более короткую форму. Самый простой способ добиться этого — добавить в схему нумерации дополнительную цифру. Новую более длинную схему межсайтового набора должны использовать только пользователи, на которые уже перешли. Все еще подключенные пользователи могут продолжать набирать семь цифр. В этом случае при использовании корпоративного телефонного плана необходимо обеспечить преобразование сокращенного семизначного набора номера от Unified CM до +E.164 или в сокращенный формат набора номера, используемый на. Это необходимо сделать перед отправкой вызова на локальный шлюз.
Пример такого изменения нумерации приведен в таблице «Переход на семизначный набор». В этом примере при сокращенном межсайтовом наборе используется управляющая цифра 8, затем двухзначный код сайта и четырехзначный добавочный номер. Чтобы избежать семизначного сокращенного межсайтового набора номеров для населенных пунктов, коды сайтов можно легко изменить на трехзначные, добавив произвольную цифру (в примере 8) к используемым двузначным кодам сайта, чтобы при межсайтовом звонке с телефонов использовалась рулевая цифра 8, затем добавочная цифра 8, старый двузначный код сайта и четырехзначный добавочный номер. Пользователям не нужно запоминать новые коды сайтов; им достаточно использовать префикс 88 в качестве префикса для межсайтового набора вместо 8.
| Сайт | Расширения | Код сайта | Корпоративный ассортимент | Код сайта | Корпоративный ассортимент |
| NYC | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
В сценарии с разными форматами корпоративных номеров и представлением корпоративных номеров в качестве информации о звонящих абонентах (например, звонки с устройств без DID) важно также обеспечить сопоставление различных форматов номеров для получения информации о вызывающих абонентах, чтобы обеспечить работоспособность обратного вызова. Такое сопоставление может быть достигнуто с помощью схемы трансформации вызывающих абонентов на магистральном канале между локальным шлюзом и локальным шлюзом.
Запись
Хорошо спроектированное решение для записи разговоров требует тщательного рассмотрения нескольких ключевых элементов дизайна, чтобы обеспечить его соответствие целям организации, нормативным требованиям и техническим ограничениям. Два наиболее важных решения связаны с выбором поставщика услуг и выбором региона. Возможно, оба решения придется адаптировать во всем мире и отменить в определенных местах в зависимости от потребностей бизнеса.
1. Выбор провайдера записи разговоров
Выбор подходящего поставщика услуг записи разговоров имеет важнейшее значение для достижения бизнес-целей и обеспечения согласованности функций в организации:
-
Выбор поставщика услуг по всему миру: организации обычно назначают основного поставщика услуг записи разговоров на глобальном уровне, обеспечивая единообразие набора функций, соответствие нормативным требованиям и поддержку во всех подразделениях
-
Переопределения, основанные на местоположении: в сценариях, когда определенные сайты или регионы имеют уникальные бизнес-потребности или нормативные требования, может возникнуть необходимость отменить выбор глобального поставщика и указать альтернативных поставщиков для этих регионов. Такая гибкость позволяет удовлетворить различные требования по соблюдению нормативных требований и локальные операционные потребности
-
Бизнес-требования: выбор поставщика должен основываться на оценке таких факторов бизнеса, как соответствие нормативным требованиям (например, MiFID II, HIPAA), обеспечение качества, разрешение споров или потребности в обучении
-
Доступность функций: поставщиков следует оценивать на основе их способности предоставлять необходимые функции, такие как мониторинг в реальном времени, возможности поиска и воспроизведения, шифрование, политики хранения, интеграция с аналитическими платформами и поддержка различных типов звонков (входящих, исходящих, внутренних).
2. Выбор региона
Определение региона, в котором хранятся и обрабатываются записи разговоров, имеет решающее значение для соответствия нормативным требованиям и производительности:
-
Выбор глобального региона: по умолчанию организации могут выбрать один регион для хранения записей разговоров, чтобы упростить управление и управление
-
Переопределение регионов, основанных на местоположении: в тех случаях, когда того требуют законы о хранении данных или корпоративные правила, может возникнуть необходимость отменить глобальные региональные настройки для определенных местоположений, обеспечив хранение и обработку записей разговоров в требуемых географических границах
-
Требования к резидентности данных: при проектировании должны учитываться международные и местные правила защиты данных (например, GDPR, CCPA или национальные требования), которые могут определять, где и как хранить записи разговоров.
Еще одним важным аспектом, на который следует обратить внимание при планировании и разработке решения для записи разговоров, является оценка требований к хранению данных. Точное прогнозирование потребностей в хранении данных необходимо для обеспечения достаточной емкости для поддержки текущих бизнес-операций, соблюдения нормативных требований и предотвращения перебоев в обслуживании.
При определении ожидаемого спроса на хранилище следует учитывать несколько ключевых параметров:
-
Количество записанных звонков: оцените ожидаемое количество звонков, которые будут записаны в течение заданного интервала времени (например, за день, неделю или месяц). Сюда входят не только внешние звонки, но и внутренние коммуникации, если того требуют деловая политика или нормативные требования
-
Средняя продолжительность разговора: рассчитайте типичную продолжительность записанных звонков, так как более длительные звонки будут занимать больше места на диске. При расчете также следует учитывать различия в продолжительности звонков в разных отделах или группах пользователей
-
Срок хранения: определите срок хранения записей, который часто определяется организационными политиками или внешними нормативными актами (например, отраслевыми стандартами соответствия). Более длительные сроки хранения повысят общие требования к хранению
-
Прогнозы роста. Рассмотрите ожидаемый рост количества звонков или расширение области записи, что может произойти в результате масштабирования бизнеса, введения новых нормативных требований или привлечения дополнительных пользователей или локаций.
Тщательно проанализировав эти параметры, организации смогут разработать надежную стратегию хранения данных, обеспечивающую масштабируемость, экономичность и соответствие нормативным требованиям своего решения для записи разговоров. Также рекомендуется регулярно пересматривать и корректировать распределение ресурсов хранения по мере изменения моделей использования.
Экстренный вызов
Любая телефонная служба, предлагающая услугу PSTN, обязательна для направления экстренного вызова в соответствующий диспетчерский центр. Кроме того, маршрутизация экстренных вызовов является неотъемлемой частью решения и включает поддержку всех национальных номеров экстренных служб в странах, оказывающих поддержку. Маршрутизация экстренного вызова зависит от определенного местоположения и способа доступа к PSTN в этом месте. Номера экстренных служб заранее определены и привязаны к стране, в которой работают пользователи и устройства.
Есть два способа доставки экстренных вызовов. Существует базовая служба маршрутизации экстренных вызовов и расширенная служба маршрутизации экстренных вызовов. Базовая служба маршрутизации экстренных вызовов будет использовать выбранный администратором номер для определения местоположения и маршрута вызова экстренных служб. Для основных вызовов экстренных вызовов обычно используется опция PSTN, установленная клиентом в указанном месте. Кроме того, имеется усовершенствованная маршрутизация экстренных вызовов, разработанная для систем в США и Канаде, где действуют нормативные требования, предусматривающие использование услуг национального провайдера для доставки экстренных вызовов в соответствующий диспетчерский центр.
Всем клиентам следует использовать как минимум базовую конфигурацию экстренных вызовов. Для базового вызова экстренных служб необходимо присвоить по крайней мере один принадлежащий клиенту номер +E.164 каждому населенному пункту, указанному в. При вызове основных экстренных служб каждое местоположение будет определяться почтовым адресом, по которому в экстренных случаях будут направлены полицейские, пожарные или скорая помощь. В большинстве случаев лучше всего использовать основной телефонный номер, обозначающий физическое местонахождение экстренной помощи. Как правило, присвоение адреса номеру +E.164 согласовывается с поставщиком услуг PSTN. На рисунках ниже показано назначение основного номера, который будет использоваться в качестве номера экстренного вызова в офисе Ричардсона.
В большинстве случаев в качестве адреса отправки на место достаточно адреса здания. Но если для конкретных пользователей или устройств требуются дополнительные сведения о местоположении, администратор может использовать описанную выше процедуру и присвоить этим устройствам определенный адрес или более точное место в адресе (например, этаж или помещение). В разделе «Управление пользователями» вкладка «Вызовы» позволяет пользователю и его устройствам использовать определенный номер для получения определенного адреса отправки. На следующих рисунках показано, как можно присвоить устройству определенный номер. Администратор отвечает за то, чтобы номеру, используемому устройством, был присвоен правильный адрес отправки. Назначение адреса обычно осуществляется провайдером PSTN в этом месте.
Для развертывания телефонных сетей в США, которые должны предоставлять усовершенствованные решения для экстренных вызовов, для маршрутизации экстренных вызовов используется интегрированная в систему RedSky Horizon Mobility. При использовании RedSky для маршрутизации вызовов администратор должен зарегистрировать учетную запись через Cisco и настроить соответствующую информацию в разделе Вызовы -> Настройки услуг, чтобы включить эту функцию. Как только служба RedSky будет включена на системном уровне, администратор включит службу RedSky на каждом уровне местоположения. Включение функции расширенного вызова экстренных вызовов в определенном месте активирует услугу для всех устройств, привязанных к этому местоположению. К устройствам, поддерживающим улучшенную экстренную связь, относятся телефоны Cisco MPP, телефоны Cisco PhoneOS и Cisco.
Есть две настройки для включения расширенного вызова экстренных вызовов в определенном месте. Для проверки правильности конфигурации RedSky для сопоставлений устройств и инфраструктуры следует использовать опцию «Разрешить RedSky получать информацию о сетевом подключении и тестовые вызовы». Эта настройка также позволяет совершать тестовые вызовы на номер 933 для проверки местоположения с помощью системы IVR RedSky для считывания местоположения звонящего. Хотя в этом документе не рассматривается конфигурация RedSky для отслеживания местоположения, администратору ВСЕГДА следует проверить определение местоположения, прежде чем активировать экстренные вызовы для маршрутизации на RedSky. После завершения тестирования и подтверждения его точности администратор перенаправит вызовы в RedSky, переключив маршрут экстренных вызовов на RedSky. Этот переключатель будет перенаправлять все экстренные вызовы о местоположении в RedSky для доставки в автоответчик, который определит местоположение.
Расширенные настройки экстренных вызовов также применимы к клиентам как в офисе, так и за его пределами. В локальной среде их можно отслеживать так же, как и настольные телефоны. Находясь вне офиса, пользователь сможет динамически определять свое местоположение непосредственно в нем. Дополнительные сведения об экстренных вызовах см. в разделе Расширенные возможности экстренного вызова.
Лицензирование
Существует несколько вариантов назначения лицензий пользователям.
Ручное назначение через
Администраторы вручную назначают лицензии отдельным пользователям через интерфейс.
Администраторы могут редактировать лицензии на услуги для отдельных пользователей и напрямую назначать лицензии на звонки.
Шаблоны автоматического назначения лицензий
Используйте шаблоны назначения лицензий для автоматического назначения лицензий пользователям на основе групповых или организационных настроек.
Автоматическое лицензирование можно осуществить с помощью синхронизации каталогов или обновления вручную, но пользователи должны иметь действительный телефонный номер в формате +E.164, а телефонные номера должны существовать в определенном месте до предоставления пользователям полномочий. Если условия не будут соблюдены (например, неправильный формат телефонного номера), лицензии не будут предоставлены.
Массовое назначение с помощью шаблона CSV
Загрузите CSV-файл с информацией о пользователе и назначениями лицензий, чтобы добавить или изменить сразу несколько пользователей.
Импорт CSV позволяет добавлять до 20 000 пользователей и назначать лицензии, но для лицензий требуются специальные поля, такие как номер телефона и добавочный номер.
Назначение на основе API
Используйте API для программного назначения лицензий и управления пользователями.
поддерживает операции API для управления пользователями и лицензиями (API People, SCIM 2.0 и Licenses), которые можно использовать для автоматизации выдачи лицензий. API лицензий позволяет одновременно назначать лицензии, телефонные номера и расширения.
| Метод назначения | Плюсы | Минусы |
|---|---|---|
| Вручную через | Просто для нескольких пользователей. Позволяет точно и детально контролировать выдачу лицензий. | Не масштабируется, отнимает много времени При ручном вводе подвержен человеческим ошибкам. |
| Шаблоны автоматических лицензий | масштабируемые Уменьшает количество ручных ошибок Может применяться как к новым, так и к существующим пользователям. | Требуются действительные телефонные номера и адреса. Более сложный в настройке Кроме того, требуется, чтобы на каждую группу пользователей приходились группы пользователей с эквивалентными лицензионными требованиями. |
| Массовая загрузка CSV-файлов | Эффективна для больших групп пользователей Позволяет одновременно назначать лицензии, телефонные номера и расширения. | Требует тщательного форматирования CSV Возможны ошибки, если телефонные номера или добавочные номера отсутствуют или неверны. |
| Назначение на основе API | Автоматизируется, гибко. Позволяет одновременно назначать лицензии, телефонные номера и расширения. | Требуются знания в области разработки и API. |
В таблице «Варианты предоставления пользователям» — сводка приведена сводная информация о вариантах подготовки пользователей, а также об их плюсах и минусах. Этот обзор помогает выбрать оптимальный метод назначения лицензий с учетом размера организации заказчика, возможностей автоматизации, процессов и требований к подготовке пользователей.
По возможности Cisco рекомендует назначать лицензии на звонки с использованием шаблонов лицензий. Для этого каждой группе пользователей требуется уникальный набор лицензий (например, Standard vs. (Professional) существует группа, состоящая из членов соответствующей группы. Как описано в разделах «Группы пользователей», группы пользователей можно создавать вручную или синхронизировать из корпоративного каталога. Возможна комбинация обоих подходов.
Пользователи, принадлежащие к нескольким группам, получают лицензии на выполнение всех заданий, применяемых ко всем группам. Это позволяет использовать специальные группы безопасности в каталоге предприятий для управления назначением лицензий, при этом конечное назначение лицензий пользователям контролируется объединением членов групп.
Дополнительные сведения см. в разделах Настройка автоматического назначения лицензий в Control Hub и Настройка шаблонов автоматического назначения лицензий для Webex Calling пользователей.
Лицензионные требования
В этом разделе рассматриваются только соответствующие лицензии. Другие типы лицензий (например, регистрация устройств Webex, обмен сообщениями, совещания) не рассматриваются. В процессе проектирования необходимо определить лицензионные требования. Необходимо рассчитать количество лицензий для следующих типов лицензий:
-
Стандарт: количество отдельных пользователей, которым требуются стандартные функции телефонии.
-
Профессионал: количество пользователей и рабочих мест, требующих расширенных функций телефонии. Виртуальные линии и групповая голосовая почта имеют право на получение каждой профессиональной лицензии в соотношении 1:1. Поэтому в редких случаях, когда количество необходимых виртуальных линий или групповых голосовых сообщений превышает количество пользователей и рабочих мест, требующих расширенных функций телефонии, необходимо учитывать дополнительные профессиональные лицензии.
-
Рабочее пространство для общего пользования: количество мест общего пользования или мест общего пользования, где требуется стандартная телефонная связь.
-
Служба поддержки клиентов: количество агентов и супервайзеров, которым требуются функции поддержки клиентов. Служба поддержки клиентов включает профессиональную лицензию.
-
Вызовы из списка маршрутов: количество необходимых вызовов PSTN, подключенных к облаку, между локальными пользователями и/или локальными специализированными сторонними приложениями.
-
Консоль сопровождающего: количество пользователей, которым требуется доступ к клиенту консоли сопровождающего.
-
План звонков Cisco (план исходящих вызовов): количество пользователей, которым требуется номер PSTN и/или доступ к исходящим вызовам PSTN для службы Cisco PSTN.
Для профессиональных рабочих пространств не существует специального типа лицензии. Для профессиональных рабочих пространств требуется лицензия Professional.
Рабочие места, работающие только на горячих столах, предоставляют услуги хоста и экстренные вызовы от хоста, работающего на горячих столах, и для их использования не требуется лицензия. Дополнительные сведения см. в разделе Добавление устройств, работающих только в режиме «горячий стол», и управление ими.
Чтобы определить необходимый тип лицензии для каждого пользователя и рабочего пространства на основе необходимых функций, см. раздел Функции, доступные по типам лицензий для Webex Calling.
Чтобы отличить функциональность очередей вызовов в сочетании с профессиональной лицензией от функций поддержки клиентов, см. в разделе Сравнение функций очереди Webex Calling вызовов и поддержки клиентов.
Подготовка пользователей
При подготовке пользователей в Webex доступно несколько вариантов, каждый из которых соответствует различным организационным потребностям и средам:
-
Ручное выделение ресурсов: администраторы могут добавлять отдельных пользователей и управлять ими непосредственно в системе. Этот метод прост, но лучше всего подходит для небольших организаций или ограниченного числа пользователей .
-
Массовое выделение ресурсов с помощью CSV-файлов. Для больших баз пользователей администраторы могут массово импортировать и обновлять пользователей, загружая туда файлы CSV. Это позволяет эффективно управлять тысячами пользователей одновременно.
-
Варианты синхронизации каталогов:
Directory Connector: это инструмент автоматической синхронизации, используемый в Microsoft Active Directory средах. Он синхронизирует учетные записи пользователей, группы и атрибуты по расписанию (ежечасно, ежедневно или еженедельно). Он поддерживает многодоменные настройки и Active Directory настройки с несколькими лесами и может синхронизировать изображения профиля и объекты комнат.
Приложение-мастер Entra ID (Azure AD): этот метод, разработанный для организаций, использующих Microsoft Entra ID (Azure AD), обеспечивает автоматическую синхронизацию учетных записей и атрибутов пользователей практически в реальном времени непосредственно с Entra ID в. Он полностью управляется и требует минимальной настройки.
Приложения SCIM 2.0. Для сред, отличных от Microsoft, или других поставщиков идентификационных данных, таких как Okta или Duo, приложения для синхронизации на основе SCIM позволяют автоматически выделять и удалять пользователей с помощью сопоставления атрибутов и синхронизации групп.
-
Unified CMсинхронизация пользователей: эта опция позволяет создавать учетные записи пользователей на основе существующих конечных пользователей путем синхронизации от до. Для этого необходимо, чтобы подключенные к облаку UC (CCUC) работали в локальных кластерах. Однако обычно рекомендуется синхронизировать пользователей из централизованного облачного каталога, такого как Entra ID, а не напрямую из него.
-
Предоставление API: для подготовки пользователей можно использовать общедоступные API (People, SCIM 2.0). Основным преимуществом использования API является возможность интеграции пользовательского обеспечения с другими корпоративными системами.
В этом обзоре и таблице представлены основные варианты подготовки пользователей, их преимущества и ограничения, которые помогут вам выбрать наилучший подход, отвечающий потребностям вашей организации.Таблица 6. Варианты подготовки пользователей для Метод выделения ресурсов Описание Плюсы Минусы Ручная Создавайте пользователей и управляйте ими по отдельности в Просто для нескольких пользователей; инфраструктура не требуется Не масштабируется; для многих пользователей требуется много времени Массовая обработка (CSV-файл) Массовый импорт/обновление пользователей через CSV-файл в Эффективно для групп; программирование не требуется Ручная подготовка CSV; менее динамичная Люди и API SCIM 2.0 Программное управление пользователями с помощью API Webex Гибкое; поддерживает автоматизацию и интеграцию Требуется разработка и инфраструктура Синхронизация каталогов Автоматическая синхронизация с приложениями AD, Entra ID, SCIM, Unified CM Автоматизирует жизненный цикл; поддерживает фильтрацию и картографирование Сложность настройки: некоторые из опций имеют ограниченные возможности или требуют инфраструктуры
Группы пользователей
Управление группами пользователей позволяет администраторам объединять пользователей в группы для эффективного массового управления лицензиями, настройками и ресурсами. Группы помогают упростить администрирование, применяя политики, лицензии и шаблоны настроек одновременно к нескольким пользователям, а не управляя пользователями по отдельности.
Управление группами пользователей дает ряд преимуществ, в том числе:
-
Упрощенное администрирование: управление лицензиями, настройками и политиками для нескольких пользователей одновременно.
-
Согласованность: применяйте одинаковые настройки и лицензии для всех пользователей в одной группе.
-
Масштабируемость: поддерживает до 250 000 участников в каждой группе.
-
Интеграция: синхронизация групп из Microsoft Entra ID (Azure AD) или Active Directory для автоматического управления пользователями и группами.
-
Гибкость: создание локальных групп или синхронизация групп безопасности; управление членством в группах вручную или с помощью файлов CSV.
-
Распределение ресурсов: управление доступом к встроенным приложениям и сервисам на основе членства в группах.
Основные варианты использования групп пользователей при выделении ресурсов:
-
Назначение лицензий: назначайте лицензии группам для автоматического предоставления членам группы таких услуг, как звонки, встречи, обмен сообщениями или гибридные услуги.
-
Шаблоны настроек: применяйте наборы сервисных настроек (например, обмен сообщениями, встречи, звонки) к группам для обеспечения единообразия пользовательского интерфейса.
-
Массовое управление пользователями: массовое добавление или удаление пользователей с помощью файлов CSV или синхронизации каталогов.
-
Автоматизация и интеграция: используйте API или синхронизацию каталогов для автоматического управления жизненным циклом пользователей и групп.
В следующей таблице перечислены различные варианты управления группами пользователей и управления группами в.
| Опция | Описание | Плюсы | Минусы |
|---|---|---|---|
| групповое обеспечение (группы) | Создавайте группы и управляйте ими непосредственно в. Добавляйте/удаляйте участников вручную или через CSV. | Полный контроль над членством в группе Немедленное применение лицензий и шаблонов Легко создавать и редактировать группы |
Требуется ручное обновление Риск ошибок при ручной загрузке CSV Нет автоматической синхронизации с внешними каталогами |
| Синхронизированные группы из Entra ID (Azure AD) или Active Directory | Автоматическая синхронизация групп безопасности и членства во внешних службах каталогов . | Автоматическая синхронизация сокращает объем ручной работы Обеспечивает согласованность с корпоративным каталогом Поддерживает крупные организации |
Невозможно изменить членство в группе в Задержка синхронизации до 12 часов Вложенные группы необходимо выбирать вручную |
| Группы и API SCIM 2.0 (группы) | Используйте группы или SCIM 2.0 API для программного управления группами и членством | Автоматизация и интеграция с другими системами Масштабируемость для больших или сложных сред |
Требует усилий по разработке Сложность зависит от использования API |
В то время как синхронизированные группы обеспечивают согласованность и предоставляют единую точку администрирования, возможен гибридный подход, сочетающий синхронизированные группы и группы (управляемые в центре управления или с помощью API). Так, например, группы для назначения лицензий могут быть синхронизированными группами, а отдельный набор групп можно использовать для назначения шаблонов пользователям и вызовам.
Такой комплексный подход к управлению группами пользователей позволяет организациям эффективно управлять пользовательскими лицензиями, настройками и политиками, обеспечивая согласованную и масштабируемую совместную работу.
Рекомендуемый подход при переходе с на
Основным источником данных для пользователей является база данных, содержащая информацию о конечных пользователях. Однако она, как правило, не является авторитетным источником для управления идентификационными данными пользователей и, что более важно, в конце переходного периода она будет закрыта и поэтому не будет использоваться в качестве надежного источника идентификационной информации в долгосрочной перспективе.
Cisco рекомендует использовать централизованный облачный каталог, такой как Microsoft Entra ID (Azure AD), в качестве единственного источника достоверной информации об идентификаторах пользователей. Синхронизация пользователей из Entra ID обеспечивает согласованность, упрощает управление и поддерживает возможности единого входа (SSO).
Чтобы убедиться, что все пользователи также присутствуют в Entra ID, организациям следует убедиться, что учетные записи пользователей соответствуют учетным записям в Entra ID. Это можно сделать, экспортировав списки пользователей из Entra ID и сравнив их со списками пользователей Entra ID.
Таким образом, рекомендуемый метод подготовки — синхронизация пользователей из Microsoft Entra ID (Azure AD) в Webex с помощью мастера Azure AD или приложений SCIM. Массовое выделение ресурсов вручную и в формате CSV доступно в качестве дополнительных методов, но для крупных организаций оно менее масштабируемо и более подвержено ошибкам. Обеспечение того, что Entra ID является достоверным источником и что в Entra ID присутствуют все пользователи, крайне важно для успешной миграции и обеспечения единообразия пользовательского опыта в разных средах.
Переход от локальной службы каталогов, например, к облачной службе каталоговActive Directory, такой как Entra ID (Azure ID), не зависит от передачи вызовов. Cisco рекомендует завершить переход на облачную службу каталогов, прежде чем начинать переход на вызовы.
Проектирование групп пользователей
После переноса корпоративного каталога из локального хранилища в облако соберите необходимые группы пользователей в соответствии с требованиями лицензий и шаблонов функций. Для каждого группового документа:
-
Имя группы: уникальное имя группы.
-
Лицензии: лицензии, которые должны быть отнесены к этой группе (если таковые имеются), и область действия (должны ли лицензии предоставляться существующим пользователям или только новым пользователям)
-
Шаблоны настроек: приложение Webex и шаблоны вызовов пользователей.
-
Синхронизация каталогов: будет ли эта группа синхронизироваться с корпоративным каталогом или это локальная группа Webex, созданная в Control Hub или через API.
-
Описание: как будет использоваться эта группа и какие пользователи должны входить в эту группу
Эти сведения будут использованы позже на этапе внедрения для создания локальных групп или групп в каталоге предприятий и управления членством пользователей в группах.
Система единого входа (SSO)
Cisco рекомендует использовать SSO для аутентификации пользователей. Использование SSO имеет ряд убедительных преимуществ, в том числе:
-
Упрощенная аутентификация пользователей: пользователи могут войти в систему один раз, используя свои корпоративные учетные данные (например, из Azure ID) для доступа к другим интегрированным приложениям и другим интегрированным приложениям, что устраняет необходимость в использовании нескольких паролей и сокращает количество запросов при входе в систему. Это повышает безопасность, гарантируя, что корпоративные пароли после аутентификации никогда не сохраняются и не передаются.
-
Упрощенное управление пользователями: автоматизирует создание, обновление и деактивацию учетных записей пользователей в зависимости от изменений в корпоративном каталоге, сокращая административные издержки и обеспечивая доступ только авторизованным пользователям.
-
Повышенная безопасность: система единого входа снижает усталость от паролей и риск взлома паролей за счет централизации аутентификации с помощью доверенных поставщиков идентификационных данных (IDP).
-
Простая интеграция многофакторной аутентификации (MFA): MFA можно легко поддерживать с помощью решения для управления доступом к идентификационным данным, такого как Cisco Duo, или с помощью поддержки IdP в многофакторной аутентификации.
Существует несколько вариантов внедрения единого входа в сервисы:
-
SSO на базе SAML 2.0: основной протокол, поддерживаемый для интеграции SSO и обеспечивающий безопасный обмен аутентификационной информацией между IdP и поставщиком услуг.
-
OpenID connect (OIDC): поддерживается в качестве альтернативного современного протокола аутентификации для интеграции SSO.
-
Webex identity: также поддерживается в качестве опции поставщика идентификационных данных.
SSO настраивается и управляется централизованно, поэтому требуется обмен метаданными между выбранным IdP и выбранным IdP.
После настройки SSO можно протестировать перед активацией, чтобы убедиться в правильной настройке.
Cisco поддерживает интеграцию с несколькими протестированными и часто используемыми IDP и системами управления идентификацией (IAM), включая, помимо прочего, следующее:
-
Cisco Duo
-
Окта
-
Microsoft Active DirectoryСлужбы федерации (ADFS)
-
Microsoft Azure
-
Ping Federate
-
Открыть AM
-
F5 BIG-IP.
Эти ВПЛ соответствуют стандартам SAML 2.0 или OpenID Connect и прошли проверку на совместимость с решениями Cisco для совместной работы.
Поддержка нескольких IdP
позволяет организациям настраивать систему единого входа с несколькими ВПЛ в сложных ИТ-средах, таких как слияния, поглощения или децентрализация ИТ-отделов, где разные группы используют разных ВПЛ. Поддержка нескольких IdP может быть реализована либо с помощью функции Multiple IdP, либо путем интеграции корпоративной системы IAM, такой как Cisco Duo.
поддержка нескольких поставщиков удостоверений (IdP) предназначена для нескольких ключевых случаев использования, когда организациям требуется гибкая и безопасная аутентификация в различных ИТ-средах:
1. Слияния и поглощения
Когда компании объединяются или приобретают другие, у них часто возникают отдельные ИТ-инфраструктуры и отдельные ВПЛ, которые не могут объединиться в федерацию. Поддержка нескольких IdP позволяет пользователям обеих организаций безопасно аутентифицироваться и сотрудничать без необходимости немедленно унифицировать свои системы идентификации.
2. Несколько независимых ИТ-отделов
Крупные организации или государственные учреждения могут иметь несколько независимых ИТ-отделов, каждый из которых управляет своим собственным ВПЛ. функция множественных IdP позволяет этим отделам поддерживать собственные системы аутентификации, обеспечивая при этом беспрепятственный доступ пользователей.
3. Различные группы пользователей или домены
Организации с разными группами пользователей (например, сотрудники или подрядчики) или несколькими доменами электронной почты могут настроить правила маршрутизации таким образом, чтобы запросы на аутентификацию направлялись соответствующему IdP в зависимости от принадлежности к домену или группе. Это обеспечивает дифференцированные политики доступа и средства управления безопасностью.
4. Поддержка различных протоколов аутентификации
поддерживает ВПЛ SAML и OpenID Connect (OIDC), что позволяет организациям интегрировать различные типы поставщиков идентификационных данных в соответствии с существующей инфраструктурой и требованиями безопасности.
5. Повышенная безопасность и соответствие нормативным требованиям
Предоставляя возможность нескольким ВПЛ, организации могут внедрить более надежные механизмы аутентификации, включая многофакторную аутентификацию (MFA), с помощью таких интеграций, как Duo, и применять согласованные политики безопасности для различных баз пользователей.
6. Упрощенный пользовательский интерфейс
Пользователи могут аутентифицироваться, используя свои учетные данные соответствующих ВПЛ, что обеспечивает унифицированный вход в систему, несмотря на сложность нескольких систем идентификации.
Хотя поддержка нескольких IdP обеспечивает гибкость, для поддержания последовательных политик безопасности и предотвращения потенциальных уязвимостей требуется тщательная координация действий групп безопасности и идентификации.
Двойная многофакторная аутентификация с системой SSO для
Duo Access Gateway (DAG) может аутентифицировать пользователей с помощью существующих локальных или облачных каталогов, таких как Active Directory (AD) и OpenLDAP. Он также поддерживает интеграцию с другими поставщиками удостоверений, такими как Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS и Shibboleth. Такая гибкость позволяет организациям использовать текущую инфраструктуру каталогов для Webex SSO с помощью Duo MFA .
Duo выступает в качестве надежного уровня аутентификации в дополнение к аутентификации основного каталога. Он выступает в роли поставщика идентификационных данных (IdP), используя SAML 2.0 для обеспечения двухфакторной аутентификации (2FA) перед предоставлением доступа. Duo оценивает контекст пользователя, устройства и сети в соответствии с настраиваемыми политиками, разрешающими или запрещающими доступ, что повышает безопасность не только имени пользователя и пароля. Duo также предоставляет гибкие средства управления политиками, например требование многофакторной аутентификации при каждом входе в систему для одних приложений и реже для других.
К преимуществам Cisco Duo относятся:
-
Повышенная безопасность: добавлена устойчивая к фишингу многофакторная аутентификация для защиты доступа и снижения риска взлома паролей.
-
Гибкие политики: позволяет детально контролировать требования к аутентификации для каждого приложения или группы пользователей.
-
Интеграция с существующими каталогами: поддерживает локальные AD, OpenLDAP, облачные каталоги и различных поставщиков SSO, сводя к минимуму изменения в инфраструктуре.
-
Удобство пользователя: поддержка технологии единого входа (SSO) позволяет снизить усталость от паролей, позволяя пользователям входить в систему один раз и безопасно получать доступ к нескольким ресурсам.
-
Надежные конечные точки: поддержка доверия к устройствам для клиентов в Windows и macOS, повышая уровень безопасности.
-
Самостоятельная регистрация: онлайн-регистрация и двусторонняя подсказка улучшают пользовательский интерфейс при настройке MFA.
Duo MFA и SSO позволяют использовать существующие каталоги, такие как OpenLDAP или Active Directory облачные поставщики идентификационных данных, для аутентификации пользователей. Роль Duo заключается в обеспечении надежного второго фактора аутентификации, основанного на политиках, интегрированного в SAML 2.0, повышающего безопасность и одновременно обеспечивающего удобство пользователей с помощью единого входа. К преимуществам относятся повышение уровня безопасности, гибкое применение политик, беспрепятственная интеграция и улучшение пользовательского опыта.
Cisco рекомендует внедрить SSO для пользователей. Для повышения безопасности рекомендуется интеграция с Cisco Duo.
Перед началом перехода на корпоративную стратегию IAM и SSO следует внедрить.
Функции
имеет полный набор основных функций, включенных в сервис. Сюда входит множество функций звонков корпоративного уровня, которые доступны уже много лет. Возможно, вы не увидите стопроцентного соотношения между функциями и функциями, однако, как показано на рисунке ниже, основные функции звонков доступны в.
Помимо множества пользовательских функций, имеет основные системные функции, включенные в платформу. К ним относятся такие функции, как автосекретари, очереди вызовов, парковка вызовов и т. д. Все доступные основные функции системы можно увидеть в разделе Сервис → Вызовы → Функции, как показано на Webex Calling рисунке Основные функции.
Автосекретарь
Автосекретарь позволяет круглосуточно автоматизировать обработку входящих вызовов, что позволяет эффективно обрабатывать звонки без необходимости отвечать на каждый звонок.
Автосекретарь отвечает на входящие звонки и предоставляет звонящему меню с опциями, указывающими, куда он хочет направить свой вызов. Это может быть адресовано человеку, ящику голосовой почты или службе телефонной связи (например, Очередь звонков). Звонящий использует клавиатуру телефона для ввода номера из меню автосекретаря.
Автосекретарь поддерживает следующие ключевые функции:
-
Рабочее расписание и расписание в нерабочее время
-
График праздничных дней
-
Опция меню набора номера, позволяющая клиентам направлять их туда, куда им нужно
-
Настройте приветствия
-
Опция набора по имени
-
Опции переадресации звонков
-
Аналитика и отчеты Control Hub.
Дополнительные сведения см. в разделе Управление автосекретарями.
Парк вызовов
Парковка вызовов позволяет пользователям легко отложить звонок, чтобы другой пользователь мог с легкостью ответить на звонок в тот момент, когда он сможет его принять. Это также позволяет пользователю, ответившему на исходный звонок, звонить или принимать другие звонки, пока звонок припаркован.
Доступны два типа парков вызовов:
-
Call Park direct — позволяет любому пользователю припарковать звонок на добавочный номер другого пользователя или на номер телефонного парка в соответствии с определением Администратора
-
Группа парковки вызовов — позволяет определенной группе пользователей автоматически парковать звонки в доступных местах парковки, определенных для группы. Этими пунктами назначения могут быть добавочные номера членов группы или номера телефонных парковок.
В зависимости от конфигурации и типа парковки пользователи могут принимать звонки, набирая *88+>, <extension of parked call>нажимая линейную клавишу, связанную с добавочным номером парка вызовов, или используя функциональную клавишу на своем IP-телефоне.
Доступна опция отзыва, позволяющая отозвать припаркованный звонок по истечении указанного периода времени пользователю, который припарковал звонок, или другому пользователю.
Дополнительные сведения см. в разделе Управление парком вызовов в Control Hub.
Перехват вызова
Функция приема вызовов позволяет администратору определить группу пользователей (участников), которые могут ответить на звонок на телефон другого участника. Это дает пользователю возможность отвечать на звонки, когда его товарищи по команде заняты и не могут ответить на входящий звонок.
Пользователи в группе должны находиться в одном и том же месте.
Для ответа на звонок пользователи могут использовать стационарный телефон или телефон.
-
:
-
Поддерживает визуальные и звуковые уведомления
-
Уведомление о входящих звонках
-
По факсу (наберите*98) или с уведомлением о приеме вызова
-
Уведомления о приеме вызовов для нескольких линий.
-
-
Настольные телефоны:
-
Уведомление о входящих звонках
-
Звуковые колокольчики и визуальные уведомления через светодиод телефона. 6821 поддерживает только звуковые сигналы
-
Если тип уведомления, выбранный в поле, не равен нулю
-
-
Уведомления о приеме вызовов только для основных линий.
-
Дополнительные сведения см. в разделе Настройка группы приема вызовов.
Очередь звонков
включает в себя очереди вызовов только голосовой связи как часть своих основных функций. Любой пользователь с лицензией Professional может быть частью очереди вызовов, агентом или супервизором. Эта функция позволяет пользователям эффективно взаимодействовать с клиентами. Очереди вызовов поддерживают ряд некоторых основных функций колл-центра, таких как голосовые очереди, обратный вызов, маршрутизация навыков или приоритетов, управление очередью агентов, аналитика, отчетность и т. д.
Интеграция Cisco Call for Microsoft Teams позволяет агентам получать доступ к вызовам и функциям очереди вызовов непосредственно из клиента Microsoft Teams.
Очереди вызовов поддерживают следующие ключевые функции:
-
Приветствия и сообщения (приветствие, утешение, шепот и т. д.)
-
Удерживайте музыку
-
Перезвоните
-
Правила маршрутизации очередей (обслуживание в ночное время, праздничные дни, пересылка)
-
Вход/выход из очереди агентов
-
Управление статусом очереди агентов
-
или поддержка по настольному телефону
-
Агент-супервайзер звонит монитору, тренеру, барже или перевозчику с помощью кодов доступа к объектам (FAC)
-
(доступ администратора) для:
-
управление очередями
-
Аналитика и отчетность по агентам и очередям
-
Управление очередями, агентами и супервизорами.
-
Дополнительные сведения см. в разделе Настройка очереди вызовов.
имеет дополнительную функцию Customer Assist, которая предоставляет дополнительные возможности очереди вызовов и повышает удобство работы агентов и супервизоров. Сравнение функций «Очередь вызовов» и «Помощь клиентам» см. в разделе Сравнение функций очереди Webex Calling вызовов и поддержки клиентов.
Охотничья группа
Hunt Groups позволяет маршрутизировать входящие звонки определенной группе пользователей по заранее заданной схеме маршрутизации вызовов. Это гарантирует, что нужная группа пользователей отвечает на вызовы или отправляет их на голосовую почту для ответа.
Одно из главных отличий между охотничьими группами и очередями вызовов заключается в том, что вызовы не ставятся в очередь в Охотничьи группы, поэтому, если в охотничьей группе нет пользователей, готовых ответить на звонок, звонок будет отключен, отправлен на голосовую почту или переадресован на другой номер (пользователя или услугу).
Дополнительные сведения см. в разделе Управление охотничьими группами в Control Hub.
Режимы работы
Функция «Режимы работы» позволяет компаниям эффективно направлять звонки различным адресатам (пользователям, голосовой почте, службам вызова, например очереди вызовов). Информация о том, куда и когда будет перенаправлен звонок, зависит от времени суток и дня недели, и любому пользователю может быть разрешено управлять этими режимами ( расписаниями) для управления изменениями в маршрутизации вызовов.
Например, звонки в очередь вызовов можно перенаправить в другую очередь вызовов, а агенты, работающие в другом часовом поясе, будут отвечать на звонки в нерабочее время, в рабочее время перенаправлять на местных агентов, а в праздничные дни — на голосовую почту для ответа после возвращения агентов в офис.
Авторизованный пользователь может переключаться между этими различными сценариями (режимами) переадресации вызовов, если ему необходимо изменить направление маршрутизации входящих вызовов на определенный период. Эти пользователи могут управлять режимами на своих телефонах 6800/7800/8800 MPP, 9800 или в Центре пользователей в разделе «Управление режимами».
Пейджинговая группа
Группы пейджинга позволяют пользователям совершать односторонний вызов для отправки аудиосообщения группе пользователей. Каждая группа может содержать до 75 целевых пользователей и/или рабочих пространств, с которыми можно связаться, набрав заранее определенный номер или добавочный номер.
Когда пользователь звонит в пейджинговую группу, одновременно звонит всем назначенным адресатам в группе, после чего звонящий может произнести свои сообщения и положить трубку, когда они закончат.
Дополнительные сведения см. в разделе Настройка пейджинговой группы в Control Hub.
Записи
поддерживает запись звонков, сделанных или полученных пользователем. Это может потребоваться для обеспечения качества, обеспечения безопасности или обучения. По умолчанию звонки записываются, но можно также использовать услуги других сторонних поставщиков звукозаписи, если требуются другие функции записи или требования соответствия нормативным требованиям.
При использовании в качестве платформы для записи все записанные звонки управляются внутри. Воспроизводить и скачивать записи могут полноправные администраторы, выполняющие роль уполномоченного по соблюдению нормативных требований. Без роли сотрудника по соблюдению нормативных требований администратор может удалять только записи.
Дополнительные сведения об этой функции и список записей сторонних производителей см. в разделе Управление записью разговоров для Webex Calling.
Охват одним номером
Охват одного номера позволяет звонить на телефонный номер пользователя на несколько устройств. Сюда могут входить другие настольные телефоны, а также мобильные телефоны. С этих устройств также можно звонить, а пользователи могут отправлять и принимать вызовы между ними.
Дополнительные сведения об этой функции и о том, как администратор настраивает ее, см. в разделе Настройка связи по единому номеру (офис в любом месте).
Дополнительные сведения о том, как пользователь может управлять этой функцией и настраивать ее для себя на Webex User Hub (портале), см. в разделе Настройка охвата одним номером (офис в любом месте).
Группа голосовой почты
Группы голосовой почты позволяют создать общий ящик голосовой почты, который можно присвоить пользователю или функции маршрутизации вызовов. Вот некоторые из причин, по которым может потребоваться группа голосовой почты:
-
Голосовая почта общего назначения для отдела или рабочей группы
-
Добавьте опцию голосовой почты автосекретарю или охотничьей группе
-
Для отправки переполненных вызовов из очереди вызовов
-
Пользователи, которым нужен только ящик голосовой почты.
Дополнительные сведения см. в разделе Управление общей голосовой почтой и входящим факсом для. Webex Calling
Консоль сопровождающего указана на странице Функции звонков в Webex, однако это дополнительная функция, для использования которой требуется приобрести лицензию на консоль оператора.
Дополнительные сведения см. в разделе Начало работы с консолью Attendant.
Сведения обо всех функциях, включая некоторые дополнительные, см. в разделе Функции, доступные по типам лицензий на Webex Calling.
Внедрить
Готовность сети
Первым шагом при переходе на Интернет является обеспечение надежного и безопасного подключения к Интернету между локальной сетью и облаком.
Поскольку большинство организаций подключаются к Интернету через один или несколько брандмауэров или устройств безопасности, важно убедиться, что требуемые потоки трафика поддерживаются.
Администраторы сети и системы безопасности должны понимать эти потоки с точки зрения:
-
Направление (входящие и исходящие)
-
Протоколы (например, SIP, TLS, SRTP, HTTPS)
-
Диапазоны IP-адресов, используемые сервисами
-
Номера портов, которые необходимо открыть или разрешить.
Это обеспечивает правильную настройку корпоративных брандмауэров, устройств NAT и другой сетевой инфраструктуры для приема трафика при соблюдении корпоративных политик безопасности.
Сведения о необходимых потоках, включая IP-адрес, порты и протоколы, см. в разделе Справочная информация по Webex Calling портам. Используйте эту информацию для настройки брандмауэра, прокси-серверов и другой сетевой инфраструктуры в существующем развертывании для обеспечения сетевых потоков.
Для таких облачных сервисов для совместной работы, как децентрализованное подключение к Интернету из каждого филиала или сайта, рекомендуется использовать такие облачные сервисы для совместной работы, как. Разрешая локальный выход трафика, эта модель:
-
Уменьшает задержку и дрожание в обе стороны, улучшая общее качество звонков
-
Эффективно масштабируется по мере того, как все больше пользователей и сайтов переходят на
-
Отлично работает с SD-WAN, которая позволяет динамически направлять сеансы в ближайшую точку входа в облако для обеспечения оптимальной производительности
- Позволяет отслеживать местоположение пользователей на основе их публичного IP-адреса, что помогает анализировать медиаканалы и устранять неполадки.
Кроме того, организации должны обеспечить достаточную пропускную способность Интернета на каждом сайте. Пропускную способность следует определять исходя из ожидаемого количества одновременных вызовов, выбранного кодека (например, Opus или G.711), а также затрат на передачу сигналов, ретрансляцию и рост трафика. Это соответствует этапу подготовки жизненного цикла PPDIO и создает прочную основу для миграции.
Первоначальная настройка
Подраздел «Первоначальная настройка» на этапе внедрения является основой для создания хорошо структурированной и управляемой облачной среды вызовов. На этом этапе решаются такие важные задачи, как создание организации, приобретение и распределение лицензий, проверка и регистрация доменов вашей компании для обеспечения надлежащего управления пользователями и их безопасности. Кроме того, он включает подготовку шаблонов лицензий для автоматизации присвоения лицензий пользователям, настройку системы единого входа (SSO) для упрощения аутентификации пользователей и повышения безопасности, а также корректировку настроек сервисов и клиентов в соответствии с политиками организации и потребностями пользователей. Выполнение этих первоначальных действий по настройке позволяет обеспечить надлежащую конфигурацию среды для обеспечения масштабируемости, безопасности и удобного пользовательского интерфейса, а также подготовить почву для последующих этапов развертывания и эксплуатации.
Верификация домена
Чтобы можно было идентифицировать пользователей, зарегистрированных на доменах электронной почты вашей компании, необходимо подтвердить ваши домены. Без проверки домена пользователи будут переведены в организацию потребителей, что усложнит управление пользователями в вашей компании. Проверка домена — обязательный шаг, позволяющий вашей организации привлекать таких пользователей и эффективно управлять ими.
Убедитесь, что все домены, связанные с адресами электронной почты ваших пользователей, проверены. Проверка домена не является эксклюзивной задачей; один и тот же домен можно проверить в нескольких организациях.
Дополнительные сведения об управлении доменами см. в разделе Управление доменами.
Запрашивайте (конвертируйте) существующих пользователей
После успешной проверки доменов вы можете приступить к регистрации пользователей, которые зарегистрировались для использования доменов электронной почты вашей компании, в вашей организации. Этот процесс объединяет всех пользователей в единую организационную структуру, обеспечивая централизованное управление и упрощенное администрирование. Заявив об этих пользователях, вы гарантируете, что ваша компания полностью контролирует учетные записи пользователей, что позволит вам эффективно назначать соответствующие лицензии, настраивать службы и оказывать необходимую поддержку. Такой унифицированный подход к управлению повышает безопасность, упрощает подготовку пользователей и обеспечивает постоянный доступ к услугам в вашей организации. Утверждение пользователей также предотвращает управление ими во внешних организациях или организациях потребителей, тем самым обеспечивая организационную целостность и контроль над ресурсами для совместной работы.
Дополнительные сведения о привлечении пользователей см. в разделе Заявка пользователей на участие в организации (преобразование) пользователей.
Настройте и протестируйте синхронизацию каталогов
Чтобы обеспечить удобное управление пользователями и группами, вы можете синхронизировать пользователей и группы из своего корпоративного каталога с помощью Microsoft Entra ID (ранее Azure AD) или Microsoft Active Directory (AD) в. Этот процесс обеспечивает постоянное сохранение идентификационных данных пользователей и членства в группах в вашей среде.
Для организаций, внедряющих поэтапное развертывание, крайне важно контролировать и ограничивать объем синхронизации во время первоначального развертывания. Это сводит к минимуму риск непреднамеренных изменений и позволяет проводить целенаправленное тестирование перед более широким внедрением.
Самый эффективный метод фильтрации синхронизируемых пользователей — использование членства в группах каталогов:
| 1 |
Создайте специальную группу синхронизации: в корпоративном каталоге (Microsoft Entra ID или AD) создайте группу безопасности, специально предназначенную для синхронизации (например, группу синхронизации). |
| 2 |
Заполните группу целевыми пользователями: добавьте в эту группу только тех пользователей, которых хотите синхронизировать (например, тестовую группу на пилотном этапе). Это позволяет жестко контролировать, кто участвует в процессе синхронизации. |
| 3 |
Настройте соглашение о синхронизации с помощью групповой фильтрации: при настройке соглашения о синхронизации в Directory Connector или Entra ID настройте область, включив в нее только пользователей, входящих в указанную группу.
|
| 4 |
При необходимости расширяйте группу. По мере перехода к более широким этапам развертывания просто добавляйте дополнительных пользователей или группы в группу синхронизации. Область синхронизации автоматически расширится и будет включать этих пользователей, что позволит осуществлять ее контролируемое и постепенное развертывание. Примеры этапов внедрения:
Ссылки: Синхронизируйте пользователей Entra ID с Control Hub |
Настройте и протестируйте систему единого входа (SSO)
Система единого входа (SSO) повышает безопасность и упрощает доступ пользователей, позволяя пользователям пройти однократную аутентификацию, используя свои корпоративные учетные данные, и получить беспрепятственный доступ к ним. поддерживает интеграцию SSO с ВПЛ, совместимыми с SAML 2.0, включая Microsoft Entra ID (ранее Azure AD), Active Directory федеративные решения (AD) и различных сторонних ВПЛ.
На этом этапе разработанная настройка SSO должна быть реализована и протестирована.
Ссылки:
Интеграция системы единого входа в центр управления
настройте систему единого входа для администрирования webex
Настройте систему единого входа с помощью Microsoft Entra ID
SSO с несколькими внутренне перемещенными лицами
Управляйте системой единого входа при интеграции в Control Hub
Приобретайте, предоставляйте и проверяйте лицензии
При первоначальной настройке важно приобрести, предоставить и проверить соответствующие лицензии для эффективного предоставления услуг и управления ими. Процесс закупки включает выбор типов лицензий в зависимости от ролей пользователей и рабочих нагрузок, таких как лицензии Professional, Standard и Workspace . Лицензии генерируются и предоставляются с помощью программных платформ Cisco или партнеров . После приобретения и предоставления лицензий необходимо проверить правильность количества лицензий. Этот процесс гарантирует, что в организации активированы и готовы к использованию при развертывании нужные лицензии.
При первоначальной настройке лицензирования важно настроить автоматическое лицензирование на уровне организации, чтобы упростить выдачу лицензий новым пользователям. Эта настройка позволяет автоматически выдавать лицензии при добавлении пользователей в организацию, устраняя необходимость в ручном назначении лицензий. При настройке автоматического лицензирования на уровне организации вы выбираете сервисы для назначения и определения области действия, например, выдача лицензий только будущим пользователям или включение существующих пользователей.
Однако если ваш план развертывания предусматривает автоматическое лицензирование на уровне групп , вы можете отказаться от назначения лицензий на уровне организации во избежание конфликтов или дублирования лицензий. При автоматическом лицензировании на уровне групп лицензии назначаются на основе членства в группе. Пользователи, входящие в несколько групп, получают лицензии по всем применимым групповым заданиям.
Настройка группового назначения лицензий должна быть выполнена после завершения синхронизации каталогов, чтобы синхронизированные группы существовали и их можно было использовать для назначения лицензий.
В частности, автоматическое назначение лицензий требует дополнительных сведений о подготовке, таких как местоположение пользователя и назначение номера телефона. Для автоматической активации лицензии рабочий телефонный номер пользователя должен быть в формате +E.164, предварительно предоставлен и привязан к действительному местоположению. Если эти условия не будут соблюдены, пользователю не будут предоставлены услуги автоматически, и может потребоваться ручное вмешательство.
Короче говоря, настройте автоматическое лицензирование на уровне организации для новых пользователей, если вы хотите распределять лицензии в широком масштабе по всей организации. Если вы предпочитаете более детальный контроль или у каждой группы разные требования к лицензированию, настройте автоматическое лицензирование на уровне группы и избегайте назначения лицензий на уровне организации, чтобы избежать дублирования и обеспечить надлежащее управление лицензиями.
Webex Callingнастройки сервиса
Очень важно провести всесторонний анализ и настройку глобальных настроек сервиса.
Для начала зайдите в раздел настроек и перейдите к нему. Внимательно изучите каждый настраиваемый параметр, включая, помимо прочего, внутреннюю конфигурацию набора номера, параметры экстренных вызовов, политики маршрутизации вызовов, управление голосовой почтой и настройки устройства по умолчанию.
Настройте эти глобальные параметры в соответствии с политиками и проектными решениями вашей организации.
Кроме того, настройте параметры и шаблоны пользователей и приложений.
Пилотная миграция
На этапе внедрения пилотная миграция является важнейшей вехой в подтверждении перехода от на. Этот пилотный проект предусматривает выделение на платформу репрезентативной подгруппы пользователей из одного или нескольких мест и обеспечение соответствия выбранной группы пользователей различным сценариям использования и организационным ролям. Параллельно с миграцией пользователей основные сервисы для совместной работы, включая голосовую почту, автосекретарей, очереди вызовов и поисковые группы, необходимо перевести на эквивалентные сервисы для обеспечения непрерывности бизнеса и функциональности обслуживания.
При пилотной миграции следует использовать ту же комбинацию инструментов, предоставленных Cisco, и утилит миграции сторонних производителей, которую планируется внедрить в более широкой организации, чтобы обеспечить тщательную проверку процессов, рабочих процессов автоматизации и точек интеграции в репрезентативных условиях.
Это пилотное развертывание преследует две основные цели: во-первых, проверить и усовершенствовать комплексные процессы перехода, включая рабочие процессы подготовки пользователей, процедуры миграции данных и конфигурации конечных точек; во-вторых, всесторонняя проверка функциональности перенесенных сервисов в реальных условиях эксплуатации.
Этот поэтапный подход позволяет проектной группе выявлять и устранять любые технические или процедурные проблемы в контролируемой среде, собирать отзывы пользователей о новой платформе, оценивать эффективность выбранных инструментов миграции и доверять методологии миграции, прежде чем приступить к более широкому организационному развертыванию.
Информация, полученная на этом пилотном этапе, помогает оптимизировать последующие волны миграции и обеспечить плавный переход с минимальными рисками для всего предприятия.
Закупите PSTN
Чтобы приобрести услуги PSTN, сначала выберите вариант подключения к PSTN во вкладке.
Если организация планирует временно или на неопределенный срок сохранить гибридное управление двойными вызовами (этап 1 на рисунке «Поэтапный переход на вызовы: гибрид и облако»), ей необходимо будет развернуть один или несколько локальных шлюзов для локальной сети PSTN, позволяющих звонить между конечными точками и конечными точками.
Если конечной целью является полный переход (этап 2) в облако, включая PSTN, то для PSTN потребуется либо план Cisco Calling, либо вариант Cloud Connect для PSTN.
Обратитесь к выбранному провайдеру, чтобы заказать и перенести телефонные номера перед их настройкой. Заказ телефонных номеров или отправка заказов на порты необходимы и возможны только для локальных PSTN и Cloud Connect для. Для тарифных планов Cisco Calling заказ и перенос заказов начинаются прямо из Control Hub сразу после создания местоположения, а также в странах, где доступен план Cisco Calling Plan. Дополнительные сведения о планах Cisco Calling см. в разделе Начало работы с планами Cisco.
В рамках внедрения PSTN убедитесь, что ваш провайдер включил входящие и исходящие услуги PSTN для вашего местоположения. Кроме того, проведите тестовые вызовы, чтобы убедиться, что вызовы правильно маршрутизируются через выбранное вами соединение PSTN.
Настройте местоположения
Перед добавлением пользователей и устройств необходимо указать места вызовов. Для каждого местоположения необходимо ввести действительный почтовый адрес. В США и Канаде этот адрес подтвержден и используется платформой для отправки информации о местоположении PIDF-LO для экстренных вызовов.
При настройке местоположений, использующих локальную сеть PSTN, необходимо соответствующим образом настроить локальные шлюзы. Во-первых, для каждого локального шлюза должны быть созданы магистраль и группа маршрутов, а затем группа маршрутов назначается в качестве выбранного PSTN для данного местоположения. Cisco настоятельно рекомендует всегда выбирать в качестве PSTN группу маршрутов, поскольку такой подход позволяет легко добавлять дополнительные магистрали в будущем, поддерживая масштабируемость и избыточность. Cisco также рекомендует включить поддержку двойной идентификации и P-Charge-Info на каждой магистрали PSTN, поскольку это упрощает идентификацию стороны, оплачиваемой за исходящие прямые или переадресованные вызовы. Если ваш поставщик услуг PSTN использует другой заголовок для выставления счетов, вы можете скопировать информацию из заголовка P-Charge-Info на локальном шлюзе в необходимый заголовок биллинга.
В местах, где в качестве опции PSTN используется Cloud Connect или план Cisco Calling Plan, просто выберите соответствующий вариант PSTN в качестве местоположения во время настройки. Если в локации используется Cloud Connect или локальная PSTN, вам необходимо добавить телефонные номера, заказанные на предыдущем шаге. Номера можно добавить как неактивные, если вы не хотите сразу включать их в маршрутизацию вызовов; эти номера можно активировать позже, когда они будут назначены пользователям или функциям.
Важно всегда устанавливать основной номер для каждого населенного пункта. Основной номер можно присвоить пользователю или функции, например автосекретарю. Чтобы включить голосовую почту на месте, обязательно задайте пилотный номер голосовой почты, также известный как номер голосового портала.
Дополнительные настройки мест вызова включают настройку данных экстренных вызовов, таких как номер обратного вызова, параметры уведомлений и расширенные функции экстренного вызова. Вам также следует просмотреть и настроить параметры записи, языковые предпочтения и конфигурации устройств в соответствии с требованиями каждого местоположения. Если в вашей организации используется сокращенная внутрисетевая телефонная связь между сайтами со значимыми корпоративными номерами, не забудьте указать уникальный код сайта для местоположения в настройках внутреннего набора. Наконец, если для внешнего набора требуется номер исходящего набора, обязательно задайте его в настройках внешнего набора. Когда цифра исходящего набора настроена, Cisco рекомендует включить принудительное применение цифр исходящего набора для обеспечения согласованности.
Интеграция с локальным управлением вызовами
Для интеграции с локальным управлением вызовами необходимо настроить магистральные каналы, группы маршрутов, корпоративные телефонные планы, а также параметры местоположения и глобальные настройки. Начните с настройки магистралей и локальных шлюзов, предназначенных для подключения к локальной системе управления вызовами; этот шаг необходим только в том случае, если необходимы выделенные магистральные каналы. Если существующих магистралей и групп маршрутов достаточно для развертывания, их можно повторно использовать для локального соединения без дополнительной настройки.
После создания транков и групп маршрутов перейдите к созданию корпоративных телефонных планов и назначьте соответствующую группу маршрутов в качестве места назначения для каждой абонентской группы. Если интеграция включает несколько локальных систем управления вызовами, подключенных по разным магистральным каналам, потребуется несколько телефонных планов. Важно обеспечить, чтобы эти телефонные планы содержали только шаблоны, необходимые для маршрутизации вызовов на локальные адресаты.
Если в вашем развертывании требуется поддержка маршрутизации по неизвестным добавочным номерам, эту функцию следует включить на уровне местоположения. Кроме того, если активирована маршрутизация по неизвестным добавочным номерам, вы должны указать максимальную длину неизвестного номера в разделе Маршрутизация вызовов между помещениями и в настройках служб вызова в. Это обеспечивает бесперебойную маршрутизацию вызовов и правильную обработку сценариев набора на основе добавочных номеров в интегрированной среде.
Перенос пользователей в пакетном режиме
При переносе пользователей из одного пользователя в другой вы, возможно, не сможете перемещать всех пользователей одновременно. Это может быть вызвано множеством причин, включая, помимо прочего, количество сайтов или пользователей, время, необходимое для одновременного перехода сайта и/или группы пользователей, ограниченность ИТ-ресурсов или ресурсов сайта для поддержки окна изменений, продолжительность окна изменений, сложность изменений и т. д.
При поэтапном переносе пользователей очень важно определить, каких пользователей необходимо перенести вместе в один пакет. Основная цель заключается в совместном переносе пользователей, которые зависят друг от друга в том, что касается сервисов и функций звонков. Вы хотите убедиться, что все их функции вызовов (например, очереди вызовов) полностью работают так же, как и до перехода.
Даже если вы внедрите взаимодействие вызовов между локальными шлюзами и с ними, вы не сможете разделить общие службы или функции в этом соединении. Поэтому вам необходимо определить зависимости между пользователями, рассмотрев такие функции , как:
-
Мониторинг других пользователей с помощью BLF
-
В одном и том же охотничьем пилоте, очереди вызовов и т. д.
-
Общие линии
-
Использование функции приема вызовов
-
Использование одних и тех же номеров колл-парков
-
Домофон
-
Исполнитель/администратор.
В качестве примера можно привести пользователя, входящего в группу Hunt, в которую осуществляется переход. Этот пользователь перейдет в охотничью группу и вместе со всеми остальными членами охотничьей группы. Таким образом, после перехода Охотничья группа и ее члены смогут успешно отвечать на звонки на новой платформе.
Это становится еще более сложным, когда пользователи подключаются к разным группам пользователей и используют разные сервисы и функции звонков. Для этого потребуется перевести несколько групп пользователей и одну службу вызова одновременно.
Используйте результаты работы инструмента Migration Insights или стороннего инструмента, который вы использовали на этапе подготовки, чтобы определить, каких пользователей и функции следует сгруппировать. Эти выходные данные следовало использовать при разработке плана миграции. Они помогут вам понять, как вы будете группировать пользователей и функции, требующие перехода.
Ключевые шаги при переходе группы пользователей:
-
Определение пользователей для совместной миграции
-
Убедитесь, что все пользователи вошли
-
Убедитесь, что все TN для пользователей существуют в
-
Проверьте правильный формат телефонного номера в каталоге
-
Убедитесь, что шаблон лицензирования и настроек для групп пользователей настроен правильно
-
Проверка или настройка всех служб и функций вызовов для группы пользователей (до или во время перехода, в зависимости от обстоятельств)
-
В корпоративном справочнике добавьте пользователей в группу пользователей с разрешенными вызовами
-
Используйте инструменты — инструменты переноса пользователей и функций и/или сторонние инструменты
-
После перехода отключите/удалите справочный номер пользователя/устройства и включите функции и службы.
После миграции группы пользователей протестируйте подгруппу пользователей, чтобы убедиться, что все их функции и службы вызовов работают правильно. Если функции вызовов, такие как очередь вызовов, группы поиска и т. д., передаются этой группе пользователей, проверьте работоспособность этих служб вызовов.
Рабочие пространства
Под рабочим пространством понимается общее место (например, конференц-зал, место для переговоров или рабочий стол), где можно назначать устройства, добавочные номера и пользователей. В отличие от традиционных телефонов Unifed CM, рабочие места — это:
-
Ориентация на местоположение: привязана к физическому пространству.
-
Гибкость в использовании: может быть установлено одно или несколько устройств (настольные телефоны, платы и т. д.).
Как только рабочие пространства будут определены как часть перехода, их можно добавить в раздел «Устройства». Каждому рабочему пространству необходимо назначить устройство, и если оно уже естьUnified CM, его необходимо перезагрузить или повторно подготовить. Такие функции, как голосовая почта, переадресация вызовов и прием вызовов, можно включать или отключать, а также применять правила в отношении видеозвонков, парковки вызовов и мобильности по мере необходимости. Протестируйте каждое рабочее пространство, совершая внутренние и внешние звонки, тестируя функции видео, конференц-связи и мобильности. Наконец, расскажите пользователям о любых процедурах, применимых к устройствам рабочего пространства и бронированиям.
Дополнительные сведения о рабочих пространствах см. в разделе Рабочие пространства.
Подготовительные устройства
Телефоны, на которые в настоящее время зарегистрированы, необходимо будет перенести на них в рамках перехода на облачные технологии. Чтобы максимально упростить миграцию и свести к минимуму вероятность сбоев, Cisco рекомендует перенести физические сайты или отделы одновременно. Однако из-за зависимостей функций может потребоваться пакетный перенос пользователей. Дополнительные сведения см. в разделе Пакетная миграция пользователей.
Все поддерживаемые телефоны, с которых вы хотите перейти, необходимо настроить в качестве пользователя или рабочего пространства, а физический телефон необходимо перенастроить для регистрации на нем. Кроме того, микропрограммное обеспечение телефонов серий 7800 и 8800 необходимо обновить с корпоративной микропрограммы до микропрограммы для многоплатформенных телефонов (MPP). Этот процесс включает загрузку переходного микропрограммного обеспечения перед загрузкой микропрограммы MPP, необходимой для регистрации. Для этого также требуется соответствующая миграционная лицензия. За последние несколько лет компания Cisco усовершенствовала этот процесс, чтобы упростить обновление телефонов Enterprise с микропрограммным обеспечением до микропрограммного обеспечения MPP. Дополнительные сведения о шагах по обновлению микропрограммного обеспечения см. в разделе Преобразование IP-телефонов Cisco серий 7800 и 8800 между корпоративным микропрограммным обеспечением и микропрограммным обеспечением MPP.
В дополнение к шагам, описанным в этой статье, имеется встроенный инструмент «Перенос телефона на»Webex Calling, который можно использовать для переноса телефонов 7800 и 8800 с корпоративной микропрограммы на MPP. Этот инструмент также позволяет добавлять телефоны и назначать их соответствующим пользователям или рабочим пространствам. Дополнительные сведения об использовании инструмента см. в разделе Перенос телефона.
На любые телефоны серии 9800, зарегистрированные с вышеуказанным требованием, перенос микропрограммного обеспечения не распространяется. Эти телефоны работают под управлением PhoneOS, которая поддерживается как и. Чтобы перевести эти телефоны на них, вам необходимо добавить ихWebex Calling, назначить пользователю или рабочему пространству, а затем восстановить заводские настройки телефонов. Последовательность загрузки PhoneOS при регистрации на рисунке ниже показывает последовательность загрузки PhoneOS и то, как телефон будет зарегистрирован после добавления в систему, даже если телефон все еще включен и/или используются опции DHCP (пример 150).
поддерживает сброс настроек устройств PhoneOS к заводским настройкам, чтобы обеспечить подключение к ним с помощью Zero-Touch. Администраторы могут удаленно восстановить заводские настройки телефонов 9800 и 8875 на страницах администрирования CUCM, что устраняет необходимость в физическом доступе к телефонам, к которым можно подключить телефоны. Эта функция поддерживается пакетами устройств с 9 сентября 2025 года:
-
CUCM v15 — диспетчер унифицированных коммуникаций версии 15
-
CUCM v14 — диспетчер унифицированных коммуникаций версии 14.
Дополнительные сведения о процессе регистрации серии 9800 см. в разделе Процесс регистрации.
В дополнение к IP-телефонам Cisco может потребоваться предоставление других устройств, таких как аналоговые телефонные адаптеры (ATA), беспроводные телефоны (Wi-Fi, DECT), видеоустройства, голосовые шлюзы и сторонние устройства и телефоны. Для многих из этих устройств, как в случае с IP-телефонами, нет способа обновления микропрограммного обеспечения для перехода с корпоративной микропрограммы на облачную микропрограмму. Поэтому вы предоставите каждое из этих устройств в Control Hub. На некоторые из них нельзя перенести, и их придется заменить эквивалентную модель (например, ATA (191/192) и другие потребуют ручной реконфигурации и/или изменений в программном обеспечении.
- Голосовые шлюзы. Сведения о переносе локального шлюза см. в разделе Перенос локального шлюза.
-
Аналоговый телефонный адаптер (ATA). Чтобы начать работу с Cisco ATA 191 и 192, см. Cisco ATA.
-
Беспроводной телефон с Wi-Fi. Сведения об интеграции беспроводных телефонов 840 и 860 см. в разделе Интеграция беспроводного телефона Webex .
-
Беспроводные телефоны DECT. Чтобы начать работу с новой серией Cisco IP DECT 6800, см. раздел Cisco IP DECT.
Дополнительные сведения о Cisco IP DECT 6800 см. в руководстве по развертыванию
-
Устройства и телефоны сторонних производителей. Обсудите с сторонними поставщиками требования к устройствам/телефонам и процесс их переноса или замены в службу поддержки.
Настройте функции
Любые необходимые функции вызовов необходимо подготовить до или во время перехода. Как уже говорилось в разделе «Пакетная миграция пользователей», функции вызовов необходимо настраивать и переносить при переходе пользователей, которые их используют.
Подробнее о том, как настроить каждую из функций, см. в соответствующих справочных статьях по настройке.
-
Автосекретари. Сведения об управлении автосекретарями см. в разделе Автосекретари
-
Парковка вызовов. Информацию об управлении парком вызовов см. в разделе Парковка вызовов
-
Перехват вызовов. Сведения о настройке группы приема вызовов см. в разделе Перехват звонков
-
Очереди вызовов. Сведения о настройке очереди вызовов см. в разделе Очередь вызовов
-
Охотничьи группы. Сведения об управлении охотничьими группами см. в разделе Управление охотничьими группами
-
Режимы работы. Сведения о маршрутизации вызовов на основе рабочих режимов см. в разделе Маршрутизация вызовов на основе рабочих режимов
-
Пейджинговые группы. Сведения о настройке пейджинговой группы см. в разделе Настройка пейджинговой группы
-
Записи. Информацию об управлении записями звонков см. в разделе Управление записями
-
Охват одного номера. Сведения о настройке охвата одним номером (в любом офисе) см. в разделе Настройка одного номера
Приемочное тестирование
Приемочное тестирование гарантирует, что перенесенная среда отвечает функциональным требованиям, работает должным образом и обеспечивает удобство работы пользователей во всех рабочих процессах связи. Этот процесс проверки многогранен и охватывает все: от подготовки пользователей и назначения номеров до операционной эффективности расширенных функций вызовов.
В этом разделе приведены примеры и ключевые аспекты, которые следует учитывать при приемочном тестировании, однако он не является исчерпывающим или исчерпывающим контрольным списком.
Подготовка пользователей и присвоение номеров
Основополагающим аспектом приемочного тестирования является проверка точности и полноты подготовки всех пользователей. Для этого необходимо провести тщательное сравнение каталога source () и вновь созданной базы пользователей, чтобы убедиться, что каждая учетная запись пользователя и связанные с ней атрибуты, такие как добавочные номера и назначения прямого входящего вызова (DID), были перенесены правильно. Полнота выделения ресурсов имеет решающее значение не только для обеспечения работоспособности в первый день, но и для текущего администрирования и поддержки.
Проверка назначения номера включает подтверждение того, что каждому пользователю присвоен правильный добавочный номер и внешний номер, а также правильность маршрутизации этих номеров как во внутренних (внутрисетевых), так и во внешних (PSTN) потоках вызовов. Очень важно проверить, нет ли совпадений, пропущенных назначений или неправильных конфигураций, которые могут привести к ошибкам маршрутизации вызовов или перебоям в обслуживании.
Потоки вызовов PSTN и представление идентификатора вызывающего абонента
Надежная процедура приемочного тестирования должна включать комплексную проверку потоков вызовов PSTN. Сюда входят сценарии как входящих, так и исходящих вызовов. В случае входящих вызовов PSTN группа тестирования должна подтвердить, что звонки доставляются на предполагаемые конечные точки, будь то отдельные пользователи, очереди вызовов, охотничьи группы или автосекретари. Исходящие вызовы PSTN должны выполняться успешно, уделяя особое внимание правильной доставке и представлению идентификационных данных вызывающего абонента. Для этого необходимо обеспечить отображение правильного имени и номера вызывающего абонента внешним получателям в соответствии с организационными политиками и нормативными требованиями.
Тестирование также должно учитывать сценарии аварийного переключения, такие как обработка недоступных конечных точек или сбои в работе сети. Это помогает убедиться, что резервные механизмы и альтернативная маршрутизация работают правильно, обеспечивая непрерывность и надежность обслуживания.
Потоки вызовов внутри сети
Внутренние или внутрисетевые потоки вызовов составляют основу корпоративной связи. Приемочное тестирование в этой области позволяет проверить правильность маршрутизации вызовов между пользователями в организации, а такие функции, как передача, удержание, переадресация и проведение конференций, работают по назначению. Должны быть подтверждены целостность телефонных планов , возможность соединения между добавочными номерами и поддержка организационных политик обработки вызовов.
Обработка вызовов пользователей и проверка функций
Важным аспектом приемочного тестирования является проверка того, как пользователи обрабатывают звонки с помощью настольных телефонов и поддерживаемых настольных телефонов. Этот процесс направлен на подтверждение интуитивности и надежности повседневных рабочих процессов звонков и беспрепятственного доступа пользователей к основным функциям, необходимым для выполнения их ролей. Тестирование должно оценить, с какой легкостью пользователи могут звонить и принимать звонки, управлять функциями удержания и возобновления вызова, а также выполнять переводы вслепую и по консультациям. Также важно убедиться, что переадресация вызовов, проведение конференций и другие расширенные функции, такие как парковка, прием вызовов или активация режима «Не беспокоить», доступны и работают без сбоев.
Опыт следует оценить на предмет ясности и оперативности реагирования, учитывая, как пользователи взаимодействуют с историей звонков, голосовой почтой и интегрированными каталогами. Дополнительное внимание следует уделить возможности перемещения активных вызовов между устройствами и эффективному использованию элементов управления входящими вызовами в приложении или на физических телефонах. Конечная цель заключается в том, чтобы после миграции конечные пользователи были стабильными, эффективными и полностью отвечали коммуникационным потребностям организации.
Очереди вызовов: опыт работы агентов и супервизоров
Очереди вызовов часто используются для обработки сценариев больших объемов входящих вызовов. Приемочное тестирование здесь сосредоточено на нескольких аспектах. Во-первых, необходимо убедиться, что вызовы распределяются между агентами в соответствии с настроенной логикой очереди, например циклическим переходом, самым длительным временем простоя или одновременным звонком. Представление вызовов в очереди на настольных компьютерах агентов необходимо изучить на предмет ясности и простоты использования, чтобы агенты могли эффективно принимать, удерживать и пересылать вызовы.
Руководителям следует оценить работу настольного компьютера с точки зрения таких функций, как мониторинг в реальном времени, отправка звонков, аналитика или анализ производительности очередей. Сюда входит, помимо прочего, проверка информационных панелей и инструментов отчетности, которые предоставляют действенные данные о распределении звонков, активности агентов и метриках очередей.
Охотничьи группы: распределение звонков
Охотничьи группы — ключевой механизм распределения звонков заранее определенным группам пользователей. Приемочное тестирование должно подтвердить, что звонки направляются членам группы на основе настроенного алгоритма поиска и что сценарии переполнения, переадресации и отсутствия ответа обрабатываются в соответствии с планом. Для обеспечения стабильности работы и удовлетворенности пользователей крайне важно обеспечить соответствие поведения членов групп и маршрутизации вызовов ранее установленным стандартам.
Автосекретари: объявления и операции с меню
Автосекретари представляют собой передовую линию автоматизированной обработки вызовов. Тестирование должно охватывать воспроизведение объявлений, точность записанных приветствий и правильную работу деревьев меню. Выбранное меню должно надежно направлять абонентов на соответствующие отделы, отдельные лица или внешние номера. Тестирование также должно включать недействительные сценарии или сценарии ожидания, чтобы убедиться, что звонящие получают четкие инструкции или перенаправляются по назначению.
Работа с голосовой почтой
Наконец, функциональность голосовой почты имеет решающее значение для удобства пользователей. Приемочные испытания должны подтвердить, что ящики голосовой почты правильно назначены и доступны как внутри организации, так и удаленно. Необходимо подтвердить возможность записи, извлечения сообщений и управления ими, а также рассылки уведомлений.
Оптимизировать
Миграция PSTN в Cloud Connect для
После того как все конечные точки и пользователи будут перенесены в облако, единственной целью вызова станет Unified CM выполнение функций транзита между шлюзами PSTN и через локальный шлюз. Устранение шлюзов PSTN и локального шлюза за счет использования Cloud Connect в качестве доступа к PSTN для всех Webex Calling пользователей дает ряд преимуществ, включая снижение затрат и повышение надежности. Чтобы перевести локальный доступ к PSTN в Cloud Connect для, выполните следующие действия:
-
Cloud Connect для выбора партнера.
Ознакомьтесь со списком партнеров Cloud Connect и выберите одного из доступных партнеров в регионе вашей организации.
-
Cloud Connect для проверки.
Перед переключением доступа к PSTN для локаций на Cloud Connect необходимо проверить и подтвердить подключение к PSTN через выбранного партнера Cloud Connect. Для этого необходимо предоставить тестовое местоположение, а некоторым тестовым пользователям — в этом тестовом месте. Затем доступ к PSTN в этом тестовом месте предоставляется партнеру Cloud Connect, а затем проверяется подключение к PSTN с помощью тестовых телефонов. После успешной проверки тестовое место может быть выведено из эксплуатации.
-
Перенос номеров.
Чтобы подготовиться к подключению к Cloud Connect, необходимо оформить заказ на портирование всех номеров, которые в настоящее время присвоены магистрали PSTN и заканчиваются на ней. Все номера необходимо перенести партнеру Cloud Connect. Чтобы обеспечить доступность между точками, необходимо портировать все номера из всех местоположений одновременно .
-
Перейдите к партнеру Cloud Connect.
На момент отключения доступ к PSTN во всех местах должен быть предоставлен поставщику подключенных к облаку PSTN, а также проверить входящее и исходящее подключение.
Как описано в разделе PSTN главы, посвященной проектированию, клиенты также могут перенести свой доступ к PSTN в Cloud Connect в начале перехода, используя транкинг PSTN для гибридных развертываний. Дополнительные сведения см. в разделе Транкинг PSTN для гибридных развертываний. Webex Calling В этом случае во время перехода доступ к PSTN осуществляется через локальный шлюз, а после перевода всех пользователей на PSTN не требуется никаких дополнительных этапов миграции, связанных с PSTN, кроме вывода из эксплуатации и использования локальных шлюзов.
Оптимизация локальной инфраструктуры
После перевода всех пользователей и перевода всех конечных точек на облачную регистрацию (или вывод из эксплуатации) обновите соответствующую локальную инфраструктуру уже сейчас, когда облачные вызовы уже используются. Обновления инфраструктуры включают следующее:
-
Удалите локальные DNS SRV записи управления вызовами и обмена сообщениями с локальных DNS-серверов, включая cisco_uds. _tcp. <domain>, cup_login. _tcp. <domain>. Эти записи SRV больше не нужны для обнаружения клиентских сервисов.
-
Удалите DNS SRV записи, связанные с периферией, из общедоступной системы DNS, включая collab_edge. _tls. <domain>. Эти записи SRV больше не нужны для обнаружения периферийных сервисов для совместной работы в службе поддержки клиентов.
-
Обновите все соответствующие области DHCP, чтобы удалить адреса серверов TFTP/Boot в вариантах 66 и 150 . Эти области больше не нужны для обнаружения и загрузки конфигурации управления вызовами конечных точек.
-
Обновите или удалите соответствующие точки вызова в локальном шлюзе/кубе, которые маршрутизируют входящие и исходящие вызовы. Unified CM Эти конечные точки вызова больше не нужны для локальной маршрутизации вызовов.
-
Удалите или удалите все виртуальные машины и/или серверы узлов кластера. При необходимости перепрофилируйте вычислительные ресурсы и оборудование . Эти ресурсы больше не нужны для управления вызовами и периферийных служб.
-
Удалите или удалите все виртуальные машины и/или серверы узлов кластера. При необходимости перепрофилируйте вычислительные ресурсы и оборудование . Эти ресурсы больше не нужны для голосовой почты и служб единой системы обмена сообщениями.
-
Очистка: после переноса доступа PSTN к подключенной к облаку PSTN магистрали PSTN, шлюзы PSTN и локальный шлюз могут быть выведены из эксплуатации.
-
В любом существующем локальном решении E911 удалите все места или номера, куда вы перешли, и после завершения полного перехода удалите виртуальные машины или серверы приложений. При необходимости перепрофилируйте вычислительные ресурсы и оборудование . Эти ресурсы больше не нужны для экстренных вызовов и служб определения местоположения.
-
Во избежание сбоев в маршрутизации вызовов и обеспечения приоритетного доступа всех служб CSS к облачному пути одних и тех же DNS следует размещать доменные имена, принадлежащие мигрировавшим пользователям.
-
Всякий раз, когда происходят изменения, обновляйте физическое диспетчеризируемое местоположение и сетевой элемент в Horizon Mobility . Типичные действия, требующие обновления:
-
Замена сетевого коммутатора
-
Замена беспроводной точки доступа
-
Изменения области DHCP
-
Физические изменения в здании (если речь идет о кабинном/офисном помещении)
-
Физическое расширение или сжатие офисных помещений в здании.
-
Используйте аналитику и устранение неполадок
предоставляет комплексные возможности аналитики и устранения неполадок, помогающие визуализировать и отслеживать развертывание. К ним относятся аналитика качества медиафайлов, подробной истории звонков, очереди вызовов, поисковой группы и автосекретаря. Пример аналитики качества мультимедиа показан на рисунке «Аналитика качества мультимедиа».
В разделе «Устранение неполадок» каждый сделанный звонок можно просмотреть с подробной информацией об основных проблемах с качеством мультимедиа и сигналами, которые помогут точно определить проблемы с медиафайлами, а также неудачные вызовы, как показано на рисунке «Устранение неполадок с качеством мультимедиа».
Устранение неполадок также можно интегрировать с другими продуктами Cisco, такими как коммутаторы ThousandEyes и Meraki, что обеспечивает еще более широкие возможности интеграции в Control Hub. Дополнительные сведения об использовании Webex Callingаналитики и устранении неполадок см. в разделе Устранение неполадок вызовов в Control Hub Webex Calling.
Введение
Прежде чем начать
Данное руководство предназначено для команд или отдельных лиц, имеющих опыт настройки и администрирования Cisco Unified Communications Manager (Unified CM) и конечных устройств Cisco, включая IP-телефоны, видеоустройства и программные клиенты Jabber. В этом документе содержатся ссылки на документацию по продукту и поддержке, которые помогут вам в работе.
Данный документ посвящен переходу от Unified CM к Webex Calling в многопользовательском режиме. Термин Webex Calling в этом документе всегда относится к многопользовательскому режиму Webex Calling.
Перед началом миграции с Unified CM на Webex Calling крайне важно иметь полное представление о решении Webex Calling и его компонентах. Для успешной миграции необходимо знание архитектуры Webex Calling, моделей обслуживания, вариантов развертывания и связанных с ними функций, чтобы правильно сопоставить существующие рабочие нагрузки Unified CM и разработать эффективный план перехода.
Для разработки эффективной стратегии перехода и обеспечения оперативной готовности необходимо досконально разбираться в следующих компонентах Webex Calling.
-
Control Hub
-
Управление каталогами и пользователями
-
Платформа для видеозвонков Webex
-
Поддерживаемые конечные точки вызова
-
Варианты подключения к телефонной сети общего пользования (PSTN)
-
Webex Calling: план набора номера и управление номерами
-
Функции обеспечения безопасности и соответствия нормативным требованиям.
Для получения дополнительной информации см. Предпочтительная архитектура Cisco для звонков Webex.
В этом руководстве будут рассмотрены инструменты и процессы, которые следует использовать на протяжении всего цикла перехода. Однако переход от локальной системы голосовой связи Unified CM к новой облачной платформе Webex Calling может потребовать значительных усилий и повлечь за собой потенциальные бизнес-задачи, технические проблемы и сложности. Чтобы помочь вам преодолеть эти трудности, компания Cisco предлагает несколько различных вариантов, которые могут оказать вам поддержку на этом пути. Важно ознакомиться с информацией по ссылке Enterprise cloud calling - Calling migration и понять каждый вариант и то, как каждый из них может помочь вам в вашей собственной миграции.
-
Инструменты миграции Webex: В Control Hub встроены бесплатные инструменты самообслуживания для упрощения перехода на Webex Calling.
-
Сертифицированные поставщики услуг миграции: Компания Cisco провела проверку поставщиков программного обеспечения и инструментов, разработавших решения для миграции, которые помогают партнерам и клиентам Webex в сложных и масштабных процессах миграции. Эти решения помогут упростить, организовать и ускорить переход на Webex Calling.
-
Помощь в настройке Webex: Сервис миграции от Cisco, который помогает клиентам и партнерам в развертывании и настройке Webex Calling, необходимых для успешной миграции пользователей и сервисов Unified CM на Webex Calling.
Обзор
С ростом популярности облачных сервисов для совместной работы все больше клиентов стремятся перенести свои существующие рабочие нагрузки в облако, учитывая преимущества облачных сервисов, такие как снижение общей стоимости владения, упрощенное управление, непрерывная доставка новых функций, увеличение масштабируемости и превосходная надежность. Поскольку клиенты стремятся перейти от локальных сервисов для совместной работы к облачным, им важно понимать, что подразумевает этот переход и какие шаги необходимы для его осуществления.
Цель данного документа — предоставить рекомендации по развертыванию для клиентов, которые планируют перейти от локальной системы Unified CM к облачной системе Webex Calling. Данное руководство по развертыванию предполагает, что читатель имеет базовое понимание процесса перехода между Unified CM и Webex Calling, включая изменения, происходящие при этом переходе, и различия при переносе рабочей нагрузки звонков из локальной среды в облако. Прежде чем продолжить, убедитесь, что вы ознакомились с информацией, представленной на карте переходов . Данный документ, представляющий собой карту перехода, содержит информацию об изменениях и различиях, происходящих в ходе этого перехода.
Как показано на рисунке Архитектура локальной среды для совместной работы: Управление вызовами и удаленный доступ, типичное локальное развертывание включает в себя различные компоненты инфраструктуры для совместной работы в сети, платформу управления вызовами, периферийную платформу, аппаратные и программные конечные точки, а в некоторых случаях даже платформы для проведения конференций и планирования. В архитектуре Cisco это включает в себя Unified CM для управления вызовами, Expressway для удаленного доступа и сервисов для взаимодействия между предприятиями (B2B), а также Cisco Meeting Server. / Cisco Meeting Management для организации конференций в локальной сети, Unity Connection для голосовой связи, а также IP-терминалы, используемые пользователями (IP-телефоны Cisco, настольные и переговорные видеосистемы Cisco) и программное обеспечение (Cisco Jabber). В некоторых средах эти компоненты могут незначительно отличаться, но это отправная точка для перехода, описанного в остальной части этого документа.
Архитектура, показанная на рисунке Архитектура для совместной работы в локальной среде: Управление вызовами и удаленный доступ основаны на предпочтительной архитектуре (PA) для локальных развертываний Cisco Collaboration Enterprise. Для получения дополнительной информации о локальной корпоративной архитектуре см. Предпочтительные архитектуры для совместной работы Cisco.
До: В таблице перечислены ключевые элементы локальной архитектуры до перехода на Webex Calling в облаке.
| Продукт | Описание |
|---|---|
| Unified CM | Система управления вызовами на локальном сервере, обеспечивающая регистрацию устройств и маршрутизацию вызовов. |
| Cisco Expressway-C/E | Периферийная инфраструктура, обеспечивающая мобильный и удаленный доступ (MRA) и функциональность для взаимодействия между предприятиями (B2B), позволяет удаленным конечным точкам безопасно подключаться извне организации. Expressway развертывается парами для обеспечения обхода брандмауэра для внешних конечных точек. |
| Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) и Cisco Telepresence Management Suite (TMS) | Локальная инфраструктура для голосовой, видео- и веб-конференцсвязи, обеспечивающая проведение многоточечных совещаний, управление совещаниями и возможности планирования. [Optional] |
| Cisco Unity Connection | Локальная платформа голосовой почты, предоставляющая возможности голосовой почты и унифицированного обмена сообщениями. [Optional] |
| Cisco Desk, Cisco Room, Cisco Board, Cisco IP Phones и Cisco Jabber | IP-устройства, зарегистрированные в Unified CM и обеспечивающие возможности голосовой и видеосвязи. |
Как показано на рисунке Решение о переходе: Для организации локальных вызовов через Webex Calling, клиенты, имеющие локальную систему управления вызовами с Unified CM и IP-терминалы для рабочих мест и видеосвязи, могут выбрать переход к облачной архитектуре Webex Calling.
Решение должно приниматься на основе функциональных требований заказчика. Клиентам, предъявляющим следующие требования, следует тщательно обдумать это решение, поскольку в конечном итоге они могут предпочесть сохранить управление вызовами на своих собственных серверах:
- Модели телефонов, не поддерживаемые Webex Calling
- Сложные или многочисленные интеграции с другими локальными системами или решениями, особенно в тех случаях, когда воспроизведение этих интеграций с Webex Calling затруднено или отсутствуют эквивалентные альтернативные решения.
- Сложный план набора номера, высокодетализированные классы обслуживания или и то, и другое.
- Ограниченный, ненадежный или ограниченный доступ в Интернет.
- Строгие правила защиты конфиденциальности и права собственности на данные.
- Требования к соблюдению норм при записи и хранении медиафайлов на территории страны или в пределах её территории.
- Интеграция со сторонними сервисами без жизнеспособной альтернативы интеграции Webex Calling.
- Интеграция контакт-центров в тех случаях, когда интеграция контакт-центра пока не переносится в облако.
Данный документ предназначен для клиентов, использующих систему управления вызовами Unified CM, и предназначен для ознакомления с общими шагами, особенностями и требованиями для включения функции Webex Calling, как описано в следующем разделе.
Основные компоненты
Целевая архитектура для этой миграции включает в себя несколько новых компонентов. Это включает в себя сервис Webex Calling для облачных звонков, приложение Webex, Cisco Directory Connector для интеграции идентификации и локальный шлюз (LGW) для доступа к телефонной сети общего пользования (PSTN), а также интеграцию локальных и облачных звонков. Дополнительные варианты доступа к телефонной сети общего пользования (PSTN) включают тарифные планы Cisco Calling или подключение к облачной сети PSTN (Cloud Connected PSTN, CCP), предоставляемое партнером Cloud Connect for Webex Calling.
Как показано на рисунке После: В архитектуру Webex Calling, новые компоненты (Webex Calling, коннектор каталога, локальный шлюз и шлюз обеспечения отказоустойчивости) добавляются к существующей локальной конфигурации.
После: В таблице перечислены новые элементы архитектуры после перехода на Webex.
| Продукт | Описание |
|---|---|
| Webex Calling | Облачный сервис обработки вызовов, предоставляемый на платформе Webex и обеспечивающий регистрацию конечных точек и маршрутизацию вызовов. |
| Cisco Directory Connector | Приложение Windows, работающее на компьютере в домене Windows и обеспечивающее синхронизацию идентификационных данных между локальной службой Active Directory предприятия и хранилищем идентификационных данных организации Webex. Для клиентов, переходящих с локальной Active Directory на Entra ID, интеграция идентификации с Webex вместо Cisco Directory Connector осуществляется с помощью приложения Entra ID Wizard. |
| Локальный шлюз | Локальный шлюз выступает в качестве моста между локальной сетью унифицированных коммуникаций клиента и облачной платформой Webex Calling. Его можно развернуть локально или разместить у партнера, обеспечивая доступ к телефонной сети общего пользования (PSTN) для зарегистрированных в облаке конечных точек, а также интеграцию вызовов между зарегистрированными в Unified CM и облачными конечными точками. Маршрутизаторы Cisco IOS-XE Integrated Services Router (серии ISR 1100 и 4000), Cisco Catalyst 8200/8300 В качестве шлюза локальной сети (LGW) для поэтапной миграции можно использовать Cisco Series, программное обеспечение Cisco Catalyst 8000V Edge Software, а также различные сертифицированные контроллеры граничных сессий (SBC) сторонних производителей. |
| Шлюз системы повышения выживаемости | Survivability Gateway (SGW) — это локальный сетевой шлюз на базе IOS-XE, который обеспечивает резервные услуги связи для локальных устройств Webex Calling во время сбоев в сети. |
| Тарифный план Cisco Calling, Cloud Connect для звонков Webex. | Cisco Calling Plan и Cloud Connect for Webex Calling — это облачные решения для доступа к телефонной сети общего пользования (PSTN) для устройств Webex Calling. Доступ к телефонной сети общего пользования (PSTN) обеспечивается облачным провайдером PSTN и не требует наличия оборудования на территории предприятия. |
| Приложение Webex | Клиентское приложение, работающее на настольных ОС (Windows, Mac) или мобильных ОС (Android, iOS) и напрямую зарегистрированное на платформе Webex Calling для обеспечения функциональности звонков. |
Обзор процесса PPDIO
Процесс PPDIO расшифровывается как Prepare, Plan, Design, Implement, and Optimize ] (Подготовка, Планирование, Проектирование, Внедрение и Оптимизация) . Это структурированная методология Cisco, которая направляет проекты от первоначальной оценки до непрерывного совершенствования, обеспечивая эффективное и успешное развертывание или миграцию.
Общее описание PPDIO
-
Подготовить: Оцените текущую ситуацию, соберите требования и согласуйте действия заинтересованных сторон для создания прочной основы.
-
План. Разработайте подробные планы проекта, включая сроки, ресурсы и стратегии снижения рисков.
-
Дизайн: Разработайте целевое решение, адаптированное к потребностям бизнеса и техническим требованиям.
-
Осуществлять: Выполните развертывание или миграцию в соответствии с проектом, проверив функциональность и производительность.
-
Оптимизировать: Постоянно совершенствуйте решение после внедрения, отслеживая производительность, уточняя конфигурации и используя инструменты автоматизации и интеграции.
Использование PPDIO для проектов миграции Unified CM на Webex Calling.
При переходе с Unified CM на Webex Calling процесс PPDIO предоставляет четкий план действий для обеспечения плавного и эффективного перехода:
Подготовка
-
Оцените существующую среду Unified CM и готовность к миграции.
-
Соберите подробные данные о пользователях, устройствах, сети и зависимостях.
-
Соберите информацию о местоположении, включая адрес службы экстренного реагирования, количество пользователей, доступ в интернет и доступ к телефонной сети общего пользования (PSTN).
-
Выявите риски и определите объем проекта для согласования действий всех заинтересованных сторон.
Планирование
-
Разработайте комплексный план миграции с расписанием пакетной обработки, распределением ресурсов и сроками.
-
Определите задачи, такие как обновление встроенного ПО устройств, предоставление лицензий и регистрация пользователей.
-
Скоординируйте сроки миграции с Cisco и партнерами, чтобы свести к минимуму сбои.
Проектирование
-
Сопоставьте текущие конфигурации Unified CM, планы набора номера и профили пользователей с аналогичными параметрами Webex Calling.
-
Разработайте среду Webex Calling, включая стратегию для телефонной сети общего пользования (временную и окончательную), местоположения, роли пользователей и точки интеграции, такие как локальный шлюз (CUBE) и синхронизация каталогов.
-
В ходе миграции необходимо предусмотреть сценарии сосуществования, при которых Unified CM и Webex Calling будут работать одновременно.
Внедрение
-
Используйте инструменты миграции Control Hub совместно с инструментами сторонних разработчиков для изменения режима работы встроенного ПО устройства, настройки функций и миграции пользователей.
-
Используйте пакетные операции и выделение ресурсов с помощью API Webex для оптимизации масштабных миграций и конфигураций.
-
Выполните предоставление лицензий, регистрацию устройств и обновление конфигурации.
-
Подтвердите успешность миграции посредством тестирования и оперативной проверки.
Оптимизация
-
Постоянно отслеживать производительность и удобство использования Webex Calling.
-
Уточняйте конфигурации и рабочие процессы на основе оперативных данных и обратной связи.
-
Используйте возможности автоматизации и интеграции для повышения эффективности и масштабируемости.
-
По мере необходимости вывести из эксплуатации устаревшие компоненты Unified CM и обеспечить их постоянную поддержку для дальнейшей работы.
Этот усовершенствованный подход PPDIO обеспечивает контролируемую, прозрачную и эффективную миграцию с Unified CM на Webex Calling, используя инструменты, API и партнерскую экосистему Cisco для поддержания непрерывности бизнеса и улучшения возможностей совместной работы.
Петли обратной связи PPDIO
Общий обзор, представленный на рисунке Итерации при выполнении PPDIO иллюстрирует единый цикл обратной связи от фазы оптимизации обратно к фазе подготовки. Это означает, что после первоначальной реализации существует постоянная возможность для непрерывного совершенствования. Каждый цикл оптимизации может выявлять новые требования или области для улучшения, которые могут быть решены в рамках последующих проектов или инициатив. В свою очередь, каждый из этих отдельных проектов следует установленному жизненному циклу PPDIO (Подготовка, Планирование, Проектирование, Внедрение, Оптимизация). Такой итеративный подход гарантирует, что система остается в соответствии с меняющимися бизнес-целями и технологическими достижениями, способствуя формированию культуры постоянного совершенствования и адаптивности.
В ходе выполнения процесса PPDIO часто бывает так, что результаты, полученные на более поздних этапах, требуют пересмотра и, возможно, корректировки решений, принятых на более ранних этапах. Например, проблемы, выявленные на этапе реализации, такие как обнаружение неясностей в проекте или недостающих деталей, могут свидетельствовать о том, что некоторые аспекты не были в полной мере учтены на этапе проектирования. В таких случаях возникает необходимость вернуться к соответствующему предыдущему этапу, чтобы решить эти проблемы, прежде чем двигаться дальше. Этот итеративный механизм обратной связи, как показано на рисунке Unified CM assisted PPDIO process, гарантирует тщательную проверку и доработку решения, что в конечном итоге способствует более надежному и эффективному развертыванию.
При переходе с Unified CM на Webex Calling каждый этап процесса PPDIO может значительно выиграть от информации, собранной в существующей среде Unified CM. Например, из текущей конфигурации Unified CM можно получить исчерпывающие списки пользователей, телефонных номеров, функций вызовов и компонентов плана набора номера. Эти данные дополняют информацию, предоставляемую непосредственно заинтересованными сторонами, и помогают оптимизировать процессы планирования и проектирования. Использование соответствующих инструментов для автоматизации извлечения и анализа данных не только повышает точность, но и ускоряет весь процесс. Благодаря использованию опыта, полученного в ходе существующей реализации, переход на Webex Calling может быть осуществлен более эффективно, чем при традиционной внедрении с нуля, при этом сохраняя структурированную методологию PPDIO. Этот процесс проиллюстрирован на рисунке Унифицированный процесс PPDIO с поддержкой CM.
Миграционный подход
При планировании перехода от локальной системы Unified CM к Webex Calling вам необходимо определить, как вы будете подходить к этому процессу. Сначала вам нужно решить, будет ли миграция мгновенной (все сразу) или поэтапной ( миграция групп). users/devices в течение длительного периода времени).
Миграция с помощью функции Flash Cut позволяет максимально быстро переместить всех пользователей и устройства. Этот метод позволит одновременно перевести всех пользователей и устройства с локальной системы Unified CM на Webex Calling. По сути, это единое окно миграции для всех пользователей и устройств. После завершения миграции все ваши пользователи и устройства будут подключены к платформе Webex Calling, и всю вашу инфраструктуру Unified CM можно будет вывести из эксплуатации. Однако многие организации не могут использовать этот подход из-за масштаба и сложности своей системы обработки звонков.
Второй подход — это поэтапная миграция . Большинство организаций будут использовать этот подход, поскольку он обеспечивает лучший контроль, управление и масштабируемость при миграции. Кроме того, он лучше подходит для масштабных развертываний унифицированных коммуникаций. and/or развертывание в нескольких регионах. Поэтому в данном документе основное внимание уделяется поэтапному подходу, включающему два этапа перехода.
Как показано на рисунке ниже Поэтапный переход вызова: В гибридном и облачном решенияхпервая фаза перехода (Фаза 1) приводит к сосуществованию двух сред вызовов. На этом этапе часть пользователей, устройств и программных клиентов переводится на Webex Calling, в то время как другие по-прежнему используют локальную систему управления вызовами Unified CM. Заключительный этап перехода (этап 2) приводит к созданию полностью облачной среды для звонков, где все пользователи, устройства и программные клиенты полностью переведены на платформу Webex Calling.
Время, необходимое организации для полного перехода на облачные звонки, будет варьироваться в зависимости от используемой ею системы. В некоторых случаях организация может совершить первоначальный переход и оставаться в фазе сосуществования с двойным управлением вызовами (фаза 1) в течение длительного периода (месяцев или даже лет), в то время как в других случаях организация может полностью перейти на Webex Calling (фаза 2) за очень короткий период (недели или месяцы). Данный документ призван охватить обе фазы (фаза 1 — сосуществование и фаза 2 — полный переход).
Вполне возможно, что некоторые организации могут поддерживать двухканальное управление вызовами неограниченно долго, не планируя в будущем полностью переходить на облачные вызовы.
Второй важный момент — это способ перехода пользователей, устройств и программных клиентов с локальной системы управления вызовами на облачную. Рекомендуемый подход — это трехэтапный переход. На рисунке Рекомендуемый 3-фазный переход ниже этот подход разбит на 3 фазы.
Подготовка к миграции: На этом этапе основное внимание уделяется подготовке сред Webex и Unified CM к миграции. Речь идёт не о конкретных планах или конфигурациях, а о выполнении действий, которые можно предпринять сейчас и до начала любого проекта миграции Webex Calling. Цель состоит в том, чтобы заложить основу для обеих сред, чтобы подготовить их к миграции.
Подготовка к миграции: На этом этапе начинается подготовка к переходу на Webex Calling. Здесь необходимо пересмотреть и обновить бизнес- и технические требования. Не стоит просто переносить существующее оборудование Unified CM, а вместо этого необходимо пересмотреть бизнес- и технические требования, необходимые вашей компании сегодня и в будущем , используя возможности Webex Calling. Кроме того, на этом этапе вы завершите проектирование, планирование конфигурации и миграцию. planning/schedule.
Миграция (внедрение и вывод из эксплуатации): На этом этапе происходит фактическая миграция пользователей, устройств, телефонных номеров и программного обеспечения. Как обсуждалось выше, этот этап может быть завершен для всех одновременно (flash-cut) или в течение нескольких окон изменений (phased-cut). Разработка планов внедрения, обучение и информирование конечных пользователей имеют решающее значение, чтобы ваши пользователи были в курсе изменений, знали, как использовать новую платформу для звонков, и понимали, когда произойдут эти изменения. Последним шагом является вывод из эксплуатации всей локальной инфраструктуры унифицированных коммуникаций, которая больше не используется.
На этапе подготовки к миграции предусмотрены действия (обязательные, рекомендуемые и необязательные), к выполнению которых вы можете приступить немедленно. Рекомендуется выполнить эти действия как можно скорее, и желательно до начала вашего проекта. Выполнение некоторых этапов может занять больше времени, поэтому их начало на более раннем этапе поможет оптимизировать сам проект миграции.
На рисунке «Предварительные действия перед миграцией» ниже выделены пять конкретных категорий действий, связанных с миграцией Webex Calling.
Подготовка
Бизнес- и технические требования
При планировании миграции с одной платформы на другую крайне важно тщательно собрать как технические, так и бизнес-требования на этапе планирования. Этот шаг гарантирует, что миграция будет соответствовать операционным целям и техническим возможностям вашей организации, сводя к минимуму риски и сбои.
Почему важно собирать требования:
-
Согласовывает бизнес-цели: Понимание потребностей бизнеса помогает адаптировать миграцию под ключевые рабочие процессы, пользовательский опыт и планы роста.
-
Обеспечивает техническую совместимость: Выявление технических требований на ранних этапах позволяет избежать проблем с интеграцией с существующей инфраструктурой, сетью и конечными устройствами.
-
Облегчает планирование ресурсов: Четко сформулированные требования помогают точно оценить сроки, затраты и необходимые ресурсы.
-
Снижает риски: Раннее выявление потенциальных проблем позволяет принимать упреждающие решения, сокращая время простоя и перебои в работе сервисов.
Бизнес-требования
Типичные бизнес-требования включают в себя:
-
Количество пользователей и местоположений, подлежащих миграции.
-
Желаемые функции и услуги (например, маршрутизация вызовов, голосовая почта, конференц-связь, автоответчики, очереди вызовов)
-
Политика соответствия требованиям и безопасности
-
Бюджетные ограничения и ожидаемые затраты
-
Потребности пользователей в обучении и поддержке
-
Сроки миграции и вопросы обеспечения непрерывности бизнеса.
Сбор необходимых функций и услуг является критически важным шагом для обеспечения соответствия новой системы потребностям бизнеса. При сборе этих требований важно учитывать не только текущую конфигурацию, но и попытаться получить фактические требования от бизнес-субъектов, которые будут использовать систему. В противном случае существует риск того, что план основан на устаревших предположениях. Обязательно оцените дополнительные или расширенные функции, доступные в , которые могут отсутствовать в , такие как облачные звонки, расширенные очереди вызовов и . Это помогает в полной мере использовать преимущества облачной платформы.
При оценке текущей конфигурации важно учитывать, что не все существующие настройки могут оставаться необходимыми из-за меняющихся требований на протяжении всего жизненного цикла системы. Основное внимание следует уделить выявлению и сохранению только тех конфигураций, которые соответствуют текущим и будущим потребностям развертывания.
Сосредоточьтесь больше на том, что вам нужно, чем на том, что у вас есть.
Политика соответствия и безопасности являются критически важными факторами при миграции с Webex Calling на Webex Calling, чтобы гарантировать соответствие новой облачной системы связи правовым, нормативным и организационным стандартам.
-
Соответствие нормативным требованиям: Организации должны убедиться, что они соответствуют отраслевым нормативным актам, таким как GDPR, HIPAA или SOX, касающимся требований к конфиденциальности, хранению и обработке данных, а также национальных требований, касающихся места хранения данных, обхода платных дорог и местоположения СМИ.
-
Безопасность данных: Обеспечение шифрования голосовых и сигнальных данных как при передаче, так и в состоянии покоя для защиты от перехвата или несанкционированного доступа.
-
Контроль доступа: Определение и обеспечение аутентификации, авторизации и доступа на основе ролей пользователей для предотвращения несанкционированного использования коммуникационных ресурсов.
-
Аудит и мониторинг: Внедрение систем ведения журналов и мониторинга для отслеживания доступа и использования в целях проведения аудитов на соответствие нормативным требованиям и расследования инцидентов безопасности.
-
Согласование политики: Согласование процесса миграции с существующими корпоративными политиками безопасности, включая безопасность конечных точек, сегментацию сети и планы реагирования на инциденты.
-
Гарантия безопасности поставщика: Оценка сертификатов безопасности и подтверждений соответствия требованиям компании Cisco для обеспечения надежности.
Учет этих требований соответствия и политики безопасности на этапе планирования помогает снизить риски, избежать юридических санкций и обеспечить целостность и конфиденциальность коммуникаций на протяжении всего процесса миграции и после него.
Обучение и поддержка пользователей являются важными компонентами в процессе миграции с на для обеспечения плавного перехода и адаптации пользователей. К основным моментам, которые следует учитывать, относятся:
-
Программы обучения: Разработайте индивидуальные обучающие сессии для различных групп пользователей (конечных пользователей, администраторов, сотрудников службы поддержки), чтобы ознакомить их с функциями, пользовательским интерфейсом и новыми рабочими процессами.
-
Документация: Предоставьте понятные и доступные руководства пользователя, часто задаваемые вопросы и краткие справочные материалы, включая раздел «Что нового и изменилось » ресурсы и пошаговые инструкции «До и после » (в видеоформате или в виде краткого руководства), чтобы помочь пользователям адаптироваться к обновленному интерфейсу после миграции.
-
Управление изменениями: Заблаговременно сообщайте об изменениях, чтобы управлять ожиданиями пользователей и снижать сопротивление.
-
Опорная структура: Создайте специальную группу поддержки или механизм эскалации для оперативного решения проблем пользователей во время и после миграции.
-
Непрерывное образование: Планируйте постоянное обновление обучающих материалов по мере выхода новых функций или обновлений.
-
Механизмы обратной связи: Внедрить каналы для сообщения пользователями о проблемах и предоставления обратной связи с целью улучшения процессов обучения и поддержки.
Учет этих потребностей в обучении и поддержке на этапе планирования помогает свести к минимуму сбои, повысить уверенность пользователей и максимизировать преимущества миграции на новую платформу.
Технические требования
Для успешной миграции с одной платформы на другую необходимо собрать и задокументировать ряд ключевых технических требований, включая следующие детали:
-
Готовность сети и пропускная способность
Комплексная оценка сети имеет решающее значение для обеспечения того, чтобы ваша существующая инфраструктура могла поддерживать новую среду Webex Calling. Включает в себя:
-
Анализ полосы пропускания: Оценка текущего и прогнозируемого использования полосы пропускания для обработки голосового, видео- и информационного трафика без перегрузок.
-
Качество обслуживания (QoS): Внедрение политик QoS для приоритезации голосового трафика и минимизации задержек, дрожания сигнала и потери пакетов.
-
Подключение к глобальной сети и интернету: Проверка соответствия каналов WAN и интернет-соединений требованиям для облачных звонков, включая возможности резервирования и переключения при сбоях.
-
Настройка брандмауэра и NAT: Обеспечение того, чтобы настройки брандмауэра и NAT разрешали необходимый сигнальный и медиа-трафик для .
-
-
Интеграция с существующей системой
Бесшовная интеграция с существующими бизнес-системами имеет решающее значение для удобства пользователей и непрерывности рабочих процессов:
-
Службы каталогов: Оценка возможности интеграции с корпоративным каталогом для автоматизированного создания учетных записей пользователей и аутентификации.
-
CRM и бизнес-приложения: Выявление точек интеграции с системами управления взаимоотношениями с клиентами и другими критически важными для бизнеса приложениями.
-
Взаимодействие между устаревшими АТС: Разработка стратегий сосуществования или поэтапной миграции в случае, если какие-либо устаревшие телефонные системы останутся в процессе перехода.
-
-
Совместимость и подготовка конечных точек
Необходимо проверить совместимость всех конечных устройств, включая стационарные телефоны, программные телефоны и мобильные устройства:
-
Поддержка устройств: Подтверждение совместимости существующих IP-телефонов и устройств с существующими или определение необходимых замен.
-
Процессы предоставления ресурсов: Разработка автоматизированных или оптимизированных методов предоставления ресурсов для эффективного подключения конечных устройств.
-
Обновления прошивки и программного обеспечения: Планирование необходимых обновлений для обеспечения совместимости и безопасности.
-
-
Настройки безопасности и стандарты шифрования
Безопасность имеет первостепенное значение в облачных коммуникациях:
-
Шифрование: Внедрение сквозного шифрования для сигнальных и медиапотоков в соответствии с передовыми методами обеспечения безопасности Cisco.
-
Аутентификация и контроль доступа: Внедрение надежных механизмов аутентификации (таких как единый вход, многофакторная аутентификация) и детального контроля доступа пользователей.
-
Согласие: Обеспечение соответствия решения соответствующим нормативным требованиям и отраслевым стандартам (например, GDPR, HIPAA).
-
Мониторинг безопасности: Интеграция с инструментами SIEM и настройка оповещений о потенциальных инцидентах безопасности.
-
| Требование | Ключевые соображения |
|---|---|
| Готовность сети и пропускная способность | Пропускная способность, QoS, WAN/Internet, Firewall/NAT |
| Интеграция с существующими системами | Справочник, CRM, АТС, Email/Calendar |
| Совместимость и подготовка конечных точек | Поддержка устройств, настройка, обновления прошивки |
| Настройки безопасности и шифрование | Шифрование, аутентификация, соответствие нормативным требованиям, мониторинг безопасности. |
| Обучение пользователей и управление изменениями | Программы обучения, документация, коммуникация в процессе изменений. |
| Перенос номера и план набора номера | Число migration/porting, перевод плана набора |
| Интеграция со сторонними сервисами | Пейджинг, контакт-центр, факс, аналоговые устройства |
Готовность и требования к сети
Готовность сети имеет решающее значение для успешной миграции на любое облачное решение для телефонной связи, например, такое. Некачественное планирование сети может привести к ухудшению качества связи, обрывам звонков и недовольству пользователей. Перед переходом на новую систему клиентам необходимо провести оценку сети. Рекомендуется подтвердить доступность полосы пропускания сети для ожидаемого объема звонков, убедиться в соблюдении требований к качеству обслуживания (QoS) и разобраться в различных портах, которые необходимо открыть в межсетевом экране (или экранах).
Надежное сетевое соединение с достаточным качеством обслуживания (пропускная способность, потеря пакетов, RTT) является базовым требованием для обеспечения наилучшего качества обслуживания пользователей на всех устройствах, клиентах и приложениях, поддерживающих голосовую и видеосвязь.
Клиенты и партнеры имеют доступ к различным вариантам подключения, помимо интернета по протоколу Over-the-top (OTT), которые позволяют оптимизировать соединение, включая Webex Edge Connect. Для получения дополнительной информации о деталях проектирования Webex Edge Connect см. Предпочтительная архитектура Cisco для Webex Edge Connect для Webex Meetings, многопользовательских звонков и выделенных экземпляров.
Клиенты могут использовать CScan для оценки сети, которая предоставляет информацию о качестве сети клиента, количестве возможных соединений, задержке и так далее. Для получения дополнительной информации об инструменте CScan см. Использование CScan для проверки качества сети Webex Calling.
Чтобы убедиться в готовности сети к миграции на новую платформу, ознакомьтесь со следующим контрольным списком:
-
Планирование полосы пропускания
Рассчитайте количество одновременных вызовов на каждом сайте, чтобы убедиться в наличии достаточной пропускной способности для входящего и исходящего трафика, а также учесть резерв для другого критически важного для бизнеса трафика и будущего роста.
В таблице Расчеты пропускной способности для типов вызовов Webex Calling показаны типы вызовов, доступные в рамках развертывания, а также кодек и максимальная пропускная способность, необходимые для каждого типа вызова. Как показано в таблице Расчеты пропускной способности для каждого типа вызовов Webex Calling, необходимую пропускную способность аудиосвязи для каждого типа вызовов можно рассчитать по следующей общей формуле:
Количество ожидаемых одновременных вызовов * Пропускная способность на один звонок в зависимости от кодека. = Требуемая пропускная способность сети.
Таблица 2. Расчеты пропускной способности для различных типов звонков Webex Calling Типы вызовов Кодек - пропускная способность Расчеты полосы пропускания / Настольный телефон -> OPUS - 70 кбит/с Количество одновременных вызовов * 70 кбит/с = Требуемая пропускная способность сети / Настольный телефон -> Настольный телефон OPUS – 70 кбит/с Количество одновременных вызовов * 70 кбит/с = Требуемая пропускная способность сети / Настольный телефон -> PSTN через LGW G.711 – 80 кбит/с Количество одновременных вызовов * 80 кбит/с = Требуемая пропускная способность сети / Настольный телефон -> Телефонная сеть общего пользования (PSTN) через облачную сеть PSTN (например, тарифный план Cisco) G.711 – 80 кбит/с Количество одновременных вызовов * 80 кбит/с = Требуемая пропускная способность сети / Настольный телефон -> Предприятие через LGW G.722 – 80 кбит/с Количество одновременных вызовов * 80 кбит/с = Требуемая пропускная способность сети / Настольный телефон -> голосовая почта OPUS – 70 кбит/с Количество одновременных вызовов * 70 кбит/с = Требуемая пропускная способность сети Суммируя требуемую пропускную способность сети для каждого типа вызовов, можно определить общую потенциальную потребность в пропускной способности для конкретного объекта.
Все линии связи всегда подключены к SBC доступа. Для определения необходимой пропускной способности интернета в любом конкретном месте необходимо учитывать не только межлокационные звонки, но и внутрилокационные звонки, а также звонки к локальному шлюзу в этом месте и от него. Например, для внутрисайтового вызова между двумя MPP-телефонами потребуется до 2 x 70 кбит/с в полнодуплексном режиме через интернет-соединение в данном месте.
В таблице Примеры расчета пропускной способности Webex Calling приведен пример полного расчета пропускной способности при условии, что все устройства находятся в одном месте.
Таблица 3. Примеры расчета пропускной способности Webex Calling Типы вызовов Количество одновременных вызовов Общая пропускная способность Приложение Webex / Настольный телефон → Приложение Webex 15 2 * 15 * 70 кбит/с = 2100 кбит/с Приложение Webex / Настольный телефон → Настольный телефон 15 2 * 15 * 70 кбит/с = 2100 кбит/с Приложение Webex / Настольный телефон → Телефонная сеть общего пользования через LGW 50 2 * 50 * 80 кбит/с = 8000 кбит/с Приложение Webex / Настольный телефон → Телефонная сеть общего пользования (PSTN) через Cloud Connect для звонков Webex 0 0 * 80 Кбит/с Приложение Webex / Настольный телефон → Корпоративный телефон через LGW 15 2 * 15 * 80 кбит/с = 2400 кбит/с Приложение Webex / Настольный телефон → Вызов Webex Голосовая почта 5 5 * 70 кбит/с = 350 кбит/с Общее количество звонков / Пропускная способность 100 звонков 14 950 кбит/с / 14,95 Мбит/с -
Все значения пропускной способности в приведенных выше таблицах относятся к пропускной способности IP-сети. Пропускная способность канала связи выше в зависимости от инкапсуляции WAN.
-
В таблицах выше указана пропускная способность для аудиозвонков. Для обеспечения пропускной способности видеозвонков используются приложение Webex и MPP. 8845/65 Телефоны поддерживают видео в формате H.264 с максимальным разрешением 720p и максимальной пропускной способностью 1500 кбит/с на один звонок. Однако объем потребляемой полосы пропускания в любой момент во время звонка будет колебаться в зависимости от переменной скорости передачи данных, присущей видеосвязи.
-
-
Качество обслуживания (QoS)
Внедрите политики QoS в вашей локальной среде для приоритезации трафика в реальном времени и обеспечения поддержания QoS на коммутаторах, маршрутизаторах и межсетевых экранах.
-
Целевые показатели задержки, дрожания и потери пакетов.
Для обеспечения оптимального качества голосовой связи при звонках через OTT-сервисы и интернет рекомендуются следующие пороговые значения:
-
Задержка — менее 100 мс в одну сторону.
-
Джиттер - менее 10 мс
-
Потеря пакетов — 0,5% или менее.
-
-
Межсетевой экран и NAT
Убедитесь, что брандмауэр настроен на разрешение трафика, указанного в статье, доступной по адресу Информация о портах для вызовов Webex. Кроме того, разрешите доступ к доменам и диапазонам IP-адресов, указанным в том же руководстве, и избегайте использования SIP ALG, поскольку он мешает передаче сигналов SIP. Следует избегать передачи медиаконтента через прокси-серверы.
-
DNS и NTP
Обеспечьте корректное разрешение DNS-запросов для доменов и надежные NTP-серверы для синхронизации часов устройств в целях проверки TLS-сертификатов и ведения журналов.
-
Планирование аварийного переключения
Учитывайте существующие каналы передачи данных провайдера (MPLS, SD-WAN и т. д.) и, как правило, планируйте прямой доступ в Интернет в каждом месте развертывания. В местах, где требуется высокая доступность, следует предусмотреть резервные каналы связи. Поскольку вы будете использовать облачные сервисы, надежное интернет-соединение с достаточной пропускной способностью является базовым требованием. Вам следует пересмотреть решение о переходе на этот формат, если интернет-соединение в ваших подразделениях, как правило, ненадежно, не имеет низкой задержки и достаточной пропускной способности как при передаче данных, так и при отдаче.
-
живучесть участка
Устойчивость сайта гарантирует постоянную доступность вашего бизнеса, даже если ваше сетевое соединение прервется. Функция Site Survivability использует шлюз в вашей локальной сети для обеспечения резервного вызова конечных устройств на месте в ситуациях, когда сетевое соединение обрывается. Если для обеспечения бесперебойной работы сети необходимы непрерывные звонки в случае сбоя сети, следует рассмотреть возможность использования локального шлюза обеспечения отказоустойчивости (SGW) для повышения отказоустойчивости сайта. Для получения дополнительной информации о проверке отказоустойчивости сайта см. Отказоустойчивость сайта для звонков Webex.
Настройка унифицированных коммуникаций через облако
Cloud Connected UC (CCUC) — это облачное решение для управления и аналитики, предназначенное для обеспечения централизованного контроля, администрирования и получения информации о развертываниях как в локальной среде (например, Unified CM), так и в облаке. Он выступает в качестве моста между традиционными локальными средами и облачными сервисами Cisco, поддерживая организации на протяжении всего процесса миграции с одной системы на другую.
В процессе перехода на новую систему CCUC играет важнейшую роль в оптимизации процесса миграции, содействуя сбору исчерпывающих данных из существующей системы унифицированных коммуникаций. CCUC оказывает помощь в решении ключевых задач по переходу, таких как миграция устройств, функций и контактов пользователей, а также автоматизация обновлений прошивки для поддерживаемых IP-телефонов. Благодаря централизованному управлению и отслеживанию данных, CCUC помогает обеспечить более плавный и эффективный процесс миграции.
Компания Cisco настоятельно рекомендует развертывать CCUC на ранних этапах проекта перехода, в идеале — до или во время подготовительной фазы. Это позволит получить необходимые знания и возможности для тщательной оценки, инвентаризации и планирования последующих миграционных мероприятий, а также для начала вашего пути к гибридным возможностям и их дальнейшего развития.
Оценка текущей ситуации
Ключевым этапом планирования миграции является оценка текущей локальной среды и развертывания. Это позволяет понять, какие потенциальные изменения могут потребоваться для успешного перехода к . Это также позволяет оценить ключевые элементы платформы в сравнении с существующей локальной инфраструктурой. Вы можете использовать эту информацию, чтобы определить, какие конкретные задачи необходимы для перехода, и какие изменения вы хотите внести, чтобы удовлетворить ваши бизнес- и технические требования, а также сценарии использования.
В рамках этой работы важно рассмотреть следующие аспекты.
Лицензирование
Понимание текущей структуры лицензирования существующей системы имеет ключевое значение при подготовке к миграции на новую. Проведите оценку лицензирования следующих областей вашего существующего локального решения Cisco.
-
Платформа
Умение четко сформулировать, что в настоящее время лицензировано на вашей основной платформе, будет иметь решающее значение при работе с вашей командой по работе с клиентами или партнером для определения оптимального пути к гибкому лицензированию. Лицензирование осуществляется с использованием гибкого лицензирования. Для получения дополнительной информации о гибком лицензировании см. гибкий план сотрудничества Cisco.
-
Пользователи и устройства
Определите, какая категория лицензии требуется вашим существующим пользователям и устройствам. Это будет использоваться для определения типа лицензии, необходимой для пользователей и устройств. Предлагается несколько типов лицензирования, включая профессиональные и стандартные лицензии для пользователей, а также профессиональные лицензии и лицензии для общих зон рабочих мест. Для получения дополнительной информации о лицензировании устройств см. техническое описание, доступное по адресу Лицензирование устройств.
-
Локальный шлюз
Если для обеспечения доступа к телефонной сети общего пользования (PSTN) в рамках данного перехода требуется Cisco Unified Border Element (CUBE), необходимо также рассмотреть вопрос лицензирования CUBE. Вопросы лицензирования CUBE рассматриваются далее в этом документе.
Locations/Sites
При планировании этого перехода следует учитывать количество и типы площадок (крупные центральные, региональные, филиальные и т. д.) в рамках существующей системы. Полное понимание существующих площадок развертывания поможет в стратегическом планировании успешного перехода, особенно в части определения того, какие площадки следует перенести и в каком порядке. При принятии решений о миграции крайне важно детально понимать требования к плану набора номера (нумерация, привычки набора номера, классы ограничений и т. д.), возможности подключения к сети и пропускную способность (Интернет, WAN, LAN), а также доступ к телефонной сети общего пользования (локальный или централизованный, IP или TDM) для каждого объекта. Для получения дополнительной информации о распространенных моделях развертывания и ключевых моментах см. информацию о моделях развертывания для совместной работы, доступную в Collaboration SRND.
Еще одним важным фактором при переходе на новую технологию является доступность по местоположению. Она обладает различными возможностями, подписками и устройствами, доступными в зависимости от местоположения вашей системы. Для получения дополнительной информации о географической доступности см. Где доступен Webex?.
Наконец, важно понимать, какое влияние переход окажет на другие сервисы для совместной работы. Исходя из цели данного документа, предполагается, что если необходимо сохранить существующие сервисы для совместной работы вне контекста телефонных звонков, то ожидается переход к описанной выше гибридной фазе 1. Примерами сервисов для совместной работы, которые могут потребовать гибридного развертывания, являются локальные контакт-центры, еще не переведенные на Webex Contact Center, а также тесная интеграция с такими системами, как системы оповещения и выставления счетов. Для получения дополнительной информации о переносе дополнительных рабочих нагрузок и сервисов для совместной работы см. Переносы в рамках совместной работы.
Имеющийся инвентарь devices/clients
Перед началом перехода важно провести инвентаризацию имеющегося у вас оборудования и программного обеспечения. Наличие полного списка устройств types/models, Версии оборудования, типы и количество программных клиентских ОС позволят вам адекватно спланировать переход устройств на облачные вызовы и смягчить последствия для тех устройств, которые невозможно перевести в облако. Инвентаризация должна использоваться для определения устройств, подлежащих переходу на новые модели, и устройств, подлежащих замене, до начала перехода.
Настольные телефоны
Для аудио- и видеостационарных телефонов поддерживаются только телефоны серий 6800, 7800, 8800 и 9800. Это подмножество IP-телефонов Cisco, которые поддерживаются данной технологией. Некоторые модели и версии телефонов 6800, 7800 и 8800 несовместимы с этим устройством. Для получения дополнительной информации о поддерживаемых моделях и версиях оборудования см. Поддерживаемые устройства для Webex Calling.
IP-телефоны серии Cisco 6800 нельзя обновить с версии Enterprise до версии Multiplatform (MPP), которая необходима для их работы. Поэтому все телефоны серии 6800, зарегистрированные для работы с корпоративной прошивкой, должны быть заменены на модель 6800 MPP или на другую поддерживаемую модель телефона.
Перед переходом на новую систему и регистрацией IP-телефонов Cisco серий 7800 и 8800 необходимо обновить до прошивки Multiplatform Phone (MPP). Чтобы определить, какие модели и версии оборудования 7800 и 8800 поддерживают прошивку MPP, см. Преобразование IP-телефонов Cisco серий 7800 и 8800 между версиями прошивки Enterprise и MPP.
Модели 8845, 8865 и 8865NR сняты с продажи, и их перенос на новую платформу не рекомендуется.
Более старые версии телефонов серии 8800 (8811, 8841, 8851, 8851NR, 8861) не рекомендуется использовать с Webex Calling. Телефоны с аппаратными версиями VID 14 или более ранними будут регистрироваться, но могут испытывать некоторые проблемы с производительностью из-за аппаратных особенностей.
Настольные телефоны серии 9800 работают под управлением PhoneOS, которая поддерживает как регистрацию, так и другие функции. Таким образом, переход на эти телефоны возможен без обновления прошивки.
Все остальные IP-телефоны необходимо заменить на телефоны серий 6800, 7800, 8800 или 9800, поддерживаемые Webex Calling. Для получения дополнительной информации о поддерживаемых IP-телефонах и стационарных телефонах см. статью по адресу Поддерживаемые устройства для вызовов Webex.
Видеотерминалы
Персональные и комнатные видеотерминалы, включая серии Cisco Board, Room и Desk, могут изначально регистрироваться по протоколу SIP. Любая из этих конечных точек, которой необходимо передавать звук. and/or Для совершения звонков по телефонной сети общего пользования (PSTN) требуется лицензия на осуществление звонков:
-
Для использования общих устройств в конференц-залах, переговорных комнатах и т. д. требуется лицензия Professional Workspace или Workspace.
-
Для использования личного устройства конечного пользователя требуется профессиональная или стандартная лицензия.
Определите, сколько видеотерминалов зарегистрировано и используется для совершения аудиозвонков. Вполне возможно, что некоторые видеотерминалы могут использоваться только для присоединения к совещаниям или совершения видеозвонков по протоколу SIP. В любом случае, конечные устройства все равно должны быть переведены на новую платформу до вывода серверов из эксплуатации, однако это поможет определить, скольким из них потребуются лицензии для продолжения совершения телефонных звонков.
-
При переносе видеоустройств из режима регистрации в облачную среду, URI для этих конечных точек изменится, поскольку теперь они зарегистрированы в облаке.
-
Телефоны моделей 8845, 8865 и 8875 — это персональные видеотелефоны, поддерживаемые различными технологиями.
Мягкие клиенты
Это единственный поддерживаемый программный клиент, в отличие от Unified CM, который поддерживает как приложение Webex, так и Jabber, и является новым программным клиентом по умолчанию для конечных пользователей.
В зависимости от режима(ов) развертывания Jabber (только для обмена мгновенными сообщениями, только для телефонов, and/or (полные режимы UC), вам также может потребоваться рассмотреть переход на новые режимы обмена сообщениями. and/or Перенос рабочих нагрузок по проведению совещаний из Jabber в . Его можно развернуть в режиме только для телефона, если он будет использоваться только как клиент для звонков, или в режиме полного пакета Webex Suite, если требуются другие рабочие нагрузки, например, Webex Messaging. and/or Совещания Webex переводятся в приложение с возможностью совершения звонков.
Это улучшает пользовательский опыт за счет предоставления таких функций искусственного интеллекта, как... audio/video сбор разведывательной информации, расшифровка телефонных разговоров и другие услуги. Подробности см. в https://www.webex.com/all-new-webex.
Прежде чем переводить пользователей на новую платформу, вам необходимо перевести их Jabber-клиенты на новую платформу. У вас есть два варианта завершения этого перехода.
-
Прежде чем перевести их на
-
Когда вы переводите их в .
Для облегчения первоначального перехода рекомендуется использовать вариант 1 и перевести пользователей на платформу, предварительно вызвав соответствующую функцию. Это даёт пользователям время ознакомиться с новым приложением, пока они ещё используют существующую локальную платформу для телефонных звонков. Когда вы будете готовы перевести пользователей на эту платформу, вам нужно будет настроить их для регистрации на платформе облачных звонков.
Для получения дополнительной информации об этих двух вариантах см. Миграционный путь — один или два шага?.
Полный список поддерживаемых устройств см. в Поддерживаемые устройства для Webex Calling.
Проверьте соответствие устройства требованиям.
Как уже упоминалось ранее, поддерживается лишь часть IP-телефонов Cisco, а для телефонов серий 7800 и 8800 требуется другой тип прошивки. На телефонах Unified CM используется корпоративная версия прошивки, а на телефонах Phones — многоплатформенная версия прошивки (MPP). Рекомендуется проверить, какие зарегистрированные телефоны подходят для обновления до прошивки MPP на этапе подготовки. Это даст вам время заменить неподходящие телефоны на одну из поддерживаемых моделей или определить альтернативный план, например, перевести пользователя только на приложение Webex.
Для определения соответствия телефонов требованиям, в Control Hub есть встроенный инструмент под названием Перенесите свой телефон на Webex Calling. При использовании этого инструмента для проверки соответствия устройства требованиям выберите опцию «Миграция » «Сгенерировать только лицензию для устройства» .
Эта опция позволяет загрузить CSV-файл со списком телефонов, чтобы проверить соответствие каждого телефона требованиям. Выбрав этот вариант миграции, вы не добавите телефоны, поскольку вы все еще находитесь на этапе подготовки и пока не готовы к этому. Для получения дополнительной информации см. Перенос телефона на Webex Calling .
Возможно, некоторые телефоны вернутся с пометкой « Неизвестно » о соответствии требованиям. Как правило, это происходит из-за невозможности проверить некоторую информацию о телефоне в серверной системе. Для телефонов со статусом Неизвестно у вас есть два варианта проверки возможности обновления до прошивки MPP.
-
Вручную проверьте каждый телефон и подтвердите модель и версию аппаратного обеспечения (PID VID).
7800/8800 Наклейка на телефон с информацией о модели и версии оборудования. -
Воспользуйтесь инструментом проверки готовности IP-телефонов Cisco.
Загрузите инструмент по ссылке https://github.com/joemar2/mpp_readiness_check.
Данный инструмент не является официальным инструментом Cisco и не поддерживается службой технической поддержки Cisco (TAC). Поддерживается по мере возможности, но пользоваться им можно бесплатно.
Данный инструмент необходимо запускать на локальном компьютере, имеющем доступ к серверам и IP-телефонам. В программе предусмотрена возможность включения веб-доступа на IP-телефонах, что рекомендуется и необходимо для достижения наилучших результатов. Поэтому его следует использовать в нерабочее время, чтобы избежать неудобств для конечных пользователей. Результатом работы инструмента является отчет, в котором перечислены телефоны серий 7800 и 8800, которые могут быть обновлены до прошивки MPP. Поскольку он напрямую обращается к телефону, он может проверить Неизвестные устройства, о которых сообщил инструмент Control Hub.
Отчет инструмента проверки готовности IP-телефонов Cisco
Пользователи
Одним из важнейших подготовительных этапов для успешной миграции является правильная настройка учетных записей пользователей. Даже при поэтапной миграции необходимо тщательно спланировать работу со всеми пользователями. Для доступа к сервису необходимо предварительно зарегистрировать пользователей по одному из следующих параметров:
-
Развертывание с помощью вызова
-
Развертывание с помощью
-
Настройка служб для пользователя
-
Чтобы пользователи могли быть найдены в телефонном справочнике (функция «звонок одним щелчком», контактная информация пользователя, поиск по телефонному справочнику).
Рекомендуется регистрировать всех пользователей до начала или в начале проекта. Это включает пользователей, которые по-прежнему используют Unified CM в качестве платформы для звонков, независимой от используемого ими устройства для звонков (IP-телефон, Jabber и т. д.). По мере миграции пользователей на (and/or Вы обновите их лицензии, чтобы включить необходимые им услуги. Предварительная настройка всех корпоративных пользователей, осуществляющих звонки, перед началом перехода позволяет пользователю, перешедшему на другую платформу, искать в каталоге корпоративного пользователя, осуществляющего звонки, который все еще использует Jabber. and/or на . Это гарантирует, что пользователи, перешедшие на новую систему, смогут найти контактную информацию любого другого пользователя и позвонить ему, используя справочник.
На рисунке поиск по каталогу показан пример поиска пользователем другого пользователя. В результатах поиска отображается контактная информация пользователя, и они могут относиться как к пользователю, который все еще использует Jabber, так и к пользователю, который перешел на другой фреймворк. and/or .
Далее определите, на какого из существующих локальных пользователей, осуществляющих звонки, будет осуществлен переход. Если планируется перевод всех или значительной части пользователей, рекомендуется перемещать пользователей группами, чтобы обеспечить возможность команде проекта, ИТ-персоналу и сотрудникам службы поддержки справиться с процессом перехода и любыми возникающими проблемами. Также следует выделить время на предоставление первоначальной информации и проведение обучающих сессий, чтобы подготовить пользователей к этому переходу. Группировка пользователей по этапам перехода может осуществляться на основе различных критериев, включая местоположение или место работы, к которому привязаны пользователи, их отделы или даже типы пользователей (специалисты по интеллектуальному труду, руководители, мобильные сотрудники и т. д.).
Например, если пользователи в рамках развертывания распределены по трем основным площадкам: Нью-Йорк (NYC), Сан-Франциско (SFC) и Исследовательский треугольный парк (RTP), то план перехода пользователей может выглядеть так, как показано в таблице План перехода пользователей по площадкам.
| Пользовательский сайт / расположение | Предпереходные информационные и обучающие сессии | Переходный период | Поддержка после перехода |
|---|---|---|---|
| Нью-Йорк (1525 пользователей) | Неделя с 1 апреля | 15 апреля – 27 апреля | Неделя с 29 апреля |
| Сан-Франциско (1600 пользователей) | Неделя с 6 мая | 20 мая – 31 мая | Неделя 3 июня |
| RTP (1275 пользователей) | Неделя 3 июня | 17 июня – 28 июня | Неделя с 1 июля |
Ещё одним важным фактором является одновременный переход пользователей, имеющих взаимные зависимости. Это может включать, помимо прочего, следующее:
-
мониторинг BLF
-
Та же охота pilot/group
-
Поделиться линиями
-
Входит в одну группу обработки звонков.
-
Используя те же номера колл-центра
-
Внутренняя связь
-
Admin/Exec.
Вы можете просмотреть конфигурацию (через графический интерфейс или экспорт) или использовать инструмент Migration Insights для определения групп пользователей, имеющих эти зависимости.
Подключение по сети PSTN
Доступ к телефонной сети общего пользования (PSTN) можно получить тремя способами: Тарифные планы Cisco для телефонной связи, Cloud Connect для (ранее Cloud Connected PSTN) и локальной телефонной сети общего пользования (локальный шлюз). Однако, как определено в данном документе, одному местоположению может быть назначен только один вариант телефонной сети общего пользования (PSTN).
Внедрение локальной телефонной сети общего пользования (PSTN) с локальным шлюзом (LGW) является важным компонентом стратегии перехода. Это обеспечивает связь между локальными развертываниями. and/or Платформа PSTN поддерживает как контроллеры граничных сессий (SBC) Cisco, так и сертифицированные сторонние контроллеры, которые могут использоваться в качестве локального шлюза. Актуальный список поддерживаемых SBC см. в Список поддерживаемых SBC.
Поддерживает до 250 одновременных вызовов с одного локального шлюза на основе регистрации и более 250 одновременных вызовов с одного локального шлюза на основе сертификата. Локальные шлюзы на основе сертификатов могут поддерживать до 6500 одновременных вызовов, но это зависит от типа подключения локального шлюза (Over-the-Top или межсетевое соединение) и модели SBC, на которой развернут локальный шлюз. Эти ограничения, по сути, представляют собой лимит по умолчанию как для локальных вызовов по телефонной сети общего пользования (PSTN) через шлюз, так и для межсайтовых вызовов между конечными точками. Для получения дополнительной информации см. Начало работы с локальным шлюзом.
Любые звонки, превышающие этот лимит, отклоняются с ошибкой 403 Forbidden. Команду show call active voice можно запустить на локальном шлюзе в любой момент времени, чтобы определить общее количество активных вызовов.
Плохие сетевые условия между локальным шлюзом и SBC доступа могут ограничивать производительность сигнального соединения, что приводит к еще более низкому лимиту одновременных вызовов. Односторонняя задержка между локальным шлюзом и центром обработки данных не должна превышать 100 мс, а дрожание сигнала должно быть менее 10 мс, при этом потеря пакетов должна быть менее 0,5. %.
Функции & использование функций
При оценке текущей среды важно определить и проанализировать, какие функции настроены. Кроме того, важно понимать, как используются эти функции, чтобы вы могли (пере)определить свои бизнес- и технические требования к развертыванию.
Чтобы определить, какие функции настроены, проанализируйте конфигурацию. Это всё статические данные, которые устанавливаются при настройке функции или параметра в системе. Для проведения этого анализа можно использовать следующие параметры:
-
Проверьте настройки в административном интерфейсе.
-
Экспорт конфигурации — массовый экспорт или AXL
-
Инструмент анализа миграции (рекомендуется)
-
Инструменты сторонних партнеров Cisco (рекомендуется).
Для эффективного анализа использования функций системы необходимо изучать динамические данные, такие как использование, регистрации и активность звонков. Различные аналитические инструменты и панели мониторинга предоставляют информацию об этих показателях, позволяя получить всестороннее представление о производительности и пропускной способности системы, что способствует принятию обоснованных решений в процессе миграции и оптимизации. Для проведения такого рода анализа можно использовать следующие параметры:
-
Анализ исходных записей CDR
-
Обзор данных Unified CM RTMT
-
Инструмент анализа миграции на основе данных CDR
-
Обзор аналитики унифицированных коммуникаций, подключенных к облаку.
-
Объем звонков
-
Зарегистрированные конечные точки
-
(CAC) местоположения
-
Использование магистральных линий связи.
-
-
Инструменты сторонних партнеров Cisco.
Компания Cisco рекомендует начать этот анализ с инструмента Webex Control Hub Migration Insights. Вам потребуется импортировать в инструмент экспортированный файл .TAR и файлы Unified CM CDR (необязательно, но необходимо для анализа использования функций). Инструмент сгенерирует следующие CSV-отчеты, которые можно использовать для начала анализа:
| Название отчета Описание отчета |
|---|
| ImportedDataBulk.csv Все пользователи и устройства из данных Unified CM |
| DeviceEligibility.csv Определяет устройства, подходящие для перехода на Webex Calling (IP-телефоны, устройства Room OS, ATA-адаптеры и устройства сторонних производителей). |
| DevicePoolNumbers.txt Список всех номеров в конкретном пуле устройств. |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Подробная информация об устройствах и пользователях, которые следует переносить вместе на основе конфигурации общих линий, пилотного вызова, очереди вызовов, парковки вызовов и группы перехвата вызовов. |
| HuntGroupMigrationInsight.csv Подробная информация о назначенных линиях охоты, группах линий и связанных с ними агентах. |
| SharedlineGroupMigrationReport.csv Обзор того, как телефонные номера (номера телефонных справочников) передаются между пользователями. |
| Название отчета Описание отчета |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Информация о возможности переноса устройства в зависимости от использования функций. |
| FeatureUsageWithLastUsageDateReport.csv Количество обращений к пилоту(ам) и в очередь(ы) вызовов, а также дата последнего использования. |
| UserWorkspaceLastUsage.csv Дата последнего использования для пользователей и рабочих пространств как для программных клиентов, так и для аппаратных телефонов. |
| DIDUsageReport.csv Использование DID-номеров как для назначенных, так и для неназначенных DID-номеров. |
Более подробную информацию об отчетах Migration Insights см. в Migration insights.
Если после ознакомления с информацией в отчетах Migration Insights вам потребуется дополнительная информация о функциях и использовании, Cisco рекомендует рассмотреть один из инструментов миграции от сторонних партнеров Cisco. and/or Для просмотра настроек в графическом интерфейсе пользователя или в данных экспорта конфигурации.
Интеграция с продуктами Cisco: Unity Connection UCCX UCCE
Голосовая почта является неотъемлемой частью предложения и изначально встроена в решение. Не может быть интегрирована с локальными решениями для голосовой почты, такими как Unity Connection или Unity Connection Express. Кроме того, отсутствует встроенная функция переноса существующих сообщений или приветствий голосовой почты Unity Connection в собственную службу голосовой почты, доступную в Unity Connection. Некоторые инструменты миграции, предлагаемые сторонними партнерами Cisco, обладают возможностями для переноса части этих данных. Для получения дополнительной информации о голосовой почте см. Настройка и управление параметрами голосовой почты для пользователя Webex Calling.
Также поддерживаются общие почтовые ящики для голосовой почты и факсов. Для получения дополнительной информации см. Управление общей голосовой почтой и входящими факсами для Webex Calling.
Встроенная функция автоматического секретаря входит в состав базовой платформы. Эта функция позволяет осуществлять переход от одной системы обработки вызовов к другой и использовать функции автоматического секретаря в Unity Connection. Инструмент Control Hub, Перенос функций из Unified CM, поддерживает перенос конфигураций Unity Connection в автоответчики. Для получения дополнительной информации об использовании этого инструмента см. Миграция устройств и функций из Unified CM в Webex Calling.
Запись вызова
Включает две опции записи разговоров без дополнительной платы.
-
Запись звонка Webex
-
Запись через Dubber Go (партнерское предложение) — интеграция между Dubber и Dubber, благодаря которой все записанные медиафайлы надежно хранятся в облаке.
включенные параметры записи в таблице выделены некоторые ключевые особенности двух вариантов записи звонков, доступных без дополнительной платы.
| Webex | Даббер Го |
|---|---|
| Доступно всем пользователям | Доступно всем пользователям |
| Неограниченное количество записей | Неограниченное количество записей |
| Срок хранения: 1 год* | 30-дневный срок хранения |
| 100 ГБ хранилища на организацию | - |
| Сотрудники, ответственные за соблюдение нормативных требований, могут получать доступ к записям телефонных разговоров и управлять ими. | - |
| API для управления записями | - |
Администраторы могут настраивать и управлять доступом пользователей к записям их телефонных разговоров.
|
Доступ к своим записям и управление ими имеют только пользователи.
|
Если вашей организации требуются дополнительные возможности записи, такие как запись звонков для обеспечения соответствия требованиям, более длительные сроки хранения, больший объем хранилища, анализ с помощью ИИ, and/or Доступ администратора, платные предложения или дополнительные модули доступны как от Cisco, так и от сторонних поставщиков услуг записи. Для получения дополнительной информации о поставщиках услуг записи, настройках и дополнительных партнерских сервисах см. Управление записью звонков для Webex Calling.
Интеграция со сторонними сервисами
Поддерживает различные интеграции состоронними сервисами, включая, помимо прочего, одноплатные компьютеры (SBC ) для локальных шлюзов, IP-телефоны, домофоны. Speaker/Pagers, АТА и т. д. Помимо этихсторонних устройств, Webex Calling поддерживает различные сторонние решения для поддержки клиентов, аналитики, записи, выставления счетов и т.д . Для получения дополнительной информации о решениях стороннихразработчиков см .Webex App Hub.
Планирование
План проекта высокого уровня
При разработке высокоуровневого плана проекта миграции с одной платформы на другую крайне важно установить четкие этапы и контрольные точки, которые соответствуют как бизнес-целям, так и техническим требованиям. Разработка плана должна начинаться с всесторонней оценки, включающей сбор подробных технических и деловых требований, а также определение заинтересованных сторон и критериев успеха. Ключевые аспекты включают распределение ресурсов, оценку сроков, управление рисками и коммуникационные стратегии для обеспечения информированности и вовлеченности всех сторон на протяжении всего процесса миграции. Кроме того, план должен включать контрольные точки проверки, такие как пилотное тестирование и поэтапное внедрение, чтобы минимизировать сбои и позволить вносить корректировки на основе обратной связи.
Примеры элементов, которые следует включить в план проекта:
-
Определение масштаба миграции (например, какие пользователи, устройства и функции будут перенесены).
-
Планирование обучающих сессий для конечных пользователей и групп поддержки.
-
Координирование оценок готовности сети и
-
Планирование мероприятий по переходу на новую систему с учетом резервных вариантов. Также важно включить в процесс проверки на соответствие нормативным требованиям и безопасности, а также этапы поддержки и оптимизации после миграции.
При разработке плана проекта с учетом этих соображений организации могут лучше управлять сложностью, снижать риски и обеспечивать более плавный переход к следующему этапу.
Миграционный процесс — один или два шага?
требует от пользователей использования этого программного клиента для совершения звонков. Таким образом, если какие-либо пользователи все еще используют , у вас есть два варианта, когда вы можете перевести их на . Вы можете выполнить миграцию пользователей в один этап или в два этапа.
Вариант 1: Миграция пользователей в один шаг
При одноэтапной миграции пользователи переходят из одной системы в другую одновременно с переходом из Unified CM в другую. Этот вариант обычно подходит для клиентов с небольшим количеством пользователей, которым необходимо перенести систему, и позволяет одновременно перенести как программный клиент, так и службу связи пользователя. Рисунок Сервис вызова пользователя, программный клиент & Телефон переходит на другой номер одновременно Ниже показан пример такого типа миграции. При выборе этого варианта пользователь сможет выполнить все следующие действия одновременно:
-
Службы связи переместились с на
-
Номера телефонов и добавочные номера перенесены с на
-
Клиентское ПО перешло с Jabber на — будет регистрироваться.
-
Регистрация по телефону перенесена с на .
Это по-прежнему может быть поэтапная миграция, при которой группы пользователей перемещаются в разное время, но при перемещении каждого пользователя все эти процессы происходят одновременно.
Вариант 2: Двухэтапная миграция пользователей
Другой подход — это двухэтапная миграция. На первом этапе пользователи переходят из одного приложения в другое, но остаются подключенными для совершения звонков. Затем на шаге 2 пользователи перемещаются из Unified CM в . Этот вариант рекомендуется для крупных клиентов, которым необходимо управлять изменениями, вносимыми конечными пользователями, и которые хотят отделить изменения в программном клиенте пользователя от изменений в вызывающей службе. На следующем рисунке выполнена миграция программного клиента; затем выполнена миграция службы вызовов и программного клиента. & Переход с телефона на Webex Calling ниже иллюстрирует этот тип миграции.
Этап 1
-
Программный клиент перешёл с на - будет зарегистрирован в .
Этап 2
-
Службы связи перенесены с на .
-
Номера телефонов и добавочные номера перенесены с на .
-
Регистрация перенесена с на .
-
Регистрация по телефону перенесена с на .
Это по-прежнему может быть поэтапная миграция, при которой группы пользователей перемещаются в разное время на обоих этапах.
Выбор варианта зависит от того, как вы хотите организовать переход пользователей на новый и новый интерфейс. Рекомендуется делать это поэтапно (Вариант 2). Это позволяет свести к минимуму изменения, вносимые конечным пользователем за один раз, и распределить усилия между различными частями проекта. Однако, если вы предпочитаете, чтобы изменения затронули пользователей только один раз, то вариант 1 также допустим.
Рассматривая рекомендуемый путь (Вариант 1), Схема перехода высокого уровня от Jabber к приложению Webex на рисунке ниже показана схема перехода высокого уровня для Шага 1.
На этом этапе пользователи переходят с Jabber на другие сервисы для совершения звонков. Однако в качестве платформы для звонков по-прежнему используется Unified CM, и она зарегистрирует свои сервисы звонков в . Как показано на схеме перехода от Jabber к Webex App высокого уровня, локальная инфраструктура не меняется, и приложение работает так же, как и Jabber. Единственное изменение заключается в том, что требуется установить соединение с .
Для получения дополнительной информации об этом переходе см. Карта перехода Jabber на Webex и руководство по развертыванию в разделе «Клиент» на странице Переход к совместной работе.
Карта высокоуровневых переходов Unified CM to Webex Calling на рисунке показан высокоуровневый переход от к . Это второй шаг рекомендуемого маршрута.
Если вы решите использовать одношаговый подход, это тоже применимо.
На этом этапе пользователи переходят к работе в группах. На этом этапе пользователи начинают использовать эти сервисы для совершения звонков, регистрации звонков и регистрации IP-телефонов.
Поскольку пользователи переходят группами, в течение переходного периода пользователи Enterprise будут распределены между двумя платформами для звонков. Этап 1 в Карта перехода высокого уровня Unified CM к Webex Calling на рисунке изображено это состояние. На этом этапе необходимо спланировать, как управлять звонками между пользователями на двух платформах и как будут маршрутизироваться звонки в телефонную сеть общего пользования (PSTN). При каждом переходе группы пользователей на новую платформу потребуется обновление планов набора номера и маршрутизации вызовов на устройствах и локальном шлюзе (шлюзах).
После того, как все пользователи, программные клиенты и устройства будут переведены на (фазу 2), всю локальную инфраструктуру унифицированных коммуникаций можно будет удалить и вывести из эксплуатации.
Проектирование
Выбор региона
Доступен по всему миру и предоставляется из резервных центров обработки данных в нескольких регионах: США (Даллас, Чикаго), Канада (Ванкувер, Торонто), Европа (Франкфурт, Амстердам), Великобритания (Лондон, Манчестер), Австралия (Мельбурн, Сидней), Япония (Токио, Осака), Саудовская Аравия (Эр-Рияд, Джидда) и Индия (Мумбаи, Ченнаи). Медиа-точки присутствия предоставляют медиа-услуги для оптимизации времени передачи медиаконтента туда и обратно. Например, сингапурский центр обработки данных используется для оптимизации времени передачи медиаданных клиентам в азиатских странах, где время передачи данных в Австралию или Японию может быть неоптимальным. Центры обработки данных соединены между собой многогигабитной и полностью резервированной магистральной сетью. На рисунке глобально распределенные центры обработки данных представлен общий обзор всех центров обработки данных. Актуальный список доступных центров обработки данных см. в Расположение центров обработки данных для Webex Calling.
Каждому клиенту предоставляется доступ к одному из экземпляров системы. Вся информация о предоставлении доступа этому клиенту хранится в этом экземпляре, а SIP-сигнализация всех конечных точек и локальных шлюзов, предоставленных этому клиенту, привязана к экземпляру, на котором предоставлен доступ клиенту. Поскольку изменить первоначальный выбор региона сложно, важно учитывать все соответствующие факторы в процессе принятия решения, ведущего к выбору региона. Чтобы избежать чрезмерной задержки передачи сигнала в обоих направлениях, важно на раннем этапе процесса перехода решить, какой экземпляр следует использовать. Компания Cisco рекомендует выбирать экземпляр, обеспечивающий наименьшее время передачи сигнала в обоих направлениях для наибольшего числа пользователей в рамках развертывания.
Информацию о доступности в разных странах см. в Где доступен Webex?.
Местоположения
Для подготовки к предоставлению информации о местоположениях необходимо собрать необходимые данные по всем целевым местоположениям для миграции. Необходимая информация для каждого местоположения суммирована в Информация, которую нужно собрать для каждого местоположения.
| Информация | Комментарий |
|---|---|
| Диапазон расширения(й) | Каждый населенный пункт может иметь добавочные номера, начинающиеся с разных цифр. Для кодового сигнала межсайтового набора необходимо оставить одну цифру (например , 8), а для кодового сигнала телефонной сети общего пользования (например , 9) — одну. Диапазон номеров не может начинаться ни с одной из этих двух цифр. Длина всех ответвлений во всех местах должна быть одинаковой. |
| Диапазон(ы) DID | - |
| цифра управления PSTN | - |
| Код сайта | Все коды сайтов во всех местах должны быть уникальными и иметь одинаковую длину. |
| Главный номер | При создании местоположения необходимо указать два DID-номера. Один номер используется как основной (например, для автоматического ответа), а другой — для портала голосовой почты. Укажите один DID-номер для голосовой почты. |
| Номер голосовой почты | |
| Количество лицензий | Требуемые лицензии по типам, включая стандартную, профессиональную, для рабочего пространства, список маршрутизации, план исходящих звонков. |
| Одновременные звонки в час пик | Сумма одновременных вызовов между устройствами, а также между устройствами и локальным шлюзом (телефонная сеть общего пользования и вызовы на устройства). Необходимо определить требуемую пропускную способность интернет-соединения. |
| Страна | - |
| Часовой пояс | - |
| Язык | - |
| Контактная информация (Имя, Телефон, Электронная почта) | - |
| Адрес (улица, город, штат, почтовый индекс) | - |
| Физическое местоположение для связи с службами экстренной помощи для конечных устройств. | К местам, доступным для вызова экстренных служб, обычно относятся следующие: адрес здания, адрес здания + номер этажа, адрес здания + номер офиса или адрес здания + номер этажа + office/cubical число. |
| Для каждого устройства предусмотрено уникальное физическое местоположение в сети для экстренных служб. | Физическое местоположение сети для экстренных вызовов обычно включает в себя следующее: выключатель / Коммутационный порт для проводных устройств, идентификаторы базового набора служб (BSSID) беспроводных точек доступа (AP) для беспроводных подключенных устройств. and/or Локальные IP-подсети для конечных устройств. |
PSTN
При проектировании развертывания у клиентов есть три основных варианта подключения к телефонной сети общего пользования (PSTN): Cisco Calling Plans (облачная услуга телефонной сети общего пользования, управляемая Cisco), Cloud Connected PSTN Providers (CCPP, где провайдеры предоставляют услуги телефонной сети общего пользования через облако) и локальная телефонная сеть общего пользования (где локальные шлюзы соединяют корпоративную сеть с телефонной сетью общего пользования). Благодаря внедрению технологии PSTN-транкинга для гибридных развертываний (подробнее см. PSTN-транкинг для гибридных развертываний Webex Calling по адресу PSTN-транкинг), организации получают дополнительную гибкость в своем подходе к миграции. Эта функция позволяет клиентам перевести свою телефонную сеть общего пользования (PSTN) на CCPP в начале процесса перехода и начать переход к облачной телефонной сети общего пользования для пользователей, используя при этом CCPP для поддержания работы телефонной сети общего пользования для пользователей, которые остаются на оборудовании Cisco во время поэтапной миграции.
Этот гибридный подход позволяет организациям сначала перевести в облако отдельные группы пользователей, не прибегая к немедленной полной перестройке всей телефонной инфраструктуры. Однако это вносит дополнительную сложность и риски, особенно в части адаптации существующей логики маршрутизации вызовов для поддержки новой архитектуры. Необходимо также тщательно продумать совместимость с устаревшими приложениями, такими как факс-серверы, контакт-центры или системы пейджинга. Ключевые технические проблемы могут включать обеспечение бесперебойного сквозного согласования кодеков и передачи сигналов DTMF (двухтональной многочастотной сигнализации) в смешанной среде, а также проверку совместимости со специализированными функциями телефонии. Тщательное планирование и тестирование имеют решающее значение для минимизации сбоев и поддержания надежной работы голосовых сервисов на протяжении всего процесса миграции. Кроме того, важны коммерческие соображения, поскольку для гибридной транкинговой связи требуется лицензия на использование, размер которой зависит от количества одновременных вызовов между локальной средой и облачным провайдером PSTN (CCPP).
В качестве альтернативы организации могут сохранить свою локальную телефонную сеть общего пользования (PSTN) на протяжении всего переходного периода. В этом сценарии миграция на CCPP может быть выполнена двумя способами: в виде единого, скоординированного перехода для всех пользователей и местоположений после завершения миграции, или поэтапно, при этом миграция в сеть PSTN будет происходить для каждого местоположения отдельно по мере перемещения пользователей. Такой подход может помочь оптимизировать сосуществование и обеспечить непрерывность интеграции устаревших систем, но он вносит ряд операционных сложностей. Среди них – проблемы, связанные с переносом номеров, такие как необходимость точной координации заказов на перенос номеров, потенциальные задержки и ограничения, налагаемые провайдером, например, ограничение количества одновременных запросов на перенос или ограничения на перенос подмножеств больших блоков номеров. Организациям необходимо тщательно спланировать стратегию перехода на использование телефонной сети общего пользования (PSTN), учитывая эти логистические аспекты, чтобы избежать перебоев в предоставлении услуг и обеспечить плавный процесс миграции.
На рисунке Миграция на CCCP на начальном этапе против сохранения локальной сети PSTN показаны два варианта миграции на PSTN, описанные выше. Иллюстрация слева показывает сценарий, в котором все локальные пользователи и приложения используют подключенные к облаку услуги PSTN через локальный канал связи и локальный шлюз, соединяющий локальную сеть с облачной сетью. Иллюстрация справа показывает сценарий, в котором существующая локальная сеть PSTN остается на месте, и пользователи Webex Calling используют локальную сеть PSTN через соединение локального шлюза между локальной сетью и облачной сетью. В период перехода на новую систему можно будет переключиться на использование облачной сети PSTN.
В обоих сценариях звонки между локальной сетью и пользователем осуществляются через локальное соединение шлюза. Соединение между локальной системой и сервером должно быть спроектировано и рассчитано соответствующим образом, исходя из ожидаемого количества одновременных вызовов и необходимой избыточности.
Dial Plan (План набора)
Для обеспечения бесперебойной совместимости между платформами и в период миграции необходимо разработать и внедрить комплексную архитектуру плана набора номера на обеих платформах. Данная двухплатформенная схема набора номера обеспечивает согласованную маршрутизацию вызовов, преобразование номеров и прозрачность функций, позволяя пользователям обеих систем общаться без ухудшения качества обслуживания или сбоев в работе на протяжении всего периода сосуществования.
План набора номера в локальной сети
В процессе перехода, для обеспечения сосуществования устройств, зарегистрированных в Unified CM и в корпоративном плане коммутации, необходимо изменить параметры таким образом, чтобы были выполнены как минимум следующие требования:
-
+E.164 набор номера с до
-
Набор добавочного номера с/на/на (внутрисайтовый, а также межсайтовый, если диапазоны добавочных номеров уникальны)
-
Сокращенный межсайтовый набор номера с до
-
Принудительный набор номера внутри сети с на
-
Обратный звонок из справочника пропущенных вызовов на указанные адреса.
-
Звонки из сети PSTN в сеть PSTN, если во время перехода используется локальная сеть PSTN.
-
Если во время перехода используется транкинг PSTN для гибридных развертываний, обеспечивающий доступ к PSTN для локальных пользователей через Cloud Connect, то вызовы из PSTN могут осуществляться в любом направлении.
-
Принудительное подключение к сети с на
-
Дозвон с одного абонента на другой (между сайтами).
Если какие-либо из вышеперечисленных способов набора номера не поддерживались до перехода, например, не существовало сокращенных способов набора номера между сайтами, то их не обязательно внедрять во время перехода.
На рисунке План набора номера в соответствии с лучшими практиками показан подход к плану набора номера в соответствии с лучшими практиками, описанный в Предпочтительная архитектура для развертывания Cisco Collaboration 12.x Enterprise On-Premises Deployments, CVD. Ключевые характеристики этого подхода включают в себя:
-
Единая перегородка для +E.164 номера справочников
-
Основная маршрутизация на основе +E.164 схемы маршрутов
-
Нормализация всех привычек набора номера для +E.164 использование шаблонов перевода
-
Использование наследования пространства поиска вызовов шаблонов трансляции (опция Использовать пространство поиска вызовов инициатора, установленное для шаблонов трансляции).
Например, набор номера по телефонной сети общего пользования (PSTN). (9+1+10D) Устройство в SJC, которому предоставлено пространство поиска вызовов линии SJCInternational, сначала будет сопоставлено с 9.1[2-9]XX[2-9]XXXXXX шаблон перевода, который нормализует номер вызываемого абонента до +E.164. Затем при вторичном поиске снова используется то же пространство поиска SJCInternational (наследование пространства поиска) и +E.164-digit строка будет либо сопоставлена с +E.164 номер каталога в разделе DN или по одному из шаблонов маршрутизации PSTN в разделе USPSTNNational или SJCPSTNLocal. Сокращенные варианты набора номера внутри и между узлами реализуются с помощью переводов в разделах ESN и SJCtoE164. В то время как раздел ESN является глобальным разделом (доступным для телефонов во всех местах), раздел SJCTOE164 доступен только для пользователей в местоположении SJC. Это предполагает перекрывающиеся диапазоны распространения.
Первый шаг для обеспечения возможности вызова из одного места в другое — убедиться, что... +E.164 Маршруты до пунктов назначения прокладываются соответствующим образом. Этого можно достичь, добавив раздел в схему набора номера, а именно: +E.164 шаблоны маршрутизации для всех пунктов назначения к этому разделу, и, наконец, добавление раздела ко всем пространствам поиска вызывающих абонентов, представляющим классы обслуживания, которые должны иметь возможность до него дотянуться. Для создания дифференцированного класса обслуживания для вызовов, исходящих из этого источника, необходимо создать отдельный раздел. Во избежание зацикливания вызовов пространство поиска входящих вызовов на транковом соединении от локального шлюза не должно иметь доступа к этому разделу.
Как показано на рисунке +E.164 маршрутизация для вызовов Webex, позволяющая осуществлять маршрутизацию из одного места в другое для определенного местоположения. +E.164 Диапазон DID +1 221 555 2XXX и код объекта 121, схема срочного маршрута, соответствующая этому. +E.164 Диапазон необходимо добавить в раздел .
Если выбор локального шлюза для конкретного сайта не требуется, то вместо использования списка маршрутов с локальной группой маршрутов в качестве пункта назначения для шаблонов маршрутизации, указывающих на одну группу маршрутов, можно настроить локальный шлюз как единственный участник, и тогда шаблоны маршрутизации будут указывать на один список маршрутов, где эта единственная группа маршрутов будет единственной записью.
Для обеспечения возможности сокращенного набора номера между узлами в раздел добавляется необходимый шаблон маршрута 8121.2XXX. Для сайтов, которые будут переведены на схему нормализации набора номера 8121.2XXX, которая нормализует набор номера ESN до +E.164 может уже существовать в разделе ESN. В этом случае 8121.2XXX кажется избыточным, но как только все номера DN соответствующего местоположения будут переведены на шаблон нормализации набора номера 8121.2XXX, шаблон маршрутизации 8121.2XXX позволит осуществлять набор номера ESN даже для пользователей, имеющих только добавочные номера, в этом диапазоне.
Благодаря этим изменениям в плане набора номера, звонки в указанное место можно совершать не только путем набора сокращенных межсайтовых номеров, но и... +E.164. Кроме того, возможен международный и национальный набор номера по телефонной сети общего пользования (PSTN), поскольку эти привычки набора номера изначально являются нормой. +E.164 через уже существующие шаблоны нормализации и преобразования набора номера, а затем маршрутизироваться путем сопоставления +E.164 Схема маршрутизации в разделе.
Он +E.164 Настройка сопоставления шаблонов маршрутизации для диапазона DID-номеров местоположения может быть выполнена, даже если все DID-номера по-прежнему размещены на сервере . Наилучший алгоритм сопоставления шаблонов гарантирует, что при наборе номера, размещенного на сервере, будет выполнено следующее: +E.164 Номер каталога, указанный при создании учетной записи, лучше соответствует запросу, чем номер с подстановочным знаком. +E.164 Шаблон маршрутизации указывает на то, чтобы вызовы распространялись на линию на и не отправлялись на .
план набора
Каждому пользователю предоставляется добавочный номер. and/or а +E.164 номер телефона. Длина удлинения — это фиксированная глобальная настройка: Все расширения в рамках одного развертывания имеют одинаковую длину. Набор добавочного номера можно использовать как между пользователями внутри одного места, так и между разными местами. Сокращенный набор добавочного номера между сайтами (последний случай) работает только в том случае, если набранный добавочный номер уникален.
Если требуется сокращенный набор номера между филиалами, но при этом происходит дублирование номеров, назначенных в разных местах, то необходимо создать корпоративный план нумерации, добавив к номерам филиалов префикс в виде кода доступа или кода филиала. Для получения дополнительной информации см. Предпочтительная архитектура для развертывания Cisco Collaboration 15 в локальной среде, обзор проектирования доступна по адресу Предпочтительные архитектуры Cisco Collaboration.
Длина добавочного номера, режим набора добавочного номера между местоположениями, длина префикса для набора номера между местоположениями и указательная цифра в маршрутном префиксе для набора номера между местоположениями настраиваются в параметрах службы вызова. :
-
Длина префикса маршрутизации местоположения: Длина префикса, включая цифру, обозначающую положение рулевого колеса. Требуется только в том случае, если необходимо разработать план корпоративной нумерации в качестве альтернативного сокращенного способа набора номера внутри компании.
-
Цифра управления в префиксе маршрутизации: Управляющая цифра для сокращенного набора номера внутри компании. Следует избегать совпадений первой цифры номера местоположения и цифр исходящего набора номера этого местоположения. Требуется только в том случае, если необходимо разработать план корпоративной нумерации в качестве альтернативного сокращенного способа набора номера внутри компании.
-
Длина внутреннего удлинения: Стандартная длина удлинителей. Может принимать любое значение от двух до десяти.
Если требуется набор добавочного номера или набор номера с использованием корпоративных значимых номеров (код управления, код объекта, добавочный номер) с локальной системы управления вызовами, и локальная система управления вызовами отправляет добавочный номер в качестве идентификатора вызывающего абонента, убедитесь также, что установлен параметр Максимальная неизвестная длина добавочного номера в разделе Маршрутизация вызовов между и объектами, чтобы гарантировать, что входящие вызовы с локальной системы управления вызовами будут корректно классифицироваться как локальные вызовы. -
Разрешить набор добавочного номера между местоположениями: Переключиться enable/disable Набор добавочных номеров между местоположениями. Эту опцию следует включать только в том случае, если все добавочные номера в организации являются уникальными. Если эта опция отключена, то для связи между подразделениями необходимо набирать важные для предприятия номера (код управления, код сайта, добавочный номер) или телефонные номера.
Первые три параметра в основном используются для построения плана набора номера на телефонах с целью минимизации тайм-аутов между цифрами при наборе номера без снятия трубки. Отклонения от этих глобальных настроек по-прежнему возможны (например, можно создавать добавочные номера другой длины), но в Центре управления появится предупреждающее сообщение, и для набора номера с телефонов может потребоваться набор номера блоками во избежание конфликтов с предварительно загруженным планом набора.
В таблице Примеры нумерации предприятий показаны три местоположения, где диапазоны добавочных номеров двух местоположений, Нью-Йорка и RTP, идентичны. Внедрение системы нумерации предприятий с межсайтовым указательным номером 8, за которым следует трехзначный код объекта и четырехзначный добавочный номер, создает непересекающуюся систему сокращенного набора номера между объектами.
| Веб-сайт | Диапазон расширения | Код сайта | Серия Enterprise |
|---|---|---|---|
| Нью-Йорк | 2XXX | 202 | 8 202 2XXX |
| Сан-Франциско | 3XXX | 203 | 8 203 3XXX |
| RTP. | 2XXX | 204 | 8 204 2XXX |
Для обеспечения плавного перехода набор привычек набора номера у пользователей до и после перехода в идеале должен оставаться неизменным. Для подготовки к переходу в каждом филиале необходимо задокументировать диапазоны номеров DID и диапазоны добавочных номеров (или сокращенные схемы набора номера внутри филиала). Исходя из этой информации, необходимо выбрать цифру для управления переадресацией между объектами.
В таблице Диапазоны расширения фиксированной длины приведен пример трех местоположений и диапазонов расширения фиксированной длины. Поскольку необходимо избегать наложения цифр при наборе номера, важно убедиться, что для любого диапазона добавочных номеров первая цифра диапазона не совпадает с управляющей цифрой для сокращенного набора номера между узлами. Если, например, в качестве управляющей цифры для межсайтового набора выбрана цифра 8, то ни один диапазон добавочных номеров на любом сайте не может начинаться с 8. Как правило, добавочные номера в данном месте соответствуют последним нескольким цифрам DID-номеров, присвоенных этому месту. Во избежание конфликтов первую цифру добавочного номера можно изменить. Если, например, DID-номера в +1 Если в определенном месте используется диапазон 408 555 8XXX, то вместо 8XXX в качестве диапазона добавочных номеров можно использовать 7XXX для добавочных номеров этого объекта.
| Веб-сайт | Диапазон расширения | Добавочные номера | Код сайта | Серия Enterprise |
|---|---|---|---|---|
| Нью-Йорк | 2XXX | 2XXX | 202 | 8 202 2XXX |
| Сан-Франциско | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP. | 1XX | 11XX | 204 | 8 204 11XX |
Семизначные наборы номера, выполняемые на устройстве, использующем американскую схему набора номера, совпадают с семизначным шаблоном для местного набора номера в предварительно загруженной американской схеме набора номера. Во избежание дублирования привычек набора номера внутри сети и вне сети (PSTN) в данном месте может использоваться обязательный код доступа для внешних звонков. Если существующая схема нумерации предприятия и соответствующая сокращенная межсайтовая нумерация совпадают с шаблонами национальной системы нумерации, то при переходе на новую схему нумерации во избежание совпадений ее можно также изменить на более длинную или короткую форму. Простейший способ добиться этого — добавить дополнительную цифру-заполнитель в схему нумерации. Новую схему более длинного межсайтового набора номера необходимо внедрить только пользователям, уже перешедшим на другую платформу. Пользователи, оставшиеся на связи, могут продолжать набирать семь цифр. В данном случае корпоративный план набора номера должен гарантировать, что сокращенный семизначный набор номера из Unified CM будет преобразован либо в один из следующих вариантов. +E.164 или к сокращенному формату набора номера, используемому на . Это необходимо сделать до отправки вызова на локальный шлюз.
В таблице Переход к семизначному набору номера приведен пример такой перенумерации. В этом примере для сокращенного набора номера между узлами используется управляющая цифра 8, за которой следует двухзначный код узла и четырехзначный добавочный номер. Чтобы избежать семизначного сокращенного набора номера между точками на карте, коды точек можно легко изменить на трехзначные, добавив произвольную цифру заполнения (8 в примере) перед двухзначными кодами точек, используемыми в карте, так что при наборе номера между точками с телефонов будет использоваться направляющая цифра 8, за которой следует цифра заполнения 8, старый двухзначный код точки и четырехзначный добавочный номер. Пользователям не нужно запоминать новые коды сайтов; им нужно лишь помнить, что для межсайтового набора номера следует использовать 88 в качестве префикса вместо 8 на .
| Веб-сайт | Добавочные номера | Код сайта | Серия Enterprise | Сайт оде | Предприятие |
| Нью-Йорк | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| Сан-Франциско | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP. | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
В сценарии с различными форматами корпоративных номеров и если корпоративные номера отображаются в качестве информации о вызывающем абоненте для звонков с одного устройства на другое (например, звонки с устройств без DID-номера), важно также реализовать сопоставление между различными форматами номеров для информации о вызывающем абоненте, чтобы обеспечить корректную работу обратного вызова. Такое сопоставление может быть достигнуто с помощью шаблона преобразования вызывающей стороны на магистральном кабеле между вызывающей стороной и локальным шлюзом.
Запись
Для создания хорошо продуманного решения для записи телефонных разговоров необходимо тщательно продумать несколько ключевых элементов дизайна, чтобы обеспечить его соответствие целям организации, нормативным требованиям и техническим ограничениям. Два из наиболее важных решений касаются выбора поставщика и выбора региона, и оба эти аспекта могут потребовать глобальной адаптации и корректировки в конкретных местах в зависимости от потребностей бизнеса.
1. выбор поставщика услуг записи телефонных разговоров
Выбор подходящего поставщика услуг записи звонков имеет основополагающее значение для достижения бизнес-целей и обеспечения согласованности функций во всей организации:
-
Глобальный выбор поставщиков: Как правило, организации назначают основного поставщика услуг записи звонков на глобальном уровне, обеспечивая единообразие набора функций, соответствия требованиям и поддержки во всех своих подразделениях.
-
Переопределение на основе местоположения: В ситуациях, когда конкретные объекты или регионы имеют уникальные деловые потребности или нормативные требования, может потребоваться отменить глобальный выбор поставщика и указать альтернативных поставщиков для этих местоположений. Такая гибкость позволяет удовлетворять различные требования соответствия и удовлетворять местные операционные потребности.
-
Бизнес-требования: Выбор поставщика услуг должен основываться на оценке таких факторов, влияющих на бизнес, как соответствие нормативным требованиям (например, MiFID II, HIPAA), обеспечение качества, разрешение споров или потребности в обучении.
-
Доступность функций: Оценивать поставщиков услуг следует на основе их способности предоставлять необходимые функции, такие как мониторинг в реальном времени, возможности поиска и воспроизведения, шифрование, политики хранения данных, интеграция с аналитическими платформами и поддержка различных типов звонков (входящие, исходящие, внутренние).
2. Выбор региона
Определение региона, где хранятся и обрабатываются записи телефонных разговоров, имеет решающее значение для соблюдения нормативных требований и повышения эффективности работы:
-
Выбор глобального региона: По умолчанию организации могут выбрать один регион для хранения записей телефонных разговоров, что упрощает управление и контроль.
-
Региональные настройки, основанные на местоположении, имеют приоритет: В случаях, когда этого требуют законы о хранении данных или корпоративная политика, может потребоваться изменить глобальные региональные настройки для конкретных местоположений, чтобы обеспечить хранение и обработку записей звонков в пределах требуемых географических границ.
-
Требования к размещению данных: При разработке необходимо учитывать международные и местные правила защиты данных (такие как GDPR, CCPA или национальные нормативные акты), которые могут определять, где и как хранятся записи телефонных разговоров.
Еще одним важным аспектом, который необходимо учитывать при планировании и проектировании решения для записи телефонных разговоров, является оценка требований к объему памяти. Точное прогнозирование потребностей в хранении данных имеет важное значение для обеспечения достаточной емкости для поддержки текущих бизнес-операций, соблюдения нормативных требований и предотвращения сбоев в предоставлении услуг.
При определении ожидаемой потребности в хранении следует учитывать несколько ключевых параметров:
-
Объем зарегистрированных звонков: Оцените предполагаемое количество звонков, которые будут зарегистрированы в течение определенного временного интервала (например, в день, неделю или месяц). Это включает в себя не только внешние звонки, но и внутреннюю коммуникацию, если это требуется в соответствии с политикой компании или нормативными требованиями.
-
Средняя продолжительность разговора: Рассчитайте типичную продолжительность записанных разговоров, поскольку более длинные разговоры занимают больше места в памяти. При составлении сметы также следует учитывать различия в продолжительности звонков в разных отделах или группах пользователей.
-
Период хранения: Определите срок хранения записей, который часто устанавливается политикой организации или внешними нормативными актами (например, отраслевыми стандартами соответствия). Увеличение сроков хранения приведет к увеличению общих требований к хранению.
-
Прогнозы роста: Учитывайте ожидаемый рост объемов звонков или расширение сферы записи, которые могут быть вызваны масштабированием бизнеса, новыми нормативными требованиями или привлечением дополнительных пользователей или филиалов.
Тщательно проанализировав эти параметры, организации могут разработать надежную стратегию хранения данных, обеспечивающую масштабируемость, экономичность и соответствие нормативным требованиям для своего решения по записи телефонных разговоров. Также рекомендуется регулярно пересматривать и корректировать распределение памяти по мере изменения характера использования с течением времени.
Экстренный вызов
Требование перенаправлять экстренный вызов в соответствующий диспетчерский центр является обязательным для любой телефонной службы, предоставляющей услуги телефонной связи общего пользования (PSTN). Благодаря этому, маршрутизация экстренных вызовов является встроенной функцией решения и включает поддержку всех национальных номеров экстренных служб в странах, которые его поддерживают. Маршрутизация экстренного вызова осуществляется на основе заданного местоположения и метода доступа к телефонной сети общего пользования (PSTN). Номера телефонов экстренных служб предопределены и специфичны для страны, в которой развернуты пользователи и устройства.
Существует два способа передачи экстренных вызовов. Существует базовая служба маршрутизации экстренных вызовов и расширенная служба маршрутизации экстренных вызовов. Базовая служба маршрутизации экстренных вызовов будет использовать выбранный администратором номер для определения местоположения и маршрута вызова для связи с экстренными службами. Для обычных экстренных вызовов канал связи обычно проходит через телефонную сеть общего пользования (PSTN) клиента в данном местоположении. Также имеется расширенная маршрутизация экстренных вызовов, разработанная для развертывания в США и Канаде, где действуют нормативные требования, предусматривающие использование общенационального провайдера для доставки экстренных вызовов в соответствующий диспетчерский центр.
Всем клиентам следует развернуть, как минимум, базовую конфигурацию для экстренного вызова. Для базового вызова экстренной помощи необходимо наличие хотя бы одного абонентского устройства. +E.164 Каждому местоположению, определенному в , будет присвоен номер. Для осуществления обычных экстренных вызовов каждое местоположение будет определяться адресом улицы, по которому в случае чрезвычайной ситуации будут направляться полиция, пожарная служба или скорая помощь. В большинстве случаев основной номер телефона лучше всего подходит для обозначения физического местоположения чрезвычайной ситуации. Как правило, присвоение адреса +E.164 Номер согласовывается с оператором телефонной сети общего пользования (PSTN). На изображениях ниже показано присвоение основного номера, который будет использоваться в качестве номера для экстренного вызова в отделении Ричардсона.
В большинстве случаев в качестве адреса для отправки груза в данном месте достаточно указать адрес здания. Однако, если для конкретных пользователей или устройств требуются дополнительные сведения о местоположении, администратор может использовать описанный выше процесс и привязать эти устройства к определенному адресу или более точному местоположению внутри этого адреса (например, к этажу или комнате). В разделе Управление пользователями вкладка Вызов позволяет использовать определенный номер для того, чтобы пользователь и его устройства могли получить конкретный адрес вызова. На следующих изображениях показано, как устройству может быть присвоен определенный номер. Администратор отвечает за то, чтобы номеру, используемому устройством, был присвоен правильный адрес отправки. Присвоение адреса обычно осуществляется через оператора телефонной сети общего пользования (PSTN), обслуживающего данное местоположение.
Для развертывания телефонных систем в США, требующих расширенных возможностей экстренного вызова, используется интегрированная в RedSky платформа Horizon Mobility для маршрутизации экстренных вызовов. При использовании RedSky для маршрутизации вызовов администратор должен зарегистрировать учетную запись через Cisco и настроить соответствующую информацию в Calling -> Настройки службы для включения этой функции. После включения службы RedSky на системном уровне администратор должен включить службу RedSky на уровне каждого местоположения. Включение функции расширенного экстренного вызова в определенном месте активирует эту услугу для всех устройств, назначенных этому местоположению. Устройства, поддерживающие расширенные функции экстренного вызова, включают телефоны Cisco MPP, телефоны Cisco PhoneOS и устройства Cisco.
Для включения расширенной функции экстренного вызова в определенном месте предусмотрены два параметра. Параметр Allow RedSky to receive network connectivity information and test calls следует использовать для проверки правильности конфигурации RedSky для сопоставления устройств и инфраструктуры. Эта настройка также позволяет совершать тестовые звонки на номер 933 для проверки местоположения с помощью системы IVR RedSky, которая зачитывает местоположение звонящего. Хотя в этом документе не рассматривается настройка RedSky для отслеживания местоположения, администратор ВСЕГДА должен проверять определение местоположения перед активацией маршрутизации экстренных вызовов в RedSky. После завершения тестирования и подтверждения его точности администратор будет перенаправлять звонки в RedSky, переключив функцию переадресации экстренных вызовов в RedSky. Этот переключатель будет перенаправлять все экстренные вызовы из данного местоположения в RedSky для последующей передачи в центр обработки звонков этого местоположения.
Расширенные настройки экстренного вызова также применяются к клиентам как на территории предприятия, так и за его пределами. При использовании в локальной сети отслеживание устройств может осуществляться тем же способом, что и отслеживание стационарных телефонов. При удаленном доступе пользователь сможет динамически устанавливать свое местоположение непосредственно в системе. Для получения дополнительной информации о вызове в экстренных случаях см. Расширенные возможности вызова в экстренных случаях для .
Лицензирование
Существует несколько вариантов назначения лицензий пользователям.
Ручное назначение через
Администраторы вручную назначают лицензии отдельным пользователям через интерфейс.
Администраторы могут редактировать лицензии на обслуживание для отдельных пользователей и назначать лицензии на вызовы напрямую.
Шаблоны автоматического назначения лицензий
Используйте шаблоны назначения лицензий для автоматического назначения лицензий пользователям на основе групповых или организационных настроек.
Автоматическое лицензирование может осуществляться посредством синхронизации каталогов или ручного обновления учетных записей пользователей, но у пользователей должна быть действующая лицензия. +E.164 Отформатированный номер телефона, и эти номера телефонов должны существовать в определенном месте до момента предоставления доступа пользователю. Если условия не будут соблюдены (например, неверный формат номера телефона), лицензии не будут выданы.
Массовое назначение с помощью CSV-шаблона
Загрузите CSV-файл с данными о пользователях и назначениями лицензий, чтобы добавить или изменить информацию о нескольких пользователях одновременно.
Импорт CSV-файлов позволяет добавить до 20 000 пользователей и назначить лицензии, но для лицензий требуются определенные поля, такие как номер телефона и добавочный номер.
Назначение на основе API
Используйте API для программного назначения лицензий и управления пользователями.
Поддерживает операции API для управления пользователями и лицензиями (People, SCIM 2.0 и Licenses API), которые можно использовать для автоматизации назначения лицензий. API для работы с лицензиями позволяет одновременно назначать лицензии, телефонные номера и добавочные номера.
| Метод назначения | Плюсы | Минусы |
|---|---|---|
| Ручным способом | Простое решение для небольшого числа пользователей. Обеспечивает точный и детальный контроль над распределением лицензий. | Не масштабируемо, трудоемко Подвержен ошибкам, связанным с человеческим фактором, при ручном вводе данных. |
| Автоматические шаблоны лицензий | Масштабируемый Снижает количество ошибок, возникающих при ручном вводе. Может применяться как к новым, так и к существующим пользователям. | Требуется указать действительные номера телефонов и местоположение. Более сложная настройка Также требуется наличие групп пользователей для каждой группы пользователей с эквивалентными требованиями к лицензированию. |
| Массовая загрузка CSV-файлов | Эффективен для больших групп пользователей. Позволяет одновременно назначать лицензии, телефонные номера и добавочные номера. | Требуется тщательное форматирование CSV-файла. Возможны ошибки, если номера телефонов или добавочные номера отсутствуют или указаны неверно. |
| Назначение на основе API | Автоматизируемый, гибкий. Позволяет одновременно назначать лицензии, телефонные номера и добавочные номера. | Требуется знание разработки и API. |
В таблице Варианты предоставления доступа пользователям - сводка приведены сводные данные о вариантах предоставления доступа пользователям, а также их преимущества и недостатки. Данный обзор поможет выбрать оптимальный метод назначения лицензий, исходя из размера организации-заказчика, возможностей автоматизации, а также процессов и требований к предоставлению доступа пользователям.
Везде, где это возможно, Cisco рекомендует назначать лицензии на вызовы, используя шаблоны лицензий. Это требует, чтобы для каждой группы пользователей, которой требуется уникальный набор лицензий (например, стандартная или профессиональная), существовала группа с соответствующим членством. Как обсуждалось в разделах Группы пользователей, группы пользователей можно определять вручную в корпоративном каталоге или синхронизировать из него. Возможно сочетание обоих подходов.
Пользователи, принадлежащие к нескольким группам, получают лицензии на все права, присвоенные всем их группам. Это позволяет использовать группы безопасности, специфичные для каждой лицензии, в корпоративном каталоге для управления назначением лицензий, при этом результирующее назначение лицензий пользователю контролируется объединением членства в группах.
Для получения дополнительной информации см. Настройка автоматического назначения лицензий в Control Hub и Настройка шаблонов автоматического назначения лицензий для пользователей Webex Calling.
Требования к лицензированию
В этом разделе рассматриваются только соответствующие лицензии. Другие типы лицензий (например, регистрация устройств Webex, обмен сообщениями, проведение совещаний) не включены в данное описание. В рамках процесса проектирования необходимо определить требования к лицензированию. Необходимо рассчитать количество лицензий следующих типов:
-
Стандартный: количество отдельных пользователей, которым требуются стандартные функции телефонии.
-
Профессиональный: количество пользователей и рабочих мест, требующих расширенных функций телефонии. Виртуальные линии и групповая голосовая почта имеют право на 1:1 соотношение для каждой профессиональной лицензии. Следовательно, в редких случаях, когда количество необходимых виртуальных линий или групповых голосовых сообщений превышает количество пользователей и рабочих мест, требующих расширенных функций телефонии, необходимо предусмотреть дополнительные профессиональные лицензии.
-
Рабочее пространство для общей зоны: количество мест общего пользования или зон общего пользования, требующих стандартных возможностей телефонной связи.
-
Помощь клиентам: количество агентов и супервайзеров, которым требуются функции службы поддержки клиентов. Поддержка клиентов включает в себя профессиональную лицензию.
-
Вызовы списка маршрутов: количество необходимых звонков по телефонной сети общего пользования (PSTN) через облачное соединение между пользователями локальной сети and/or специализированные сторонние приложения, устанавливаемые локально.
-
Консоль оператора: количество пользователей, которым необходим доступ к клиентской консоли администратора.
-
Тарифный план Cisco для исходящих вызовов: количество пользователей, которым требуется номер PSTN and/or Доступ к исходящим вызовам по телефонной сети общего пользования (PSTN) для сервиса Cisco PSTN.
Для профессиональных рабочих пространств не существует отдельного типа лицензии. Для работы в профессиональных рабочих пространствах требуется профессиональная лицензия.
Рабочие места по принципу «горячего стола» предоставляют услуги ответственного за предоставление «горячих столов», возможность экстренного вызова от ответственного за их использование и не требуют лицензирования. Для получения дополнительной информации см. Добавление и управление устройствами, доступными только по принципу «горячего стола».
Чтобы определить необходимый тип лицензии для каждого пользователя и рабочего пространства в зависимости от требуемых функций, см. Функции, доступные в зависимости от типа лицензии для Webex Calling.
Чтобы понять разницу между функциональностью, предлагаемой очередями звонков в сочетании с профессиональной лицензией, и функцией помощи клиентам, см. Сравнение функций очереди звонков и помощи клиентам Webex Calling.
Подготовка пользователей
При создании учетных записей пользователей в Webex доступно несколько вариантов, каждый из которых подходит для различных организационных потребностей и условий:
-
Ручная настройка: Администраторы могут добавлять и управлять отдельными пользователями непосредственно в системе. Этот метод прост, но лучше всего подходит для небольших организаций или при ограниченном количестве изменений, вносимых пользователями.
-
Массовое выделение ресурсов через CSV: Для больших пользовательских баз администраторы могут импортировать и обновлять пользователей массово, загружая CSV-файлы в систему. Это позволяет эффективно управлять одновременно тысячами пользователей.
- Параметры синхронизации каталогов:
Соединитель каталогов: Это инструмент автоматической синхронизации, используемый в средах Microsoft Active Directory. Она синхронизирует учетные записи пользователей, группы и атрибуты по расписанию (ежечасно, ежедневно или еженедельно). Он поддерживает многодоменные и многолесные конфигурации Active Directory и может синхронизировать изображения профилей и объекты помещений.
Приложение-мастер Entra ID (Azure AD): Этот метод, разработанный для организаций, использующих Microsoft Entra ID (Azure AD), обеспечивает автоматическую синхронизацию учетных записей пользователей и их атрибутов практически в режиме реального времени непосредственно из Entra ID в . Система полностью управляется и требует минимальной настройки.
Приложения SCIM 2.0: Для сред, отличных от Microsoft, или других поставщиков идентификационных данных, таких как Okta или Duo, приложения синхронизации на основе SCIM позволяют автоматически создавать и удалять учетные записи пользователей с сопоставлением атрибутов и синхронизацией групп.
-
Единая синхронизация пользователей CM: Эта опция позволяет создавать учетные записи пользователей на основе существующих конечных пользователей путем синхронизации данных из одной системы в другую. Для этого необходимо, чтобы Cloud Connected UC (CCUC) работала на локальных кластерах. Однако, как правило, рекомендуется синхронизировать пользователей из централизованного облачного каталога, такого как Entra ID, а не напрямую из него.
-
Предоставление API: Для предоставления доступа пользователям можно использовать общедоступные API (People, SCIM 2.0). Главное преимущество использования API заключается в возможности интеграции системы управления учетными записями пользователей с другими корпоративными системами.
Данный обзор и таблица отражают основные варианты предоставления доступа пользователям, их преимущества и ограничения, чтобы помочь вам выбрать оптимальный подход, соответствующий потребностям вашей организации.Таблица 6. Параметры предоставления доступа пользователям для Метод предоставления ресурсов Описание Плюсы Минусы Вручную Create/manage пользователи индивидуально в Простое решение для небольшого количества пользователей; не требует дополнительной инфраструктуры. Не масштабируемо; отнимает много времени у большого количества пользователей. Массовая загрузка (CSV-файл) Import/update пользователей массово через CSV-файл Эффективно для работы в группах; программирование не требуется. Ручная подготовка CSV-файлов; менее динамично. Люди и API SCIM 2.0 Программное управление пользователями через API Webex Гибкий; поддерживает автоматизацию и интеграцию. Требуется развитие и инфраструктура. Синхронизация каталогов Автоматическая синхронизация из AD, Entra ID, приложений SCIM, Unified CM. Автоматизирует жизненный цикл; поддерживает фильтрацию и сопоставление. Сложность настройки: Некоторые из вариантов имеют ограниченный функционал или требуют наличия инфраструктуры.
Группы пользователей
Управление группами пользователей позволяет администраторам организовывать пользователей в группы для эффективного массового управления лицензиями, настройками и ресурсами. Группы помогают оптимизировать администрирование, применяя политики, лицензии и шаблоны настроек к нескольким пользователям одновременно, вместо того чтобы управлять пользователями по отдельности.
Управление группами пользователей предоставляет ряд преимуществ, в том числе:
-
Упрощенное администрирование: Управляйте лицензиями, настройками и политиками для нескольких пользователей одновременно.
-
Последовательность: Примените единые настройки и лицензии ко всем пользователям в одной группе.
-
Масштабируемость: Поддерживает до 250 000 участников в группе.
-
Интеграция: Синхронизируйте группы из Microsoft Entra ID (Azure AD) или Active Directory для автоматизированного управления пользователями и группами.
-
Гибкость: Создавайте локальные группы или синхронизируйте группы безопасности; управляйте членством в группах вручную или с помощью CSV-файлов.
-
Распределение ресурсов: Регулировка доступа к встроенным приложениям и сервисам на основе членства в группах.
Основные сценарии использования групп пользователей при создании учетных записей:
-
Передача лицензий: Назначайте лицензии группам для автоматического предоставления участникам группы таких услуг, как звонки, собрания, обмен сообщениями или гибридные сервисы.
-
Шаблоны настроек: Для обеспечения единообразного пользовательского опыта применяйте наборы настроек сервисов (например, обмен сообщениями, встречи, звонки) к группам пользователей.
-
Массовое управление пользователями: Добавляйте или удаляйте пользователей одновременно с помощью CSV-файлов или синхронизации каталогов.
-
Автоматизация и интеграция: Используйте API или синхронизацию каталогов для автоматизированного управления жизненным циклом пользователей и групп.
В следующей таблице приведено краткое описание различных вариантов управления группами пользователей и управления группами в .
| Параметр | Описание | Плюсы | Минусы |
|---|---|---|---|
| групповое предоставление ресурсов (группы) | Создавайте и управляйте группами непосредственно в . Add/remove Участники вручную или через CSV-файл. | Полный контроль над членством в группе. Немедленное применение лицензий и шаблонов Легко создавать и редактировать группы. |
Требуется ручное обновление Риск ошибок при ручной загрузке CSV-файлов. Отсутствует автоматическая синхронизация с внешними каталогами. |
| Синхронизированные группы из Entra ID (Azure AD) или Active Directory. | Автоматическая синхронизация групп безопасности и членства в них из внешних служб каталогов. | Автоматическая синхронизация сокращает объем ручной работы. Обеспечивает соответствие корпоративному справочнику. Поддерживает крупные организации |
Невозможно изменить состав группы. Задержка синхронизации до 12 часов Для вложенных групп требуется ручной выбор. |
| Группы и API SCIM 2.0 (Группы) | Используйте группы или API SCIM 2.0 для программного управления группами и членством. | Автоматизация и интеграция с другими системами Масштабируемость для крупных или сложных сред |
Требует усилий по разработке. Сложность зависит от использования API. |
Хотя синхронизированные группы обеспечивают согласованность и предлагают единую точку администрирования, возможен и гибридный подход, сочетающий синхронизированные группы и группы (управляемые либо через центр управления, либо через API). Так, например, группы для назначения лицензий могут быть синхронизированными группами, а отдельный набор групп может использоваться для назначения пользователей и вызова шаблонов.
Этот комплексный подход к управлению группами пользователей позволяет организациям эффективно управлять лицензиями, настройками и политиками пользователей, обеспечивая согласованный и масштабируемый опыт совместной работы.
Рекомендуемый подход при миграции с на
Основным источником данных для пользователей является база данных, содержащая информацию о конечных пользователях. Однако, как правило, это не является авторитетным источником информации для управления идентификацией пользователей, и, что более важно, он будет отключен по завершении переходного периода, поэтому его исключают в качестве долгосрочного авторитетного источника информации об идентификации.
Компания Cisco рекомендует использовать централизованный облачный каталог, такой как Microsoft Entra ID (Azure AD), в качестве единого источника достоверной информации об учетных записях пользователей. Синхронизация пользователей из Entra ID обеспечивает согласованность данных, упрощает управление и поддерживает возможности единого входа (SSO).
Чтобы гарантировать, что все пользователи также присутствуют в Entra ID, организациям следует убедиться, что учетные записи пользователей в соответствуют учетным записям в Entra ID. Это можно сделать, экспортировав списки пользователей и сравнив их со списками пользователей Entra ID.
Вкратце, рекомендуемый метод подготовки пользователей — синхронизация пользователей из Microsoft Entra ID (Azure AD) с Webex с помощью мастера Azure AD или приложений SCIM. Ручное и пакетное выделение ресурсов с использованием CSV-файлов доступны в качестве дополнительных методов, но они менее масштабируемы и более подвержены ошибкам для крупных организаций. Для успешной миграции и обеспечения единообразного пользовательского опыта во всех средах крайне важно убедиться, что Entra ID является авторитетным источником и что все пользователи зарегистрированы в Entra ID.
Переход от локальной службы каталогов, такой как Active Directory, к облачной службе каталогов, такой как Entra ID (Azure ID), не зависит от процесса перехода к новой системе. Компания Cisco рекомендует завершить переход на облачную службу каталогов, прежде чем начинать переход на использование облачных сервисов для обработки вызовов.
Разработка пользовательских групп
После переноса корпоративного каталога из локальной среды в облако соберите необходимые группы пользователей, исходя из требований к лицензированию и шаблонам функций. Для каждого группового документа:
-
Имя группы: уникальное название группы.
-
Лицензии: Лицензии, подлежащие назначению этой группе (если таковые имеются), и область действия (следует ли назначать лицензии существующим пользователям или только новым пользователям)
-
Шаблоны настроек: Шаблоны вызовов для приложения Webex и пользователей.
-
Синхронизация каталогов: Будет ли эта группа синхронизироваться из корпоративного каталога, или это локальная группа Webex, созданная в Control Hub, или она будет создана через API?
-
Описание: Как будет использоваться эта группа и какие пользователи должны быть её членами?
Эти данные будут использованы позже на этапе внедрения для создания локальных групп или групп в корпоративном каталоге и управления членством пользователей в группах.
Система единого входа (SSO)
Компания Cisco рекомендует использовать единый вход (SSO) для аутентификации пользователей. Использование единого входа (SSO) имеет ряд существенных преимуществ, в том числе:
-
Упрощенная аутентификация пользователей: Пользователи могут войти в систему один раз, используя свои корпоративные учетные данные (например, из Azure ID), для доступа к другим интегрированным приложениям, что исключает необходимость использования нескольких паролей и сокращает количество запросов на авторизацию. Это повышает безопасность, гарантируя, что корпоративные пароли никогда не сохраняются и не передаются после аутентификации.
-
Упрощенное управление пользователями: Автоматизирует создание, обновление и деактивацию учетных записей пользователей на основе изменений в корпоративном справочнике, снижая административные издержки и гарантируя, что доступ имеют только авторизованные пользователи.
-
Повышенная безопасность: Система единого входа (SSO) снижает усталость от паролей и риск утечек данных, связанных с паролями, за счет централизации аутентификации через доверенных поставщиков идентификационных данных (IdP).
-
Простая интеграция многофакторной аутентификации (МФА): Многофакторная аутентификация (MFA) может быть легко реализована либо с помощью решения для управления идентификацией и доступом, такого как Cisco Duo, либо с помощью поддержки MFA поставщика идентификации (IdP).
Существует несколько вариантов реализации единого входа (SSO) для сервисов:
-
Единый вход (SSO) на основе SAML 2.0: Основной протокол, поддерживаемый для интеграции SSO, обеспечивает безопасный обмен информацией для аутентификации между поставщиком идентификации (IdP) и поставщиком услуг.
-
OpenID Connect (OIDC): Поддерживается в качестве альтернативного современного протокола аутентификации для интеграции SSO.
-
Идентификатор Webex: Также поддерживается в качестве опции поставщика идентификационных данных.
Единый вход (SSO) настраивается и управляется централизованно через , что требует обмена метаданными между и выбранным поставщиком идентификации (IdP).
После настройки можно протестировать SSO перед активацией, чтобы убедиться в правильности установки.
Cisco поддерживает интеграцию с множеством проверенных и широко используемых поставщиков идентификации (IdP) и систем управления идентификацией (IAM), включая, помимо прочего:
-
Cisco Duo
-
Okta
-
Служба федерации Active Directory Microsoft (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 BIG-IP.
Эти поставщики идентификации соответствуют стандартам SAML 2.0 или OpenID Connect и прошли проверку на совместимость с решениями Cisco для совместной работы.
Поддержка нескольких поставщиков идентификации
Это позволяет организациям настраивать единый вход (SSO) с использованием нескольких поставщиков идентификации (IdP) для работы в сложных ИТ-средах, таких как слияния, поглощения или децентрализованные ИТ-подразделения, где разные группы используют разные IdP. Поддержка нескольких поставщиков идентификации (IdP) может быть реализована либо с помощью функции Multiple IdP, либо путем интеграции с корпоративной системой управления идентификацией и доступом (IAM), такой как Cisco Duo.
Поддержка нескольких поставщиков идентификационных данных (IdP) позволяет решить ряд ключевых задач, в которых организациям требуется гибкая и безопасная аутентификация в различных ИТ-средах:
1. Слияния и поглощения.
При слиянии или поглощении компаний часто возникают ситуации, когда у них есть отдельные ИТ-инфраструктуры и различные поставщики идентификации, которые не могут быть объединены в единую систему. Поддержка нескольких поставщиков идентификации позволяет пользователям из обеих организаций безопасно аутентифицироваться и сотрудничать без необходимости немедленного объединения их систем идентификации.
2. Несколько независимых ИТ-отделов
В крупных организациях или государственных учреждениях может быть несколько независимых ИТ-отделов, каждый из которых управляет собственным поставщиком идентификации. Функция множественных поставщиков идентификации (IdP) позволяет этим отделам поддерживать собственные системы аутентификации, обеспечивая при этом беспрепятственный доступ пользователей.
3. Различные группы пользователей или домены
Организации с различными группами пользователей (например, сотрудники и подрядчики) или несколькими почтовыми доменами могут настраивать правила маршрутизации для направления запросов аутентификации к соответствующему поставщику идентификации в зависимости от принадлежности к домену или группе. Это обеспечивает дифференцированные политики доступа и средства контроля безопасности.
4. Поддержка различных протоколов аутентификации
Поддерживает поставщики идентификации SAML и OpenID Connect (OIDC), что позволяет организациям интегрировать различные типы поставщиков идентификации в соответствии с их существующей инфраструктурой и требованиями безопасности.
5. Повышенная безопасность и соответствие нормативным требованиям
Благодаря возможности использования нескольких поставщиков идентификации (IdP), организации могут внедрять более надежные механизмы аутентификации, включая многофакторную аутентификацию (MFA) с помощью таких интеграций, как Duo, и обеспечивать соблюдение единых политик безопасности для различных групп пользователей.
6. Упрощенный пользовательский интерфейс
Пользователи могут проходить аутентификацию, используя свои существующие учетные данные от соответствующих поставщиков идентификации, что обеспечивает единый процесс входа в систему, несмотря на сложность, лежащую в основе множества систем идентификации.
Поддержка нескольких поставщиков идентификации (IdP) обеспечивает гибкость, но требует тщательной координации между командами безопасности и идентификации для поддержания согласованных политик безопасности и предотвращения потенциальных уязвимостей.
Двойная программа магистратуры в области изящных искусств с SSO для
Duo Access Gateway (DAG) может аутентифицировать пользователей, используя существующие локальные или облачные каталоги, такие как Active Directory (AD) и OpenLDAP. Он также поддерживает интеграцию с другими поставщиками идентификационных данных, такими как Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS и Shibboleth. Такая гибкость позволяет организациям использовать свою существующую инфраструктуру каталогов для единого входа Webex с многофакторной аутентификацией Duo.
Duo выступает в качестве надежного уровня аутентификации поверх аутентификации по основному каталогу. Он функционирует как поставщик идентификационных данных (IdP), используя SAML 2.0 для обеспечения двухфакторной аутентификации (2FA) перед предоставлением доступа. Duo анализирует контекст пользователя, устройства и сети в соответствии с настраиваемыми политиками, чтобы разрешить или запретить доступ, повышая безопасность не только за счет имени пользователя и пароля. Duo также предоставляет гибкие возможности управления политиками, например, возможность требовать многофакторную аутентификацию при каждом входе в систему для некоторых приложений и реже для других.
К преимуществам Cisco Duo относятся:
-
Повышенная безопасность: Добавляет защищенную от фишинга многофакторную аутентификацию для защиты доступа, снижая риск взлома паролей.
-
Гибкая политика: Позволяет осуществлять детальный контроль над требованиями к аутентификации для каждого приложения или группы пользователей.
-
Интеграция с существующими каталогами: Поддерживает локальные Active Directory, OpenLDAP, облачные каталоги и различные поставщики единого входа, сводя к минимуму изменения инфраструктуры.
-
Удобство для пользователя: Поддерживает единый вход (SSO), что снижает утомляемость от паролей, позволяя пользователям входить в систему один раз и безопасно получать доступ к нескольким ресурсам.
-
Доверенные конечные точки: Поддерживает доверие к устройствам для клиентов на Windows и macOS, повышая уровень безопасности.
-
Самостоятельная регистрация: Встроенная регистрация и запрос на ввод двухфакторной аутентификации улучшают пользовательский опыт во время настройки многофакторной аутентификации.
Двухфакторная аутентификация с единым входом (SSO) использует существующие каталоги, такие как Active Directory и OpenLDAP, или облачные сервисы идентификации для аутентификации пользователей. Задача Duo — обеспечить надежный, управляемый политиками второй фактор аутентификации, интегрированный через SAML 2.0, повышая безопасность и сохраняя удобство для пользователей благодаря единому входу (SSO). К преимуществам относятся улучшенная безопасность, гибкое применение политик, бесшовная интеграция и улучшенный пользовательский опыт.
Компания Cisco рекомендует внедрить единый вход (SSO) для пользователей. Для повышения уровня безопасности рекомендуется интеграция с Cisco Duo.
Стратегию корпоративного управления идентификацией и доступом (IAM) и единого входа (SSO) следует внедрить до начала перехода с одной системы на другую.
Функции
Обладает полным набором основных функций, включенных в сервис. Это включает в себя множество функций корпоративного уровня для совершения звонков, которые доступны уже много лет. Возможно, вы не увидите 100% совпадения между функциями, однако, как видно на рисунке ниже, ключевые функции вызова доступны в .
Помимо множества пользовательских функций, платформа обладает основными системными функциями. К ним относятся такие функции, как автоматические операторы, очереди звонков, парковка звонков и т. д. Все доступные основные функции системы можно увидеть в разделе Сервис → Вызовы → Функции, как показано на рисунке Основные функции вызовов Webex.
Автосекретарь
Автоматический секретарь позволяет 24/7 Автоматизация обработки входящих звонков, которая позволяет эффективно обрабатывать вызовы без необходимости присутствия оператора на каждом звонке.
Автоматический секретарь отвечает на входящие звонки и предоставляет звонящему меню с вариантами переадресации звонка. Это может быть звонок конкретному человеку, на автоответчик или в службу обработки звонков (например, в очередь звонков). Абонент использует клавиатуру своего телефона для ввода номера из меню автоответчика.
Автоматический секретарь поддерживает следующие ключевые функции:
-
График работы в рабочее и нерабочее время
-
График выходных дней
-
Функция меню набора номера позволяет направлять ваших клиентов туда, куда им нужно.
-
Настройте приветствия
-
Возможность набора номера по имени
-
Параметры переадресации вызовов
-
Аналитика и отчеты Control Hub.
Для получения дополнительной информации см. Управление автоответчиками.
Парковка вызова
Функция «Парковка вызова» позволяет пользователям легко ставить вызов на удержание, чтобы другой пользователь мог легко его принять, когда освободится. Это также освобождает пользователя, ответившего на первоначальный звонок, от необходимости совершать или принимать другие звонки, пока звонок находится в режиме ожидания.
В настоящее время доступны два типа парковок вызовов. :
-
Прямая парковка вызовов - позволяет любому пользователю припарковать вызов на добавочный номер другого пользователя или на добавочный номер для парковки вызовов, как определено Администратором.
-
Группа парковки вызовов - позволяет определенной группе пользователей автоматически парковать вызовы на доступных местах парковки, определенных для этой группы. Этими пунктами назначения могут быть добавочные номера участников группы или номера телефонов парковки.
В зависимости от конфигурации и типа парковки, пользователи могут принимать звонки, набрав . *88+><extension of parked call>, нажав клавишу линии, связанную с добавочным номером парковки вызова, или используя программную клавишу на своем IP-телефоне.
Доступна опция отзыва, позволяющая отозвать припаркованный вызов по истечении указанного периода времени у пользователя, который припарковал вызов, или у другого пользователя.
Для получения дополнительной информации см. Управление парковкой вызовов в Центре управления.
Перехват вызовов
Функция перехвата вызова позволяет администратору определить группу пользователей (участников), которые могут отвечать на звонки на телефоны других участников. Это позволяет пользователю отвечать на звонки, когда его коллеги заняты и не могут ответить на входящий звонок.
Пользователи в группе должны находиться в одном и том же месте.
Пользователи могут ответить на звонок либо с помощью мобильного телефона, либо с помощью своего стационарного телефона.
-
:
-
Поддерживает визуальные и звуковые уведомления.
-
Уведомление о входящем вызове
-
На основе FAC (циферблат) *98) или всплывающее уведомление о переадресации звонка
-
Уведомления о переадресации вызова для многоканальных систем.
-
-
Настольные телефоны:
-
Уведомление о входящем вызове
-
Звуковые сигналы и визуальное оповещение через светодиодный индикатор на телефоне. Модель 6821 поддерживает только звуковые сигналы.
-
Когда тип уведомления, выбранный в поле, не равен none
-
-
Уведомления о переадресации звонков доступны только для основных линий.
-
Для получения дополнительной информации см. Настройка группы перехвата вызовов.
Очередь вызовов
В числе основных функций — очереди звонков только для голосовой связи, и любой пользователь с профессиональной лицензией может быть участником очереди звонков, агентом или супервайзером. Эта функция позволяет пользователям эффективно взаимодействовать с клиентами. Очереди звонков поддерживают часть основных функций колл-центра, таких как голосовые очереди, обратные звонки, маршрутизация по навыкам или приоритетам, управление очередями операторов, аналитика, отчетность и т. д.
Предложение Cisco об интеграции с Microsoft Teams позволит операторам получать доступ к вызовам из очереди и другим функциям непосредственно из своего клиента Microsoft Teams.
Очереди вызовов поддерживают следующие ключевые функции:
-
Приветствия и сообщения (добро пожаловать, утешение, шепот и т. д.)
-
Мелодия режима удержания
-
Обратный вызов
-
Правила маршрутизации очередей (ночное обслуживание, праздничные дни, переадресация)
-
Очередь агентов login/logout
-
управление статусом очереди агентов
-
или поддержка по стационарному телефону
-
Оператор-супервайзер может контролировать, инструктировать, прерывать или брать на себя управление звонками с помощью кодов доступа к функциям (FAC).
-
(доступ администратора) для:
-
управление очередями
-
Анализ и отчетность по агентам и очередям
-
Управление очередью, агентами и супервайзерами.
-
Для получения дополнительной информации см. Настройка очереди вызовов.
Включает в себя дополнительную функцию «Помощь клиенту», которая расширяет возможности обработки звонков и улучшает взаимодействие операторов и супервайзеров с системой. Для сравнения функций очереди звонков и помощи клиентам см. Сравнение функций очереди звонков и помощи клиентам Webex Calling.
Группа поиска
Группы переадресации позволяют направлять входящие вызовы определенной группе пользователей в соответствии с заранее заданным шаблоном маршрутизации вызовов. Это гарантирует, что на звонки ответит нужная группа пользователей или они будут перенаправлены на голосовую почту для дальнейшего рассмотрения.
Одно из главных отличий между группами переадресации вызовов и очередями вызовов заключается в том, что в группах переадресации вызовов вызовы не ставятся в очередь, поэтому, если в группе переадресации нет доступных пользователей для ответа на вызов, он будет прерван, перенаправлен на голосовую почту или переадресован на другой номер (пользователя или службу).
Для получения дополнительной информации см. Управление группами поиска в Центре управления.
Режимы работы
Функция «Режимы работы» позволяет компаниям эффективно перенаправлять звонки в различные пункты назначения (пользователям, голосовой почте, службам обработки вызовов, таким как очередь звонков). Маршрутизация вызова определяется временем суток и днем недели, и любой пользователь может быть авторизован для управления этими режимами (расписаниями) с целью контроля изменений в маршрутизации вызовов.
Например, звонки в одну очередь могут быть перенаправлены в другую очередь с операторами, находящимися в другом часовом поясе, для ответа на звонки в нерабочее время, в рабочее время — местным операторам, а в праздничные дни — на голосовую почту для последующего обслуживания после возвращения операторов в офис.
Авторизованный пользователь может переключаться между этими различными сценариями (режимами) переадресации вызовов, если ему необходимо изменить маршрутизацию входящих вызовов на определенный период. Эти пользователи могут управлять режимами через свои 6800/7800/8800 Телефоны MPP, телефоны 9800 или в пользовательском центре по адресу Управление режимами.
Для получения дополнительной информации см. Маршрутизация вызовов на основе режимов работы в Webex Calling.
Пейджинговая группа
Группы пейджинговых операторов позволяют пользователям совершать односторонние вызовы для отправки аудиосообщения группе пользователей. Каждая группа может содержать до 75 целевых пользователей. and/or Рабочие места, доступ к которым осуществляется путем набора заранее определенного номера или добавочного номера.
Когда пользователь звонит в группу пейджинга, одновременно совершается вызов всем назначенным абонентам в группе, после чего вызывающий абонент может произнести свое сообщение и завершить вызов, как только оно будет произнесено.
Для получения дополнительной информации см. Настройка группы пейджинга в Центре управления.
Записи
Поддерживает запись звонков, совершаемых или принимаемых пользователем. Это может потребоваться для обеспечения качества, гарантии, безопасности или обучения. По умолчанию звонки записываются в [название сервиса], но при необходимости можно использовать и другие сторонние сервисы записи, если требуются дополнительные функции записи или соблюдение нормативных требований.
При использовании в качестве платформы для записи все записанные звонки обрабатываются внутри . Администраторы с полным доступом и ролью "Специалист по соблюдению нормативных требований" могут воспроизводить и скачивать записи. Без должности специалиста по соблюдению нормативных требований администратор может только удалять записи.
Для получения дополнительной информации об этой функции и списка сторонних сервисов записи см. Управление записью звонков для Webex Calling.
Дозвон по единому номеру
Функция "Обзвон с помощью одного номера" позволяет звонкам на телефонный номер пользователя поступать на несколько устройств. Это может включать в себя как стационарные, так и мобильные телефоны. С этих устройств также можно совершать звонки, и пользователи могут принимать и отправлять звонки между ними.
Для получения дополнительной информации об этой функции и о том, как администратор может ее настроить, см. Настройка доступа по одному номеру (office anywhere).
Для получения дополнительной информации о том, как пользователь может управлять этой функцией и настраивать ее самостоятельно в Webex User Hub (портале), см. Настройка единого номера доступа (Office Anywhere).
Группа голосовой почты
Группы голосовой почты позволяют использовать общий почтовый ящик, который можно назначить пользователю или использовать в качестве средства маршрутизации вызовов. Группа голосовых сообщений может потребоваться по следующим причинам:
-
Автоответчик общего назначения для отдела или рабочей группы.
-
Добавить функцию голосовой почты в автоответчик или группу переадресации вызовов.
-
Для отправки переполняющих вызовов из очереди вызовов
-
Пользователям, которым нужен только ящик голосовой почты.
Для получения дополнительной информации см. Управление общей голосовой почтой и входящими факсами для Webex Calling.
Функция «Консоль оператора» указана на странице «Функции вызова» в Webex, однако это дополнительная функция, для использования которой требуется приобрести лицензию на консоль оператора.
Для получения дополнительной информации см. Начало работы с консолью оператора.
Для получения информации обо всех функциях, включая некоторые дополнительные функции, см. Функции, доступные в зависимости от типа лицензии для Webex Calling.
Внедрение
готовность сети
Первым шагом при переходе является обеспечение надежного и безопасного интернет -соединения между локальной сетью и облаком.
Поскольку большинство организаций подключаются к интернету через один или несколько межсетевых экранов или устройств безопасности , крайне важно убедиться в поддержке необходимых потоков трафика .
Администраторы сетей и безопасности должны понимать эти потоки с точки зрения:
-
Направление (входящее или исходящее)
-
Протоколы (Пример - SIP TLS, SRTP, HTTPS)
-
Диапазоны IP-адресов, используемые службами
-
Номера портов, которые необходимо открыть или разрешить.
Это гарантирует правильную настройку корпоративных межсетевых экранов, устройств NAT и другой сетевой инфраструктуры для обработки трафика при соблюдении корпоративных политик безопасности.
Для получения информации о необходимых потоках данных, включая IP-адрес, порты и протоколы, см. Справочная информация о портах для Webex Calling. Используйте эту информацию для настройки брандмауэра, прокси-серверов и другой сетевой инфраструктуры в существующей системе, чтобы обеспечить передачу сетевых потоков.
Для облачных сервисов для совместной работы рекомендуется децентрализованный выход в интернет из каждого филиала или объекта. Эта модель, позволяющая трафику выходить локально, обеспечивает следующее:
-
Уменьшает задержку и дрожание сигнала в обоих направлениях, улучшая общее качество связи.
-
Эффективно масштабируется по мере перехода всё большего числа пользователей и сайтов на эту технологию.
-
Бесперебойно работает с SD-WAN, которая может динамически маршрутизировать сеансы к ближайшей точке входа в облако для оптимальной производительности.
- Позволяет отслеживать местоположение пользователя на основе его публичного IP-адреса, что помогает в анализе пути передачи мультимедиа и устранении неполадок.
Кроме того, организации должны обеспечить достаточную пропускную способность интернета на каждом объекте. Размер полосы пропускания следует определять исходя из ожидаемого количества одновременных вызовов, выбранного кодека (например, Opus или G.711), а также накладных расходов на сигнализацию, повторную передачу и рост. Это соответствует этапу подготовки жизненного цикла PPDIO и закладывает прочную основу для миграции.
Начальная настройка
Подраздел первоначальной настройки в рамках этапа внедрения развертывания имеет основополагающее значение для создания хорошо структурированной и управляемой среды облачных вызовов. Этот этап включает в себя такие важные задачи, как создание организации, приобретение и распределение лицензий, а также проверка и подтверждение доменов вашей компании для обеспечения надлежащего управления пользователями и безопасности. Кроме того, он включает в себя создание шаблонов лицензий для автоматизации назначения лицензий пользователям, настройку единого входа (SSO) для упрощения аутентификации пользователей и повышения безопасности, а также корректировку параметров сервисов и клиентов в соответствии с политиками организации и потребностями пользователей. Выполнение этих первоначальных действий по настройке гарантирует правильную конфигурацию среды для масштабируемости, безопасности и бесперебойной работы пользователей, подготавливая почву для последующих этапов развертывания и эксплуатации.
Проверка домена
Для того чтобы идентифицировать пользователей, зарегистрированных в почтовых доменах вашей компании, необходимо подтвердить ваши домены. Без подтверждения домена пользователи будут привязаны к потребительской организации, что усложнит управление пользователями в вашей компании. Подтверждение домена — обязательный шаг, позволяющий вашей организации эффективно регистрировать и управлять этими пользователями.
Убедитесь, что все домены, связанные с адресами электронной почты ваших пользователей, проверены. Проверка домена не является эксклюзивной; один и тот же домен может быть проверен в нескольких организациях.
Для получения дополнительной информации об управлении доменами см. Управление доменами.
Заявить права на существующих пользователей (конвертировать их)
После успешной проверки ваших доменов вы можете приступить к добавлению в организацию пользователей, зарегистрировавшихся для использования почтовых доменов вашей компании. Этот процесс объединяет всех пользователей под эгидой единой организации, обеспечивая централизованное управление и оптимизированное администрирование. Зарегистрировав этих пользователей, вы обеспечиваете своей компании полный контроль над их учетными записями, что позволяет назначать соответствующие лицензии, настраивать сервисы и эффективно оказывать необходимую поддержку. Такой унифицированный подход к управлению повышает безопасность, упрощает предоставление доступа пользователям и обеспечивает согласованный доступ к сервисам во всей организации. Присвоение прав на пользователей также предотвращает управление ими во внешних или потребительских организациях, тем самым сохраняя организационную целостность и контроль над ресурсами для совместной работы.
Для получения дополнительной информации о подтверждении прав пользователей см. Подтверждение прав пользователей вашей организации (преобразование) пользователей.
Настройка и тестирование синхронизации каталогов.
Для обеспечения бесперебойного управления пользователями и группами вы можете синхронизировать пользователей и группы из корпоративного каталога либо через Microsoft Entra ID (ранее Azure AD), либо через Microsoft Active Directory (AD). Этот процесс обеспечивает согласованность идентификационных данных пользователей и членства в группах во всей вашей среде.
Для организаций, внедряющих поэтапное развертывание, крайне важно контролировать и ограничивать масштабы синхронизации на начальных этапах внедрения. Это сводит к минимуму риск непреднамеренных изменений и позволяет проводить целенаправленное тестирование перед более широким внедрением.
Наиболее эффективным методом фильтрации синхронизируемых пользователей является использование членства в группах каталога:
| 1 |
Создайте выделенную группу синхронизации: В корпоративном каталоге (Microsoft Entra ID или Active Directory) создайте группу безопасности, специально предназначенную для синхронизации (например, группа синхронизации). |
| 2 |
Заполните группу целевыми пользователями: Добавляйте в эту группу только тех пользователей, которых вы хотите синхронизировать (например, тестовую группу на этапе пилотного проекта). Это позволяет вам строго контролировать, кто именно участвует в процессе синхронизации. |
| 3 |
Настройте соглашение о синхронизации с фильтрацией на основе групп: При настройке соглашения о синхронизации в Directory Connector или Entra ID укажите область действия таким образом, чтобы в нее включались только пользователи, являющиеся членами указанной группы.
|
| 4 |
Расширяйте группу по мере необходимости: По мере перехода к более масштабным этапам развертывания просто добавляйте дополнительных пользователей или группы в группу синхронизации. Область синхронизации автоматически расширится, включив в себя этих пользователей, что позволит осуществлять контролируемое и постепенное развертывание. Пример этапов реализации:
Ссылки: Синхронизация пользователей Entra ID с Control Hub. |
Настройка и тестирование единого входа (SSO)
Единый вход (SSO) повышает безопасность и упрощает доступ пользователей, позволяя им проходить аутентификацию один раз с помощью корпоративных учетных данных и получать беспрепятственный доступ. Поддерживается интеграция SSO с поставщиками идентификации (IdP), совместимыми с SAML 2.0, включая Microsoft Entra ID (ранее Azure AD), федеративные решения Active Directory (AD) и различные сторонние поставщики идентификации.
На данном этапе разработанную систему единого входа (SSO) следует внедрить и протестировать.
Ссылки:
Интеграция единого входа в центр управления
Настройка единого входа для администрирования Webex
Настройте единый вход с помощью Microsoft Entra ID.
Единый вход (SSO) с несколькими поставщиками идентификации (IdP)
Управление единым входом (SSO) при интеграции в Control Hub.
Получение, предоставление и проверка лицензий.
В рамках первоначальной настройки необходимо приобрести, предоставить и проверить соответствующие лицензии для эффективного включения и управления сервисами. Процесс закупки включает в себя выбор типов лицензий в зависимости от ролей пользователей и выполняемых ими задач, таких как лицензии Professional, Standard и Workspace. Лицензии генерируются и предоставляются через программные платформы Cisco или через партнеров. После закупки и предоставления лицензий необходимо проверить правильность количества лицензий. Этот процесс гарантирует, что организация имеет все необходимые активированные лицензии, готовые к использованию в процессе развертывания.
В рамках первоначальной настройки лицензирования важно настроить автоматическое лицензирование на основе организации, чтобы упростить назначение лицензий новым пользователям. Такая настройка позволяет автоматически предоставлять лицензии при добавлении пользователей в организацию, устраняя необходимость в ручном назначении лицензий. При настройке автоматического лицензирования на уровне организации вы выбираете службы для назначения лицензий и определяете область действия, например, применяете ли вы лицензии только к будущим пользователям или включаете в них и существующих пользователей.
Однако, если ваш план развертывания предполагает использование автоматического лицензирования на уровне группы, вы можете отказаться от назначения лицензий на уровне организации, чтобы избежать конфликтов или дублирования назначений лицензий. При автоматическом лицензировании на уровне группы лицензии назначаются в зависимости от членства в группе. Пользователи, состоящие в нескольких группах, получают лицензии по всем соответствующим групповым назначениям.
Настройка назначения лицензий на основе групп должна выполняться после завершения синхронизации каталогов, чтобы синхронизированные группы существовали и могли использоваться для назначения лицензий.
В частности, для автоматического назначения лицензий требуются дополнительные данные для предоставления доступа, такие как местоположение пользователя и присвоение номера телефона. Рабочий номер телефона пользователя должен быть указан в +E.164 формат, предварительно настроен и назначен действительному местоположению для автоматической активации лицензии. Если эти условия не будут соблюдены, пользователю не будут автоматически предоставляться услуги, и может потребоваться ручное вмешательство.
В заключение, если вам необходимо широкое распределение лицензий по всей организации, настройте автоматическое лицензирование на основе организации для новых пользователей. Если вам требуется более детальный контроль или у вас разные потребности в лицензировании для разных групп, настройте автоматическое лицензирование на уровне группы и избегайте назначения лицензий на уровне организации, чтобы предотвратить дублирование и обеспечить надлежащее управление лицензиями.
Настройки службы Webex Calling
Крайне важно провести всесторонний анализ и настройку глобальных параметров сервиса в рамках системы.
Для начала зайдите в систему и перейдите в раздел настроек. Внимательно изучите каждый настраиваемый параметр, включая, помимо прочего, конфигурацию внутреннего набора номера, параметры экстренных вызовов, политики маршрутизации вызовов, управление голосовой почтой и настройки устройства по умолчанию.
Отрегулируйте эти глобальные настройки в соответствии с политикой вашей организации и проектными решениями.
Также, настройки параметров и шаблоны пользователей и приложений.
Пилотная миграция
На этапе внедрения выполнение пилотной миграции является критически важным этапом для подтверждения перехода с на . В рамках этого пилотного проекта на платформу будет подключена репрезентативная группа пользователей из одного или нескольких местоположений, что обеспечит соответствие выбранной популяции разнообразным сценариям использования и организационным ролям. Параллельно с миграцией пользователей необходимо перевести основные сервисы для совместной работы, включая голосовую почту, автоответчики, очереди вызовов и группы переадресации, на их аналоги для обеспечения непрерывности бизнеса и функциональности сервисов.
В пилотном проекте по миграции следует использовать ту же комбинацию инструментов, предоставляемых Cisco, и сторонних утилит для миграции, которая планируется для более широкого внедрения в организации, обеспечивая тщательную проверку процессов, рабочих процессов автоматизации и точек интеграции в репрезентативных условиях.
Основные цели этого пилотного проекта двояки: Во-первых, проверить и усовершенствовать сквозные процессы перехода, включая рабочие процессы предоставления доступа пользователям, процедуры миграции данных и конфигурации конечных точек; и во-вторых, всесторонне проверить функциональность перенесенных сервисов в реальных условиях эксплуатации.
Поэтапный подход позволяет проектной команде выявлять и устранять любые технические или процедурные проблемы в контролируемой среде, собирать отзывы пользователей о работе с новой платформой, оценивать эффективность выбранных инструментов миграции и убедиться в правильности методологии миграции, прежде чем приступать к более широкому внедрению в организации.
Информация, полученная в ходе этого пилотного этапа, имеет решающее значение для оптимизации последующих этапов миграции и обеспечения плавного перехода с минимальными рисками для всего предприятия.
Закупка PSTN
Для подключения к телефонной сети общего пользования (PSTN) сначала выберите вариант подключения к PSTN в настройках.
Если организация планирует поддерживать гибридное двойное управление вызовами ( фаза 1 на рисунке Поэтапный переход к вызову: В случае гибридных и облачных решений( временно или на неопределенный срок) им потребуется развернуть один или несколько локальных шлюзов для локальной телефонной сети общего пользования (PSTN), чтобы обеспечить возможность совершения звонков между конечными точками.
Если конечной целью является полный переход ( фаза 2) в облако, включая телефонную сеть общего пользования (PSTN), то для PSTN потребуется либо тарифный план Cisco Calling Plan, либо опция Cloud Connect.
Перед настройкой телефонных номеров в системе, пожалуйста, свяжитесь с выбранным вами провайдером для заказа и переноса номеров. Заказ телефонных номеров или инициирование портовых заказов — это лишь... required/possible для локальной телефонной сети общего пользования (PSTN) и облачного подключения (Cloud Connect). Для тарифных планов Cisco Calling Plan оформление заказа и перенос номера инициируются из Control Hub сразу после создания местоположения, а также в странах, где доступны тарифные планы Cisco Calling Plan. Для получения дополнительной информации о тарифных планах Cisco Calling см. Начало работы с тарифными планами Cisco.
В рамках внедрения телефонной сети общего пользования (PSTN) убедитесь, что ваш провайдер включил как входящие, так и исходящие звонки по PSTN для вашего местоположения. Кроме того, выполните тестовые звонки, чтобы убедиться в правильности маршрутизации вызовов через выбранное вами соединение PSTN.
Настройка местоположений
Перед добавлением пользователей и устройств необходимо настроить места совершения вызовов. Для каждого местоположения необходимо ввести действительный адрес улицы. В США и Канаде этот адрес проверяется и используется платформой для отправки информации о местоположении PIDF-LO для экстренных вызовов.
При настройке местоположений, использующих локальную телефонную сеть общего пользования (PSTN), необходимо соответствующим образом настроить локальные шлюзы. В этом случае для каждого локального шлюза необходимо создать транк и группу маршрутов, после чего группа маршрутов назначается в качестве варианта подключения к телефонной сети общего пользования (PSTN) для данного местоположения. Компания Cisco настоятельно рекомендует всегда выбирать группу маршрутов в качестве варианта подключения к телефонной сети общего пользования (PSTN), поскольку такой подход позволяет легко добавлять дополнительные каналы в будущем, обеспечивая масштабируемость и резервирование. Компания Cisco также рекомендует включить поддержку двойной идентификации и P-Charge-Info на каждом транке телефонной сети общего пользования (PSTN), поскольку это упрощает идентификацию плательщика за исходящие прямые или переадресованные вызовы. Если ваш оператор PSTN использует другой заголовок для выставления счетов, вы можете скопировать информацию из заголовка P-Charge-Info на локальном шлюзе в необходимый заголовок для выставления счетов.
Для местоположений, использующих Cloud Connect или тарифный план Cisco Calling Plan в качестве варианта подключения к телефонной сети общего пользования (PSTN), просто выберите соответствующий вариант PSTN для данного местоположения во время настройки. Если в данном месте используется Cloud Connect или локальная сеть PSTN, вам потребуется добавить номера телефонов, заказанные на предыдущем шаге. Номера можно добавить как неактивные, если вы не хотите, чтобы они сразу включались в маршрутизацию вызовов; вы можете активировать эти номера позже, когда они будут назначены пользователям или функциям.
Важно всегда указывать основной номер телефона для каждого местоположения. Основной номер может быть присвоен либо пользователю, либо функции, например, автоматическому секретарю. Чтобы включить голосовую почту в данном месте, обязательно укажите пилотный номер голосовой почты, также известный как номер голосового портала.
Дополнительные настройки для определения местоположения при вызове включают в себя настройку параметров экстренного вызова, таких как номер для обратного вызова, параметры уведомлений и расширенные функции экстренного вызова. Также следует проверить и скорректировать настройки записи, языковые предпочтения и конфигурацию устройств в соответствии с требованиями каждого местоположения. Если ваша организация использует сокращенный внутрисетевой набор номера с корпоративными номерами, не забудьте настроить уникальный код местоположения в параметрах внутреннего набора номера. Наконец, если для совершения внешних звонков требуется цифра для исходящего вызова, обязательно укажите это в настройках внешних звонков. При настройке исходящей кодовой цифры Cisco рекомендует включить принудительное применение исходящей кодовой цифры для обеспечения согласованности.
Интеграция с локальной системой управления вызовами.
Для интеграции с локальной системой управления вызовами необходимо настроить транки, группы маршрутизации, корпоративные планы набора номера, а также параметры местоположения и глобальные настройки. Для начала настройте каналы связи и локальные шлюзы, предназначенные для подключения к локальной системе управления вызовами; этот шаг необходим только в том случае, если требуются выделенные каналы связи. Если существующих каналов связи и групп маршрутизации достаточно для вашей конфигурации, их можно повторно использовать для локального межсоединения без дополнительной настройки.
После создания каналов связи и групп маршрутизации перейдите к созданию корпоративных планов набора номера и назначьте соответствующую группу маршрутизации в качестве пункта назначения для каждого плана набора номера. При интеграции нескольких локальных систем управления вызовами, соединенных через разные каналы связи, потребуется несколько планов набора номера. Важно убедиться, что эти планы набора номера содержат только те шаблоны, которые необходимы для маршрутизации вызовов к абонентам, находящимся в локальной сети.
Если ваша система требует поддержки маршрутизации с неизвестными добавочными номерами, эту функцию следует включить на уровне местоположения. Кроме того, при активации маршрутизации неизвестных добавочных номеров необходимо указать максимальную длину неизвестного добавочного номера в разделе Маршрутизация вызовов между помещениями настроек служб вызова в . Это обеспечивает бесперебойную маршрутизацию вызовов и надлежащую обработку сценариев набора номера по добавочному номеру в вашей интегрированной среде.
Перенос пользователей партиями.
При переносе пользователей из одной системы в другую может оказаться невозможным переместить всех пользователей одновременно. Это может быть вызвано множеством причин, включая, помимо прочего, количество сайтов или пользователей, а также время, необходимое для перехода сайта на новую платформу. and/or группа пользователей одновременно, ограниченные ИТ-ресурсы или ресурсы сайта для поддержки периода внесения изменений, продолжительность периода внесения изменений, сложность изменений и т. д.
При поэтапной миграции пользователей крайне важно определить, каких пользователей необходимо мигрировать одновременно в одной и тойже группе. Основная цель — объединить пользователей, которые зависят друг от друга в отношении используемых сервисов и функций. Вам необходимо убедиться, что все функции обработки звонков (например, очереди звонков) полностью работоспособны, как и до перехода на новую версию.
Даже если вы реализуете взаимодействие между локальными шлюзами и самими шлюзами, вы не сможете разделить общие сервисы или функции через это соединение. Следовательно, необходимо выявить зависимости между пользователями, анализируя такие характеристики, как:
-
Мониторинг других пользователей с помощью BLF
-
В рамках одной и той же охоты пилот, очередь вызовов и т. д.
-
линия, к которой предоставлен совместный доступ
-
Используя функцию перехвата звонка
-
Используя те же номера колл-центра
-
Внутренняя связь
-
Executive/Admin.
Примером может служить пользователь, входящий в группу поиска, которая находится в процессе перевода на другую платформу. Этот пользователь перейдет в состав группы Hunt Group и будет взаимодействовать со всеми другими членами этой группы. Таким образом, после перехода на новую платформу Hunt Group и ее сотрудники смогут успешно отвечать на звонки.
Это становится более сложной задачей, когда пользователи подключены к разным группам пользователей для использования различных услуг и функций связи. Для этого потребуется одновременно перевести на новую систему более одной группы пользователей и одну службу связи.
Используйте результаты работы инструмента Migration Insights или стороннего инструмента, который вы использовали на этапе подготовки для определения того, каких пользователей и функции следует сгруппировать вместе. Полученные данные следует использовать для разработки плана миграции, и они позволят вам понять, как сгруппировать пользователей и функции, которые необходимо перенести одновременно.
Ключевые этапы при переводе группы пользователей следующие:
-
Определение пользователей для совместной миграции.
-
Убедитесь, что все пользователи зарегистрированы.
-
Убедитесь, что все номера телефонных номеров (TN) для пользователей существуют.
-
Проверьте правильность формата номера телефона в телефонном справочнике.
-
Убедитесь, что шаблоны лицензирования и настроек для групп пользователей заданы правильно.
-
Проверка или настройка всех служб и функций вызовов для группы пользователей (до или во время перехода, в зависимости от ситуации).
-
В корпоративном справочнике добавьте пользователей в группу пользователей, которым разрешены звонки.
-
Инструменты Use Tools — инструменты для миграции пользователей и функций. and/or сторонние инструменты
-
Disable/Delete user/device номер справочника и звонки features/services после перехода.
После миграции группы пользователей протестируйте подгруппу пользователей, чтобы убедиться в корректной работе всех функций и сервисов связи. Если функции вызова, такие как очередь вызовов, группы поиска и т. д., передаются вместе с группой пользователей, необходимо проверить корректность работы этих служб вызова.
Рабочие пространства
В данном контексте рабочее пространство — это общее место (например, конференц-зал, переговорная комната или рабочее место общего пользования), которому могут быть назначены устройства, добавочные номера и пользователи. В отличие от традиционных телефонов Unifed CM, рабочие места здесь:
-
Ориентированность на местоположение: привязан к физическому пространству.
-
Гибкая совместимость с устройствами: Может включать одно или несколько устройств (настольные телефоны, доски и т. д.).
После того как рабочие пространства будут определены в рамках перехода на новую систему, их можно добавить в раздел «Устройства». Каждому рабочему пространству необходимо назначить устройство, и если они уже находятся в Unified CM, их необходимо сбросить или повторно настроить. Можно включать или отключать такие функции, как голосовая почта, переадресация вызовов и перехват вызовов, а также применять политики для видеозвонков, парковки вызовов и мобильности по мере необходимости. Протестируйте каждое рабочее пространство, совершая внутренние и внешние звонки, проверяя видеосвязь, конференц-связь и функции мобильной связи. Наконец, сообщите пользователям о любых применимых процедурах, касающихся рабочих устройств и бронирования.
Для получения дополнительной информации о рабочих пространствах в , см. Рабочие пространства.
Устройства обеспечения
Телефоны, которые в настоящее время зарегистрированы в облачной сети, необходимо будет перенести в новую сеть в рамках перехода на облачные сервисы. Чтобы максимально упростить миграцию и свести к минимуму вероятность сбоев, Cisco рекомендует одновременно переносить физические площадки или подразделения. Однако из-за зависимости функций вам может потребоваться переносить пользователей партиями. Более подробную информацию см. в разделе Перенос пользователей партиями.
Все поддерживаемые телефоны, с которых вам необходимо перейти, нужно будет настроить как пользователя или рабочее пространство, а физический телефон необходимо будет перенастроить для регистрации в системе. Кроме того, для телефонов серий 7800 и 8800 необходимо обновить прошивку с версии Enterprise до версии Multiplatform Phone (MPP). Этот процесс включает в себя загрузку переходного программного обеспечения перед загрузкой программного обеспечения MPP, необходимого для регистрации. Для этого также требуется соответствующая миграционная лицензия. За последние несколько лет компания Cisco усовершенствовала этот процесс, чтобы упростить обновление корпоративных телефонов до прошивки MPP. Для получения дополнительной информации о шагах по обновлению микропрограммы см. Преобразование IP-телефонов Cisco серий 7800 и 8800 между версиями Enterprise и MPP.
В дополнение к шагам, описанным в этой статье, имеется встроенный инструмент Перенос телефона на Webex Calling, который можно использовать для переноса телефонов 7800 и 8800 с прошивки Enterprise на MPP. Этот инструмент также позволяет добавлять телефоны и назначать их соответствующим пользователям или рабочим местам. Для получения дополнительной информации об использовании инструмента см. Перенос данных с телефона.
Для всех телефонов серии 9800, зарегистрированных с указанной выше прошивкой, требование о миграции не применяется. Эти телефоны работают под управлением PhoneOS, которая поддерживается как [название операционной системы], так и [название операционной системы]. Для перевода этих телефонов в режим Webex Calling вам потребуется добавить их в Webex Calling, назначить их пользователю или рабочему пространству, а затем выполнить сброс телефонов до заводских настроек. Последовательность загрузки PhoneOS для регистрации На рисунке ниже показана последовательность загрузки PhoneOS и то, как телефон будет регистрироваться после добавления в систему, даже если телефон все еще находится в режиме инициализации and/or Используются параметры DHCP (например, 150).
Поддерживается сброс до заводских настроек устройств PhoneOS для обеспечения автоматической настройки без участия пользователя. Администраторы могут удаленно сбросить до заводских настроек телефоны 9800 и 8875 через страницы администрирования CUCM, что исключает необходимость физического доступа к телефонам для их настройки. Данная функция поддерживается в пакетах обновлений устройств, выпущенных начиная с 9 сентября 2025 года:
-
CUCM v15 - Unified Communications Manager Версия 15
-
CUCM v14 - Unified Communications Manager Version 14.
Для получения дополнительной информации о процессе регистрации для серии 9800 см. Процесс регистрации.
Помимо IP-телефонов Cisco, может потребоваться настройка других устройств, таких как аналоговые телефонные адаптеры (ATA), беспроводные (Wi-Fi, DECT) телефоны, видеоустройства, голосовые шлюзы, а также устройства и телефоны стороннихпроизводителей . У многих из этих устройств отсутствует возможность обновления прошивки, как у IP-телефонов, для перехода с корпоративной прошивки на облачную. Следовательно, вам потребуется настроить каждое из этих устройств в Центре управления. На некоторые из них переход невозможен, и потребуется замена на эквивалентную модель (например, ATA). 191/192) а для других потребуется ручная перенастройка and/or изменения в программном обеспечении.
- Голосовые шлюзы - Чтобы перенести локальный шлюз, см. Перенос локального шлюза.
Для получения дополнительной информации о настройке голосового шлюза VG400, VG410 или VG420 в Control Hub см. Локальный шлюз
-
Аналоговый телефонный адаптер (ATA) - Чтобы начать работу с Cisco ATA 191 и 192, см. Cisco ATA.
-
Беспроводной телефон Wi-Fi - Для интеграции беспроводных телефонов 840 и 860 см. Интеграция беспроводного телефона Webex.
-
Беспроводные телефоны DECT - Чтобы начать работу с вашей новой серией Cisco IP DECT 6800, см. Cisco IP DECT.
Для создания и управления цифровой сетью DECT в Control Hub см. Управление сетью DECT
Для получения дополнительной информации о Cisco IP DECT 6800 см. Руководство по развертыванию
-
Устройства и телефоны сторонних производителей - Работа с поставщикамисторонних производителей на device/phone требования и процесс их миграции или замены для обеспечения поддержки.
Настройка функций
Все необходимые функции вызовов должны быть настроены до или во время перехода. Как обсуждалось в разделе «Пакетная миграция пользователей», функции вызова необходимо настраивать и переводить одновременно с переводом пользователей, которые ими пользуются.
Подробную информацию о настройке каждой из функций см. в соответствующих статьях справки по настройке.
-
Автоматические операторы — Для управления автоматическими операторами см. Автоматические операторы
-
Парковка вызовов — Для управления парковкой вызовов см. Парковка вызовов
-
Перехват вызова — Чтобы настроить группу перехвата вызова, см. Перехват вызова
-
Очередь вызовов - Для настройки очереди вызовов см. Очередь вызовов
-
Группы поиска — Для управления группами поиска см. Управление группами поиска
-
Режимы работы — Для вызова маршрутизации в зависимости от режимов работы см. Вызов маршрутизации в зависимости от режимов работы
-
Группы пейджинга — Чтобы настроить группу пейджинга, см. Настройка группы пейджинга
-
Записи — Чтобы управлять записью звонков, см. Управление записями
-
Доступ по одному номеру — Чтобы настроить доступ по одному номеру (Office Anywhere), см. Настройка доступа по одному номеру
-
Группа голосовой почты — Чтобы управлять общей голосовой почтой и входящим факсом для , см. Управление голосовой почтой.
Тестирование перед допуском
Приемочное тестирование гарантирует, что перенесенная среда соответствует функциональным требованиям, работает должным образом и обеспечивает бесперебойную работу пользователей во всех коммуникационных процессах. Процесс проверки многогранен и охватывает все аспекты, от предоставления доступа пользователям и присвоения номеров до эксплуатационных характеристик расширенных функций вызовов.
В этом разделе приведены примеры и выделены ключевые аспекты, которые следует учитывать при приемочных испытаниях; однако он не претендует на роль исчерпывающего или всеобъемлющего контрольного списка.
Предоставление доступа пользователям и присвоение номеров
Фундаментальным аспектом приемочного тестирования является проверка того, что все пользователи точно и полно зарегистрированы в системе. Для этого требуется тщательное сравнение исходного каталога () с вновь созданной базой пользователей, чтобы убедиться, что каждая учетная запись пользователя, а также связанные с ней атрибуты, такие как добавочные номера и назначения прямых входящих вызовов (DID), были корректно перенесены. Полнота предоставления ресурсов имеет решающее значение не только для обеспечения работоспособности в первый день, но и для дальнейшего администрирования и поддержки.
Проверка присвоения номеров включает в себя подтверждение того, что каждому пользователю присвоен правильный добавочный номер и внешний номер, а также что эти номера корректно маршрутизируются как во внутренних (внутри сети), так и во внешних (телефонная сеть общего пользования) потоках вызовов. Крайне важно проверить наличие каких-либо наложений, отсутствующих назначений или неправильных настроек, которые могут привести к ошибкам маршрутизации вызовов или перебоям в обслуживании.
Схемы обработки вызовов в телефонной сети общего пользования (PSTN) и отображение идентификатора вызывающего абонента.
Надежная процедура приемочного тестирования должна включать сквозную проверку потоков вызовов в телефонной сети общего пользования (PSTN). Это включает в себя как входящие, так и исходящие звонки. При входящих звонках в телефонную сеть общего пользования (PSTN) группа тестирования должна подтвердить, что звонки доставляются на соответствующие конечные точки, будь то отдельные пользователи, очереди звонков, группы переадресации или автоответчики. Для успешного совершения исходящих вызовов в телефонную сеть общего пользования (PSTN) необходимо уделить особое внимание правильной передаче и отображению информации об идентификаторе вызывающего абонента. Это включает в себя обеспечение отображения правильного имени и номера звонящего для внешних получателей в соответствии с политикой организации и нормативными требованиями.
В ходе тестирования также следует рассмотреть сценарии переключения на резервный сервер, такие как обработка недоступных конечных точек или сбоев в сети. Это помогает подтвердить, что механизмы резервного копирования и альтернативные маршруты функционируют должным образом, обеспечивая непрерывность и надежность обслуживания.
Схемы внутрисетевых вызовов
Внутренние, или внутрисетевые, потоки звонков составляют основу корпоративной связи. Приемочное тестирование в этой области подтверждает корректность маршрутизации звонков между пользователями внутри организации, а также работоспособность таких функций, как переадресация вызовов, удержание, переадресация и конференц-связь. Необходимо подтвердить целостность планов набора номера, связь между внутренними номерами и поддержку корпоративных политик обработки вызовов.
Обработка пользовательских вызовов и проверка функциональности.
Важным аспектом приемочного тестирования является проверка того, как пользователи обрабатывают звонки с помощью и поддерживаемых стационарных телефонов. Этот процесс направлен на подтверждение того, что повседневные рабочие процессы обработки звонков интуитивно понятны и надежны, а также на обеспечение беспрепятственного доступа пользователей к основным функциям, необходимым для выполнения их обязанностей. В ходе тестирования следует оценить удобство, с которым пользователи могут совершать и принимать звонки, управлять функциями удержания и возобновления вызова, а также выполнять как анонимные, так и консультативные переводы звонков. Также крайне важно убедиться, что переадресация вызовов, конференц-связь и другие расширенные функции, такие как удержание и возобновление вызовов или активация режима «Не беспокоить», доступны и работают бесперебойно.
При оценке удобства использования следует учитывать ясность интерфейса и скорость отклика, а также то, как пользователи взаимодействуют с историей звонков, голосовой почтой и встроенными справочниками. Дополнительное внимание следует уделить возможности перевода активных вызовов между устройствами и эффективному использованию элементов управления вызовами в приложении или на физических телефонах. Конечная цель — обеспечить согласованность, эффективность и полную поддержку коммуникационных потребностей организации после миграции со стороны конечного пользователя.
Очередь вызовов. Опыт работы в качестве агента и супервайзера.
Очереди звонков часто используются для обработки большого объема входящих звонков. В данном случае приемочные испытания сосредоточены на нескольких аспектах. Во-первых, необходимо убедиться, что звонки распределяются между агентами в соответствии с настроенной логикой очереди, например, по принципу циклического распределения, по принципу наибольшего времени простоя или по принципу одновременного звонка. Необходимо проверить отображение вызовов в очереди на рабочих местах операторов на предмет ясности и удобства использования, чтобы операторы могли эффективно принимать, удерживать и переводить вызовы.
Руководителям следует оценить функциональность рабочего стола на предмет таких возможностей, как мониторинг в реальном времени, перехват звонков и аналитика или получение информации о производительности очереди. Это включает, помимо прочего, проверку информационных панелей и инструментов отчетности, предоставляющих полезные данные о распределении звонков, активности операторов и показателях работы очереди.
Сервисные группы: Распределение вызовов
Группы поиска являются ключевым механизмом распределения вызовов между заранее определенными группами пользователей. Приёмочное тестирование должно подтвердить, что звонки направляются членам группы в соответствии с настроенным алгоритмом поиска, а также что сценарии переполнения, переадресации и отсутствия ответа обрабатываются в соответствии с проектом. Для обеспечения операционной согласованности и удовлетворенности пользователей крайне важно, чтобы членство в группах и поведение маршрутизации вызовов соответствовали ранее установленным параметрам.
Автосекретари: Объявления и работа с меню
Автоматические операторы представляют собой передовую линию автоматизированной обработки звонков. Тестирование должно охватывать воспроизведение объявлений, точность записанных приветствий и корректную работу древовидных меню. Выбор пунктов меню должен обеспечивать надежную переадресацию звонков в соответствующие отделы, к конкретным сотрудникам или по внешним номерам. Тестирование также должно включать сценарии с некорректными данными или превышением времени ожидания, чтобы подтвердить, что абоненты получают четкие инструкции или перенаправляются должным образом.
работа голосовой почты
Наконец, функциональность голосовой почты имеет решающее значение для удобства пользователя. В ходе приемочных испытаний необходимо убедиться в правильности назначения и доступности почтовых ящиков голосовой почты как внутри организации, так и удаленно. Необходимо подтвердить возможность записи, извлечения и управления сообщениями, а также доставку уведомлений.
Оптимизация
миграция телефонной сети общего пользования (PSTN) на Cloud Connect для
После того, как все конечные устройства и пользователи будут переведены на облачную связь, единственная цель Unified CM — выступать в качестве транзитного устройства между шлюзами телефонной сети общего пользования (PSTN) и через локальный шлюз. Исключение из схемы шлюзов PSTN, а также локального шлюза, путем использования Cloud Connect в качестве доступа к PSTN для всех пользователей Webex Calling, имеет ряд преимуществ, включая снижение затрат и повышение надежности. Для переноса локального доступа к телефонной сети общего пользования (PSTN) в Cloud Connect выполните следующие действия:
-
Cloud Connect для выбора партнеров.
Ознакомьтесь со списком партнеров Cloud Connect и выберите из доступных партнеров тех, кто находится в вашем регионе.
-
Для проверки используйте Cloud Connect.
Перед переключением доступа к телефонной сети общего пользования (PSTN) для определенных местоположений на Cloud Connect необходимо проверить и подтвердить возможность подключения к PSTN через выбранного партнера Cloud Connect. Для этого необходимо создать тестовую локацию и зарегистрировать в ней тестовых пользователей. После этого доступ к телефонной сети общего пользования (PSTN) для данного тестового местоположения устанавливается на партнера Cloud Connect, а затем с помощью тестовых телефонов проверяется подключение к PSTN. После успешной проверки тестовую площадку можно будет отключить.
-
Перенос номеров.
Для подготовки к переходу на Cloud Connect необходимо оформить заявку на перенос портов для всех номеров, которые в настоящее время назначены на абонентский канал телефонной сети общего пользования (PSTN). Все номера необходимо перенести к партнеру Cloud Connect. Для обеспечения доступности номеров между различными местоположениями необходимо одновременно перенести все номера всех местоположений.
-
Переключитесь на партнера Cloud Connect.
В день перехода доступ к телефонной сети общего пользования (PSTN) для всех местоположений должен быть настроен на использование облачного провайдера PSTN, и необходимо проверить входящее и исходящее соединение.
Как обсуждалось в разделе PSTN главы о проектировании, клиенты также могут на начальном этапе перехода перевести свой доступ к PSTN в Cloud Connect, используя транкинг PSTN для гибридных развертываний. Для получения дополнительной информации см. Транкирование PSTN для гибридных развертываний Webex Calling. В этом случае во время перехода доступ к телефонной сети общего пользования осуществляется через локальный шлюз, а после перевода всех пользователей на другую сеть никаких дополнительных шагов по миграции, связанных с телефонной сетью общего пользования, кроме вывода из эксплуатации и отключения локальных шлюзов, не требуется.
Оптимизация локальной инфраструктуры
После того, как все пользователи будут переведены на облачную регистрацию, а все конечные устройства — на облачную регистрацию (или будут выведены из эксплуатации), обновите соответствующую локальную инфраструктуру, поскольку теперь используется облачная связь. В число обновлений инфраструктуры входят:
-
Удалите записи DNS SRV для управления вызовами и сообщениями с локального DNS-сервера (серверов), включая cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Эти записи SRV больше не требуются для обнаружения клиентских сервисов.
-
Удалите связанные с периферией DNS SRV-записи из общедоступной DNS-системы, включая collab_edge._tls.<domain>. Эти записи SRV больше не требуются для обнаружения клиентскими сервисами служб на периферии для совместной работы.
-
Обновите все соответствующие диапазоны DHCP, удалив опции 66 и 150. TFTP/boot адреса серверов. Эти области действия больше не требуются для обнаружения и загрузки конфигурации управления вызовами конечных точек.
-
Update/remove соответствующие dial-peers в локальном режиме Gateway/CUBE Этот маршрут осуществляет вызовы к Unified CM и обратно. Эти узлы маршрутизации больше не требуются для маршрутизации вызовов в локальной сети.
-
Удалите или удалите все виртуальные машины узлов кластера. and/or серверы. При необходимости перераспределяйте вычислительные ресурсы и оборудование. Эти ресурсы больше не требуются для управления вызовами и работы периферийных служб.
-
Удалите или удалите все виртуальные машины узлов кластера. and/or серверы. При необходимости перераспределяйте вычислительные ресурсы и оборудование. Эти ресурсы больше не требуются для голосовой почты и служб унифицированных сообщений.
-
Уборка: После переноса доступа к телефонной сети общего пользования (PSTN) на облачную сеть PSTN, магистральные линии PSTN, шлюзы PSTN и локальный шлюз могут быть выведены из эксплуатации.
-
Для любого существующего локального решения E911 удалите все местоположения или номера, которые были перенесены, а после завершения полного перехода удалите виртуальные машины или серверы приложений. При необходимости перераспределяйте вычислительные ресурсы и оборудование. Эти ресурсы больше не требуются для экстренных вызовов и определения местоположения.
-
Номера телефонов (DN), принадлежащие перенесенным пользователям, следует размещать в скрытом разделе, чтобы избежать сбоев маршрутизации вызовов и обеспечить всем операторам связи приоритетный доступ к облачному пути для одних и тех же номеров телефонов.
-
В системе Horizon Mobility необходимо обновлять физическое местоположение, доступное для диспетчеризации, и сетевой элемент при каждом изменении. К числу действий, требующих обновления, относятся:
-
Замена сетевого коммутатора
-
Замена беспроводной точки доступа
-
изменения диапазона DHCP
-
Физические изменения внутри здания (если принимается решение о...) cubical/office)
-
Физическое расширение или сокращение офисного пространства внутри здания.
-
Используйте аналитику и методы устранения неполадок.
Предоставляет комплексные аналитические возможности и средства устранения неполадок, которые помогут вам визуализировать и отслеживать развертывание. Они охватывают качество медиаконтента, подробную историю звонков, очередь звонков, группы переадресации и аналитику автоответчика. Пример анализа качества медиаконтента показан на рисунке анализ качества медиаконтента.
В режиме устранения неполадок каждый совершенный вызов можно просмотреть с подробной информацией о ключевых проблемах, связанных с качеством мультимедиа и сигнализацией, что помогает выявить проблемы с мультимедиа, а также неудачные вызовы, как показано на рисунке устранение неполадок с качеством мультимедиа.
Функция устранения неполадок также может интегрироваться с другими продуктами Cisco, такими как коммутаторы ThousandEyes и Meraki, обеспечивая еще более расширенные возможности интеграции в Control Hub. Для получения дополнительной информации об использовании аналитики Webex Calling и устранении неполадок см. раздел « Устранение неполадок при звонках Webex Calling в Control Hub» .