Возвращение блудного автора

11.07.2012

Привет всем, кто еще не удалил этот блог из подписок.

Трёхмесячный перерыв закончен (по крайней мере, я на это надеюсь). Этим сообщениям я открываю новый сезон статьеписания.

Начнем со старостей и анонсов

За прошедшее время произошло много событий, но почти ни одно из них не является чем-то, из ряда вон:

  • Вышел Microsoft SQL Server 2012, и было объявлено, что он НЕ поддерживается для Lync Server 2010. Досадно, но не критично. Просто теперь, до выхода следующей версии Lync, нужно следить еще и за версией SQL
  • Вышел очередной набор обновлений для Lync Server: Cumulative Updates for Lync Server 2010: June 2012, как его называет маркетинг MS, или просто CU6 для всех остальных. :-) Из интересного – частичная поддержка веб-конференций для iPad и поддержка Wildcard-сертификатов на Exchange CAS для IP-телефонов Lync Phone Edition. 
  • Avaya окончательно купила Radvision.
  • Polycom сертифицировали свои DECT трубки KIRK на работу с Lync Server.  Работало и раньше, но теперь официально.
  • Polycom продает свое отделение беспроводных решений (читай, лишается Wifi-телефонов SpectraLink) компании Sun Capital Partners Affiliate.  С одной стороны, непонятно, будет ли обеспечена в дальнейшем совместимость этих телефонов с Microsoft Lync Server (напомню, сейчас  с этих телефонов через Lync можно и звонить и сообщения писать), c другой, учитывая стоимость SpectraLink (около 1 000$ за штуку) туда им и дорога. За такие деньги лучше купить «окнофон»  с контрактом, включающим безлимитный интернет.
  • В России появились первые MCM по Lync Server 2010. Это сотрудники Microsoft. Сейчас в списке светится только Николай Муравлянников, занимающий сейчас должность Lync Service Delivery Specialist. В ближайшее время должно появиться еще одно имя.
  • Microsoft купил социальную сеть Yammer. Пока без комментариев. Посмотрим, как MS распорядится этой покупкой.
  • Появился новый тип партнерства с Microsoft — Microsoft Lync Certified Support Partners. Заключив соглашение о техподдержке Lync Server с организацией, имеющий этот статус, вы автоматически получаете на техподдержку и Microsoft. Но, в отличие от контракта с Microsoft напрямую, в контракт с компанией из списка, вы можете прописать SLA. А также включить в поддержку голосовые шлюзы и телефонные аппараты. Коротко и программе тут.  До России пока программа не добралась.  Как доберется, подробности Microsoft сам расскажет.  :-)
  • И немного о себе. MVP мне продлили. Последние 3 месяца не писал, но, видимо, предыдущие 9 этот факт пересилили. :-)

Ну и под конец немного анонсов

Хотел подготовить короткую статью, в которой расписал бы нужные для Lync записи DNS и сертификаты. Статья разрослась до описания процесса регистрации пользователя в Lync Server. В формате одной статьи всю процедуру описать не смогу, так что в ближайшее время стартует цикл статей, описывающий все стадии процесса, включая направления траблшуттинга при сбоях на каждой стадии. :-) Собственно, только понимая куда, зачем и как клиент обращается, можно правильно выбрать DNS имена и сертификаты. Например, почему в качестве имени для SIP-интерфейса на внешнем интерфейсе Lync Edge желательно указывать sip.<имя SIP-домена>.

Возможно, в скором времени некоторые из моих новых статей будут размещены и в блоге UC RU на TechNet, организованном и поддерживаемом  Николаем Муравлянниковым (Lync MCM). У нас бывают разногласия идеологического плана, но Николай пообещал, что цензуры не будет.  Это уже вторая попытка объединить блоги Российских авторов статей по Lync в одном месте. Надеюсь, на этот раз будет более удачная. По крайней мере,  думаю, что с blogs.technet.com какой-нибудь «сбой» статьи не удалит, как было с сайтом Барри Муртазина :-)

Сейчас в Торонто проходит конференция Microsoft для партнеров (WPC 2012). На ней уже засветили бету Exchange 2012, выпуска Windows 8, а также покупку компании Perceptive Pixel, производителя сенсорных экранов. Конференция только началась. Может и первая публичная информация о Lync появится… Сейчас интересующиеся могут только наблюдать в Интернете скриншоты клиента Lync 15 из состава Office15 Technical Preview. А очень интересующиеся могут, покопавшись в статьях MSDN, найти некоторые изменения в Lync Server 15 Technical Preview относительно Lync Server 2010. Ссылок не даю. Очень интерисующиеся сами найдут. Если нет — значит они не очень интерисующиеся. :-)

Изменения на рынке видео-конференций и Scalable Video Coding

27.03.2012

Пойдем от крупного к мелкому…

Ситуация на рыке видео-конференций

Забавная ситуация. Рынок видео-конференций растет (по данным IDC 2.7 миллиарда в 2011 и, предположительно, 3.2 миллиарда в 2012), а крупных игроков скупают «бочками». 

Сначала Tandberg, второй по величине производитель решений ВКС, был куплен Cisco.

Потом в HP решили избавиться от «лишнего» подразделения и продали его Polycom.

Теперь вот Avaya покупает компанию Radvision.  

Зачем Cisco и Avaya покупают производителей ВКС понятно: компании расширяют свои возможности решений в сфере Unified Communications. Причем, после поглощения Tandberg, действие Avaya вполне ожидаемо. Долгое время ходила шутка, что следующей сделкой будет приобретение компанией Avaya компании Polycom, но, видно, главный игрок на рынке пока за жизнь цепляется, а рыбку поменьше, да еще пострадавшую от Cisco (до приобретения Tangberg, компания Cisco продавала Radvision по OEM каналам) поймать удалось. На самом деле, политика Avaya последнего времени это тема для отдельной статьи, так что вернемся видео-конференциям.

Так вот, зачем продавать бизнес при таком росте возможностей?

Виной тому изменения, происходящие на рынке в настоящее время.

Что включают в себя ВКС-решения

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

  •  Решения для конечных абонентов. От программных клиентов до персональной выделеной плазмы и аппаратного кодека ВКС
  • Решения для переговорных комнат среднего уровня (по максимуму, это пара плазменных панелей, аппаратный кодек с возможностью сбора видео конференций на себе, выносные микрофоны и камеры, отслеживающие говорящего)
  • Серверы видео-конференций, обрабатывающие большое число видео-потоков. Стандартного CPU тут мало. В серверах ВКС используется специальный DSP, отвечающий за обработку видео. Его же можно отлично припособить под взлом паролей, так что иногда с с ввозом серверов ВКС возникают проблемы. :-)
  • Telepresence решения, или, как говорится, ВКС без компромиссов. В общем, решения, максимально создающие эффект присутствия. В комплект к трем/четырем панелям, куче микрофонов и аппаратных кодеков, идет комплект мебели, включая стены. Собрав пару таких комнат в комнате и посадив в них участников можно создать ощущение пристутствия в одном большом кабинете.
  • Средства централизованного управления всем перечисленным выше, а также шлюзы и сопутствующие средства сопряжения (с ТфОП, со службами каталога и т.д.)

Тенденции

Уже долгое время идет процесс оттеснения производителей ВКС в верхний сегмент рынка.

Недорогие качественные мониторы и HD камеры плюс удобные и простые в использовании программные решения отбирают у производителей ВКС сегмент персоонального оборудования.

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

В ближайшее время, благодаря технологии scalable video coding (SVC), потребность в  дорогом оборудовании серверов ВКС может значительно снизиться, так что на долю производителей аппаратных ВКС решений останутся только комнаты совещаний для особо требовательных клиентов.

Если еще подумать, то окажется, что нижний сегмент займут корпоративные решения класса всё в одном, то есть UC-решения. А значит, нужно будет обеспечить сопряжение с ними VIP (Telepresence) решений. И получается, что у компаний, ставших частью производителей UC, будущее намного перспективнее, ведь если UC решение уже имеется, выбор аппаратного  Telepresence решения очевиден.

В общем, получается, что хоть рынок ВКС и растет, не факт, что эта дополнительная прибыль достанется производителям аппаратных решений.

Те кто хотят выжить — ищут новые рынки. Polycom, например, «затачивает» свои аппаратные кодеки и телефонные аппараты под работу с Microsoft UC и надеется выйти на рынок веб-конференций (покупка ViVu)

Ну а на закуску, немного информации о том, что же такое SVC и с чем его едят.

Scalable video coding

SVC — это одно из расширений стандарта сжатия H.264. Основное отличие: возможность передачи видео в несколько потоков (с несколькими разрешениями и частотами).

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

Итак, как это работает…

Сначала разберемся с частотой

При передаче потока видео, полная картинка пересылается с низкой периодичностью. В каждом следующем кадре до передачи очередной полной картинки передается только информация об отличии текущего кадра от предыдущего. То есть, если  картинка передается с частотой 30 кадров в секунду, значит 30 раз в секунду передаются изменения полного кадра. При использовании H.264 SVC мы можем передавать информацию об отличии текущего кадра как от предыдущего, так и от более раннего.

Грубо описать передаваемую информацию для H.264 AVC (Advanced Video Coding) и H.264 SVC можно так.

H.264 AVC: Полный кадр->А1->A2->A3->A4->A5->A6

H.264 SVC: Полный кадр->А1->A2(B1)->A3->A4(B2)(C1)->A5->A6(B3)-> A7->A8(B4)(C3)(D1)->

Допустим, обоих случаях кадры «А» передаются 60 раз в секунду и говорят об изменениях с последнего передаваемого кадра.

Но, в случае  H.264 SVC, дополнительно передается информация “B” (30 раз в секунду), “С” (15 раз в секунду) и «D» (7,5 раз в секунду). 

В результате, мы получаем два преимущества:

  • При потере одного из пакетов «A» мы не будем ждать следующего полного пакета, а просто переключимся на более низкую частоту. Соответственно, значительно возрастает процент потерь пакетов, который можно пережить без появления «артефактов».
  • Если идет многоточечная конференция и часть абонентов не может принять видео с высокой частотой, серверу конференций не потребуется тратить процессорные ресурсы на перекодирование видео для этих абонентов.

