none
Не определяются Display Name при входящих звонках RRS feed

  • Вопрос

  • Всем здравствуйте!

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

    Есть развернутый SE. У пользователей в AD прописаны телефоны в формате XXX- внутренний (центрекс), XXXXXXXX- городской, XXXXXXXXXXX - сотовый.

    В файлике Company_Phone_Number_Normalization_Rules.txt  прописаны следующие правила:

    ^([2-3]\d{2})$
    $1;phone-context=dialstring

    ^(\d{8})$
    $1;phone-context=dialstring

    ^(\d{11})$
    $1;phone-context=dialstring

    В карточках контактов эта информация благополучно отображается.

    Однако при поиске по номеру не отображается пользователь-владелец номера. С коротким номером отображается и контакт и искомый номер.

    Со всеми остальными засада. Показывается только номер и все.

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

    При звонке с городского уведомлении о звонке в клиенте, полностью соответствует уведомлению о пропущенном звонке, но не сопоставляет его с контактом которому принадлежит данный номер.

    Хотя данный номер закреплен за контактом и отображается в карточке контакта.

    Хотелось бы идентифицировать внутренних абонентов при просмотре в Exchange уведомлений о пропущенных звонках корректно, ибо без этого History не имеет особого значения.

     


    Ни что не вечно под луной...


    13 июля 2012 г. 8:39

Ответы

  • была один в один  такая же траббла, 

    У нас система такая  Lync - mediacodac - Panasonic TDA600

    на атс номера трхзнаки типа 555  , дак вот когда я написал в линке номер  просто как 555  то звонок входящий не распознается  в имя,

    меняем на +555  как требует этого вообще то линк ... появятся другая проблема , панасоник отдает номер в формате 555 без плюса, теперь пишем

    правила нормализации для входящего звонка

    New dial plan - > New pool dial plan  - выбрать ваш PSTN gateway  ну и написать там

    ^(\d{3})$     +$1

    все входящий звонок определяется как +555  и преобразуется в имя ))) все работает ))

    • Помечено в качестве ответа Nikita Sokolov 20 июля 2012 г. 8:59
    20 июля 2012 г. 5:50

Все ответы


  • Ни что не вечно под луной...

    13 июля 2012 г. 8:40
  • Согласно данному обсуждению http://social.technet.microsoft.com/Forums/ru-RU/lync2010ru/thread/ac2cb06a-c4d0-4a7d-9a01-d998173f4353/ у меня настроено все корректно.

    Дано у пользователя в AD занесен номер 2379888

    В файлике Company_Phone_Number_Normalization_Rules.txt  кое что поменял и в данный момент прописаны следующие правила:

    ^([2-3]\d{2})$
    $1;phone-context=dialstring

    ^(\d{7})$
    $1;phone-context=dialstring

    ^(\d{11})$
    $1;phone-context=dialstring

    Номера сравниваются по следующей схеме:

    номер из AD + правила нормализации из Company_Phone_Number_Normalization_Rules.txt = номеру введенному в lync клиент + правила нормализации в dialplan-е самого Lync 

    И так получается:

    2379888 

    ^(\d{7})$
    $1;phone-context=dialstring  -----> 2379888 

    В DialPlan есть правило

    ^(([2-3])(\d{6}))$ в которое попадает этот номер.

    Создал так называемое закрепляющее правило 

    ^(\d{7})$

    И все равно при наборе номера в строке поиска карточка абонента не появляется. И при звонке с этого номера не видно карточки звонящего.

    Опять темный лес.



    Ни что не вечно под луной...

    13 июля 2012 г. 13:26
  • Единственное в чем разница, это то что на Lync мне приходит CallerID c 9, например 92379888, а вот CalledID без 9, например 3121020. Такие номера 6-значные у меня прописаны в TEL URI.

    Поэтому я не могу повесить на Pool диал план с правилами нормализации, потому как они применяются к обоим номерам. И если я создаю DialPlan уровня Pool, и вешаю туда  правила :

    9(\d{7})$  ---->9$1

    (\d{7})$  ---->9$1, то у меня просто напросто не проходят звонки. Пишет "No Matching Rule".

    Если я уберу допустим 9 c CallerID, поможет ли это в моей ситуации?



    Ни что не вечно под луной...


    16 июля 2012 г. 10:47
  • Ребята, спасайте, помогайте, не то руководство съест и меня и этот Lync. Казалось бы простая задачка, а решить с помощью этого монстра пока не удается.

    Как заставить эту скотину сопоставлять CallerID с карточкой вызываемого абонента?

    Заполнил в AD  у пользователя телефоны: 2379XXX и 92379XXX.

    В карточке они появились.

    Делаю вызов с этого абонента на любой номер.

    Вижу.

    На входящих транках стоят все правила нормализации.

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

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

    Не оставляйте человека на растерзание!!!


    Ни что не вечно под луной...

    20 июля 2012 г. 4:55
  • В почту сыпется уведомлении о пропущенном вызове, сопоставленное с карточкой абонента абсолютно правильно.

    В INVITE следующая информация:

    Start-Line: SIP/2.0 100 Trying
    From: "93120109"<sip:93120109;phone-context=PstnGateway_10.250.60.8@astel.kz;user=phone>;epid=70E45D933F;tag=d9ebfc7550
    To: <sip:2379860;phone-context=PstnGateway_10.250.60.8@astel.kz;user=phone>


    Ни что не вечно под луной...



    20 июля 2012 г. 4:56
  • Вот без 9.

    Message-Type: request
    Start-Line: INVITE sip:2379860;phone-context=PstnGateway_10.250.60.8@astel.kz;user=phone SIP/2.0
    From: "3120109"<sip:3120109;phone-context=PstnGateway_10.250.60.8@astel.kz;user=phone>;epid=70E45D933F;tag=68d5deb80
    To: <sip:2379860;phone-context=PstnGateway_10.250.60.8@astel.kz;user=phone>

    Однако ничего не меняется.


    Ни что не вечно под луной...

    20 июля 2012 г. 5:09
  • Интересно, сам с собой разговариваю... Сюда кто нибудь заходит вообще??? ))))

    Ни что не вечно под луной...

    20 июля 2012 г. 5:33
  • я с тобой морально ))) У меня тоже есть подобная проблема. Но часть номеров, которые приходят в виде E164 всё же отображаются  в виде карточки.

    20 июля 2012 г. 5:37
  • была один в один  такая же траббла, 

    У нас система такая  Lync - mediacodac - Panasonic TDA600

    на атс номера трхзнаки типа 555  , дак вот когда я написал в линке номер  просто как 555  то звонок входящий не распознается  в имя,

    меняем на +555  как требует этого вообще то линк ... появятся другая проблема , панасоник отдает номер в формате 555 без плюса, теперь пишем

    правила нормализации для входящего звонка

    New dial plan - > New pool dial plan  - выбрать ваш PSTN gateway  ну и написать там

    ^(\d{3})$     +$1

    все входящий звонок определяется как +555  и преобразуется в имя ))) все работает ))

    • Помечено в качестве ответа Nikita Sokolov 20 июля 2012 г. 8:59
    20 июля 2012 г. 5:50
  • Ок, значит все таки надо привести номера к стандарту E.164? И все будет в ажуре? 

    Ни что не вечно под луной...

    20 июля 2012 г. 6:12
  • поможет ли на 100% не знаю, но попробуй
    20 июля 2012 г. 6:45
  • Помогло.

    Это ж надо, столько времени угрохать на то что в принципе реализовать наверное невозможно by design. Как не крути а уж больно любит Lync E.164.

    Буду переделывать все по  стандарту.

    Всем Спасибо!

     

    Ни что не вечно под луной...


    20 июля 2012 г. 9:03