По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Многим организациям необходимо предоставлять и поддерживать большое количество удаленных офисов.
Например:
Розничные сети могут иметь сотни или даже тысячи магазинов по всему миру.
Региональный банк может иметь сотни отделений и тысячи банкоматов.
Когда поставщики услуг фиксированной частной телефонной связи предлагали свои услуги в любом масштабе, такого рода проблемы решались с помощью large-scale и hub-and-spoke сетей. На рисунке показана hub-and-spoke сеть.
Сеть, показанная на рисунке выше, на самом деле довольно мала: три узла в центре удаленных сайтов могут представлять сотни или тысячи дополнительных узлов. Во многих реализациях (особенно старых) каналы связи между двумя маршрутизаторами-концентраторами, A и B, и удаленными устройствами, такими как C и N, являются двухточечными. Это означает, что на концентраторе-маршрутизаторе должен быть настроен интерфейс для каждого удаленного маршрутизатора, фильтры маршрутизации, фильтры пакетов и любые конфигурации Quality of Service. Это не только серьезная проблема с точки зрения конфигурации, но также трудно поддерживать тысячи отдельных соседей с точки зрения использования процессора и памяти.
Чтобы уменьшить объем вычислительной мощности, необходимой для обслуживания такой сети, протоколы были изменены, чтобы исключить обработку удаленных узлов, как если бы они были частью дерева. Вместо этого, эти модификации позволили рассматривать эти удаленные узлы, как если бы они были выходными или тупиковыми сетями. Еще одним шагом на пути к упрощению создания таких сетей и управления ими было использование интерфейса point-to-multipoint (с соответствующей базовой технологией, такой как Frame Relay) на концентраторах-маршрутизаторах. Когда соединения с удаленными узлами настроены как point-to-multipoint, концентраторы-маршрутизаторы A и B обрабатывают все периферийные устройства так, как если бы они находились в одном сегменте широковещательной передачи (фактически, как сегмент Ethernet). Однако каждый spoke маршрутизатор по-прежнему рассматривает свое соединение с маршрутизаторами-концентраторами как соединение point-to-point. Даже с этими модификациями создание и обслуживание таких больших сетей все еще очень сложно. Необходимо проложить каналы на каждый удаленный узел и управлять ими, необходимо настроить удаленное оборудование и управлять им, необходимо управлять конфигурацией маршрутизаторов-концентраторов и т. д.
Программно-определяемые глобальные сети (SD-WAN) изначально были разработаны для решения этой конкретной задачи. Идея DMVPN, зародившаяся в Dynamic Multipoint Virtual Private Network (DMVPN) от Cisco, заключалась в использовании туннелируемой оверлейной сети, работающей поверх общедоступного Интернета. Это позволило удаленным узлам использовать локально доступное подключение к Интернету, а не покупать канал для каждого узла, а также сократить время настройки и обслуживания за счет автоконфигурации и других инструментов.
SD-WAN - это еще один шаг вперед в концепции сети over-the-top. Решение SDWAN обычно строится с использованием нескольких компонентов:
Специализированное устройство или виртуализированная служба для замены маршрутизаторов, обычно размещаемых в центральных и оконечных точках.
Модифицированная версия стандартного протокола маршрутизации для обеспечения доступности (и, возможно, одного из показателей жизнеспособности цепи) и передачи политик по сети.
Реализация либо IP-безопасности (IPsec), либо безопасности транспортного уровня (TLS) для обеспечения безопасной туннельной передачи между оконечными устройствами.
Контроллер для мониторинга состояния каждого виртуального канала, приложений, использующих канал, и количества полезной пропускной способности по сравнению с объемом трафика, а также для динамической корректировки потока трафика и параметров QoS для оптимизации работы приложений в over-the-top сети виртуальной сети.
Есть много разных способов реализации SD-WAN, например:
SD-WAN может заменить "последнюю милю". Вместо того чтобы устанавливать схему на каждом удаленном узле, вы можете использовать решения SD-WAN для достижения точки обмена или коллокации, а затем передавать трафик через более традиционную службу через провайдера обратно к маршрутизаторам-концентраторам (это форма backhaul).
SD-WAN может заменить весь путь от сети организации до удаленных узлов.
SD-WAN можно использовать для привлечения трафика в облачную службу, где может быть выполнена некоторая предварительная обработка или развернуты некоторые приложения, причем только трафик, который должен быть перенесен в сеть организации, переносится остальная часть пути в маршрутизаторы-концентраторы.
Существуют компромиссы с SD-WAN и другими передовыми решениями, как и с любой другой сетевой технологией. Например, передача трафика корпоративного удаленного узла через "обычное" публичное интернет-соединение (или пару услуг, или какую-то другую услугу, завершенную Ethernet) может быть "достаточно хорошей" в некоторых ситуациях, но провайдеры, как правило, лучше относятся к трафику в более дорогих услугах (что вполне естественно), особенно при отключениях.
Мы продолжаем постигать основы важнейшего протокола, использующегося в IP телефонии и в сегодняшней статье рассмотрим основные сценарии установления соединения, а также работу основных компонентов протокола SIP. Протокол SIP имеет 3 стандартных сценария установления соединения, которые отличаются наличием и участием тех или и иных устройств.
Пример №1
Установление соединения между User Agent’ами, когда в сети отсутствуют всякого рода серверы. Простейшим примером является сеанс связи, в котором принимают участие только два пользователя. Терминальное оконечное оборудование называется UA (User Agent), когда одновременно совмещает в себе функции UAС (User Agent Client) - клиента и UAS (User Agent Server) - сервера. В данном случае сценарий установления соединения будет выглядеть так: .
Абонент A снимает телефонную трубку и набирает номер Абонента B, тем самым генерируя запрос INVITE , который содержит описание сеанса связи.
Устройство абонента B отвечает сообщением 100 Trying , которое означает, что запрос находится в обработке.
После обработки запроса устройство абонента B уведомляет его о входящем вызове, а в сторону абонента A отвечает сообщением 180 Ringing, что соответствует контролю посылки вызова.
Абонент B снимает телефонную трубку, отвечая сообщением 200 OK, означающее успешную обработку запроса.
Устройство абонента A прекращает прием контроля посылки вызова и посылает подтверждение ACK, означающее прием ответа на запрос INVITE.
Между абонентами устанавливается разговорная фаза. Происходит передача голосового трафика по протоколу RTP (Real-Time Transfer Protocol).
Важно отметить, что SIP не участвует в непосредственной передаче голоса, а лишь предоставляет условия и способы согласования открытия неких каналов обмена на основе других протоколов, в данном случае - RTP.
Абонент A кладет телефонную трубку, тем самым инициируя завершение передачи голосового потока. Устройство абонента A генерирует запрос Bye, в сторону устройства абонента B.
Устройство абонента B отвечает сообщением 200 OK, означающем успешную обработку запроса Bye.
Терминальное оконечное оборудование абонентов A и B возвращается в исходное состояние.
Однако, данный сценарий установления соединения является самым примитивным, можно даже сказать частным. Обычно в сети присутствует SIP прокси сервер, который принимает и обрабатывает запросы от пользователей и выполняет, соответствующие этим запросам, действия.
Пример №2
Рассмотрим сценарий установления соединения между двумя пользователями.
В данном случае задачу поиска и приглашения абонента выполняет Прокси сервер, вызывающему пользователю необходимо знать только постоянный номер вызываемого абонента. Отметим, что функции прокси сервера выполняет офисная телефонная станция
Как видно из рисунка, процесс установления и разъединения соединения происходит аналогично первому сценарию, только в качестве посредника при передаче сообщений протокола SIP выступает SIP Proxy.
Пример №3
Допустим, что в сети имеется множество пользователей, число которых постоянно пополняется. Они могут менять свое фактическое положение, ставить переадресацию (redirection) на другой номер, проводить конференц – звонки и др. Для предоставления подобных сервисов требуется наличие в сети соответствующих серверов, поддерживающих ту или иную функцию.
Сервер регистрации (Registration Server) для аутентификации и авторизации пользователей.
Сервер определения местоположения (Allocation Server) для определения реального местонахождения пользователей.
Сервер переадресации (Redirect Server) для перенаправления звонков на другие номера, в случае если пользователь настроил данную функцию.
Сервер регистрации это логический элемент и обычно его функции выполняет SIP Proxy, такие совмещенные сервера называют Registar. SIP Proxy может также выполнять функции серверов определения местоположения и переадресации, такое совмещение полезно в плане масштабируемости сети.
Приведем пример, когда сеть содержит некий комбинированный SIP Proxy, который поддерживает все функции, описанные выше. Допустим, что новый, еще не зарегистрированный пользователь A,вызывает пользователя B, который уже прошел процедуру авторизации.
Новый User Agent A посылает серверу сообщение REGISTER , которое инициирует процесс регистрации.
Т.к User Agent A ещё не зарегистрирован, то сервер Registar отвечает сообщением 401 Unauthorized
Тогда User Agent A посылает серверу сообщение REGISTER + login, содержащее логин и пароль.
Сервер Registar отвечает сообщением 200 OK, на этом процесс регистрации закончен. Теперь пользователь А авторизован на сервере и может совершать звонки.
User Agent A инициирует установление связи с пользователем B сообщением INVITE.
На данном этапе включаются функции серверов определения местоположения и переадресации, сервер отвечает сообщением 302 Moved Temporarily, означающее, что вызываемый абонент временно сменил местоположение и содержащее его новые данные для установления соединения.
User Agent A отвечает сообщением ACK, которое означает прием ответа от Redirect сервера на запрос INVITE.
Далее User Agent A инициирует новое установление соединения напрямую к пользователю B, в соответствии с полученными данными.
Как видно из рисунка дальнейший процесс соединения происходит аналогично сценарию 1.
В следующей статье мы подробно рассмотрим основные модификации протокола SIP для взаимодействия с традиционными телефонными сетями, использующими сигнализацию ОКС-7.
Привет! Мы в одной из предыдущих статей уже рассказывали про то, как зарегистрировать IP-телефон в CME (CUCME) , работающий по протоколу SCCP. Сегодня поговорим про то, как зарегистрировать Third Party SIP телефоны (то есть от других производителей) в CME.
Настройка
Для начала инициализируем SIP звонки и сервер регистрации:
CME(config)#voice service voip
CME(conf-voi-serv)#allow-connections sip to sip
CME(conf-voi-serv)#sip
CME(conf-serv-sip)#registrar server
voice service voip – вход в режим конфигурации voip;
allow-connections sip to sip – по-умолчанию IOS не разрешает SIP вызовы;
sip – команда sip, введенная в меню конфигурации voice service voip позволяет использовать команды для настройки SIP;
registrar server – определяет CME как сервер регистрации для сторонних SIP телефонов;
Далее применим глобальные настройки CME:
CME(config)#voice register global
CME(config-register-global)#mode CME
CME(config-register-global)#max-dn 10
CME(config-register-global)#max-pool 10
CME(config-register-global)#source-address 192.168.1.1 port 5060
CME(config-register-global)#tftp-path flash:
CME(config-register-global)#authenticate register
CME(config-register-global)#camera
CME(config-register-global)#video
CME(config-register-global)#create profile
voice register global– вход в режим глобальных настроек CME;
mode CME – устанавливает поведение устройства как CME;
max-dn [X] – максимальное количество номеров dn (directory number);
max-pool [Y] – максимальное количество телефонов;
source-address X.X.X.X port Y – указываем откуда будут загружаться конфигурационные файлы для IP-телефонов;
tftp-path flash: - корневой каталог TFTP это flash память маршрутизатора;
authenticate register – аутентификация для телефонов, находящихся в другой подсети;
camera – команда включает камеру;
video – команда включает видео;
create profile – создает конфигурационные файлы;
После этого создадим номер:
CME(config)#voice register dn1
CME(config-register-dn) number 1001
voice register dn1 – создание ephone-dn с меткой 1;
number [номер] – указываем номер;
Далее зарегистрируем SIP телефон в CME:
CME(config)#voice register pool 1
CME(config-register-pool)#id mac 0123.45ab.cdef
CME(config-register-pool)#type 9971
CME(config-register-pool)#number 1 dn 1
CME(config-register-pool)#username admin password admin
CME(config-register-pool)#codec g711ulaw
CME(config-register-pool)#dtmf-relay rtp-nte
CME(config-register-pool)#camera
CME(config-register-pool)#video
voice register pool [X] – режим конфигурации SIP телефонов (тут pool означает телефоны);
id mac XXXX.XXXX.XXXX – mac-адрес устройства (для third-party можно ввести любой);
type – указываем тип телефона, для third party эта команда не обязательна;
number [X] dn [Y] – назначаем на копку X номер Y;
username XXXX password YYYY – включает аутентификацию для SIP телефонов с указанными данными;
codec g711ulaw – указываем используемый кодек;
dtmf-relay rtp-nte – указываем тип DTMF-relay;
Теперь переходим к настройке на самом third-party софтфоне (на примере софтфона 3CX):
Здесь необходимо заполнить следующие поля:
Extension – номер, который мы создали на CME;
ID – username, созданный на CME;
Password – пароль, созданный на CME;
IP of your PBX/SIP server – IP адрес CME;