О национальной дискриминации телефонных номеров в Lync
2012-03-13, 11:40 / ArgonВ данной заметке я покажу, как различается отображение телефонных номеров в контактах Lync для номеров с кодом +1 и для всех остальных, и как сильно все остальные страдают от этого.
В своё время статья Assigning Telephone Numbers to Lync Enterprise Voice Users открыла мне глаза на то, как правильно назначать телефонные номера пользователям Lync.
Вкратце основные выводы:
- Телефонный номер всегда должен быть в формате E.164 и глобально достижим, так как телефонные номера публикуются в адресных книгах и передаются партнёрам по федерации в Lync. Если пользователь не имеет прямого публичного номера, глобально достижимый номер должен содержать как общий телефонный номер компании, так внутренний номер.
Пример: tel:+14999269000;ext=1193
- Даже прямой публичный телефонный номер должен иметь соответствующий ему внутренний номер (extension) в компании. Причин для этого несколько:
- Полный номер в формате E.164 человек в здравом уме вводить вручную откажется, поэтому в Lync нужно настроить правила нормализации, превращающие короткие номера в полный вид E.164.
- Extension нужно вводить для авторизации при подключении к Lync Dial-in конференциям.
- Автоответчик Exchange UM понимает только внутренние номера, телефонные номера в формате E.164 выше его понимания.
Пример: tel:+14999269193;ext=9193
Хотя пользователь имеет прямой публичный номер, ему присвоен внутренний номер, повторяющий последние 4 цифры публичного номера.
Итак, мы убедились, что назначать пользователям Lync номера в глобально достижимом формате с расширением — нужно и полезно. Однако, если мы забьём в таком виде (+149992699193;ext=9193
) все телефонные номера в свойства учеток AD, пользователи не одобрят. К счастью, Address Book Service в Lync способен понимать следующий формат:
+1 (499) 926 9193 X9193
Согласитесь, вполне понятно и читаемо, к тому же поддерживается Outlook: код города и внутренний номер занимают положенные им места в карточках контактов.
Address Book Service, следуя своим встроенным правилам нормализации, преобразует номер из +1 (499) 926 9193 X9193
из учетки в AD в понятный Lync формат E.164 tel:+14999269193;ext=9193
.
До текущего момента все спокойны и счастливы! Но, внезапно, нам понадобилось использовать российские телефонные номера, которые начинаются на +7.
Как оказалось, Lync по-разному отображает номера, относящиеся к США (код +1) и всему остальному миру.
Было создано два пользователя с различиями только в коде страны в номерах телефона:
Пользователь | Alice | Bob |
---|---|---|
Рабочий телефон | +1 499 926 9000 X1193 | +7 499 926 9000 X7193 | Мобильный телефон | +1 965 126 6080 | +7 965 126 6080 | Line URI в Lync | tel:+14999269000;ext=1193 | tel:+74999269000;ext=7193 | Правило нормализации коротких номеров | 1XXX → +14999269000;ext=1XXX | 7XXX → +74999269000;ext=7XXX |
Теперь взглянем на карточки контактов в Lync у данных пользователей…
![]() |
![]() |
Что же мы видим:
- Телефонные номера Alice приобрели скобочки для кода региона и дефисы-разделители, которых изначально не было.
- Телефонные номера Bob потеряли все форматирование (пробелы), и также внутренний рабочий номер. В таком виде не просто неудобно читать, да ещё и полной информации не отображается. Хотя номер остается кликабельным и дозвон осуществляется правильно: не на общий номер, а с учетом внутреннего номера.
Теперь же попробуем позвонить Alice и Bob по их коротким номерам:
![]() |
![]() |
- Поиск по адресной книге происходит одинаково хорошо
- Отображение номеров полностью соответствует карточкам контакта
- Несмотря на урезанное отображение рабочего номера для Bob, дозвон происходит корректно
Вывод из заметки:
На стороне клиента Lync происходит дискриминация по телефонному коду страны. Не зависимо от правил нормализации на стороне сервера Lync и формата записи телефонных номеров в учетке в AD, клиент Lync преобразует эти номера по разным правилам для телефонов с кодом +1 и для всех остальных. Причем «остальным» ничего приятного не достаётся: пропадает читаемость и внутренний номер…
Я искренне надеюсь, что разработчики вскоре исправят этот баг.
Рубрика | Unified Communications |
---|---|
Метки | lync server, office communications server, ocs |
Опубликовано | 2012-03-13, 11:40; обновлено 2012-03-13, 21:33 |
Комментарии | 13 комментариев » | Лента комментариев RSS |
Ссылки | Постоянная ссылка | Обратная ссылка |
13 комментариев
Только что Муравлянников сказал что в CU4 на сервере и клиенте отображается нормально.
В моей тестовой лабе, где я проводил эти эксперименты, установлен CU4 (Nov 2011). Вот CU5 еще не ставил, так как он до Windows Update пока не дошел. Сейчас попробую.
К сожалению, ничего не поменялось. Поставил обновления Feb2012 на сервер и на клиент, перегенерировал адресные книги.
Если мы создаём нового пользователя, то какое-то время его телефоны отображаются в том виде, как они забиты в AD.
Однако, по прошествии какого-то времени, а также добавления этого пользователя себе в контакты, брюки превращаются в то, что описано в этой заметке.
На фоне всего этого была бы интересна статья о том, кто и где вводит эти телефонные номера, как именно обновляются все адресные книги (Exchange, Lync, Sharepoint). Какая из систем является мастером и в каком направлении осуществляется обновление информации в этих системах.
Ещё был совет в AD хранить телефоны в формате
+74951234567 X1234
спрошу сегодня поподробней как добились корретного отображения.
>Ещё был совет в AD хранить телефоны в формате
>+74951234567 X1234
К сожалению, ничего не меняется. Также подтверждаю, что с обновлением сервера и клиента CU5 баг остался.
Нет никаких сведений, когда будет пофиксено?
Я отписал в глобальную внутреннюю рассылку MS по UC еще в понедельник… Молчат. Или вопроса не поняли, или всем пофиг.
А если на Lync отключить работу встроенных правил нормализации (заменив их на свои собственные, одинаковые для всех номеров: и для +1, и для +7)?
Можно отключить встроенные правила нормализации, который применяются при вытягивании из AD, но оно не помогает. Разница между +1 и +7, похоже, зашита где-то в клиенте при отображении.
не просто отключить, а написать свои собственные правила. Все равно не помогает?
«Баг» еще c OCS 2007 (RTM) тянется :-)
Так что, надежды это хорошо, но разработчики пока на это, похоже забили. Скорее это не баг для всех а фича для американцев :-)
Приветствую.
Спешу поделиться новостями в этом направлении. Не так давно вышло обновление, которое включили в октябрьский CU для клиента Lync, и которое по описанию должно исправить давнюю несправедливость.
Здесь его можно загрузить — http://support.microsoft.com/kb/2737155,
а здесь http://support.microsoft.com/kb/2735322 почитать описание.
Внимание, там необходимо редактировать клиентскую политику на сервере.
Первые впечатления — пока полёт нормальный.
Есть несколько странных особенностей, возможно вызванные особенностями конкретной среды. Добавочные номера в клиенте отображаются то X1234, то ;ext=1234. Также пришлось создать дополнительное правило нормализации, преобразующее E.164 в … E.164 (^\+(\d{12})(;ext=)(\d{4}) —> +$1;ext=$3). Без него нельзя было звонить из карточки контактов, когда в карточке номер отображается с ;ext=1234.
Есть подозрение, что IgnoreGenericRules из Get-CsAddressBookConfiguration, которое по дефолту выключено, содержит правило нормализации
\+1(\d{10})[Xx](\d{4})
+1$1;ext=$2
Потому как добавление в Company_Phone_Number_Normalization_Rules.txt
правила
\+7(\d{10})[Xx](\d{4})
+7$1;ext=$2
Позволяет отображать номера и с +7 и с екстеншином
если в AD телефоны в формате +7 (1234) 12-34-56 x1234