Теперь про разрешение

Тут тоже всё не так сложно. Видео передается как бы слоями в несколько потоков. От QVGA до FULL HD. Таким образом, что собрать FULL HD требуется выполнить немного больше работы для сбора слоев, но зато если разные абоненты конференции могут принимать видео с разным качеством, серверу не нужно заниматься перекодированием. Можно просто отправить слабым абонентам только нужные слои. :-)

Стандартизация

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

Сейчас определяют несколько версий H.264 SVC. Базовая версия H.264 SVC «0» – это фактически H.264 AVC (отличие только в SDP и заголовке). Версии с другими цифрами/буквами обозначают наличие какого-либо дополнительного функционала, относительно H.264 AVC.

Microsoft Lync и SVC

В Polycom открыто заявляют, что помогают MS внедрить H.264 SVC в следующие версии Microsoft Lync. Ждем и надеемся. :-)

Ссылки

Рынок ВКС решений по мнению Gartner.

Иформация о покупке Radvision.

Защита от снижения качества видео при помощи SVC на примере решения Ravision.

Заявление Polycom, в котором упоминается H.264 SVC и Microsoft Lync.

Старости (ноябрь 11 — февраль 12)

05.03.2012

С момента последних cтаростей произошло довольно много событий. Так что статья будет длинная, и, надеюсь, интересная. Как всегда, к новостям будет прилагаться мой взгляд, дурацкие шутки и ситуации из жизни. Если не нравится – читайте первые абзацы после заголовков. Не согласны с моей оценкой событий – обсудим в комментариях. Кстати, эту статью я пишу из отеля (начал писать). Только что закончился MVP Summit 2012. Всё что касается саммита под NDA (что делает «старости» еще более «старостями»), однако про некоторые события вокруг я могу писать. Но об этом позже.

Новости партнёров Microsoft

LifeSize сертифицировали свои точки ВКС на совместимость с Lync по программе Lync Video Interoperability Program. Общаться с клиентами Lync они могут только в режиме точка-точка и с качеством CIF. Но умеют подключаться из сети Интернет. Сертифицированы точки ВКС Room 220, Team 220, Express 220, Passport.

В Radvision решили пойти другим путем и выпустили шлюз Scopia Video Gateway, позволяющий регистрировать точки ВКС Radvision, Cisco/Tandberg и Polycom на сервере Lync. При этом шлюз также займется транскодингом  видео, что позволит добиться HD качества для точек ВКС не поддерживающих RTVideo. С другой стороны,  транскодинг требует больших вычислительных мощностей, что отрицательно сказывается на стоимости решения.

Так же шлюз работает в обратную сторону, позволяя подключаться с Lync к конференциям, организованным на MCU Radvision, Cisco/Tandberg или Polycom с качеством до 720p (HD).

В то время как в LifeSize занимались сертификаций своих точек ВКС на работу с Lync, инженеры Polycom вносили изменения в прошивки своих телефонов, обеспечивая им совместимость c Lync Server без дополнительных шлюзов типа Audiocodesc SPS или NET SmartSip.

В список совместимых устройств входят:

  1. SoundPoint IP 321, 331, 335, 450, 550, 560 и 650
  2. SoundStation IP 5000
  3. SoundStation Duo
  4. VVX 500 и 1500.  VVX 1500, кстати говоря – видеофон. Видео-коммуникации с Lync на нем пока официально не поддерживаются, но реально работают в режиме точка-точка.
  5. SpectraLink серии 8400. Жутко дорогие неубиваемые WIFI телефоны. Для них дополнительно поддерживаются мгновенные сообщения.

Процесс внесения изменений и  тестирования подошел к концу. Так что теперь Polycom сможет заняться сертификаций своих решения в Microsoft. Об этом, как говорят журналисты, пару дней назад рассказали Mike Stacy и Jeff Schertz: архитекторы Polycom и, за компанию, MVP со специализацией Lync. Для приехавших на MVP саммит ребята устроили экскурсию в ближайший офис Polycom.  После опустошения холодильника с пивом ;-) нам показали работу телефонов в связке с сервером Lync, CX 7000 а также комнаты конференций с эффектом присутствия для общения больших боссов. Всё то же самое можно увидеть и в московском офисе Polycom, так что для меня было важнее узнать мнение коллег об изменениях на рынке видеоконференций. Программные решения вытисняют производителей ВКС из нижнего сегмента рынка. Старым игрокам приходится приспосабливаться. Подстраиваться под новые, многофункциональные решения конкурентов и облачные службы. В Polycom это понимают. Насколько хорошо они смогут адаптироваться к новым условиям – покажет время.

Кроме разговоров за жизнь и обсуждения планов Polycom в меняющимся мире, была затронута еще одна интересная тема: новое расширение группы кодеков H.264 под названием SVC (Scalable Video Coding). О том, что именно интересного (или, по крайней мере, важного для судьбы индустрии ВКС решений) в H.264 SVC я расскажу в отдельной статье в ближайшее время.

UC Office — Сайт с партнерскими приложениями для Lync. Call-центры, чат-боты, решения для записи разговоров и даже решения, помогающие настроить логику обработки вызовов в зависимости от статуса абонента. ЗаходЫ, выбирай, покупай. 

Microsoft Lync Server 2010 Multitenant Pack for Partner Hosting - Решение для операторов, позволяющее предоставлять функционал Lync для нескольких независимых компаний одновременно. Отличительные особенности перечислю ниже:

  1. Процесс установки. Читаем гайд. Пытаемся понять. Отчаявшись, идем за поллитрой. Снова пытаемся понять. Засыпаем во время процесса. Проспавшись, забиваем на понимание и тупо действуем по инструкции. 
  2. Сервер с ролью Director. На конец-то он стал активно использоваться. Теперь пользователи подключаются сразу к директору а Edge используется, в основном, для федераций.
  3. Белые IP-адреса. Теперь они требуются даже для сервера конференций. Не говоря уж про Edge и Director.
  4. ACP. Для части функционала (например, дозвон в конференцию из телефонной сети) требуется наличие сертифицированного Audio Conference Provider.  Тут два варианта. Либо использовать один из существующих (в России нет, предоставляются как сервис),  либо писать свой.
  5. Администрирование. Осуществляется из PowerShell. Веб-морду тоже нужно писать свою.

Мобильные клиенты

Lync Mobile таки вышел для Windows Phone, iPhone, iPad и Android. Для Android он вышел даже два раза. Второй раз с поддержкой функции call Back. Правда, на планшеты на Android в MS «забили». Lync Mobile для Nokia застрял где-то в дороге (или я его пропустил; пишите в комментариях — исправлюсь).

Собственно, ради функции Call Back по сути Lync Mobile пока и нужен. И ради этого приходится выполнять настройку серверной части, которая пока является таким же костылём, каким в свое время были Address Book и Device Update. Доделают, видимо, только в следующей версии.

Skype для Windows Phone тоже наконец появился. Пока правда в бете. Вот чего все ждут от Lync Mobile. Голосовые и видео-вызовы через IP. Работает, кстати отлично. О сием чуде узнал в понедельник утром (вечером по Москве) от коллеги по работе Алексея Ватутина. Утренних сессий на саммите для меня не было, так что уже через два часа я уже выбирал подарки в местном гипермаркете консультируясь с супругой через Skype и бесплатный местный Wifi. Этому занятию очень способствует возможность переключения на фронтальную камеру на лету. :-)

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

Wave 15

Не секрет, что продукты MS выпускаются так называемыми волнами. То есть, в приблизительно в одно время выходит несколько продуктов, адаптированных на работу друг с другом.

Например, в 14-ую волну вошли такие продукты как Office 2010, Exchange 2010, Lync 2010, Share2010.

Из 15 волны пока официально известно только про Windows 8 и новую версию Microsoft Office. Причем, про офис информации не так много. Он будет работать на ARM версии Windows 8 и, соответственно, будет оптимизирован под работу пальцами.  Скриншоты новых офисных продуктов можно поискать в Интернет. 

О Windows 8 известно намного больше. Еще до выхода беты, которую теперь назвали Consumer Preview, IT-сообщество знало о Windows 8 столько же подробностей, сколько фанатки проекта Дом 2 о своих кумирах.

Windows 8 считается одним из наиболее рискованных проектов Microsoft. Прощай привычное с Windows 95 меню «Пуск», привет новый планшетный режим.

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

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

Но вот оценят ли это сегодняшние пользователи, скоро узнаем. Пока отношение в блогосфере колеблется от «попробуем, посмотрим» до «опять все поменяли, но привыкнем и к этому».

Кстати, пока под описанную мной концепцию одного устройства попадает как раз только одно устройство: Samsung Series 7 Slate. Остальные имеющиеся на рынке Intel-планшеты оснащены процессором Intel Atom Z670 1.50 ГГц и максимум двумя Гб ОЗУ, чего для полноценной работы недостаточно, и/или имеют непозволительно малое время работы.

Предположительные сроки выхода 15-ой волны продуктов от MS удобно отслеживать тут. Сразу предупреждаю, что информация по ссылке не является официальным заявлением MS. Просто набор слухов.

Новый инструмент диагностики

И на последок. На днях вышел новый инструмент диагностики продуктов MS: Fix IT Center Pro.

Принцип работы инструмента прост. Инженеры MS, обнаруживая проблему в работе какого-либо продукта, сохраняют информацию о симптомах, точно идентифицирующих проблему в единую базу. Имея доступ в сеть Интернет, вы можете загрузить с сайта Microsoft приложение, которое соберет необходимую для диагностики информацию (различные журналы, дамп памяти и т.д.) и, спросив у Вас разрешение, перешлет эту информацию на серверы Microsoft, где данные прогонятся через тесты на совпадение с известными симптомами. В ответ вы получите рекомендации по устранению со ссылками на файлы и КБ. При этом, если устранение неисправности потребует ввода информации, которая была в журналах (например, FQDN сервера при выполнении команды из КБ), выведут и её. Если Вам не повезло, и с такой проблемой в MS еще не сталкивались, прямо из интерфейса Fix IT Center Pro вы сможете открыть кейс в MS. («Нет проблем хозяин, были бы бабки», как говорил один джин). В этом случае инженер поддержки сразу получит достаточно информации для начала работы, что ускорит решение проблемы.

Продуктов в списке пока не много, но Exchange и Lync среди них есть.

Обновления

Очередной пакет обновлений для Microsoft Lync вышел в конце февраля / начале марта. Обновления доступны как для сервнрых компонентов, так и для клиентов Lync. Для Lync Phone Edition обновления заявлены, но пока (05.03) недоступны для скачивания, так что проверить, изменили ли часовые пояса для России, можно будет позже.
Наиболее значительное обновление из текущего пакета - возможность видео-вызовов для пользователей Lync,  для которых включен режим Remote Call Control (RCC). Подробнее — тут.
Кроме того, стоит отметить возможность указания DFS каталога в качестве файлового хранилища в Topology Builder. Официально это поддерживалось еще с RTM, однако заработало только сейчас.

Обработка телефонных вызовов в Lync Server 2010

12.02.2012

Тема непростая, но обязательная для изучения всеми, кто хочет «собрать» из Lync телефонную станцию. При чтении желательно иметь перед глазами интерфейс администрирования Lync Server под странным названием: «Communications Server Control Panel» (CSCP). В противном случае, многие места понять будет довольно сложно.

Итак, CSCP открыт… Кружка пива (чашка кофе) на столе под рукой… Мозг расслаблен… Приступаем.

Форматы номеров в Lync.

Существует три идеологически верных :-) формата телефонных номеров в Lync:

  • Е.164: +<код страны><код региона/ оператора><номер>, например +74951234567
  • E.164 c доб. номером: +<код страны><код региона/оператора><номер>;ext=<доб. номер>, например +74951234567;ext=1234

Первый вариант подходит для прямых номеров, второй для случаев, когда имеется один прямой номер на организацию/филиал организации. Номер без «ext=XXXX» в этом случае хитрым правилом должен ссылаться на автосекретарь.

Однако второй вариант может использоваться и в случае, когда у каждого пользователя имеется прямой номера. Преимущество этого варианта в упрощении идентификации пользователя в Lync. То есть, по запросу пользователю нужно ввести только номер Ext. Частным случаем такой схемы является использование в качестве Ext последниз цифр прямого номера пользователя.

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

Недостатков тоже вагон и маленькая тележка, но об этом позже. А пока скажу, что намного чаще приходится давать пользователям стандартные  номера форматов XXX, XXXX или XXXYYYY.

Нормализация

Как Lync проверяет, что номер в формате Е.164? Очень просто. Смотрит на «+» в начале номера. То есть «прокатит» даже +123. Если же идет звонок на номер без «+», такой номер нужно нормализовать, то есть, в идеале, преобразовать к формату E164.

Правило нормализации можно условнео разделить на три категории (моё личное разделение, в документации этого нет):

  • Преобразующие номер к E.164
  • Преобразующие номер к другому формату нежели у.164
  • Закрепляющие правила

Как происходит нормализация. В Lync существуют наборы правил преобразования номеров (normalization rules), называемые планами нумерации (Dial Plan). Dial Plan может назначаться на пользователя, применяться ко всем вызовам пула Lync или сайта Lync. Кроме того, всегда существует Dial Plan с именем Global, применяемый ко всей организации Lync. К каждому объекту может быть применен только один Dial plan. При наличии нескольких Dial Plan, применимых к объекту на разных уровнях, выбирается Dial Plan с наименьшей зоной действия. В порядке уменьшения приоритета User, Pool, Site, Global.

Правила внутри Dial Plan применяются в порядке, выставленном администратором до первого соответствия. Если правило не приводит номер к формату E.164, то ищется закрепляющее правило. Если номер не подпадает под какое-либо правило, либо отсутствует закрепляющее праило, происходит сбой вызова.

В докуменации ничего не говорится про закрепляющие правила, но схема работы проверена на нескольких инсталяциях с декабрьскими обновлениями (CU4) . Возможно требование к «закреплению» правил это Баг и исправят позднее. Закрепляющие правила могут не изменять номер, но дают Lync Server понять, что вы уверены в том, что хотите использовать номер не в E.164 формате. Просто измененный одним правилом номер должен подпадать под регулярное выражение другого правила.

Примеры:

Имеем Dial Plan из  6-и правил:

  • Правило 1: ^(\d{4})$ -> 111$1
  • Правило 2: ^(\d{5})$ -> 111$1
  • Правило 3: ^(\d{7})$ -> $1      (Закрепляющее правило для правила 1)
  • Правило 4: ^9(\d{7})$ -> +7495$1
  • Правило 5: ^98(\d{10})$ -> +7$1
  • Правило 6: ^(\d{3})$ -> +74951234567;ext=$1

И имеем 6 вызовов, попавших на этот Dial Plan, на следующие номера:

  • 12
  • 12345
  • 1234
  • +74951234567
  • 91234567
  • +1234
  • 123

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

Вызов 1. Звонок на номер 12. Номер не в формате E.164 и не подходит ни под одно правило. Значит, вызов будет отбит без дополнительных проверок. 

Вызов 2. Звонок на номер 12345. Согласно правилу 2 вызов преобразуется к 11112345. Но это еще не всё. Правил для номера 11112345 нет, вызов не «закреплен» и также будет отбракован.

Вызов 3. Звонок на номер 1234. Согласно правилу 1 вызов преобразуется к 1111234, а согласно правилу 3 происходит «закрепление». Проверка нормализацией пройдена.

Вызов 4. Звонок на номер +74951234567. Номер уже в формате E.164 и в нормализации не нуждается. Проверка пройдена.

Вызов 5. Звонок на номер 91234567. Согласно правилу 4 номер преобразуется  к +74951234567. Номер +74951234567 в формате E.164. Больше преобразования не требуются. Проверка пройдена.

Вызов 6. Звонок на номер +1234. «+» перед номером есть, значит, считаем, что номер в порядке J. Преобразований не требуется. Проверка пройдена.

Вызов 7. Звонок на номер 123. Согласно правилу 6 номер преобразуется  к +74951234567;ext=123. Больше преобразования не требуются. Проверка пройдена. Собственно, это пример правила, преобразующего номер к формату, рекомендованному MS для организаций, в которых имеется один прямой номер.

Принцип понятен? Тогда еще нюансы:

  • При исходящих вызовах проверяется и меняется только номер вызываемого абонента (Calling ID).
  • При входящем вызове меняется и номер вызывающего (Caller ID) и номер вызываемого (Calling ID), но проверяется только (Caller ID). То есть, если Caller ID  не подпадает ни под одно правило – вызов всё равно пройдет.
  • Для входящих вызовов можно использовать планы только план нумерации уровня пула, (где пул – это голосовой шлюз) либо global.
  • Вызовы, пришедшие от автосекретаря Exchange UM, если уж они пришли, подпадают только под план нумерации global.       

Сколько следует создавать планов нумерации? 

Обычно – столько, сколько у вас филиалов с выходом в город. Посмотрите на правило номер 4 из приведенного выше примера. В каждом городе люди захотят звонить в родной город по короткому номеру. Если сможете приучить пользователей звонить в ближайший город, используя E.164 или формат из правила 5 того же примера, сможете обходиться одним Dial Plan на организацию.

Кроме того, если одна/две/три первых цифры номера отвечают за номер филиала, пользователи могут захотеть звонить внутри филиала по коротким номерам, без этого префикса. Это обеспечивается выделенным планом (правило 1 из примера) и тоже требует привязки планов нумерации к филиалам.

Транзитные АТС

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

<Телефон 1> — <АТС 1> — <АТС 2> — <АТС 3> — <Телефон 2>

Так вот, ни OCS, ни Lync в текущей версии, транзитной АТС не является. То есть, для всех телефонных вызовов, номер вызывающего или вызываемого должен быть в базе OCS/Lync.

Единственный способ обойти правило – создать в конфигурации Lync аналоговое устройство. Например, мы говорим, что у нас есть аналоговый телефон с номером 1234 и находится он за шлюзом АТС 3. Теперь с любого номера через АТС 1 можно позвонить на номер 1234 за АТС 3. С обратным сценарием сложнее, но об этом в другой раз.

Обработка входящих вызовов

Теперь у нас достаточно информации для разбора процесса обработки входящих вызовов. Итак:

  1. На первом этапе к номерам  Caller ID и Called ID применятся Dial Plan.
  2. Полученный после обработки номер  Called ID проверяется на соответствие телефонным номерам объектов Lync: клиентов, почтовых контактов, аналоговых аппаратов, служб конференций и групп дозвона (Response Group).
  3. Если соответствие найдено – вызов пересылается на нужный объект: клиенту, на сервер Exchange с ролью Unified Messaging либо на шлюз, за которым находится аналоговый телефон.

Отображение имени звонящего

Кстати, если телефонный номер вызывающего абонента по итогам нормализации пришел клиенту Lync в формате E.164, клиентское ПО Lync попытается распознать вызывающего, сопоставив номер с имеющимся списком контактов. Если же номер пришел без «+» в начале, единственный способ увидеть имя звонящего – передать Caller Name через шлюз.  

Обработка исходящих вызовов

В этом сценарии действий чуть больше.

После выполнения нормализации проводится проверка, имеет ли право абонент звонить на этот номер.

Политики Вызовов

Для исходящих вызовов, после выполнения нормализации, выполняется проверка, может ли пользователь звонить по набранному номеру (нормализованному).

В проверке участвуют три компонента: Voice Policy, PSTN Usage и Route.

Voice Policy (голосовая политика) применяется по той же схеме, что и Dial Plan. Помимо доступных функций телефонии, Voice Policy определяет перечень так называемых PSTN Usage (приблизительно можно перевести как тип вызовов), включая приоритет использования.

