Настройка sip телефонии skype for business

Обновлено: 04.07.2024

Прямые подключения SIP поддерживаются между Skype для бизнеса Server шлюзами PSTN и IP-PBX в Корпоративная голосовая связь.

Вы можете использовать прямые подключения SIP для подключения Skype для бизнеса Server к следующему:

Чтобы реализовать прямое подключение SIP, необходимо выполнить, по существу, те же действия по развертыванию, что и при реализации магистрали SIP. В обоих случаях подключение реализуется с помощью внешнего интерфейса сервера-посредника. Единственное отличие заключается в том, что магистрали SIP подключаются к внешнему объекту, такому как шлюз поставщика услуг Интернет-телефонии, и устанавливаются прямые подключения SIP к внутреннему объекту внутри локальной сети, например к шлюзу телефонной сети общего пользования (ТСОП) или УАТС на базе протокола IP.

Параметры развертывания прямого SIP

Skype для бизнеса Server Stand-Alone

Если в организации используется одно из развертывается, описанное в этом разделе, вы можете использовать Skype для бизнеса Server в качестве единственного решения телефонии для части или всей организации. В этом разделе подробно описаны следующие развертывания:

Постепенное развертывание: Этот параметр предполагает, что у вас есть существующая инфраструктура обмена частными филиалами (PBX), и вы намерены постепенно внедрять Корпоративная голосовая связь для небольших групп или групп в вашей организации.

Развертывание только для voIP: этот параметр предполагает, что вы Корпоративная голосовая связь развертывание на сайте, где нет традиционной инфраструктуры телефонии.

Постепенное развертывание

При постепенном развертывании Skype для бизнеса Server является единственным решением телефонии для отдельных групп или отделов, в то время как остальные пользователи в организации продолжают использовать PBX. Эта стратегия постепенного развертывания предоставляет один из способов внедрения IP-телефонии в ваше предприятие с помощью управляемых пилотных программ. Группы, чьи потребности в коммуникации лучше всего обслуживаются Microsoft Unified Communications, перемещаются в Корпоративная голосовая связь, в то время как другие пользователи остаются на существующем PBX. Дополнительные группы можно перенести в Корпоративная голосовая связь, если это необходимо.

Дополнительный вариант рекомендуется, если у вас есть четко определенные группы пользователей, которые имеют общие требования к связи и которые поддаются централизованному управлению. Этот параметр также эффективен, если у вас есть группы или отделы, которые распространяются по широким географическим областям, где экономия в междугородных зарядах может быть значительной. На самом деле этот параметр полезен для создания виртуальных команд, члены которых могут быть разбросаны по всему миру. Вы можете создавать, изменять или расформировать такие группы в быстром реагировании на изменение бизнес-требований.

На следующем рисунке показана общая топология для развертывания Корпоративная голосовая связь за PBX. Это рекомендуемая топология для постепенного развертывания.

Дополнительный параметр развертывания

Если вы подключали развертывание Skype для бизнеса Server к сертифицированным партнерам direct SIP, шлюз открытой телефонной сети (PSTN) между сервером-посредником и PBX не требуется. Список сертифицированных партнеров прямого SIP см. в программе открытой межоперабельности Microsoft Unified Communications.

Путь мультимедиа, показанный на этом рисунке, имеет включен обход мультимедиа (рекомендуемая конфигурация). Если вы решите отключить обход мультимедиа, путь мультимедиа будет проходить через сервер-посредник.

В этой топологии для Корпоративная голосовая связь. Шлюз PSTN связывает группу голосовой связи с протоколом Интернета (VoIP) с поддержкой PBX. Пользователи, которые включены для Корпоративная голосовая связь, включая удаленных сотрудников, общаются по сети IP. Вызовы Корпоративная голосовая связь пользователей в PSTN и коллегам, которые не включены для Корпоративная голосовая связь, будут перенастроен в соответствующий шлюз PSTN. Вызовы от коллег, которые по-прежнему находятся в системе PBX, или от звонивших в PSTN, перенадвигаются в шлюз PSTN, который передает вызовы в Skype для бизнеса Server для маршрутивки.

Существует две рекомендуемые конфигурации для подключения Корпоративная голосовая связь к существующей инфраструктуре PBX для обеспечения связи: Корпоративная голосовая связь за PBX и Корпоративная голосовая связь перед PBX.

Корпоративная голосовая связь За PBX

