Маршрутизация вызовов в Lync Server 2010
2011-03-22, 18:41 / ArgonВ данной заметке я опишу проблемы при маршрутизации телефонных вызовов между Lync Server 2010 и другими телефонными системами, с которыми мне доводилось проводить интеграцию.
Рассмотрим следующую ситуацию: имеется сервер Lync c ролью Mediation, к нему подключено два голосовых шлюза
- Asterisk 1.8, через который происходит подключение к городской сети
- Audiocodes Media Pack, который соединяет Lync с унаследованной офисной ATC
Хотя Lync и позиционируется производителем как полная замена старым АТС, без подключения к городской телефонии через Asterisk (или других IP-PBX) в российских реалиях обойтись трудно: Lync Server не может быть SIP-клиентом, не может работать по протоколу UDP…
Без интеграции с существующей офисной АТС представить серьезное внедрение Lync тоже трудно: разом всех пользователей на Lync не переведешь, а также должен быть план отката на предыдущее состояние, если внедрение Lync Server «не пошло», да и на случай программных и аппаратных отказов — тоже.
Маршрутизация вызовов между шлюзами
Итак, настроив интеграцию Lync Server с Asterisk и с Audiocodes, используя имеющиеся в достатке мануалы (на некоторые из которых я приведу ссылки в конце заметки), убедившись, что звонки между любым шлюзом и Lync-ом работают, можно подумать, что дело сделано.
Однако, при дальнейшем тестировании обнаруживается, что звонки по маршруту Audiocodes → Lync → Asterisk не проходят. Как выяснилось, дело в следующем: полная маршрутизация звонков, в соответствии с маршрутами на Lync Server выполняется только для авторизованных пользователей. Видимо, в целях учета лицензий. Пока звонки со шлюзов не авторизованы, их могут принимать только клиенты Lync Server, маршрутизация на другие шлюзы заблокирована.
Конечно, можно прописать прямые маршруты между Asterisk и Audiocodes, минуя Lync. Но зачем тогда нам Lync, в чем тогда будет состоять «Unified Communications»? Поэтому, чтобы звонки со шлюза Audiocodes могли уходить наружу по маршруту Audiocodes → Lync → Asterisk, на Lync-е для шлюза Audiocodes нужно создать учетную запись подобной командой:
New-CsAnalogDevice -LineUri tel:+901 -SipAddress "sip:audiocodes@argon.pro" -DisplayName "Audiocodes Gateway" -RegistrarPool lync.argon.pro -AnalogFax $False -Gateway audiocodes.argon.pro -OU "OU=LyncContacts,DC=argon,DC=pro"
А на шлюзе Audiocodes прописать Caller ID, равный +901 для всех исходящих звонков.
Для прохождения звонков по маршруту Asterisk → Lync → Audiocodes нужно проделать аналогичные действия… Но, здесь возникает проблема. Если в случае Audiocodes мы можем смириться с тем, что Caller ID будет заменен на номер, указанный в учётке AnalogDevice, то для поступающих вызовов из городской сети это может быть не допустимо.
Поэтому, вопрос прохождения вызовов по маршруту Asterisk → Lync → Audiocodes с сохранением оригинального Caller ID остается открытым. Комментарии приветствуются.
Переадресовывая вызовов от Asterisk
Добившись прохождения вызовов между подключенными к Lync Server шлюзами, приключения не заканчиваются. Как выяснилось, вызов, исходящий с Asterisk на Lync, не может быть переведен на другой номер.
Пытаться переводить может кто или что угодно: будь то голосовое меню (Lync Server или Exchange Server Unified Messaging), или же живой оператор. Результат не удачен: от возвращения вызова обратно переводящему абоненту с сообщением «Вызов не может быть переведен», до банального обрыва.
Чтобы починить перевод вызовов, в настройках Lync Server нужно отключить Refer Support, который включен по умолчанию, но не поддерживается Asterisk. Для отключения Refer Support нужно выполнить следующее:
- пройти в Lync Server Control Panel → Voice Routing → Trunk Configuration
- выбрать New Pool Trunk → шлюз Asterisk
- в конфигурации созданной записи снять галку Enable Refer Support
- применить (commit) изменения
- PROFIT!
Добавление Analog Device в Hunt Group
Продолжая налаживать отношения между Lync Server и унаследованной АТС, я обнаружил еще одну пренеприятнейшую особенность: в группу дозвона (Hunt Group в терминах телефонии, Response Group в терминах Lync) можно добавлять только стандартных пользователей Lync Server. Аналоговые устройства, которыми представлены в Lync-е голосовые шлюзы — в пролёте. Таким образом, еще одно ограничение ставит под сомнение возможность Lync Server полноценно работать совместно с унаследованной АТС и постепенно стать ей полной заменой.
Для обхода этого ограничения, предлагаю использовать всемогущий Asterisk: завести нём специальные номера для групповых вызовов (например, +5900).
- убедиться, что маршрутизация из Lync на эти номера идёт на шлюз Asterisk
- настроить в Asterisk (sip.conf) прямой SIP Trunk на Audiocodes
[audiocodes]
type=peer
host=10.0.0.51
transport=tcp
insecure = port,invite - сконфигурировать в extensions.conf служебный номер для групповых вызовов
exten => 5900,1,Answer()
exten => 5900,n,Dial(SIP/lync/180 & SIP/audiocodes/900)
exten => 5900,n,Hangup
Полезные ссылки
- Integrating AudioCodes MP-114/MP-118 Media Gateways with Microsoft Unified Communications Products
- Configuring the AudioCodes MP-114 IP gateway for a UM demo
- How to configure interoperability between Microsoft Exchange Server 2010 Unified Messaging and pbxnsip IP PBX version 3.0
Благодарю Александра Донина за помощь в решении описанных в заметке проблем.
Рубрика | Unified Communications |
---|---|
Метки | lync server, office communications server, ocs, совместимость, устранение ошибок |
Опубликовано | 2011-03-22, 18:41; обновлено 2011-04-10, 15:09 |
Комментарии | 15 комментариев » | Лента комментариев RSS |
Ссылки | Постоянная ссылка | Обратная ссылка |
15 комментариев
в продолжении http://argon.pro/blog/2011/03/lync-edge-ssl-certificate/#comment-4837
У меня Avaya c Lync соответственно по SIP, а вот сама Avaya с внешним миром по протоколу H.323 и кодек G.729
Соответственно, Авая должна уметь перекодировать g729 в понятный Линку g711.
Конечно, я пока к Астерискам не прикрутил перекодировку g729, а провайдер упорно не хотел работать по другим кодекам, соединения с городскими сетями не устанавливались.
У меня провайдер точно не перейдёт на G.711. Так как я хотел это сделать потому что в G.729 не ходит Fax…
Блин и какие у меня есть варианты?
Настраивать перекодировку на Авае, а если не умеет, то через Астериск. Но там тоже — бубен.
Опа! А вот этого я незнаю, может она это или нет… Астерикс я точно ставить не буду :)))
Эхх… буду копать Avaya… Хотя признаюсь в ней(Avaya) я понимаю не много )))
Хотя сдругой стороны все телефоны Avaya внутри организации у меня работаю по протоколу H.323 и кодеку G.729, а Lync SIP, G.711 и звонки проходят на Ура…
может дело что-то в другом…
Для прохождения звонков по маршруту Asterisk → Lync → Audiocodes можно в маршруте на Asterisk поставить галочку «Intra Company Route», тогда CID будет передаваться аудиокодесу. Как минимум это работает, когда внутренний абонент астериска звонит абоненту аудиокодеса.
Попытался разобраться.
1. У меня голый Aстериск, а «Intra Company Route» — это настройка FreePBX, и как она транслируется в конфигурацию Asterisk, я пока не нашел.
2. CID в мой конфигурации итак всегда передается. Конфуз в том, что если я звоню от известного Линку CID-a (который прописан как AnalogDevice) то звонки идут по маршруту, если от звоню как кто-то внешний, то нифига.
>>> «я обнаружил еще одну пренеприятнейшую особенность: в группу дозвона (Hunt Group в терминах телефонии, Response Group в терминах Lync) можно добавлять только стандартных пользователей Lync Server.»
———
А «AutoAttendant(Exchange2010)» для Lync Server также является нестандартным пользователем?
Попытался указать в Responce Group телефон AutoAttendant на Exchange — безуспешно.
Пробовал различные способы: 1) в настройках группы («Lync Control Panel» -> «Responce Group» -> «Group») в параметре «Use an existing email distribution list» — указал адрес «distribution list», членом в которой является mail-enabled контакт «AutoAttendant», 2) в очереди «queue» в параметре «enable queue time-out» пытался указать в «Call Action» -> «Forward to sip address» указать адрес «AutoAttendant»).
—
В итоге сценарий:
Ext/int call -> Lync Server Responce Group -> Autoattendant Exchange
реализуем в принципе?
Сколько не пытался, и базу напрямую правил, и атрибуты юзеров мучал — не получилось. В Response Group работают только пользователи Lync Client. А вот наоборот PBX > Ex UM > Lync RG — работать будет.
У меня похожая топология, единственное что астериск соединен с sip провайдером для звонков по межгороду. Устройство кодес mp-118 fxs_fxo. Задача — с телефонов подключенных к кодесу иметь возможность звонить по межгороду через астериск (раньше такой задачи не стояло, а сейчас планируется обновление шлюза и теперь такая возможность требуется). Так вот, в соответствии с постом для кодеса создал «New-CsAnalogDevice», прописал ему номер с плюсом.
В общем на линк набранный номер доходит, но никуда не маршрутизируется. В логе diagnostic id 12004 «Reason: The user is not authorized to call the specified number. Description: Administrators should check the user’s voice policy and add a route with a usage that matches the dialed number. Please refer to the Diagnostic Reports information below for more details on this diagnostic ID»
Mожет надо для аналоговых устройств как-то поставить в соответсвие Voice Policy?(просто голосовая политика по-умолчанию не позволяет пользователям звонить по межгороду)