Маршрут (Route) включает в себя регулярное выражение и ссылку на голосовые шлюзы, через которые можно отправить вызов, подпадающий под это регулярное выражение. Route также связывается с PSTN Usage.

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

Пример использования такой схемы не самый эффективный, но сойдет для понимания концепции:

  • Голосовая политика MSK_BUH – включает в себя два типа вызовов: BRANCHES_LOCAL и MSK_RU.
  • Голосовая политика SBP_ BUH включает в себя два типа вызовов: BRANCHES_LOCAL и SPB_RU.
  • Голосовая политика MSK_VIP – включает в себя три типа вызовов: BRANCHES_LOCAL, MSK_ALL и SPB_ALL
  • Голосовая политика SPB_VIP – включает в себя три типа вызовов: BRANCHES_LOCAL, SPB_ALL и SPB_ALL
  • И т. д.

Соответственно, BRANCHES_LOCAL входит в кучу маршрутов формата +7<код города филиала> -> шлюз в филиале.

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

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

Нормализация на выходе

Моя «любимая» тема :-)

Теперь, когда мы почти уже выполнили вызов, осталась самая малость… Привести номера в соответствие требованиям оператора телефонии.  Хотелки у операторов бывают разные. 84951234567, 4951234567, 74951234567.Некоторые хотят получить номер 1234567, для локальных вызовов и 74951234567 для вызовов по стране.

А что мы можем?

В настройках взаимодействия со шлюзом (Trunk settings) можно указать регулярные выражения для манипуляций Called ID, что не может не радовать…. Но вот номер звонящего (Calling ID) можно поменять только в свойствах маршрута, причем не регулярным выражением, а исключительно на другой номер (один на маршрут).  В Trunk settings мы можем дополнительно только срезать с Calling ID пресловутый «+».

Выходит, что для каждого VIP с прямым номером, мы должны делать отдельные Voice Policy, PSTN Usage и Route. Это если у нас нет шлюза, и мы не договорились с оператором. :-)

Ждем Lync 15.

Обработка исходящих вызовов

Теперь коротко весь процесс для исходящих вызовов:

  1. На первом этапе, еще на клиенте Lync, к номеру Called ID применятся Dial Plan.
  2. Полученный после обработки номер Called ID прогоняется через связку Voice Policy, PSTN Usage, Route
  3. Если соответствие найдено – идет попытка вызова на маршрут. При этом номера Called ID и Calling ID меняются в соответствии с настройками Trunk settings и Route.
  4. Если шлюз не доступен – проверяется следующий шлюз маршрута
  5. Если все шлюзы маршрута недоступны – ищется следующий подходящий маршрут.

И напоследок. Обычно, получая номера формате +74951234567;ext=1234 шлюз отбрасывает ;ext=1234, что нам и требуется.

И напоследок, снова про форматы номеров

Предположим, у нас есть 10 филиалов, в каждом из которых есть по 10 VIP пользователей с прямыми номерами. Остальным можно дозвониться через локальный номер автосекретаря.

Как я уже говорил, обычно для каждого филиала создается свой Dial Plan.

Теперь считаем.

В каждом Dial Plan для каждого филиала нужно создать правило: <внутренние номера диапазона филиала> -> <номер автосекретаря>;ext=<внутренние номера диапазона филиала>.

Итого 10*10 = 100 правил

VIP наверняка получат красивые внутренние номера (а значит записанные вразнобой) и для них нужно написать отдельные правила формата <внутренний номер VIP пользователя> -> <городской номер VIP пользователя>;ext=<внутренний номер VIP пользователя>.

Итого 100*10 = 1000 Правил.

1100 правил. При этом любое изменение нужно отразить в 10 местах. Вот почему я так «люблю» формат +74951234567;ext=1234 :-)

Есть кстати еще одна причина. Если у вас имеется сопряжение с другими АТС и номер от другой АТС пришел к вам после преобразований формате +74951234567;ext=1234, в клиенте вы увидите только +74951234567.  Причем, с номерами, начинающимися на «+1″ такой проблемы нет. Может на тот момент когда вы читаете эту статью, проблема уже исправлена, но я застал её и в OCS и Lync Server. 

P.S.

Давно не писал статьи, так что считайте эту своего рода извинением перед читателями. Уверен, что читать её было сложно, но до сих пор столько фактов по обработке вызовов в Lync Server в одном месте я не встречал.

А вы готовы к Lync Mobile?

12.12.2011

Ждать выхода Lync Mobile осталось совсем немного. Счет идет на дни, если не на часы.

На Microsoft Download уже можно скачать «надстройку» над Lync Server (Mobility Service), необходимую для работы Lync Mobile (требует установки четвертого пакета обновлений для Lync Server).

Там же выложено руководство по настройке функционала Mobility.

Кроме того, CHM файл, включающий полное руководство по работе с Lync Server, также был обновлен.  Поиск по слову «Mobile» в файле выдает на 105 результатов (страниц руководства, где слово встречается) больше, чем в старой версии файла. В общем, работа была проделана немаленькая.

Некоторые особо активные участники Интернет-сообщества уже успели написать и выложить на всеобщее обозрение короткие пошаговые инструкции по настройке функционала Mobility.

Пошел обратный отсчет :-)

Первым должен выйти клиент для Windows Phone. Ищите на Microsoft MarketPlace. За ним подтянутся клиенты для iPhone, iPad, Android, Symbian. Клиента от MS для Blackberry не будет. Но не потому, что данную платформу проигнорировали, а потому что производитель смартфонов Blackberry уже все сделал сам  :-)

Часовые пояса на телефонах Lync и приоритеты MS

25.11.2011

Еще немного негатива в адрес уважаемой компании :-) На этот раз в адрес конкретного подразделения.

30 октября в России часы не были переведены на зимнее время. На телефонах с Lync Phone Edition время «поехало».

21 ноября вышло очередное обновление для Lync Phone Edition.

Так вот, товаГиши. Ответственно заявляю, что телефоны нам всё еще вГут. Это антипГоГГесивно и аГхинегативно.

нда..

Зная MS, могу предположить, что отдельного патча исправляющего только эту ошибку не будет, а общего ждать еще не меньше двух месяцев.

Сопряжение с SIP-системами в продуктах серии Communications Server. От Trusted Host до Trusted Application.

21.11.2011

Статья выросла из так и ненаписанного комментария к веб-касту Илгиза Мамышева и Александра Станкевича, описывающему сопряжение Lync Server c системы видео конференций (ВКС) от компании Polycom. Один из вопросов, прозвучавший во время веб-каста и так и оставшийся без ответа, касался назначения настройки Trusted Application и Static Route на стороне Lync. Начав писать про эти настройки, я понял, что формат комментария не подходит. Кроме того, в голове родилась мысль одного эксперимента, но об этом позже.

Как это было…

Мало кто знает, но через LCS 2005 уже можно было звонить по протоколу SIP на другие IP-АТС. Без роли Mediation (так нелюбимой многими в OCS 2007 и OCS 2007 R2 за необходимость выносить её на отдельный сервер), без проприетарного кодека RTAudio и, даже, без пресловутого E.164.

Все взаимодействие с телефонными станциями и системами видео-конференций в LCS 2005 настаивалось на двух вкладках: Host Authorization и Routing.

Разделение довольно простое: Host Authorization определяет, от кого могут приходить SIP-сообщения, Routing – куда отправлять SIP-сообщения в различных ситуациях.

Host Authorization

clip_image002clip_image004

Host Authorization (ныне Trusted Application) отвечает за две вещи: возможность входящих вызовов от SIP-адресов из других доменов и возможность регистрации абонентов в LCS/OCS без необходимости аутентификации.

Допустим у нас есть:

  • организация LCS/OCS/Lync (SIP-домен mydom.ru);
  • пользователь Вася c SIP-адресом vasya@mydom.ru;
  • сервер ВКС от компании Polycom.

Мы можем создать домен polycom.mydom.ru и пригласить в конференцию пользователя vasya@mydom.ru от имени конференции Meet-room@polycom.mydom.ru.

А можем создать учетные записи для нужных нам комнат в Active Directory, настроить их на работу с LCS/OCS с именами Meet-roomXX@mydom.ru и настроить сервер Polycom на регистрацию комнат в LCS/OCS без необходимости аутентификации. В этом случае пользователи будут видеть статус доступности комнат. Как минимум: On-Line, Off-Line. А в приглашении Вася увидит не SIP-адрес, а нормальное имя конференции, указанное в поле Display Name учетной записи, используемой конференцией.

Данный механизм можно использовать для подключения к LCS/OCS (для Lync не проверял) стандартных (не заточенных под решение от MS) SIP-телефонов, спотыкающихся на этапе аутентификации. Абсолютно противопоказано с точки зрения любых политик безопасности, но поиграть можно.

Routing

clip_image006

Routing (ныне Static Routes) определяет, куда отправлять вызовы, в которых получателем значится определенный SIP-адрес (убрали в OCS) или любой адрес из указанного SIP-домена.

В предыдущем примере, если мы хотим, чтобы пользователи могли звонить в конференцию Meet-room@polycom.mydom.ru, нужно создать маршрут, описывающий на какой сервер и в каком виде слать сообщения для домена polycom.mydom.ru или пользователя Meet-room@polycom.mydom.ru.

Можно указать свой SIP-домен (в примере mydom.ru). В этом случае в сторону маршрута будут уходить вызовы на имена формата <имя>@mydom.ru, которые не зарегистрированы в LCS/OCS. В LCS/OCS можно указать, что маршрут будет использоваться для вызовов на телефонные номера (Phone URI). Этот параметр нужен для настройки RCC или маршрутизации телефонных вызовов.

Безопасность

Коммуникации между LCS/OCS и другим SIP-сервером рекомендуется шифровать. Для этого нужно настроить с обеих сторон отправку/вызовов по протоколу TLS (само собой, требуется установка на серверы сертификатов безопасности, организация доверия сертификату другой стороны и включения механизма прослушивания TLS).

Federation

