Главная Exchange/UC, Без рубрики, Новое Lync, Lync Server 2010
  • Введение в архитектуру Lync Server 2010 (Часть 2)

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

  • Главная Exchange/UC, Без рубрики, Новое Lync, Lync Server 2010
    • Введение в архитектуру Lync Server 2010 (Часть 1)

      logoПрежде чем начинать работать с продуктом обязательным условием для меня является знакомство с архитектурой. Без понимания принципов работы, ролей, взаимосвязей компонентов делать что то весьма проблематично. Не смотря на то, что по Lync Server 2010 есть весьма неплохая документация, я решил написать вводную статью для новичков в Lync Server, дабы  дать старт для последующей работы в направлении объединённых коммуникаций от Microsoft.

      • FAQ: Exchange Server 2010 Часть 7

        Продолжение серии ответов на часто задаваемые вопросы об Exchange Server 2010. На этот раз разговор пойдет о лицензировании Exchange. Сколько серверных лицензий нужно? Чем отличается Standard от Enterprise? Что такое клиентская лицензия? Как проверить версию и как перейти с младшей редакции на старшую? В качестве второй темы в докладе кратко дается ответ на вопрос "сколько нужно серверов Exchange для построения решений высокой доступности?" Как и все части серии FAQ доклад ориентирован ша широкую аудиторию администраторов, имеющих начальные знания в Exchange Server 2010.

        • Forefront Protection 2010 для Exchange Server (Часть 3)

          Logo

          После того как письмо прошло проверку источника и проверку протокола начинается время фильтров контентной проверки. В качестве старой корпоративной традиции Microsoft купила антиспам решение и интегрировала его в десятую версию ForeFront. В комментариях к прошлым статьям спрашивали “чем же антиспам FF отличается от Edge агентов?”. Собственно ответ – Cloudmark Authority Engine, один из основных инструментов борьбы со спамом в FF.

          • FAQ: Exchange Server 2010 Часть 6

            CaptureИ хотя я собирался завершить серию FAQ по Exchange, шестая часть все же увидела свет и по-прежнему в видео  даются ответы на наиболее часто задаваемые вопросы об Exchange Server 2010. В данной части разговор пойдет о типе получателя Linked Mailbox, о ремонте возможности поиска по почтовым ящикам и о том как быстро пересоздать профиль пользователя в Outlook. Основу доклада составляют демонстрации различных операций управления сервером Exchange.

            • Forefront Protection 2010 для Exchange Server (Часть 2)

              Spam-a-tin-ofВ предыдущей части статьи мы начали разговор о вариантах защиты от спама в случае использования Forefront Protection 2010 для Exchange Server. И становились на блоке проверок “Анализ протокола”, сочетающего  в себе средства протокола SMTP и фишки от от Forefront. С этого момента и продолжаем, следующая проверка “Limiting Submission Rate”.

               

              • Forefront Protection 2010 для Exchange Server (Часть 1)

                1297937239_spam_kazaxstan_obem_rassylkaКаждый раз, когда приходится браться за внедрение реального Exchange сервера встает вопрос защиты. Вопрос состоит из двух подзадач, а именно из защиты от вирусов и защиты от спама. Решений на данную тему масса, но лично меня интересуют следующие вещи:  возможность работать через привычную мне систему (и здесь все Linux решения для меня  отваливаются),  приемлемая стоимость,  эффективность и производительность. Даже используя Edge сервер (либо активируя агентов на Hub) мы  всего лишь получаем минимальный антиспам, эффективность которого весьма сомнительна, но самое главное штатно в системе нет антивируса. В свое время предыдущая версия Forefront для  Exchange 2007 оставила весьма неприятный осадок, но время идет и компания я надеюсь поработала над ошибками. Документация по Forefront Protection 2010 для Exchange Server представлена несколькими разрозненными документами, один из которых по антиспаму попал мне в руки. (White Paper: Implementing Antispam technologies in Forefront Protection 2010 for Exchange Server) По мере чтения я русифицировал его, оставляя свои комментарии.

                • Exchange 2010 DAG: Replay Lag Time

                  42911223

                  Про Database Availability Group написано давно и много , но все же остается ряд опций и настроек, которые находятся “за кадром” для большинства системных администраторов. При этом данные настройки играют серьезную роль  в работе DAG и учитывать их при планировании высокой доступности просто необходимо. Итак, приступим, поговорим про параметр “Replay Lag Time” и принципы его работы.

                  • Exchange 2010 DAG: Процесс выбора оптимальной реплики базы.

                    logoТе, кто работают с Exchange 2010 должны знать, что обеспечение высокой доступности баз данных почтовых ящиков реализуется технологией DAG. (database availability group) Суть технологии в создании двух и более реплик одной базы на разных Mailbox серверах. В случае падения диска или сервера, одна из оставшихся реплик становится активной и продолжает обслуживать клиентов. Причем количество реплик может достигать 16 штук. Все это понятно и несложно, а меня волнует немного другой вопрос. Как осуществляется выбор реплики которая должна стать активной в случае падения диска или сервера? Если у нас 3-16 реплик, как понять какая из реплик станет активной?

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

                      Вместо предисловия

                      Во время Teched Russia 2011 самым задаваемым мне вопросом оказался вопрос про отсутствие длинного гудка при вызове абонента Lync из ТфОП. При этом, все спрашивающие являлись читателями ITBand.RU. Так что, первым делом по возвращении домой с MVP Open Days, я решил перенести уже готовую статью по данной теме из собственного блога (являющегося для меня чем-то вроде инкубатора) сюда. Надеюсь будет полезно.

                      Урок номер 3

                      Продолжаем разговор про использование 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.