none
Lync, sip-trunk и факсы RRS feed

  • Вопрос

  • Коллеги, привествую.

    Поделитесь опытом по сабжу.

    Вот ситуация - есть sip-trunk до провайдера. Провайдер выделил адрес в своей подсети, один из интерфейсов медиейшена смотрит в сеть провайдера, другой в корповую сеть. Сети не маршрутизируются. Сама связь отлично работает (единственно что напрягает это невозможность выключения VAD, но это уже вопрос другой). Есть шлюз Audiocodes MP-112, на нем висят два факса зарегистрированные как Analog Device (AnalogFax=$False). С них тоже можно звонить как внутри так и наружу, принимать звонки и т.д. Единственная проблема - качество отправленных и принятых факсов отвратительное.

    Коллеги, у кого есть опыт, подскажите где подкрутить?

    17 апреля 2012 г. 17:43

Ответы

  • В данной статье (http://technet.microsoft.com/en-us/library/gg398314.aspx) пишут

    <---

    noteNote:

    Fax calls are not supported through a SIP trunk.

    --->

    А затем

    <---

    If your deployment includes fax machines that interact with Lync Server so that CDR reports are logged for fax calls, you must enable media bypass. This means configuring settings to enable media bypass globally and also on the trunk connection to the gateway to which the fax machines connect. The fax machines need to be correctly configured in the contact object configuration, as described in the “Contact Objects" section later in this topic. The gateway must present fax calls to Lync Server as G.711 audio calls; if presented as image calls, they will be rejected. These calls will be hairpinned to the gateway from which they were received. Bypass causes the hairpin to be moved to the gateway.

    --->

    И вдогонку

    <---

    Note:

    When Lync Server detects that a direct inward dial (DID) number is associated with a fax machine, the Mediation Server does not terminate media. Rather, Lync Server routes the call to the destination fax machine, bypassing the Mediation Server. You can use centralized call detail recording and policy management functionality for these types of calls because the signaling for fax machine calls flows through a Front End pool or a Standard Edition server.

    --->

    Соответвенно, напрашиваются противоречивые выводы: должен быть media bypass и кодек g711 на шлюзе, тогда все должно работать. С другой стороны, c самого начала пишут, что факсы через SIP Trunk не поддерживаются...


    MCITP: EA, SA, EMA, LSA, VA; MCSA



    17 апреля 2012 г. 18:11
  • Есть два способа передачи факса по IP: внутри G.711 и по спец. протоколу T.38.

    Lync Server не поддерживает T.38

    Передача по G.711 может исказиться при низком качестве среды передачи. (стандартные джитер, задержка, потери пакетов).

    Если Audiocodes MP-112 у вас недалеко от Lync Server (в той же 100 мегабитной сети), предлагаю, для начала подключить Audiocodes MP-112 к провайдеру вместо Lync Server (отключив поддержку T.38) для чистоты эксперимента.

    P.S. В нескольких проектах использовал Media Bypass и AnalogFax=$False. Проблем не наблюдал. Но там шлюзом в ТфОП был Audiocodes Mediant 1000 в той же сети, гед сам Lync Server.

    • Помечено в качестве ответа Yuriy Lenchenkov 3 мая 2012 г. 12:03
    18 апреля 2012 г. 6:28
  • Аха, но для этого вам прйдется ставить у себя еще шлюз. MB подразумевает что трафик до клиентов Lync идет от шлюза напрямую. Оператор наверняка не согласится на кучу IP-адресов с которых нужно разрешать трафик.

    А если хотите совсем поддерживаемое MS решение, то факсы нужно подключить к тому же шлюзу и включить AnalogFax=$True

    • Помечено в качестве ответа Yuriy Lenchenkov 3 мая 2012 г. 12:03
    18 апреля 2012 г. 7:41

Все ответы

  • В данной статье (http://technet.microsoft.com/en-us/library/gg398314.aspx) пишут

    <---

    noteNote:

    Fax calls are not supported through a SIP trunk.

    --->

    А затем

    <---

    If your deployment includes fax machines that interact with Lync Server so that CDR reports are logged for fax calls, you must enable media bypass. This means configuring settings to enable media bypass globally and also on the trunk connection to the gateway to which the fax machines connect. The fax machines need to be correctly configured in the contact object configuration, as described in the “Contact Objects" section later in this topic. The gateway must present fax calls to Lync Server as G.711 audio calls; if presented as image calls, they will be rejected. These calls will be hairpinned to the gateway from which they were received. Bypass causes the hairpin to be moved to the gateway.

    --->

    И вдогонку

    <---

    Note:

    When Lync Server detects that a direct inward dial (DID) number is associated with a fax machine, the Mediation Server does not terminate media. Rather, Lync Server routes the call to the destination fax machine, bypassing the Mediation Server. You can use centralized call detail recording and policy management functionality for these types of calls because the signaling for fax machine calls flows through a Front End pool or a Standard Edition server.

    --->

    Соответвенно, напрашиваются противоречивые выводы: должен быть media bypass и кодек g711 на шлюзе, тогда все должно работать. С другой стороны, c самого начала пишут, что факсы через SIP Trunk не поддерживаются...


    MCITP: EA, SA, EMA, LSA, VA; MCSA



    17 апреля 2012 г. 18:11
  • Игорь, привет.

    У меня тоже была идея с Media ByPass, но подумал может есть другие способы, потому как есть сложности с маршрутизацией.

    Я уточнил у провайдера - у них есть клиенты у которых факсы подключены через такой же AudioCodes  и жалоб нет. Самое интересное, что сами по себе факсы ходят, иногда "почти нормально", т.е. не читается например одно-два слова, иногда вместо ОАО "Ростелеком" на факсе ОАО "Ростком" и т.д.

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

    17 апреля 2012 г. 18:25
  • Есть два способа передачи факса по IP: внутри G.711 и по спец. протоколу T.38.

    Lync Server не поддерживает T.38

    Передача по G.711 может исказиться при низком качестве среды передачи. (стандартные джитер, задержка, потери пакетов).

    Если Audiocodes MP-112 у вас недалеко от Lync Server (в той же 100 мегабитной сети), предлагаю, для начала подключить Audiocodes MP-112 к провайдеру вместо Lync Server (отключив поддержку T.38) для чистоты эксперимента.

    P.S. В нескольких проектах использовал Media Bypass и AnalogFax=$False. Проблем не наблюдал. Но там шлюзом в ТфОП был Audiocodes Mediant 1000 в той же сети, гед сам Lync Server.

    • Помечено в качестве ответа Yuriy Lenchenkov 3 мая 2012 г. 12:03
    18 апреля 2012 г. 6:28
  • Факсы передаются внутри G.711, Т-38 не включен. Мы тестировали с провайдером среду передачи - все нормально. Как говорит провайдер - проблем с факсами ни у кого нет (и тут я склонен верить, так как их клиенты из числа корпоративных заказчиков уже давно бы отказались от услуг). Попробуем подключить шлюз напрямую и протестировать. Если качество будет хорошим, то выход только MB?

    18 апреля 2012 г. 7:26
  • Аха, но для этого вам прйдется ставить у себя еще шлюз. MB подразумевает что трафик до клиентов Lync идет от шлюза напрямую. Оператор наверняка не согласится на кучу IP-адресов с которых нужно разрешать трафик.

    А если хотите совсем поддерживаемое MS решение, то факсы нужно подключить к тому же шлюзу и включить AnalogFax=$True

    • Помечено в качестве ответа Yuriy Lenchenkov 3 мая 2012 г. 12:03
    18 апреля 2012 г. 7:41
  • Vitaly Popov, вопрос решен?

    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий

    25 апреля 2012 г. 12:09
  • А как вы организовали доступ по SIP транку, именно телефония интересует. С двумя интерфейсами.
    26 сентября 2013 г. 11:18
  • В те времена я пользовался Asterisk как промежуточное звено между провайдером телефонии и Lync:

    http://argon.pro/blog/2010/11/lync-asterisk-integration/

    http://argon.pro/blog/2011/03/lync-call-routing/

    Сейчас, наверно, подключено напрямую


    MCITP: EA, SA, EMA, LSA, VA; MCSA

    26 сентября 2013 г. 11:36
  • ПРосто мне мой провайдер интернета дает возможность потестировать SIP Trunk, но никак не получается у нас:(
    26 сентября 2013 г. 11:48
  • WireShark вам в помощь

    26 сентября 2013 г. 11:51