Стоит сразу отметить, что Host Authorization и Routing позиционируются для коммуникаций внутри организаций. Для внешних коммуникаций еще в LCS использовался граничный сервер (Access Proxy в LCS или Access Edge позднее).

Приложения

Основное назначение Host Authorization и Routing с точки зрения Microsoft – обеспечение доступа сторонних приложений к LCS/OCS. В первую очередь откликнулись телефонисты (RCC). Во вторую – производители систем ВКС. Как я уже писал, производители IP-телефонии охладели к RCC в «эпоху» OCS 2007 (когда поняли, что MS хочет занять их позиции) и активизировались после выхода OCS 2007 R2 и приближении выхода Lync, когда поняли, что у MS может получиться. С производителями ВКС ситуация похожа.

Конференции

Забавно, но только сейчас интеграция Lync с Polycom выходит на уровень, имевшийся во времена LCS 2005 SP1. Связано это, пожалуй, с излишней самоуверенностью разработчиков OCS.

В LCS 2005 не было своего сервера конференций (MCU), и Office Communicator 2005 был «заточен» под взаимодействие с серверами конференций третьих фирм. См. скриншот.

clip_image008

Производители ВКС писали инструкции по настройке клиентов под их решения, создавали скрипты, выполняющие настройки автоматически и надстройки над Office Communicator 2005, позволяющие создавать конференции на их оборудовании одним кликом.

Уже LCS 2005 при интеграции с оборудованием Polycom была возможность, которая в Lync, при той же интеграции появилась только недавно и то пока находится на стадии беты: возможность выделить несколько человек из списка контактов и создать конференцию, в которой будет видно всех участников.

Вся красота разрушилась с выходом OCS 2007. Мало того, что в MS убрали возможность подключения к сторонним MCU, так еще и изменили формат SIP-сообщений (например, добавили поддержку ICE v12). Производители ВКС «прифигели» от такого «счастья» настолько, что отошли только через год после выхода OCS 2007 R2. А еще через полгода вышел OCS 2007 R2 с поддержкой ICE v19 и опять проблемы сопряжения. Мы поддерживаем работу наших систем c OCS 2007 R2, писали производители ВКС, дописывая мелким шрифтом, что клиент при этом должен оставаться Office Communicator 2007 (не R2). :-) Потом конечно поправили и это, но настолько тесной интеграции, как была при LCS 2005, пока что нет.

Настоящее время

В Lync Server интерфейс администрирования был переделан с нуля (не считая куска Response Group, но это отдельная тема), и сопряжение с SIP-серверами у разработчиков было далеко не на первом месте. В последнее время это означает, что функционал остается, но доступен только через PowerShell. :-)

Так что, вместо вкладок выше, имеем команды

  • XXX-CsTrustedApplicationPool
  • XXX-CsTrustedApplicationComputer
  • XXX-CsTrustedApplicationEndpoint
  • XXX-CsTrustedApplication

и

  • XXX-CsStaticRoute
  • XXX-CsStaticRoutingConfiguration

Кроме того, для сопряжения систем по TCP (без шифрования) придётся еще и руками править файл конфигурации Lync. (Об этом я уже писал в отдельной статье)

В официальной документации информации по командам не так много. К счастью, уже есть неплохие инструкции по настройке RCC от Cisco и сопряжения с оборудованием ВКС от Polycom. Их вы можете использовать (в части настроек на стороне Lync) и при настройке сопряжения с оборудованием других фирм.

Чего ждать

О продолжении банкета пока говорить рано.

Судьба RCC каждую новую версию весит на волоске, прямо как Public Folders в Exchange.

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

От сторонних разработчиков MS не откажется, так что Trusted Application и Static Route никуда не денутся. Может, только опять поменяется интерфейс доступа.

Эксперимент

Описание данного механизма нигде, вроде, не встречалось, но логично предположить, что используя Trusted Application и Static Route, одну организацию LCS/OCS/Lync можно скрестить с другой организацией LCS/OCS/Lync без использования серверов с ролью Edge. Данной идеей я поделился с Александром Станкевичем (известным в Российском IT-сообществе любителем такого рода «асоциальных» экспериментов). Поделился и лег спать, планируя вместе настроить всё в свободное время. А на утро получил письмо, что эксперимент успешно завершен. :-)

… Тут у нас с тезкой должен быть спор на 5 листов, сколько технической информации для эксперимента я ему дал и сколько он сам накопал, но вырезано цензурой для сокращения объема статьи. Ожидайте предложения в комментах :-) …

В общем, имеем: организация Lync, организация OCS 2007 R2.

Настроено сопряжение по протоколу TLS, используя Trusted Application и Static Route со стороны Lync и Host Authorization и Routing со стороны OCS.

Работает весь функционал, включая отображение статуса, голос, видео, демонстрация рабочего стола, конференции (даже с федеративными контактами). Кстати, поскольку абонент подключен не через федеративные отношения, значок clip_image010отсутствует. Отличия: контактов нет в адресной книге (без дополнительных асоциальных экспериментов), и статус доступности не отображается, пока не разрешит пользователь другой организации. Ну и само собой, поддержки от MS при таком решении не видать.

TechEd Russia и подтверждение слухов

20.10.2011

Слухи подтверждаются. Согласно программе конференции TechEd Russia, в своем выступлении Тимур Баязитов покажет клиенты для Lync под Windows Phone 7, iPhone, iPad и Android.

Кстати, до встречи на TechEd Russia. Подходите в зону экспертов, задавайте вопросы :-)

Старости

17.10.2011

1. Покупка Skype

clip_image002Компания Microsoft объявила о завершении приобретения Skype. Теперь, наконец, займутся полезной работой: Skype для X-BOX, Skype для Windows Phone, сопряжение Skype с Lync и настройкой Office 365 на использование выходов в ТфОП, используемых Skype. Последнее веселее всего. Если я прав, когда начнут и наступят на свои же грабли, доработают в Lync возможности по настройке SIP в части взаимодействия с разными голосовыми шлюзами. :-)

2. Lync for Mac

clip_image004Коротко новость должна выглядеть так: Lync for Mac вышел, Lync for Mac споткнулся о последнее обновление для Office for Mac и упал :-)

Официальная страница клиента тут. Инструкция по установке тут. Описание ошибки с установкой обновления Office for Mac и способ решения тут.

Кстати, интересный факт: вышедшая до этого версия клиента под Mac, совместимая с Lync, называлась Communicator for Mac, потому как обладала урезанным функционалом. В MS считали, что продукт не готов называться гордым именем LYNC. :-)

3.  «Окнофон» в России

clip_image006Мобильные телефоны с Windows Phone 7.5 на борту официально поставляются в Россию. Microsoft MarketPlace не нужно обманывать, указывая в Live-ID другой регион. Жизнь налаживается. :-) Если у вас возник вопрос, какое отношение это имеет к объединенным коммуникациям, значит, пора переходить к следующей старости….

4. Мобильный Lync. Слухости

clip_image008 В скором времени должно выйти очередное обновление для Lync Server. А вместе с ним и версия Lync для мобильных платформ. Есть вероятность, что озвучены и показаны подробности будут на Teched Russia. Ждем.

Тут официальная информация, а тут видео «окнофона» с запущенным клиентом Lync.

5. Lync Social

clip_image010 Появилась небольшая бесплатная надстройка над Lync для «монстров социального общения». Комментарий из Lync (который многие используют для демонстрации всем личного афоризма) с её помощью реплицируется в LinkedIn и Twitter.

6. Телефоны. Тема номера :-)

clip_image012Теперь телефоны для Lync создает еще и HP. Звучит хорошо, но если присмотреться, это те же две, уже ставшие стандартными, модели:

  • Полноценный UC-Phone — HP 4120 IP. Аналоги: Polycom CX600 и Aastra 6725ip.
  • Телефон без интеграции с компьютером — HP 4110 IP. Аналоги: Polycom CX500 и Aastra 6721ip.

Небольшой совет. При выборе телефона для Lync не сморите на модель без интеграции с компьютером как на полноценный телефон сотрудника. Microsoft его так и не позиционирует.

Совет небольшой, а разъяснение будет длинное. :-)

Чтоб было понятно:

  • Существует два способа авторизоваться на Lync Phone Edition: а) ввести на телефоне свой номер и PIN и б) при подключении телефона к компьютеру по USB кабелю ввести имя входа и пароль пользователя из Active Directory на компьютере.
  • Часть данных телефон Lync берет из почтового ящика пользователя на сервере Exchange (контакты Outlook, пропущенные вызовы!!!, список встреч и т.д.).
  • Для доступа к почтовому ящику на телефоне должны храниться имя входа и пароль пользователя из Active Directory. Ваш телефонный PIN знает только Lync Server, но не Exchange Server.

Делайте выводы…

Ну и конечно, без связки с рабочей станцией теряется функционал Click to Call, Click to Conference и т.д. то есть, теряется вся прелесть UC решения. По опыту, после внедрения Lync пользователи очень быстро престают нажимать на кнопки на телефоне. :-)

Кстати, вместо HP 4110 IP, Polycom CX500 или Aastra 6721ip для обычных (не VIP) пользователей я обычно предлагаю USB-телефоны Polycom CX300. Недоверия у IT-администраторов к USB телефонам обычно больше чем оказывается на деле у пользователей. Плюсы от интеграции с компьютером перевешивают недовольство от необходимости включать компьютер для работы телефона.

Lync и SIP. Объявление медиа-возможностей и ошибка КПВ

12.10.2011

Продолжаем разговор про использование SIP в Lync Server 2010. На этот раз мы разберем SDP пакет, генерируемый Lync при видео-вызове в части предлагаемых способов аудио/видео взаимодействия и ответим на пару вопросов из предыдущей статьи, включая наиболее популярный: про отсутствие гудков при звонке на Lync.

Домашнее задание

Для начала, проверим домашнее задание – посмотрим, какие кодеки использует Lync.

Как и в прошлый раз, я выложил разбор в отдельный PDF.

Несколько коментариев:

  1. Как видно из SDP, H.263 в реализации от MS не будет принимать/передавать разрешение больше чем CIF. Только используя 121 x-rtvc1/90000 можно добиться VGA и HD разрешения приема/передачи видео. Поэтому, при сопряжении Lync / OCS c большинством  систем ВКС, качество видео будет довольно низким.
  2. Ответ на вопрос про Communicator for MAC, заданный в предыдущей статье, также довольно прост. Поддержки H.263 в нем нет. Остается только проприетарный кодек от MS. А если двум системам не удалось найти общий кодек – соединение данного типа не будет установлено. Вот и получится – организовывали видео-вызов (голос + видео) – получили просто голосовой.
  3. Если посмотреть на SDP приглашения отправляемого от Lync на голосовой шлюз, вы увидите только два голосовых кодека: G.711 в его двух разновидностях.  Забавно, что убрали RTAudio. Производители шлюзов уже давно были на низком старте, готовые включить данный кодек в следующую прошивку, как только MS даст разрешение. А тут такой облом. :-) Зачем? Почему? Ни RTAudio, ни G.729.
  4. Доступные разрешения видео-вызова при использовании RTVideo зависит от мощности рабочей станции и настроек Lync Server. Подробности тут.

Разбор ошибки с отсутствие гудков

Во второй части статьи опишу причину наиболее часто возникающей ошибки при настройке Lync Server в качестве АТС. А именно, отсутствие контроля посылки вызовов (КПВ) при поступающих на Lync звонках.  Проще говоря, отсутствие гудков.

Идеальная ситуация

Упрощенно, процесс телефонного вызова из ТфОП в IP-телефонию выглядит так:

   

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

Но это в идеале. Почему же при работе с решением от MS генерация КПВ в некоторых случаях не происходит?Ноги у этой проблемы растут довольно далеко. Все началось в далеком 2007-ом году… (театральная пауза).

Истоки проблемы

В OCS 2007 в Microsoft внедрили поддержку протокола ICE (Interactive Connectivity Establishment), позволяющего обходить «двойной NAT» для голосового трафика. Это обеспечило возможность приема/передачи голоса и видео для пользователей OCS, подключаемых из сети Интернет. Однако, технология предусматривала последовательный опрос нескольких точек подключения, что требует некоторого времени. Источник вызова не мог начать опрос возможных вариантов соединения до получения сообщения 200 ОК, содержащий вложение SDP со списком возможных способов связи. Как результат, какое-то время в трубке была слышна тишина, а первые сказанные фразы могли потеряться. Исключение составляли вызовы на голосовой шлюз.
Приблизительная схема выглядит так:
 
Имеем стандартную схему. Внутренний пользователь, сервер с ролью Front End, Сервер с ролью Edge (условно его можно разделить на Access Edge и Audio/Video Edge), внешний пользователь.
 
Попытки соединения для передачи RTP трафика и сам трафик от вызываемого абонента не рассматриваю, так как его можно стартовать сразу после сообщения INVITE, потому что оно уже содержит описание возможностей вызывающего.
В OCS 2007 R2, чтоб избежать такой ситуации была использована одна хитрость, заложенная в RFC 3960, и связанная с обработкой ответов 183 Session in progress.

Ответ 183 Session  Progress и RFC

Тут нужно сделать паузу и немного рассказать про ответ 183 Session in progress.
Из RFC 3621, описывающему протокол SIP: 
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified.  The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress

Никакой конкретики. В реальности, ответ 183 Session progress обычно используется для передачи голоса до установления соединения, Early Media (Например, чтоб проиграть голосовое сообщение или музыку, пока абонент не возьмет трубку). Так вот, если ответ получен,  но голосовые пакеты еще не пошли, то согласно RFC 3960 IP-АТС / голосовому шлюзу рекомендуется передавать КПВ.
Из RFC 3960
With this in mind, a UAC should develop its local policy regarding local ringing generation.  For example, a POTS («Plain Old Telephone Service»)-like SIP User Agent (UA) could implement the following local policy:

  1. Unless a 180 (Ringing) response is received, never generate local ringing.
  2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
  3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
  4. Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session.

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

Реализация Early Media от MS

MS использует ответ 183 Session progress дважды. Первый раз после отправки 100 Trying, просто чтоб показать, что работа в разгаре. Сам не знаю, зачем. Второй раз, когда запрос дошел до конечной точки маршрута. На этот раз уже ответ cодержит SDP.
Покажу на примере. На этот раз разберем обмен сообщениями чуть подробнее.


 
Получаем, что сессия устанавливается еще до того, как абонент поднял трубку. Если одновременно запущен только один клиент Lync, то он и ответит на вызов и в ответе 200 ОК будут те же данные, что и в 183 Session progress. Сессия установлена заранее. Как только получен ответ – голосовой/видео трафик пошел. PROFIT!

Что имеем

Проблему решили, но, в результате получили новую. :-) Идеей загорелись, и ответ 183 Session progress начали передавать даже в сторону голосовых шлюзов/IP-АТС. Однако, как оказалось, ответ 183 Session progress - одна из давних головных болей IP-АТС. Одни IP-АТС перестают отдавать КПВ, получая ответ 183, содержащий SDP, и ждут, когда пойдет голосовой трафик. У других «сносит крышу» от ответа 183, не содержащего SDP. А  теперь еще и Microsoft, в продуктах которого традиционно почти нет настроек сопряжения с продуктами «партнеров».
Некоторые производители в очередных обновлениях по просьбам трудящихся добавили корректную обработку 183 Session progress (Например, Avaya). Другие предлагают срезать приходящие ответы 183 от Microsoft (Cisco).
Один из инженеров MS даже написал плагин для OCS 2007 R2, генерирующий КПВ пока не будет установлен настоящий вызов. Но, видимо, это шло вразрез с политикой партии, и в Lync Server данный функционал  добавлен не был.
В общем, пока проблема есть и решается индивидуально. Так и живем….

P.S.

Основой для статьи (в части разбора ошибки с КПВ) является серия статей в блоге Криса Нормана, ака voipnorm. Там же вы можете много подробностей сопряжения Lync/OCS с Cisco/Avaya.

Очередные старости UC

13.08.2011

Не писал давно. Как следствие, старости еще более старости, чем обычно, и их просто больше.

Обновления

  1. Обновления для Lync Server 2010, Lync 2010 и Lync Phone 2010. От большой лени, даю ссылку на сайт, где они уже скомпонованы.
  2. Обновление для Exchange 2010. Вторая версия четвертого накопительного обновления для первого пакета обновлений. Звучит!!! :-)

Документация

  1. Еще одно обновление. Но на этот раз документации. Последняя версия полной документации по Lync Server одним файлом в формате CHM доступна тут.
  2. Server 2010 Resource KIT. Microsoft наконец закончили титанический труд по созданию руководства по работе с Lync Server 2010. В отличие от  такого же документа по OCS 2007 R2, Lync Server 2010 Resource KIT изначально находится в открытом доступе в виде кучи документов MS Word. Лично у меня  Lync Server 2010 Resource KIT  вызывает смешанные чувства. Такое ощущение, что некоторые главы писались «левой пяткой», а другие просто не в тему. Но зато наконец есть раздел по резервному копированию, оно в конце концов бесплатно, и, еще один важный момент, продолжает обновляться. Несколько дней назад обновили главу по EV. Само творчество сборной команды писателей Microsoft находится тут.  

Телефония

  1. Cisco поддерживает RCC c Lync Server 2010 при использовании  Cisco Unified Communications Manager 8.x и Cisco Unified Presence 8.5.2. Об этом я уже писал в одной из предыдущих статей.
  2. MS выпустил подробный документ по direct SIP между IP-АТС Cisco CUCM и MS Lync Server 2010. В документе описан извилистый маршрут в обход граблей, возникающих из-за странного взгляда наших любимых производителей на RFC. Хотя, что тут странного. (Оба вендора) Мы делаем для вас кучу примочек, которых нет ни у кого на рынке, но у нас нет времени на их заточку и проверку в разных вариантах настройки. Поэтому мы не будем давать вам что-то настраивать сверх меры. Так что, 
    • (Cisco) оборудование Cisco отлично интегрируется с оборудованием Cisco. Покупайте только наше оборудование.
    • (Microsoft) используйте  оборудование сертифицированных партеров.
  3. Приложение NET SmartSIP теперь поддерживает DECT телефоны от компаний Avaya и Aastra. В полку беспроводных устройств работающих с Lync Server 2010 (хоть и не напрямую) прибыло.

Polycom. Нынешний любимый партнер Microsoft и сразу три старости

  1. Dect телефоны Polyсom Kirk научились работать с Lync без NET.
  2. Polycom выпустили CX7000. Кодек со встроенным клиентом Lync. Вот такой странный гибрид. Зато теперь не нужно ломать голосу, что ставить в комнате совещаний. Всё таки CX5000 (бывший RoundTable) вещь в себе. Хотя отзывы об использовании, которые до меня доносились, вполне положительные.
  3. Polycom приобрел часть бизнеса HP, связанную с видео-конференциями. Прощай UC альянс Microsoft — HP. Поздравляем крупнейшего поставщика решений ВКС и … абонентских окончаний для UC решения Microsoft :-).   

Поделки

  1. MS выпустил несколько расширений для Microsoft Lync 2010. Устанавливаем и играемся, кому интересно. Кому-то част приходится общаться с иноязычными коллегами, кому-то давно хотелось иметь в Lync закладки аля ICQ.
  2. И напоследок, немного веселья. Наткнулся на интересное партнёрское решение. Фактически, индикатор занятости, крепящийся, например, на монитор. Что дальше? Ответ можно найти у игроделов.

 

Обратите внимание, индикатор статуса доступности встраивается в рабочую одежду. Цифра наверху, видимо, количество пропущенных вызовов и полученных сообщений голосовой почты ;-).

 

Lync на SMB рынке. Разбор одного случая

13.08.2011

Наткнулся недавно на интересную статью. Автор описывает свои впечатления от установки Lync Server 2010.
Читая, отмечал про себя ошибки, допущенные автором, и пытался проанализировать ситуацию с разных сторон.

Разбор действий

  • Требования к дополнительным компонентам легко найти в документации, на которую есть ссылка из мастера установки. Planning for Microsoft Lync Server 2010 > Determining Your Infrastructure Requirements > Determining Your System Requirements > Additional Software Requirements.
  • SQL потребовался потому как в Topology Builder была выбрана установка Enterprise версии продукта, отличающаяся от Standard только наличием высокой доступности, которая, собственно, и требует выделенного сервера (в идеале, кластера) SQL. Видимо, устанавливающий решил что версия Enterprise имеет больший функционал. Избежать этой ошибки можно было изучив лицензирование Lync Server либо воспользовавшись инструментом c говорящим названием Lync Server 2010 Planning Tool. Ссылка на инструменты также имеется в мастере установки Lync Server 2010.
  • Ну и раз уж был выбран Enterprise Pool – для него нужно создать запись в DNS. Можно было бы это сделать автоматически, но вдруг у вас имя доменная часть пула отличается от AD и совпадает в SIP доменом. А SIP домен обслуживают другие серверы.
  • Кроме того, для автоматического поиска северов тоже нужны записи в DNS. Об этом говориться в документации в разделе по планированию внедрения (что логично) и в инструменте Lync Server 2010 Planning Tool, упоминавшемся ранее.
  • Silverlight устанавливается при установке Lync (хотя как раз это можно и не заметить), а к консоли администрирования можно подключаться по сети из веб браузера. Адрес консоли есть в Topology Builder в разделе Simple URL. Даже если там пусто – консоль доступна по адресу HTTPS://FQDN сервера/sccp. Но эту информацию тоже нужно найти в документации.
  • Про Exchange – всё так и есть. Lync Server без Exchange ставить смысла нет. Никто это не скрывает.
  • А вот информацию, что при отсутствии связи между пользователями, голос и видео передаются через Lync Edge, а не через Front End искать можно очень долго. Странно поведение, хотя и объяснимое. Кстати, трафик конференций идет через Front End, так что удивление бывает еще большим, если доходит до конференций с тремя участниками и сервер Lync Edge не установлен. Общаются двое – нет звука. Общаются трое – звук есть.

Как видно, из описания выше, большая часть ошибок связанна с тем, что была попытка поставить «тяжелый» продукт без хотя бы базового изучения документации. Автор решил поставить Lync Server с наскока и результата закономерен. Однако, есть и моменты, такие как хождение трафика голоса/ видео в защищенной сети, которые без гугла или интеграторов не решить.

Оценка ситуации

Точка зрения автора, как представителя ИТ-администраторов, работающих на SMB рынке, понятна из статьи.

С точки зрения Microsoft, продукт нацелен на Enterprise рынок. Lync Server “заточен” под масштабное внедрение. Именно поэтому криво выглядит установка первого сервера. Если у вас нет своего специалиста, прошедшего обучение в сертифицированном центре, пригласите интегратора. При этом маркетинг MS понимает, что SMB тоже можно продать Lyn Server и понимают, что собственными силами ИТ-отдел заказчика легко «завалит» внедрение. Недаром, недавно стартовала новая компания: маленькие интеграторы за маленькие деньги поставят вам один сервер с базовым функционалом (шаблон документации, разработанный в MS прилагается).

ИТ-администраторы, работающие в компаниях среднего и Enterprise уровня, где имеется специализация ИТ-персонала, посоветовали бы автору прочесть документацию перед внедрением нового продукта :-). Также поступят отвечающие на форумах специалисты интеграторов. Но и здесь есть подвох. Документация тоже заточена под внедрение в компаниях уровня Enterprise. Простой инструкции по настройке сервера Standard Edition в ней нет. Вернее есть, но разброса она по всему немаленькому многостраничному документу. Тут требуемые для установки сервера службы, тут описание инструмента Topology Builder в котором описывается топология Lync Server, там указания на дополнительные записи в DNS, для автоматического поиска сервера. В общем, для ИТ-администратора, у которого нет времени головой погружаться в изучение еще одного продукта, более правильным способом будет найти в пошаговую инструкцию на одном из блогов. И хорошо, если инструкция будет написана специалистом, а не коллегой бедолаги админа, который с горем пополам поставил новый продукт и теперь готов рассказать всему миру, как он это сделал.

Статья по ссылке – не единичный случай в моей практике. Периодически слышу подобные замечания. Да и сам, когда-то ставя LCS в первый раз долго удивлялся, почему мастер установки сам не создал нужные записи в DNS. Теперь я это понимаю, а про невозможность установки нужных компонентов Windows удивляюсь до сих пор. Exchange 2010 SP1 это делать криво-косо, но научился. Опять же, это не критично для Enterprise рынка,  но для SMB…

В компании, где я работаю, есть программа поощрений для сотрудников, приносящих полезные идеи, помогающие продвигать бизнес. Если такая программа есть в MS и эту запись читают сотрудники MS – предложите разработчикам сделать отдельный мастер установки для SMB рынка. Чуть больше вопросов. Большое предупреждение c длинным текстом ограничений использования и куча скрытых скриптов :-).
А может, я ошибаюсь, и это не недоработка, а хитрый способ вырастить множество партнеров, которые будут уметь внедрять Lync Server ;-). От представителей одного производителя (не MS), я как то слышал, что они могли бы сделать интерфейс проще, но не будут. Потому как их продукцию продвигают партнеры, внедряющие решение. Если заказчик сам может внедрить продукт, ему не нужны будут партнеры. Значит, некому будет продвигать решение этого производителя. Вот такой забавный расклад.

Старости и новости Remote Call Control

20.07.2011

 RCC и с чем его едят

Remote Call Control (RCC) – технология, позволяющая управлять телефоном, подключенным к какой-либо телефонной станции из программного клиента (Office Communicator / Lync) без необходимости расширения клиента. RCC позволяет из программного клиента принять телефонный вызов, выполнить вызов, переключить входящий или текущий вызов на другого пользователя. При этом соответствующие действия будут выполнены на аппаратном телефоне, подключенном к другой телефонной станции. Статус пользователя во время телефонного разговора изменяется на «говорю по телефону».

Сама технология была придумана задолго до того как Microsoft примеил её в LCS 2005 SP 1 и называется Computer Supported Telecommunications Applications (CSTA).  Для работы CSTA от MS требуется промежуточный сервер, переводящий запросы стандарта TR/87 в запросы понятные АТС. Общая схема решения приведена на рисунке ниже.

Программный клиент через сервер MS и TR/87 Proxy регистрируется в качестве источника управления вызовами телефонного аппарата, подключенного к АТС. На клиент приходит информация о событиях на телефоне. Команды клиента передаются на телефон.

 Старости :-)

 Глава 1. LCS

Впервые RCC появился в Microsoft Office Live Communications Server 2005 SP1. В то время это был очень хитрый маркетинговый ход. В Microsoft понимали перспективы рынка IP телефонии и свою неготовность к выходу на этот рынок.

В то же время, удобный интерфейс всегда был одним из главных достоинств Microsoft. На этом и решили сыграть.

Набрать одиннадцатизначный номер мобильного телефона парой кликов мыши или видеть, готов ли ваш коллега принять телефонный вызов – неплохое расширение функционала телефонной станции.  Под этим соусом решение и подавалось. И производители АТС «купились», на перебой предлагая свои решения по интеграции с Microsoft LCS / OCS. Ведь, RCC стал конкурентным преимуществом. Нет у тебя, но есть у конкурента – купят конкурента. Так производители АТС сами начали раскручивать своего будущего конкурента.

 Глава 2. OCS 2007

Выход на рынок Microsoft Office Communications Server 2007 происходил довольно весело. В это время в Microsoft начали активно продвигать понятие Unified Communications (UC). Все коммуникации в одном. Синергия в чистом виде. За полгода до выхода OCS маркетинг Microsoft был уверен, что их разработчики выведут на рынок настоящую бомбу, которая будет на голову выше любой АТС. Однако ближе к выходу об этом начали забывать, всё больше вспоминая прежнюю концепцию расширения функционала АТС. Только изредка звучало скромное: «а для тех, кому нужно больше функционала, возможен полный переход на OCS». От телефонных аппаратов предлагали полностью отказаться и переходить на USB гарнитуры. Из RCC вырезали возможность переадресации вызовов по расписанию.  Остальной функционал остался, но отставание от возможностей телефонии на OCS появилось не из-за этого. Удаленный доступ и конференции. Возможность делать телефонные вызовы из сети Интернет без использования VPN и мышкой собирать телефонную конференцию были отличным поводом перейти на использование OCS как телефонии. К сожалению, доводов против было намного больше, так что RCC использовался повсеместно, как одна из причин внедрения Office Communications Server.

Для того, чтобы побудить людей попробовать использовать OCS в качестве АТС был придуман еще один маркетинговый ход – Dual forking. При грамотной настройке — входящий вызов поступал как на АТС так и OCS. Предполагалось, что при работе из Интернет вы ответите в программном клиенте и будите говорить через гарнитуру, а на рабочем месте продолжите использовать ваш старый телефон. Самый «козырный» сценарий (Dual Forking + RCC) был доступен только с АТС основного партнера MS в области телефонии на тот момент – Nortel CS 1000.

Есть мнение, что RCC в OCS 2007 оставили как раз, чтоб обеспечить отображение статуса доступности при разговоре с телефона в режиме Dual Forking + RCC. Но идею Dual Forking производители АТС не поддержали. И почему бы это? :-)

 Глава 3. OCS 2007 R2

Microsoft Office Communications Server 2007 R2 стал логичным предложением идей, заложенных в OCS 2007. Телефония развивалась и достигла приемлемого уровня, достаточного для внедрения на небольших предприятиях (если закрыть глаза на отсутствие нормальных телефонов), в то время как наличие RCC до самого релиза ставилось под сомнение.