Когда Корпоративная голосовая связь развертывается за PBX, все вызовы из PSTN поступают в PBX, который передает вызовы Корпоративная голосовая связь пользователям на шлюз PSTN и вызывает пользователей PBX в PBX.

Корпоративная голосовая связь перед PBX

Когда Корпоративная голосовая связь развертывается перед PBX, все вызовы поступают на шлюз PSTN, который передает вызовы для Корпоративная голосовая связь пользователей Skype для бизнеса Server и звонки для пользователей PBX в PBX. Вызовы в PSTN как Корпоративная голосовая связь, так и пользователей PBX перенапрягаются по сети IP в наиболее экономичный шлюз PSTN. В следующей таблице показаны преимущества и недостатки этой конфигурации.

Преимущества и недостатки развертывания Корпоративная голосовая связь перед PBX

Преимущества	Недостатки
PBX по-прежнему обслуживает пользователей, не включенных для Корпоративная голосовая связь.	Существующие шлюзы могут не поддерживать нужные функции или емкость.
PBX обрабатывает все предыдущие устройства.	Требуется магистраль от шлюза к PBX и от шлюза к серверу-посреднику. Возможно, вам потребуется больше магистральных магистрали от поставщика услуг.
Корпоративная голосовая связь сохранить те же номера телефонов.

VoIP-Only развертывание

Корпоративная голосовая связь предоставляет новые предприятия, а также новые сайты офисов для существующих предприятий с возможностью реализации полнофюлектного решения VoIP без необходимости беспокоиться об интеграции PBX или нести значительные затраты на развертывание и обслуживание инфраструктуры IP-PBX. Это решение поддерживает как удаленных, так и удаленных сотрудников.

Помимо сетевой инфраструктуры, необходимой для поддержки Skype для бизнеса Server, развертывание только для VoIP может использовать небольшой, квалифицированный шлюз для поддержки факсимиловых машин и аналоговых устройств.

На следующем рисунке показана типичная топология развертывания только для VoIP.

Параметр развертывания только для VoIP

Параметры развертывания PSTN Gateway

Шлюзы ТСОП

Шлюзы открытой телефонной сети (PSTN) — это сторонние компоненты оборудования, которые переводят сигналы и носитли между инфраструктурой Корпоративная голосовая связь и ПСПС непосредственно или через подключение к магистральм SIP. При любой топологии канал PSTN оканчивается шлюзом. Шлюз изолирован в собственной подсети и подключен к корпоративной сети с помощью сервера-посредника.

Предприятие с несколькими сайтами обычно может развернуть на каждом сайте один или несколько шлюзов. Сайты филиалов могут подключаться к PSTN либо через шлюз, либо через устройство для ветвей, объединяющее шлюзы и серверы в одном окне. Если сайты филиалов используют шлюз, на сайте требуется как регистратор, так и сервер-посредник, если только ссылка WAN не является устойчивой. Один или несколько серверов-посредников, расположенных на серверах переднего входа, могут маршрутить вызовы для одного или более шлюзов на каждом сайте. Рекомендуется развертывать регистратор, сервер-посредник и шлюз, необходимые на сайте, в качестве устройства для ветвей в живых.

Определение количества, размера и расположения шлюзов PSTN является, пожалуй, самым важным и дорогостоящим решением, которое необходимо принять при планировании Корпоративная голосовая связь инфраструктуры.

Следует принять во внимание несколько основных вопросов. Помните, что ответы на все эти вопросы зависят друг от друга.

Сколько требуется шлюзов ТСОП? Ответ зависит от числа пользователей, предполагаемого числа одновременных звонков (трафика) и числа сайтов (на каждом сайте требуется один шлюз).

Каков должен быть размер шлюза? Ответ зависит от числа пользователей на сайте и трафика.

Где шлюзы должны быть расположены? Ответ частично зависит от топологии и частично от географического распределения организации.

Следует также учитывать характеристики топологии шлюза (для получения дополнительных сведений см. пункт «Топологии шлюзов» далее в этом разделе).

Поддержка магистрали M:N

Серверы-посредники могут маршрутировать вызовы через несколько шлюзов, контроллеры пограничной связи сеансов (SBCs), предоставляемые поставщиками интернет-телефонии, или сочетание этих двух. Кроме того, несколько серверов-посредников в пуле могут взаимодействовать с несколькими шлюзами. Логический маршрут, определенный между сервером-посредником и шлюзом, называется магистралью. Когда внутренний пользователь помещает вызов PSTN, логика исходящие маршрутивки в пуле переднего конца выбирает, какой магистраль для маршрута из всех возможных комбинаций, которые могут быть доступны для маршрутинга этого конкретного вызова. При балансировки нагрузки DNS, если вызов не достигает шлюза из-за проблемы с определенным сервером-посредником в пуле, вызов будет повторно вызван на альтернативный сервер-посредник в пуле.

Сведения о планировании нескольких шлюзов см. в материале M:N trunk in Skype для бизнеса Server.

Дополнительные сведения о других усовершенствованиях исходящих вызовов см. в разделе Call Routes.

Топологии шлюзов

Во время рассмотрения основных вопросов развертывания шлюзов придерживайтесь следующего подхода:

Подсчитайте сайты, на которых необходимо обеспечить подключение к PSTN с помощью Корпоративная голосовая связь.

Оцените трафик в каждом сайте (число пользователей и среднее число звонков в час на пользователя).

Разверните один или несколько шлюзов на каждом сайте, чтобы обрабатывать предполагаемый трафик.

В этой топологии звонки между работниками на каждом сайте и между сайтами маршрутизируются через интрасеть. Звонки в PSTN маршрутизируются через корпоративную IP-сеть в шлюзы, которые размещены наиболее близко к расположению конечных номеров. Но что если организация поддерживает десятки, сотни или даже тысячи сайтов, распределенных по одному или нескольким континентам, как это происходит в больших финансовых учреждениях и на других крупных предприятиях? В таких случаях развертывание отдельных шлюзов в каждом сайте непрактично.

Чтобы решить эту проблему, многие крупные компании предпочитают развертывать один или несколько крупных центральных сайтов телефонии.

В этой топологии на каждом центральном сайте развернуто несколько больших шлюзов, достаточных для размещения ожидаемой пользовательской нагрузки. Все звонки пользователям предприятия переадресовываются поставщиком услуг телефонии предприятия в центральный сайт. Логика маршрутизации на центральном сайте определяет, следует ли маршрутизировать вызов через интрасеть или в PSTN.

Расположение шлюза

Расположение шлюзов также может определять типы выбираемых шлюзов и их настройку. Есть десятки протоколов PSTN и ни один из них не является мировым стандартом. Если все ваши шлюзы расположены в одной стране или регионе, то проблем нет, но если шлюзы расположены в нескольких странах или регионах, то каждый шлюз должен настраиваться в соответствии со стандартами PSTN этой страны или региона. Более того, шлюзы, которые сертифицированы для работы, скажем, в Канаде, могут не быть сертифицированы в Индии, Бразилии или Европейском союзе.

Размер и число шлюзов

Размер шлюзов ТСОП, которые большинство организаций будут выбирать для развертывания, находится в диапазоне от 2 до 960 портов. (Есть и более крупные шлюзы, но они используются в основном поставщиками услуг телефонии.) При оценке числа портов, необходимого организации, используйте следующие рекомендации:

Организации с небольшим использованием телефонной связи (один звонок ТСОП на пользователя в час) должны выделять один порт на 15 пользователей. Например, если есть 20 пользователей, нужен шлюз с двумя портами.

Организации со средним использованием телефонной связи (два звонка ТСОП на пользователя в час) должны выделять один порт на 10 пользователей. Например, если есть 100 пользователей, в сумме нужно 10 портов, содержащихся в одном или нескольких шлюзах.

Организации с высоким использованием телефонной связи (три или более звонков ТСОП на пользователя в час) должны выделять один порт на пять пользователей. Например, если есть 47 000 пользователей, в сумме нужно 9 400 портов, содержащихся минимум в десяти крупных шлюзах.

Дополнительные порты могут приобретаться по мере увеличении в организации числа пользователей или трафика.

При любом числе пользователей, которых требуется поддерживать, есть выбор между развертыванием меньшего числа крупных шлюзов или большего числа небольших шлюзов. Как правило, рекомендуется развертывать минимум два шлюза, чтобы поддерживать доступность в случае сбоя одного шлюза.

Каждый развернутый шлюз PSTN должен иметь по крайней мере один соответствующий сервер-посредник.

Использование программных продуктов для звонков, чатов и видеоконференций стало неотъемлемой частью работы практически любой компании. Всё чаще возникает ситуация, когда для связи между сотрудниками используются параллельно две системы — IP-АТС и так называемая система объединенных коммуникаций (Skype for Business, Teams и другие). Возникает путаница: пользователям не всегда понятно, какой тип связи предпочтительнее использовать, где лучше организовать конференцию, куда приглашать внешних участников на встречу. В статье я расскажу об успешной интеграции телефонии и системы объединенных коммуникаций, реализованной «ЛАНИТ-Интеграцией» в крупной нефтехимической компании. И хотя кейс не является пошаговой инструкцией, уверен, он будет многим полезен.

О проекте

К нам за помощью обратилась крупная нефтехимическая компания с большим количеством офисов по всей стране. В офисах используются IP-АТС различных производителей, в основном Cisco и Avaya, при этом часть задач помогает решать Skype For Business (SFB). Нам предстояло провести интеграцию системы телефонной связи компании со Skype For Business так, чтобы пользователи SfB могли осуществлять вызовы на стационарные телефоны и наоборот. Отказываться от одного из каналов связи и целиком переходить на другой заказчик не планировал. Требовалось настроить работу системы таким образом, чтобы на каждый входящий звонок пользователь имел возможность ответить как ему удобнее — с телефона или со SfB. Разумеется, решение должно быть отказоустойчивым.

Для тех, кто не знаком близко с работой SIP-телефонии, кратко опишу ее базовые принципы. При звонке между клиентами возникает передача двух видов сетевого трафика: трафика сигнализации (SIP – Session Initiation Protocol) и медиатрафика (RTP – Real-time Transport Protocol и SRTP – Secure Real-time Transport Protocol). По SIP передается информация, необходимая для начала и завершения сеанса разговора. В пакетах SIP присутствуют данные, например, о номерах телефонов или информация, когда абонент ответил на вызов, когда завершил его. Медиатрафик включает в себя непосредственно звук (голос), сжатый кодеками.

При настройке интеграции SfB c IP-АТС есть два возможных сценария:

настройка SIP-транков (каналов связи между двумя системами) напрямую между IP-АТС и SfB;
настройка взаимодействия между системами через SBC (Session Border Controller).

На площадках заказчика — большое количество IP-АТС различных производителей с различными версиями прошивок. Не со всеми из них была техническая возможность установки прямого SIP-транка со SfB.
Решение должно быть типовым на всех площадках.
Одно из требований – минимизация изменений в конфигурациях IP-АТС.

В качестве SBC мы использовали решение от компании AudioCodes. В линейке решений этого производителя есть AudioCodes Mediant Virtual Edition (VE). В нашем случае оно подходило лучше остальных, так как на площадках уже имелись хосты виртуализации с достаточным количеством свободных мощностей. Если на каждой площадке развернуть по две виртуальные машины и разместить их на разных хостах, то мы получим отказоустойчивое решение на уровне сервиса – это нам и было нужно. Такое решение избавляло от необходимости приобретения и установки дополнительного оборудования.

В итоге схема построения SIP-транков и размещения SBC была такой:

Размещение SBC на каждой площадке обусловлено несколькими причинами:

в дальнейшем возможно использование SBC для интеграции с местными операторами связи;
сбой на одной площадке никак не должен отражаться на работе остальных;
администраторы площадки должны полностью управлять своими SBC, не влияя на остальные площадки.

При тестировании нам требовалось:

найти рабочую конфигурацию оборудования для построения SIP-транка с каждым типом и версией прошивки IP-АТС заказчика;
проверить работу требуемых сценариев звонков с каждым типом и версией прошивки IP-АТС;
описать требуемые изменения.

IP-АТС ищет абонента с номером 202 и находит его. В настройках этого абонента стоит одновременный звонок на номер 5202.
Звонок уходит на телефон 202 и срабатывает маршрутизация звонка в SIP-транк с SBC.
SBC направляет звонок в SfB.
SfB находит пользователь с номером 5202 и направляет звонок на клиент SfB этого пользователя.

Схема звонка с форкингом:

Есть четыре возможных сценария обработки входящего вызова:

пользователь снимает трубку на телефоне;
пользователь отвечает в SfB;
пользователь нигде не снимает трубку и звонок сбрасывается по таймауту;
звонящий кладёт трубку до того, как будет принят вызов или звонок сбросится по таймауту.

Пользователь снимает трубку на телефоне

Проблема: В SfB вызов может отмечаться как пропущенный в журнале вызовов. Почему так происходит? Дело в том, что при форкинге IP-АТС направляет звонок сразу на два номера: абоненту IP-АТС и в SIP-транк. И когда звонок снимается на телефоне абонента, IP-АТС отправляет SIP-запрос «CANСEL» в сторону SfB, как бы говоря, что звонить больше не надо.

IP-АТС может не вложить в запрос «CANCEL» информацию о том, что трубка снята в другом месте. В этом случает SfB думает, что это звонок, который сбросил сам звонящий, и помечает его как пропущенный, а это не является правдой. При детальном разборе логов звонков и изучении документации было найдено RFC, в котором описывается заголовок Reason для запросов «CANCEL». Именно в этом заголовке должна содержаться информация о том, что звонок был принят в другом месте.

Большая часть IP-АТС заказчика не поддерживала RFC 3326.

Решение: Выяснилось, что чаще всего в последних версиях прошивок IP-АТС включена поддержка RFC 3326. После обновления до последней версии проблема пропала.

Для тех же IP-АТС, в которых нет поддержки RFC 3326, найдено обходное решение: SBC Audiocodes позволяет модифицировать отправляемые SIP–пакеты. В этом сценарии нам необходимо добавлять в запросы «CANCEL» заголовок с информацией о том, что звонок был принят в другом месте. В нашем случае для этого необходимо было в Audiocodes создать новый Message Manipulations, который добавляет заголовок Reason со значением 'SIP;cause=200;text="Call completed elswhere";ms-acceptedby="sip:OnPBX@domain.local"' и привязать это правило на соответствующую IP Group.

Пользователь отвечает в SfB

В этом сценарии проблемы с отображением звонка как пропущенного не возникло.

Пользователь нигде не снимает трубку — звонок сбрасывается по таймауту

Проблема: После сброса звонка по таймауту клиент SfB может продолжать звонить, хотя сессия звонящего с IP-АТС уже разорвана.

Это происходит потому, что при срабатывании таймаута на некоторых IP-АТС, они не отправляют никакую информацию в сторону SfB, и SfB не знает, что сессия уже завершена.

Решение: Изменить настройки так, чтобы время таймаута SfB было меньше, чем время таймаута на IP-АТС.В случае, если звонок завершается по таймауту со стороны SfB, звонок завершается и на телефоне. Информация о пропущенном звонке везде отображается корректно.

Звонящий кладёт трубку до того, как будет принят вызов или звонок сбросится по таймауту.

Проблема: Если звонящий положил трубку до ответа, и если звонок принят на телефоне IP-АТС без поддержки RFC 3326, то в сторону SfB отправляются абсолютно одинаковые SIP-запросы «CANCEL». SBC обрабатывает эти запросы по правилу, которое было создано ранее, и на SfB звонок не появляется как пропущенный.

Решение: Использование IP-АТС с поддержкой RFC 3326.

В нашем проекте заказчик принял решение всё же временно использовать добавление заголовка Reason и в дальнейшем отказаться от использования IP-АТС без RFC 3326.

Детальное предварительное тестирование решения со всеми видами IP-АТС позволило заранее узнать о большинстве тонких моментов. Внедрение прошло относительно быстро – один-два дня на каждую площадку.

Хотя в статье был описан один кейс интеграции Skype For Business с телефонией, принципы и решения подходят для любых подобных интеграций. Например, аналогичные решения мы успешно применяли в проектах интеграции телефонии с Microsoft Teams. Надеюсь, описанные в статье решения помогут сэкономить вам время при внедрении.

А ещё у нас есть вакансия: Ведущий инженер (инфраструктурные решения). Приходите к нам работать!

В этой статье рассмотрим настройку Asterisk для интеграции с Skype for business (Lync).

Описание (Lync) Skype for business

Lync Basic 2013 предоставляет основные функциональные возможности, доступные в полной версии — Lync 2013. Однако если вы хотите использовать любую из указанных ниже функций, обратитесь в службу технической поддержки вашей компании.

· Дополнительные функции вызовов, доступные не для всех подписок Office 365, включают в себя групповой и одновременный звонок, переадресацию, приостановку и делегирование вызовов, голосовую почту, группы ответа, а также удаленное управление звонками.

· Просмотр видео из коллекции

· Общий доступ к заметкам OneNote

· Поиск по навыкам (недоступен в Office 365)

· Инфраструктура виртуальных рабочих столов, VDI (недоступна в Office 365)

Тем не менее, рано или поздно могут понадобятся иные функции, которые продукты Microsoft предоставить не могут, а отказываться от уже настроенной платформы затруднительно. В расширении функционала поможет интеграция с Asterisk чем и посвящена данная статья.

О системе, на которой проводим настройку и цели

Нумерация внутренних номеров asterisk: 100-499
Нумерация внутренних номеров skype: 2000-2999

Нужно:
1. Чтобы пользователи Asterisk могли звонить пользователям Lync 2013 и на оборот
2. Нужно звонить во внешний мир пользователям Lync 2013 через Asterisk (правила набора на Asterisk)

Asterisk версии 13.18.2 установлен на CentOS 6.9 (Final). В качестве web-интерфейса используется FreePBX 13. Данные программные продукты вы можете скачать на нашем сайте по следующим ссылкам:

Если у вас не установлен Asterisk, то советуем ознакомиться с нашей статьей по настройке Asterisk по следующей ссылке:

Настройка Asterisk:

И так, у вас есть уже установленный Asterisk с web-интерфейсом, можем приступить к настройке. Вводим наш логин и пароль администратора от web-интерфейса

Вводим логин и пароль администратора

После чего попадаем в главное меню с общей статистикой звонков

Screenshot_4 Переходим в Extensions

Добавляем новый extensions согласно нашей нумерации. Пусть тестовый номер будет 499.

Будьте осторожны если решите назначить внутренний номер 500-699, 5XX и 6XX номера назначать нежелательно т.к по умолчанию 5XX номера это группы вызова, а за 6XX номерами по умолчанию закреплены очереди вызова.

Вводим желаемый номер, отображаемое имя и нажимаем Submit, после чего нажимаем Apply Config.

Отлично, номер для теста есть. Переходим к следующему этапу. Номер для теста мы создали, но нам так же нужно связать нашу АТС и сервер Skype при помощи транка и настроить логику.

Переходим к настройке транка 1

Настраиваем транк, переходим по следующему пути: Connectivity – Trunks

Переходим к настройке транка 2 Connectivity – Trunks

Тут у нас отображены все имеющиеся транки и их состояния (включены или отключены).

Для соединения Asterisk и Skype будем использовать обычный SIP-trunk. Нажимаем + Add Trunk – Sip trunk

В данном разделе нас интересуют следующие пункты:

· Trunk Name – Здесь прописываем имя нашему транку

Всегда давайте любым своим транкам «осмысленные» названия иначе в дальнейшем при дебаге могут возникнуть сложности.

· Disable Trunk – Убедитесь, что установлен параметр «No»

Заполнили. Переходим в sip Settings.

Сервер скайп-а расположен по адресу 10.20.0.22.Мы будем использовать следующие настройки транка:

type=friend
qualify=yes
nat=no
insecure=invite,port
host=10.20.0.22
port=5060
transport=tcp
context=from-internal
disallow=all
allow=alaw&ulaw
promiscredir=yes
conreivite=yes

TCP – Это протокол, который используется Lync
5060 – Порт, который использует Lync

Учитывайте, что если сервер skype находится за nat-ирующим устройством, то параметр nat нужно установить nat = yes. Так же учитывайте, что Lync работает только по tcp.

Как и ранее, после того, как все заполнили, нажимаем Submit и Apply Config.
И так, транк мы настроили, но нам нужно еще настроить маршрутизацию, а так же внести кое-какие правки в sip settings.

Переходим по следующему пути: Connectivity – Outbound Routes

Нажимаем Add «Outbound Route»

Для создания исходящего маршрута достаточно указать:

· Route Name – Желаемое название маршрута.

· Trunk Sequence for Matched Routes – здесь указываете, через какой именно транк будут осуществляться звонки. В нашем случае это ранее созданный trunk.

А так же Dial Patterns, о котором ниже:

Dial Patterns – Указываем шаблоны для набора номеров.

Правила набора номера:

Так же обратите внимание на внутренний номер на стороне Lync. Перед внутренним номером нужно дописывать «+», т.к любой внутренний номер на Lync набирается через +

Как и ранее, после того, как все заполнили, нажимаем Submit и Apply Config.

По аналогии так же нужно сделать исходящий маршрут для звонков на мобильные телефоны для тестов. К примеру, вот таким образом:

Обратите внимание, что для исходящих маршрутов я использую уже другой транк, через который будут проходить вызовы и использовать транк который соединяет АТС и Skype

И так, маршрутизация для тестов настроена.

Осталось провести еще настройки Sip setting. Переходим по следующему пути: Settings – Asterisk Sip Setting

Переходим в Chan SIP Settings

Прокручиваем эту страницу вниз, до пункта «Advanced General Settings»

Нас интересуют следующие пункты:

В старых версиях FreePBX нет этих пунктов, если вы используете старую версию FreePBX, то на вкладке «Other SIP Settings» добавьте данные поля и пропишите эти значения, после чего примените настройки

Пример настроек для старой версии FreePBX:

Сохраняем и применяем настройки.

Настройка со стороны Lync 2013:

Мы закончили настройку со стороны Asterisk, но чтоб подключение прошло, нужно настроить подключение так же со стороны Lync.

Стоит отметить, что с нашими настройками в пункте «Для начала разрешаем работать через TCP» указывайте порты как на скриншоте ниже

После того, как вы провели все настройки, нужно проверить поднялся ли транк. Для этого не обязательно подключаться к АТС через ssh и все можно сделать через FreePBX. Переходим по следующему пути: Admin – Asterisk CLI

Данный инструмент является многоцелевым и может выполнять следующие функции:

· Получение информации о системных компонентах Asterisk

· Настройка системной конфигурации

· Просмотр логов, ошибок и предупреждений

· Генерация звонков в целях проведения тестов

· Просмотр расширенной документации – для API, приложений, функций, настройки модулей и так далее.

Посмотрим подключение через команду «Sip show peers»

Стоит отметить, что в web-версии Asterisk CLI нет возможно просматривать логи в реальном времени. Потому для траблшутинга лучше всего подключаться к станции через ssh

И как видим соединение установлено, отлично. Значит, если вы правильно настроили маршрутизацию, то сейчас мы сможем совершить звонок со skype на внутренние номера телефонов asterisk, а так же на внешние номера.

Для проверки прохождения вызова лучше подключитесь к станции по ssh, так вы сможете просмотреть логи, ошибки и предупреждения в реальном времени.

Проверяем внутренний вызов

Для теста, к примеру, наберем внутренний номер 115

И теперь сделаем обратный звонок, к примеру, со 102 на 2220

Вызов так же успешно прошел.

По аналогии прозвонитесь на свой мобильный и если вы правильно настроили маршрутизацию, и не забыли указать транк через который будет идти вызов, то исходящий вызов пройдет без проблем.

На этом базовая настройка завершена. Если у вас возникли проблемы с подключением тестового софтфона то перейдите в следующую главу.

Проблемы с регистрацией телефона:

Учитывайте, что случайный пробел так же может быть воспринят системой как символ и связи с этим регистрация не пройдет

Пример ошибки SIP Registrations в консоли asterisk:

Подключаемся по ssh

Подключаемся по ssh к станции, вводим логин root и ваш пароль

Мы попали на стартовый «экран», с основной информацией о системе. Перед всеми манипуляциями необходимо сделать дамп правил.

Даже если вы уверены, что та или иная небольшая правка не может что-то сломать все равно сделайте дамп правил iptables с помощью которого в случае чего можно будет вернуть работоспособность системы.

Переходим в папку src с помощью команды cd /usr/src

Выгружаем правила при помощи следующей команды iptables-save > dump

Проверим, появился ли файлик с сохраненными правилами при помощи команды ls –l . Как видно на скриншоте выше – файлик успешно создан. Можем приступать к редактированию правил. Аналогичным образом выгружаем правиал еще раз, но на этот раз имя файла будет не dump, а предположим «dd».

Теперь открываем созданный файлик любым текстовым редактором. К примеру, я буду использовать nano.

Текстовый редактор nano не является стандартным в Centos и прежде чем его использовать – его нужно установить. Его можно установить, выполнив следующую команду:

yum install nano

Зашли, спускаемся к цепочке -A SIP -j PHONES и прописываем следующее:

-A SIP -s 192.168.12.0/24 -j ACCEPT

Прописали. Теперь осталось сохранить.

Нажмите CTRL + X

Y, а затем Enter.

iptables-restore < dd
service iptables savey
service iptables restart.

Проверить правила можно с помощью iptables –L –n, которая выведет все действующие правила.

Правильная настройка Mikrotik позволит избежать большой части проблем связанных с Nat.

В этом посте проводится анализ вариантов построения телефонии на базе Мicrosoft Skype For Business.

