Перейти к содержимому


Фотография

Радикальное Решение Проблем С Односторонней Слышимостью.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 4

#1 artemlight

artemlight

    Новичок

  • Пользователи
  • 4 сообщений

Отправлено 30 Август 2016 - 16:00

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

 

В общем, история такова. 

Есть офис на 200 человек, телефонов примерно столько же. Есть астериск, работающий сразу по четырем аплинкам (Ростелеком, Билайн, Мегафон и Задарма). И есть проблема - вызываемый абонент иногда нас не слышит. десяток звонков в день (из нескольких сотен), но всё же.

 

Путём опроса пользователей выяснилось, что страдает отдельное направление (вроде это был МТС-Москва). Сделали запрос в СТП - они говорят, что проблемы у нас. Ок.

За следующие два часа мы слегка перепилили нашу АТС, а именно:

 

Мы вынесли Астериск с виртуалки на отдельную машину.

Подцепили к ней отдельный интерфейс с внешним IP-адресом.

Явным образом перечислили все необходимые маршруты на хосты со странички ss.zadarma.com.

Не забыли закрыть остальное через -P INPUT DROP на этом интерфейсе.

Поставили воипмонитор на хост с астериском.

 

Улыбнулись, включили и стали ждать заявок.  И... нифига не изменилось!

Более того, стала теряться регистрация. Может быть, что-то не так с файрволом? Смотрим в лог дропнутых пакетов и видим совершенно другие хосты. Делаем выводы.

 

Грабли №1: список серверов на страничке ss.zadarma.com актуален далеко не всегда.

 

Окей, где наша не пропадала - наша пропадала везде (с). Пишем кляузу в стп, получаем новый список и просим, чтобы обновили на страничке. Сотрудник СТП божится, что там всё есть и присылает нотариально заверенный скриншот. То ли меня глаза подводят, то ли сотрудника - у меня другой список! Меня терзают смутные сомнения...

 

Грабли №2: список серверов на страничке ss.zadarma.com различается при входе на сайт из разных стран. Большой привет удаленщикам без гуя на удаленных линуксах. СТП об этом не знает, кстати.

 

Окей, так ведь даже интереснее. Пилим скрипт на курле, заодно советуем СТП отдавать этот список в виде json или ещё как-нибудь так, чтобы без регулярок работало. Они говорят, что когда-нибудь обязательно сделают. Ну ок, выдыхаем, удивляемся.

 

На следующий день регистрация уже не валилась, но в целом ничего не изменилось. 2-3% звонков - абонент нас не слышит. И снова МТС.

 

Но у нас же есть воипмонитор! Делаем дамп, делаем второй дамп, кляузы, кляузы, кляузы в стп! Две заявки были закрыты без какого-то конкретного ответа, а вот на третью наконец-то ответил человек со знанием дела.

 

Грабли №3: астериск игнорирует ptime в SDP, если не производится транскодинг. Наш поликомовский DECT работал с ptime 40 мсек в a-law, у цискофонов по умолчанию a-law:30 стояло. При этом zadarma выставляла огромный список кодеков в SDP (это в общем-то логично) с заявленным ptime в 20 мсек. Кем бы не был инициирован вызов с нашей стороны - кодеки с задармой всегда согласовывались без транскодинга, и репакетизация не работала. При этом звука не было только на некоторых направлениях, а так-то он вообще был почти везде.

 

Решить эту проблему при помощи Asterisk так и не удалось - мы выставили на всех наших устройствах ptime 20 мсек и проблема ушла. 

 

Но верите Вы мне или нет - пользователи продолжали жаловаться на одностороннюю слышимость.

 

1-2 звонка в день, но всё же.

 

Я снимаю дампы с Voipmonitor - там всё слушабельно, размер пакета правильный и всё вообще сферически-вакуумно идеально. Отправляю их в СТП - они говорят, что дампы крутые, по нашим направлениям контрольные звонки ок, сделать ничего нельзя, потому что делать ничего не нужно. Может быть, мой провайдер гадит в ртп?

 

Грабли №4: Zadarma не предоставляет никаких инструментов для диагностики RTP-потоков.  Вообще есть RTCP, и там-то сразу видно, что оператор связи не получает мой ртп. Всё это можно классифицировать в том же воипмониторе и лечить не по заявкам от пользователей (которые им чаще всего лениво писать), а по конкретным алертам. Но нет. Операторы стп говорят, что когда-нибудь будет, но json-интерфейс для выгрузки списка серверов я жду до сих пор :)

 

Охохонюшки. Зеркалируем интерфейс коммутатора, выцепляем с него L2+ правилом всё на SIP\RTP. Полученный поток шлем в виртуалку с выделенным воипмонитором, который всё раскладывает по полочкам. Заодно на внешнем маршрутизаторе ставим правило, считающее RTP и SIP пакеты от астериска (они не должны туда идти - но вдруг они там есть). 

 

И правда - есть там! Почему, если есть маршрут в другую сторону? 

 

Грабли №5: Connection Tracking на Asterisk может серьёзно подгадить.  И это касается не только протухших регистраций через нат.  Voipmonitor, работающий на нескольких интерфейсах одновременно, проблемы в этом не увидит, и объединит всё в один дамп. А в реальной жизни ртп из этого дампа ходит через роутер (где успешно или дропается, или натится вникуда), а сип - через внешний интерфейс, специально для этого предназначенный.

 

Решение - устанавливать воипмонитор только "в разрыв" интерфейса, по одному инстансу на каждый интерфейс.  И отключать nf_conntrack, конечно же. У нас он оказался вкомпилен в ядро, поэтому пока просто conntrack -F в кроне, а там подумаем.

 

Что я хочу сказать всем вот этим:

 

Уважаемая администрация проекта!

Мы ценим вас и любим, и пользуемся, и платим даже немножко.

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

Плюс - нет возможности отследить качество сервиса. RTCP нам ОЧЕНЬ нужен, вы уже поняли, думаю.

Ну и разный Lync эти вопросы решает при помощи выделенного vpn-туннеля к провайдеру. У нас не Lync, но мы тоже так хотим. 

И если нет возможности сделать обновляемый список адресов - сделайте хотя бы оповещалку по элпочте. Чтобы об изменениях в этом списке мы от Вас узнавали, а не от наших любимых пользователей.

 

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

 

 

 

 

 

 

 

 

 

 

 

 



#2 Igor

Igor

    Продвинутый участник

  • Главные администраторы
  • 4 892 сообщений

Отправлено 01 Сентябрь 2016 - 13:37

На самом деле сам текст больше к админам чем к администрации :)

 

Могу кратко сказать: оповещать каждого клиента что от него в одном звонке из 100 не пришли пакеты проблематично при наших масштабах (очередная гора спама :) ), и главное - мало что даст. Так как в 90% случаев у клиента не будет админа способного что-то перенастроить. А настройками и поддержкой клиентского оборудования мы к сожалению не занимаемся, так как это совсем другая работа.

Когда был очередной баг в FPBX и клиентов начали часто ломать, мы разослали всем у кого эта АТС, эффект почти нулевой, так что даже почту мало кто читает.

 

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

 

По поводу туннеля к провайдеру, неоднократно думали о таком решении, даже делали тестовые версии, но пока спрос на это очень мал (а мы регулярно исследуем спрос). Как закончится список более востребованных новшеств, обязательно добавим и это :)



#3 artemlight

artemlight

    Новичок

  • Пользователи
  • 4 сообщений

Отправлено 01 Сентябрь 2016 - 14:51

оповещать каждого клиента что от него в одном звонке из 100 не пришли пакеты

я бы душу продал за такую галку в SIP-настройках. Это ж сразу все косячные клиенты видны. RTCP, конечно, лучше, но хоть так...

 

даже почту мало кто читает.    

 

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

Также каждый раз при добавлении нового блока адресов (а это не так часто) мы оповещаем во всех новостях, включая все соцсети.

 

 

 на мою почту никогда не приходили новости о добавлении\изменении блоков адресов. А если бы такие новости приходили (да ещё и с priority:high, например), мы бы их напрямую в наш OTRS-Sharepoint-ManageEngine-YetAnotherHelpdeskEngine роутили бы, и получали бы аккуратные заявки вместо жалоб пользователей. 

 

Это, кстати, ещё одна отличная галочка где-нибудь в панели. 

 

Вообще всё письмо было о том, что в business-critical вещах (а телефония - это именно критичный сервис) грустно жить без end-to-end мониторинга. И вот есть у меня, например, в Кемерово точка с Ростелекомом, на точно такой же АТС с точно таким же поликомом. Но там - один ip-адрес, не меняющийся уже много лет. Так вот проблем с ним вообще никаких нет - он некорректные сессии (без RTP, с кривым RTP, с кривым PTIME) и т.д. просто отбивает даже после Invite с 503 ошибкой. А на сервер он заводится в виде pppoe-туннеля с непубличным ip-адресом. Вот это - 100% business ready солюшн, потому что поставил и забыл, ток деньги главное платить. Отвалился pppoe - алерт! Отвалилась регистрация - алерт! SIP 503 - алерт! Бизнес любит мониторинг, черт подери! Люди ж ради крешей офиса на клиентах систем центр покупают, а тут такой кусок инфраструктуры.

 

А обновляемый скриптом (или того хуже - вручную) файрвол - это не бизнес реди, это абы что.  Вот придёт бизнес-админ, вобьет сип.задарма.ком в свой астериск или коллменеджер. Пройдется по паре из вышеперечисленных граблей, плюнет и останется на РТ. Потому что деньги компании - это не его личные деньги, а вот личное время придётся потратить на всё это.  Может, потому и нет спроса на Линк, админы - люди ленивые.



#4 pbx.gal.cv.ua

pbx.gal.cv.ua

    Продвинутый участник

  • Пользователи
  • 183 сообщений
  • Пол:Мужчина

Отправлено 02 Сентябрь 2016 - 13:15

 

Также каждый раз при добавлении нового блока адресов (а это не так часто) мы оповещаем во всех новостях, включая все соцсети.

 на мою почту никогда не приходили новости о добавлении\изменении блоков адресов. А если бы такие новости приходили (да ещё и с priority:high, например), мы бы их напрямую в наш OTRS-Sharepoint-ManageEngine-YetAnotherHelpdeskEngine роутили бы, и получали бы аккуратные заявки вместо жалоб пользователей. 

 

Это, кстати, ещё одна отличная галочка где-нибудь в панели. 

 

Вообще всё письмо было о том, что в business-critical вещах (а телефония - это именно критичный сервис) грустно жить без end-to-end мониторинга. И вот есть у меня, например, в Кемерово точка с Ростелекомом, на точно такой же АТС с точно таким же поликомом. Но там - один ip-адрес, не меняющийся уже много лет. Так вот проблем с ним вообще никаких нет - он некорректные сессии (без RTP, с кривым RTP, с кривым PTIME) и т.д. просто отбивает даже после Invite с 503 ошибкой. А на сервер он заводится в виде pppoe-туннеля с непубличным ip-адресом. Вот это - 100% business ready солюшн, потому что поставил и забыл, ток деньги главное платить. Отвалился pppoe - алерт! Отвалилась регистрация - алерт! SIP 503 - алерт! Бизнес любит мониторинг, черт подери! Люди ж ради крешей офиса на клиентах систем центр покупают, а тут такой кусок инфраструктуры.

 

А обновляемый скриптом (или того хуже - вручную) файрвол - это не бизнес реди, это абы что.  Вот придёт бизнес-админ, вобьет сип.задарма.ком в свой астериск или коллменеджер. Пройдется по паре из вышеперечисленных граблей, плюнет и останется на РТ. Потому что деньги компании - это не его личные деньги, а вот личное время придётся потратить на всё это.  Может, потому и нет спроса на Линк, админы - люди ленивые.

 

Можно автоматом. Мой роутер, например, добавит в правило все ip из А-записей, если вписать DNS имя хоста.


Сообщение отредактировал pbx.gal.cv.ua: 02 Сентябрь 2016 - 13:16


#5 Igor

Igor

    Продвинутый участник

  • Главные администраторы
  • 4 892 сообщений

Отправлено 02 Сентябрь 2016 - 13:39

 

А обновляемый скриптом (или того хуже - вручную) файрвол - это не бизнес реди, это абы что

 

Я наверное вас удивлю, но большинство работает за NAT и им этот список вообще не критичен.

 

 

Отвалился pppoe

 

Насколько понимаю речь о чем-то вроде adsl и поверх него pppoe. Да, мониторить это быть может чуть проще, но выглядит криво.

А через public ip пережимать голос в туннель, это может быть еще лишний минус к качеству и плюс к проблемам (нужно чтобы с mtu вопросов не было и роутер ваш успевал все пакеты быстро запаковывать). Так что туннель это опция, но никак не "стандарт".

Например между операторами я не видел туннелей никогда, либо прямой стык либо public ip. В вашем примере это скорее прямой стык на месте, что удобней по качеству и надежности, но обычно в разы дороже (а иногда и на порядок).

 

 

добавит в правило все ip из А-записей, если вписать DNS имя хоста.

 

Не верное решение :) Научите роутер использовать SRV записи. Об этом писали в том числе на форуме.






Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 скрытых пользователей