Тем не менее, RCC сохранился в прежнем объеме. Теперь уже RCC стал оружием производителей АТС в борьбе против MS. Оставьте Microsoft ПО, а телефонию нам. Каждый делает то, в чем лучше разбирается. Говоря так, тем не менее, основные игроки на рынке активно пытались догнать Microsoft на его поле. Идея UC уже распространилась и все понимали, что просто IP-телефония скоро уже будет мало кого интересовать. Как IP-телефония постепенно заменила аналоговую, так UC решения постепенно заменят собой обычные средства коммуникаций, включая IP-телефонию «без наворотов».  Независимые аналитики прогнозировали в недалеком будущем борьбу за рынок UC между гигантами Cisco и Microsoft.

 Глава 4. Lync Server 2010

Lync Server вышел на рынок всё так же с поддержкой RCC. Это был вынужденный ход. Слишком много заказчиков, которых нужно было пересадить на Lync Server, активно использовали RCC.  

Для Microsoft в Lync Server 2010 RCC стал тем же, чем Public Folders в Exchange Server. И хочется выкинуть, да все используют. Функционал RCC опять урезан. На этот раз, пользователи RCC лишились возможности участия в видео конференциях Lync Server. Судя по всему, это ошибка, которую не стали исправлять, пожалев время. Возможно, функционал вернут в одном из патчей, если будет много «криков» от заказчиков.

Взамен, в Microsoft предложили протокол обмена статусами доступности между АТС. Такая же мертворожденная идея как Dual Forking + RCC и Advanced Gateway. Обе идеи поддержали по одному производителю, да и то, когда в MS к самим идеям уже охладели. :-) 

Обещанная конкуренция идет полным ходом (сам принимал участие в паре крупных проектов / битв Cisco vs MS) и RCC используется, как последний аргумент против полной миграции на Lync Server c других платформ.

 Кому я должен — я всем прощаю

C RCC у Microsoft связана интересная ситуация. Microsoft поддерживает технологию, но не поддерживает реализацию. Что это означает? Если вы настроите один компонент  Lync Server без оглядки на Supportability Guide, а проблемы будут с другим компонентом, техническая поддержка может отказаться решать вашу проблему пока первый компонент не будет настроен. Поддержка технологии означает, что использование RCC разрешено. Однако, если возникнут проблемы именно с работой RCC, и вы обратить непосредственно в Microsoft, вам ответят, что вам следует обратиться к тому, кто заявил, что их решение работает с Microsoft Lync Server 2010 в режиме RCC.

 И что теперь?

За прошедшие две недели сразу два производителя заявили о поддержке RCC с Lync Server 2010.

Cisco поддерживает RCC c Lync Server 2010 при использовании  Cisco Unified Communications Manager 8.x и Cisco Unified Presence 8.5.2. На самом деле, все отлично работает и на старых версиях CUCM и CUPS. Но зачем Cisco поддерживать интеграцию последней версии продукта конкурента со старой версией своего продукта? Так можно постепенно быть вытесненным из заказчика. http://www.microsoft.com/download/en/confirmation.aspx?id=11530

В Avaya добавили поддержку RCC с Lync Server в AE Services R6.1.1. К слову, в данном случае, добавили поддержку, значит, устранили недочет, вызывающий сбой. До AE Services R6.1.1 настроить RCC между Lync Server и Avaya Session Manager было нельзя. http://support.avaya.com/css/P8/documents/100144425

На этом можно и закончить рассказ об истории небольшой технологии, которая несколько лет двигала прогресс вперед и повышала эффективность бизнеса. Сейчас использование RCC не окупается. Правильный вариант — выбрать одну платформу, а не платить сразу двум производителям. Я совсем забыл упомянуть про лицензирование. В LCS / OCS функционал RCC требовал лицензии Enterprise CAL, а в Lync – Plus CAL. Те же лицензии требуются для функционала телефонии и стоимость, соответственно одинакова. Но в дополнении к  RCC  вам нужно иметь оплачивать еще и поддержку существующей телефонии, и ограничивать себя в функционале.

 

Снова MVP и кое-что еще

19.07.2011

Вернувшись из отпуска, обнаружил два письма от Microsoft.

В первом письме сообщалось о продлении моего статуса MVP, так что начался третий срок! Как всегда, обещаю, что буду стараться, но это всё, что могу обещать. Всё-таки работа важнее, а её в последнее время предостаточно. 

Второе как раз касалось работы :-) Во время прошедшей недавно партнерской конференции Microsoft (WPC 2011) компания, в которой я работаю (КРОК), была выбрана в качестве Microsoft CEE Voice Partner of the year.  CEE — Central and Eastern Europe.

Решил отметить эти события и окончание отпуска в последний день перед работой в чешской пивнушке, но закончилось всё обсуждением ближайших планов с менеджером в том же баре. :-) А планов — море! Скучать времени не будет. Радует одно: больше интересных проектов — больше новых знаний. А значит, возможно, больше новых тем для статей.

Lync и SIP. Обзор SDP и разбор SIP сообщения

18.07.2011

Вступительное слово

Данная статья является второй частью рассказа, про использование SIP в Lync Server 2010.

Статья сильно отличается от того что я писал ранее. Даже статьёй данный текст можно только с большой натяжкой. Больше похоже на второй урок. Так что я даже решил воспользоваться терминологией преподавателей.

В документации по Lync часто можно увидеть пример SIP запроса с комментарием типа: «вот так выглядит SIP сообщение, генерируемое в таком конкретном случае». Разобрать что к чему, не проштудировав кучу дополнительной документации довольно сложно. Как понять, на что стоит обращать внимание, что является признаком некорректной работы? Особенно это важно при работе с внешними SIP системами.

Целью первых двух уроков (напоминаю, что это уже второй) является заложить базовые знания SIP/SDP, что поможет в будущем понять непростые взаимоотношения Lync Server с другими устройствами и системами, работающими на базе SIP. :-)

Итак, сегодня наш урок будет поделен на две части:

  • Вначале – теория. Я постараюсь кратко изложить RFC 4566, описывающий Session Description Protocol (SDP).
  • Потом, вместо практической части, будет разбор одного SIP сообщения, выдернутого из Snooper, включая SDP часть. Так мы закрепим знания первых двух уроков.

Новая тема

Сообщение SDP состоит из множества строк формата <параметр> = <значение> … [<значение>...<значение>].

Как я уже упоминал в статье, SDP описывает параметры сессии обмена данными. Каждый участник обмена передает другому участнику (или серверу конференций) информацию о том, как ему удобно получать данные. На какие порты, по каким протоколам и т.д.

В случае SIP, SDP сообщение вкладывается к SIP сообщение. В этом случае SIP часть считается заголовком сообщения, а SDP часть (или части, если SDP сообщений несколько) включается в тело сообщения.

Большинство параметров SDP и их описание приведены в следующей таблице. Ох и намучился же я, занимаясь этой выжимкой. Собственно, таблица и есть почти вся теория на сегодня. :-) Ознакомьтесь с ней и можно приступать к практическому занятию. Жирным шрифтом я выделил параметры, на которые нужно обращать внимание при поиске проблем.

v(protocol version) Версия протокола SDP. Пока – «0».
o(owner/creator and session identifier) <username> <session id> <version> <network type> <address type> <address>Информация об инициаторе сессии: имя абонента, код сессии, сколько раз уже в рамках сессии встречался SDP , тип сети, тип адреса, сам адрес.
s(session name) Имя сессии.
i(session information) Информация по сессии.
u(URI of description) Ссылка на более подробное описание сессии.
e(email address) Почтовый адрес для связи с ответственным за проведение конференции.
p(phone number) Телефонный номер для связи с ответственным за проведение конференции.
c(connection information — not required if included in all media) <network type> <address type> <connection address> Куда следует слать трафик медиа: тип сети, тип адреса, сам адрес.
b(bandwidth information) Максимальная возможная полоса пропускания.
t(time the session is active) <start time>  <stop time>Время начала и конца сессии. 0 0 означает отсутствие. Ограничений
m(media name and transport address)  <media> <port> <transport> <fmt list>Тип медиа (аудио/видео), порт по которому слать поток, транспортный протокол, список поддерживаемых форматов (обычно — кодеков).
a(zero or more media attribute lines)  a=<attribute>a=<attribute>:<value>Без комментариев. Ниже – несколько примеров.
a=rtpmap:  rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]Тип кодека, имя кодека / параметры кодека (обычно – частота дискретизации в герцах).
a=fmtp:Частный случай 2  <format> <format specific parameters>Номер кодека, параметры формата. MS таки образом обозначает используемую полосу пропускания кодека.    
a=candidate Куда слать трафик медиа. Используется когда нужно указать несколько возможных вариантов. Например, при использовании ICE.Подробности тут.

Первичное закрепление

Разбирать будем пришедший на Lync Server запрос (сообщение INVITE) на голосовой вызов с телефона CX 600. пользователь Calling@croc.ru звонит пользователю Called@croc.ru.

Информация скопирована из Snooper. Реальные IP адреса заменены на “(IP адрес)”.

Как и на прошлом уроке, я постарался дать комментарий к каждой строке сообщения. Если комментария к строке нет, значит, я решил что на данном этапе знание параметра не особо нужно и не полез перерывать Интернет в поисках его описания. :-)

Поскольку на странице текст разбора отображается не очень хорошо, я вынес его в PDF.

Итоги урока

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

В следующих статьях/уроках на ту же тему, если они будут, конечно, вы узнаете:

  • почему основной проблемой связки Lync c другими АТС является отсутствие контроля посылки вызова (КПВ, ring back tone);
  • действительно ли нужно, как часто советуют на форумах отключать Refer Support при проблемах с Exchange Auto Attendant;
  • почему у communicator for MAC проблемы  при интеграции с ВКС;
  • на что влияет параметр «AnalogFax» в команде New-CSAnalogDevice;
  • и т.д. и т.п. :-)

В качестве домашнего задания, предлагаю выполнить подобный разбор пары сообщений на вашем сервере. Кроме того, я специально не стал проводить описание всех кодеков из a=rtpmap:в сегодняшней статье. Считайте это домашним заданием, а правильный ответ будет во время следующего урока по теме :-)


Отслеживать

Get every new post delivered to your Inbox.