Всем добрый день. При построении телефонии в компании, в большинстве случаев выбор лежит среди традиционных телефонных производителей, таких как: Cisco/Avaya/Siemens(Unify)/Panasonic/NEC и прочие. В первую очередь это обусловлено тем, что люди выбирают телефонию и смотрят на классических производителей. Но всё чаще компании в своих требованиях, среди прочего, указывают возможности объединенных коммуникаций. А почему бы не подойти к этому вопросу иначе, выбирать систему объединенных коммуникаций, и на её базе уже строить систему телефонии? В данной статье я хочу рассмотреть возможность построения полноценной телефонии на базе решения Microsoft Skype For Business.

Перевод вызова
Переадресация вызова
Одновременный вызов
Группы поиска
Перехват вызова
И прочие.

Microsoft поддерживает SIP поверх TCP и/или TLS. SIP поверх UDP Microsoft не поддерживает. Но по мимо этого реализация протокола SIP у Microsoft весьма своеобразна. Если быть точнее, то Microsoft использует не сильно популярные расширения стандартов SIP, а где-то эти стандарты интерпретирует по-своему. Далеко не каждая станция совместима с Microsoft S4B, и даже если она совместима, то имеет ряд ограничений. Все эти ограничения описаны на страницах TechNet.
Если требуется использовать стандартный SIP, снять ограничения интеграции S4B и телефонных станций, то для этого используется устройство SBC, которое обеспечивает полную совместимость с Microsoft S4B и сторонними телефонными станциями, преобразуя диалекты протокола SIP под те требования, которые есть с разных сторон.
Так же, одна из немаловажных функций SBC заключается в обеспечении безопасного подключения к SIP оператору поверх публичной сети интернет.

Как сильные стороны я бы выделил

Ну а теперь можно поговорить и о слабых сторонах Skype For Business в качестве телефонии:

Skype For Business 2015 интеграция с бесплатной PBX

Настройки Vodia PBX

Для настройки Vodia PBX необходимо:

В разделе Security->General указать логин и пароль для администратора. При необходимости можно создать дополнительный аккаунт.
В разделе SIP проверить номера портов, которые используются для SIP протокола.

В разделе Domains необходимо создать домен (я создал домен соответсвующий SIP домену в Skype).
После создания домена, необходимо зайти в его настройки, нажав на его название.

В настройках домена WCFC.demo в разделе Trunks создать новый транк, нажав на кнопку Add. Предполагается, что транк будет использовать транспортный протокол TCP, адрес Mediation сервера uc01.wcfc.local, порт TCP: 5068.

Настройки транка указаны ниже:

В настройках транка в разделе SIP Caller-ID Presentation (см выше) указаны следующие значения полей, по умолчанию прямые значения которых не отображаются, поэтому чтобы узнать их настоящие значения в Value нужно указать Other.

Настройки в домене WCFC.demo раздела Advanced->General Settings

В качестве клиента использовался бесплатный SIP клиент PhonerLite

Настройка Skype

Для настройки голосовой интеграции между Skype и PBX или прокси необходимо:

Установить Mediation Server;
Создать в топологии PSTN Gate и Trunks;
Создать Dial Plan;
Создать голосовую политику (Voice Policy);
Настроить конфигурацию транка;
Настроить пользователей Skype;
Иметь в наличие специализированные лицензии.

1 Установка Mediation Server

Для того, чтобы проверить или установить Mediation Server, необходимо открыть соответсвующий раздел в Topology Builder.

2 Создание PSTN Gate

В качестве имени шлюза необходимо указывать FQDN, который корректно разрешается в DNS Mediation севером. Trunks создаются автоматически, после создания PSTN Gate.

3 Создание Dial Plan

Dial Plan это правила нормализации, которые преобразуют телефонные номера в единый стандарт (E. 164). Это относится как к входящим так и к исходящим номерам.

В реальной жизни форматов номеров конечно же больше, чем в приведенным ниже примере.

4 Голосовая политика маршрутизации

В результате на стенде было создано два маршрута, один отслеживал звонки +57xx и отправлял на Vodia, второй маршрут отправлял звонки +56xx на MX-One PBX.

5 Настройка транка

6 Настройка пользователей в Skype

Для пользователей необходимо включить функцию Enterprise Voice, назначить голосовую политику, так как она создана на пользователей и назначить номер телефона.

После того, как все настройки на Vodia и Skype будут выполнены, между пользователями двух систем можно выполнять аудио звонки. Единственный нюанс заключается в том, что Vodia в бесплатном режиме может осуществлять не более двух одновременных вызовов.

Читайте также: