Pull to refresh

Comments 12

Внимательно прочел обе статьи… Что могу сказать — в целом интересно!
Просьба только ответить почему asterisk, а не freeswitch с его богатыми возможностями по интеграции с языками программирования? Или платформа бралась только из расчета «я ее знаю» и другие в принципе не рассматривались?

ЗЫ. Сам разработал на freeswitch оснастку для небольшого оператора связи с мониторингом, статистикой и оформлением счетов для юр.лиц. Да — первоначально это все было построено на asterisk, но уже больше полугода перевели на новую систему.
А что не стандартного? Очередная наколенная система. Таких полно. Все стандартно ))
Так не про стандарты даже речь, какие могут быть стандарты при построении самодельных систем)
Да и что такое вообще стандарты? В наше время все что хочешь можно сделать стандартным. К примеру систему автора сделать коробочным вариантом, навесить рекламу и продвиженцев(в народе — «зазывалы») нанять — вполне себе стандартом станет)

Я интересуюсь чем руководствовались в выборе платформы?

Ну во первых нас позвали переделать существующий конфиг с клиентами и прочим.
Во вторых из-за отсутствия чёткого ТЗ, состоявшего в основном из потока сознания людей далёких от ИТ технологий и выглядевшего как "сделайте так же как у нас было, но лучше. Как оно устроено мы не знаем, мы хотим поменять команду разработчиков, потому что старые п… ы".
В третьих с астером я работаю довольно плотно с 2005 года, раньше опыт был в основном по железным АТС(Panasonic, Nortel, DeTeWe) и кастомайзил их ломая прошивки, прикручивая DECT и прочая.
В четвертых времени не было от слова совсем. До нашего прихода старая команда работала полтора года, и наработок было много. У нас был срок 2-3 месяца на прототип. Без ТЗ и описаний понять ход мыслей людей непросто.
Дальше уже естественно стали присматриваться к другим продуктам и скорее всего бы спокойно их запрограммили на нужную логику, если бы не разругались.
Вчера вот взглянул на свой механизм LCR по другому и переписал его. База вместо 140 мегабайт по 400000 префиксов стала весить 9 метров со всеми префиксами и тарифами. обслуживает спокойно 2600 req/s с ранжированием по операторам и генерацией строки дозвона в зависимости от оператора и тарифа. Вот подумываю допилить до боевого использования и выложить на github.

… поменять команду разработчиков, потому что старые п… ы

… запрограммили на нужную логику, если бы не разругались


По моему проблема не в разработчиках как раз)
Астериском занимаюсь не так давно, но перешел также с Панасоников и прочих УАТС ))

Да, реально жалко когда наработки пропадают, ибо написанный код должен работать. Выкладывайте ваши наработки по LCR (необязательно в готовом виде), подключусь, ибо сейчас тоже продумываю новые варианты реализации.

Да. коллеги еще подсказали. нам нужен был IAX для межсерверных линков, ибо там было шифрование и он более Firewall и Nat friendly. А так как система планировалась распределённая, то с SIP могли быть проблемы

Ну для межсервеных, при условии что контролируются конечные сервера, отлично подходит решение с VPN.
Какой тип VPN — тут каждый выбирает по вкусу. Для обхода NAT мы, к примеру, при подключении клиентских серверов используем openvpn(или ipsec если позволяют условия подключения). Между партнерами — ipsec(у них обычно стоит оборудование посерьезней в виде cisco).
Минус Вашей системы как раз в использовании различных технологий передачи данных. К ней еще добавить h323 и будет совсем уж прекрасно(это конечно-же «вредный совет»).
Спасибо за ответ.

проблема с разными технологиями в принципе немного надумана, т.к. никто не мешает заменить forward через IAX на вызов через SIP, тем более конфиг системы позволяет :) Нам так было удобнее я бы сказал, внутрикорпоративные межофисные линки через IAX чудесно работают, тем более за натом и при отсутствии постоянных внешних адресов.
по поводу VPN да. вся корп телефония так работает. OpenVPN на Андроидах + CSIPSimple чудесно справляются с задачами. Тоже самое с яблоками Bria+OpenVPN. Хочешь из Турции или Японии поговорить с коллегами по работе — ВЕЛКАМ!


Но еще раз повторюсь, мы выступали как подрядчики, а у заказчика свой взгляд на проект.
Мы еле убедили заказчика, что система с категориями жизненно необходима, если они не хотят терять деньги на фроде. И что нужно ввести дополнительные меры безопасности, но нам отвечали, что старая система без этого работала, значит и новая должна. Поэтому "в каждой избушке свои погремушки" :)

Если в итоге пользовать только SIP то странное решение вообще подобную систему строить на Asterisk, ну или по крайней мере только на астериск. Ведь у вас через него я больше чем уверен медиа полностью гоняется. Здесь самое место как раз для PROXY серверов. Это будет производительнее в разы при тех же трудозатратах.

Гонять все через Asterisk? а его использовать только как сообщалку что баланс в минусе или подобных штуках — это как из пушки по воробьям…

в качестве функционала там еще был webrtc, конференции, originate и много всякой мелочёвки.

WebRTC и астериск? тем более зря…
Есть более гуманные и при это работающие решения. Я больге о том чтт тут правильно было бы распределять зоны ответственности. оставить астериск как медиа сервер и как конферец микшер, ivr проигрыватель. Остальное все выносить.

Sign up to leave a comment.

Articles