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

Тема непростая, но обязательная для изучения всеми, кто хочет «собрать» из 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 в одном месте я не встречал.

комментариев 26 to “Обработка телефонных вызовов в Lync Server 2010”

  1. Vitaly Says:

    Александр, спасибо за статью, давно ждал.

    Несколько комментариев, чтобы еще больше фактов в одном месте:
    1. Отображение имени звонящего.
    Допустим, что Caller ID от провайдера к нам приходит в виде 74957772211, есть контакт в оутлук с номером +74957772211, в глобальном диал плане есть правило нормализации, приводящее такие номера в формат E.164. В момент звонка (после применения правил нормализации) высвечивается имя контакта из оутлук, но как только снимается трубка, то «брюки превращаются…», вместо имени звонящего на телефоне высвечивается не нормализованный номер. Странное поведение, несколько раздражающее.
    2. Столкнулись со следующей проблемой, корни которой растут из пункта 1. При таком Caller ID перестали работать переводы вызовов на внешние номера. Т.е. сценарий, когда на офисный телефон позвонил человек, а его звонок нужно было переадресовать на мобильный сотрудника или другой внешний номер. При этом, если перевести звонок на внутреннего абонента, у которого назначена переадресация на мобильный звонок проходил. Долгое и муторное изучение этого вопроса с провайдером никак не приводило к решению проблемы. Совершенно случайно, «гуглив» по описанию ошибки из лога Mediations наткнулся на совет приводить Caller ID звонящего в формат E.164. Попросил провайдера добавить плюсик и все заработало. Стоит также отметить, что транк был организован достаточно давно, а проблемы появились в районе Нового года. Единственное с чем связываю изменение — установка роллапов для возможности использования Lync Mobile.

  2. Argon Says:

    Саша, привет! Действительно нужная статья.

    Есть пара комментов…

    «Если правило не приводит номер к формату E.164 либо не фиксирует номер, то правила применяются снова»

    Насколько помню, по несколько раз правила не применяются. Хотя, возможно, я не понимаю смысла сакрального слова «фиксируется».

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

    Что значит «не зафиксирован»? Если в БД есть юзер с телефоном 11112345, то ему позвонят😉

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

    Что значит «фиксируется»?

    «Вот почему я так «люблю» формат +74951234567;ext=1234»

    А я люблю формать +74999269193;ext=9193

    То есть даже если у тебя DID, то все равно используется EXT. Нужен для Exchange UM и Dialin-конференций.

    Подробнее — здесь:
    http://blogs.technet.com/b/nexthop/archive/2011/11/30/assigning-telephone-numbers-to-lync-enterprise-voice-users.aspx

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

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

    Недавно столкнулись с проблемой: хотя мы делаем в Линке нормализацию для входящих номеров, Caller ID не отражает эти манипуляции, и, начиная с какого-то апдейта Линка, перестает работать трансфер водящего вызова с городского номера на другой городской. Если каллер приходит в Линк сразу нормализованным, то всё работает.

    • Александр Донин Says:

      Спасибо за коментарий. Дописал в статье про использование ext с прямыми номерами.
      Сам пользовался этой схемой только один раз. У меня в проектах обычно как минимум несколько регионов и обычно есть сопряжение с другими АТС…. в общем проблемно использовать такой формат🙂.

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

      P.S. А ты разве не устроился в Microsoft?

      • Argon Says:

        Насчет номеров «+…xxx;ext=xxx». Это действительно головняк, когда будет несколько регионов и даже в пределах одного диалплана при наличии как DID-номеров для VIP-ов, так и обычных, донабираемых.

        На практике пока не реализовывал, но предстоит… Так и представляю кучи правил нормализации, учитывающие такие «выколотые» из общей схемы номера.

        «Недавно делали эксперимент. Если приходит вызов с номера с “+” вначале, то идет сопоставление имени.
        Если нет “+” перед номером нет, то нет и сопаставления.
        Само собой, файл нормализации адресной книги был настроен.»

        Ну как же, есть сопоставление. Но как Виталий писал, оно после установки соединения пропадает. Точно знаю, что сопоставляются внутренние номера вида xxxx с контактами В Аутлуке. Также сопоставляются с Analog Device’ами.

        «P.S. А ты разве не устроился в Microsoft?»

        В MS-е я, но Линк — не основная моя специализация, к сожалению🙂

    • Александр Донин Says:

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

      • Argon Says:

        Так и не понял про «фиксацию», хотя Линк вижу всёж-таки не первый раз. Правила в диалплане действуют до первого срабатывания.

        Так, чтобы набираемая строка попала под одно правило, «не зафиксировалась» и пошла нормализоваться дальше по списку правил с начала, пока не «зафиксируется»… не встречал. И зачем это, какой практический смысл, если все правила можно написать для одного прохода.

        Или я что-то концептуально не понимаю?

      • Александр Донин Says:

        «Или я что-то концептуально не понимаю?»
        Видимо так. Или с очередным CU поменяли.🙂
        Только что проверил еще раз по просьбам трудящихся. без «закрепляющего» правила вызов не проходит даже внутреннему пользователю. В журнале ругань, что нельзя найти правило для уже измененного номера. После создания правила (приоритет ему в этот раз выставил выше, так что точно второй прогон) вызов прошел.

  3. Vitaly Says:

    Видимо мы с Игорем почи одновременно писали комментарии🙂

  4. Александр Донин Says:

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

  5. Argon Says:

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

    КААК? Что за фиксация? Что за галочка или ключ павершелла?

    У нас есть набор правил нормализации в диалплане. Затем нормализованная строка, будучи не найденной среди пользователей Линка идет по списку маршрутов. Попав на маршрут нормализуется так, как прописано в Trunk Config.

    Где тут возможен повторный прогон правил?

  6. Александр Донин Says:

    Не кричи. меньше нервов, больше снупера.🙂
    Как я выяснил, второе (закрепляющее) правило в Dial plan может быть любым. главное, чтоб результат первого подпадал под его условие.

    Проверил на двух инсталяциях. Если хочешь дальше спорить — сначала сам получи результаты теста.
    Можешь спросить у коллег почему оно так работает.

    • Argon Says:

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

      Если ты про правило, содержащее только $1 в translation rule, то без таких правил работает. Если набираемая строка корректно преобразуется любым правилом выше.

      Если будет ссылка на технет, то совсем хорошо.

      • Александр Донин Says:

        Ты уверен, что так работает в CU 4?
        Проверял несколько раз.
        Создай одно правило в dial plan: 1234 -> 000$1.
        Включи журнал и попробуй позвонить. Увидешь ошибку отсутствия правила в Dialplan для номера 0001234.

      • Argon Says:

        Саша, я же тоже не по памяти рассказываю, проверял на живой инсталляции. Убирал эти правила, без них работает. Test voice routing и реальные звонки это подтверждают.

        Конкретно сейчас еще раз проверить не могу (удалить все правила и создать одно), люди пользуются ))

        Ты так и не дал ни определения «фиксирующего правила», ни ссылки на технет. Ни объяснил, зачем нужно многократное применение правил, и как избежать зацикливания.

        А отправлять спрашивать у моих коллег — не очень правильно, так как вопрос по теме статьи. Не будешь же ты всех _своих_ читателей отправлять к _моим_ коллегам?

        В поддержку моих слов приведу ссылку на примеры правил наормализации на технете. http://technet.microsoft.com/en-us/library/gg413082.aspx

        Нет там ни одного правила, содержащего только «$1»

      • Vitaly Says:

        Сейчас проверил на существующей инсталляци. На примере Emergency вызовов. В диал плане есть правило, которое Александр классифицирует как фиксирующее. Правда уточнение: номера типа 01,02 и т.д. попадают ТОЛЬКО под это правило. В маршрутах прописано. Как только убираем правило из диал плана, так звонки не идут.

      • Александр Донин Says:

        «Конкретно сейчас еще раз проверить не могу (удалить все правила и создать одно), люди пользуются ))»

        Напоминаю, что можно создать dialplan уровня пользователя

        «В поддержку моих слов приведу ссылку на примеры правил наормализации на технете. http://technet.microsoft.com/en-us/library/gg413082.aspx

        Нет там ни одного правила, содержащего только “$1″»

        А еще там нет ни одного правила, которое не бы приводило бы номер к E.164.

      • Argon Says:

        Проверил, а также прочитал твои дополнения в статье по поводу недокументированности сего поведения.

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

      • Александр Донин Says:

        Ну вот.. так бы сразу…🙂
        Проверил, убедился…

  7. Vitaly Says:

    Хотел бы уточнить, есть ли возможность изменить поведение линка в ситуации описанной мною в первом комментарии в п.1.
    Такая же фигня, когда на транке номер преобразуется в формат принимаемый шлюзом или АТС (именно поэтому на аудиокодесах я на самих шлюзах делал преобразования). Человек набирает номер в виде +78332775533, а потом видит на экране 775533. Ну а с международными так вообще…
    Помнится мы с Игорем были на Техэде на одном из докладов по Линку и в конце разговаривали с человеком, который описывал именно такое поведение. Как сейчас помню сказали что такого не может быть🙂

    • Александр Донин Says:

      Слышал раньше о таком поведении, но пока не сталкивался. В возможность на Lync Server что-то кастомизировать в части SIP транков давно не верю как в бабушкины сказки.
      Я бы попробовал создать правило для проблемного формата номера в DialPlan, прменяемом к пользователю. Вот только Блог не лучшее место для траблшутинга. Лучше задать вопрос на форумах Technet. Там я подключусь к обсуждению.

      • Vitaly Says:

        Да, наверно не самое правильное место, соглашусь. Однако странно, что «Слышал раньше о таком поведении, но пока не сталкивался.» Потому как именно эта ситуация, точнее то что приводит к такому поведению описана в пункте статьи «Нормализация на выходе»

      • Александр Донин Says:

        До сих пор не пользовался нормализацией на выходе, потому как она работает только на called ID. + отрезал через RemovePlusFromUri. Проблем не наблюдал.

  8. Stanky Says:

    Ну и мои пять копеек для точности:

    «Вызов 2. Звонок на номер 12345. Согласно правилу 1»
    У нас же пять цифр в номере, а значит он подпадает под второе правило.

    «Вызов 3. Звонок на номер 1234. Согласно правилу 2»
    А тут наоборот — под первое.

  9. Обработка телефонных вызовов в MS Lync 2010 | vMind.ru Says:

    […] тема вас заинтересовала, рекомендую почитать также статью MVP о звонках Lync. Там все очень подробно рассказано. […]

  10. Lync Server 2010 Voice Routing. Пример настройки | Заметки ИТ инженера Says:

    […] Дополнительные материалы (обновлено 12.09.2013): — Маршрутизируем звонки в Lync: как отловить, преобразовать телефонный номер и направить его по нужному маршруту — Обработка телефонных вызовов в Lync Server 2010 […]

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s


%d такие блоггеры, как: