Comments 141
А как технически реализована поддержка push-notifications с любым SIP сервером? Когда подобный функционал появился в Softphone/Groundwire несколько лет назад, они отправляли SIP credentials на свой сервер в Чехии, регистрировали соединение с него и присылали на телефон PUSH когда приходил звонок.
Вы тоже к себе на сервер отправляете SIP credentials?
Вы тоже к себе на сервер отправляете SIP credentials?
Да, совершенно верно, так и происходит, только сервер в AWS находится — в статье описан принцип действия.
Т.е. получается что мы разбиваем SIP звонок на 2 плеча — от сервера в AWS до провайдераVOIP он идет по старому, а второе плечо — от AWS к клиенту (наиболее уязвимое) уже зашифровано и снабжено пушем.
Т.е. получается что мы разбиваем SIP звонок на 2 плеча — от сервера в AWS до провайдераVOIP он идет по старому, а второе плечо — от AWS к клиенту (наиболее уязвимое) уже зашифровано и снабжено пушем.
Сервис Zadarma использует сразу четыре дата-центра для обеспечения надежности связи. Для максимального качества наша система автоматически выбирает ближайший дата-центр к клиенту.
Мы, то есть проект Zadarma, не несем ответственности за качество и надежность голоса при передаче его через сторонние сервера.
И да — в бесплатном и недавно обновленном приложении Zadarma для iOS уже реализована работа с PUSH и позже будет реализована работа с TLS. (аналогичные планы и для android).
Мы, то есть проект Zadarma, не несем ответственности за качество и надежность голоса при передаче его через сторонние сервера.
И да — в бесплатном и недавно обновленном приложении Zadarma для iOS уже реализована работа с PUSH и позже будет реализована работа с TLS. (аналогичные планы и для android).
Мало того что реклама, так по факту толком ничего не объяснили. Что за волшебные пуши такие, которые не дают спать. Каким образом появляется шифрование… Не из-за того ли что коннект идет через непонятный левый сервак…
А Задарма знает про ваше приложение? И именно они отправляют push вашему приложению при входящем звонке когда у абонента нету активной регистрации на их сервере?
Или ваше приложение сливает все пароли на ваш сервер и уже он регистрируется у voip-провайдера и шлет push вашему приложению. Если так то шифрование как бы уже побоку.
Или ваше приложение сливает все пароли на ваш сервер и уже он регистрируется у voip-провайдера и шлет push вашему приложению. Если так то шифрование как бы уже побоку.
А Задарма знает про ваше приложение? И именно они отправляют push вашему приложению при входящем звонке когда у абонента нету активной регистрации на их сервере?
Нет, Задарма не знает, мы просто на нем тестировали. У них только недавно пуш появлился и только для iOS версии.
У нас универсальное решение, не только для Задарма.
Или ваше приложение сливает все пароли на ваш сервер и уже он регистрируется у voip-провайдера и шлет push вашему приложению.
Да, приницип в статье расписан. Только не сливает, а передает :)
Если так то шифрование как бы уже побоку.
Не побоку, ибо ваши данные знают только 2 стороны — провайдер и софтфон.
И эти 2 стороны будут ВСЕГДА знать.
Вы доверяете CSipSimple например или другим софтфонам, но все равно ими пользуетесь?
Так какая разница в нашем случае?
А вот если ваш SIP незашифрован, то ваши переговоры могут писать кто угодно — любой сосед.
CSipSimple
У него открытый кот. У вашего сервера, который заботливо хранит у себя чужие логины-пароли, кот закрытый.
любой сосед
Удачи соседу с перехватом моего LTE-траффика, чо уж тут.
У него открытый кот. У вашего сервера, который заботливо хранит у себя чужие логины-пароли, кот закрытый.
Вы уверены что у них там именно так все реализовано как написано?
У него, несмотря на открытость, криво работает шифрование, точнее вообще не работает нормально. К тому же есть куча других популярных софтфонов с закрытым кодом — что им прикажете делать?
Удачи соседу с перехватом моего LTE-траффика, чо уж тут.
Ну вы видимо уникальный человек, не пользуетесь вайфаем.
Ну тогда это не для вас, это же очевидно.
Этой статьей я и не предполагал решить именно ВАШИ проблемы, уж извините меня за такую неловкость…
Ну вы видимо уникальный человек, не пользуетесь вайфаем.
Удачи соседу с взломом хэша ключа.
А можно подробнее про неработающее шифрование в CSipSimple?
Попробуйте включить ZRTP и позвонить через сервер, на котором ZRTP отродясь не бывало — CSipSimple будет говорить вам что звонок идет и все нормально.
Месяц назад так было.
Месяц назад так было.
CSipSimple будет говорить вам что звонок идет и все нормально.
Так соединение до абонента Б устанавливается или нет? Если да, то любопытно, что там в обмене происходит в это время, а вот если нет… тогда тоже интересно, да.
Попробовать, что-ли, в домашней лабе дамп снять…
А с SRTP у CSipSimple подобные проблемы есть?
А выше вы пишете что
Так все таки голос шифрованный стало быть тоже у вас терминируется? Если так то это дабл эпик фейл.
мы разбиваем SIP звонок на 2 плеча — от сервера в AWS до провайдера VOIP он идет по старому, а второе плечо — от AWS к клиенту (наиболее уязвимое) уже зашифровано и снабжено пушем — в статье об это написано.
Так все таки голос шифрованный стало быть тоже у вас терминируется? Если так то это дабл эпик фейл.
Думаю, провайдер забанит автоматом, когда слишком много регистраций с одного ip польется…
Да реги-то что, на них особо никто не смотрит — люди под натами же работают тоже.
Чтобы из-под одного белого ip на ресурс одновременно пришли 2 и более человек — он должен быть просто сверхопулярный.
Не могу сказать, сколько в среднем абонентов сидит на одном белом ip, цифры у всех разные. Но, думаю, если на каком-либо sip провайдере сидит каждый 10-й пользователь интернета, то он, провайдер, просто мегагигант.
Не могу сказать, сколько в среднем абонентов сидит на одном белом ip, цифры у всех разные. Но, думаю, если на каком-либо sip провайдере сидит каждый 10-й пользователь интернета, то он, провайдер, просто мегагигант.
Они на AWS сидят, так просто их не побанить :(
Да ничего здесь такого нет — например организация взяла виртуальную АТС и всех сотрудников подключила.
Там у них будут сотни рег под одним IP адресом.
Там у них будут сотни рег под одним IP адресом.
Это не тот случай. Тут виртуальная АТС про них знает, правила будут другие.
Это не тот случай. Тут виртуальная АТС про них знает, правила будут другие.
В смысле не тот случай????
Там такие же абоненты, также получившие логины-пароли у этого же провайдера и положившие деньги на свои аккаунты.
Вы наверное думаете что это что-то запрещенное, так делать?
Надо делать строго как прописали и не шаг в сторону?
Я вам вот что скажу — посмотрите немного с высоты на это все.
И вы увидите что рынок вот таких SIP провайдеров с каждым годом схлопывается, это стагнирующий и идущий вниз рынок по маржинальности.
С каждым годом зарабатывать деньги там становится труднее и труднее — конкуренция, падение цен, масса различых предложений, мобильные операторы с большим баблом на этот рынок лезут и т.д.
Мессенджеры отъедают частных пользователей, бизнес пользователей кто только не окучивает, всякие AI ввредяет гугл и т.д.
WhatsApp вот недавно туда же полез.
Там деньги трудно зарабатываются и их все меньше и меньше.
То, что мы предлагаем — это называется омниканальностью.
У пользователя есть выбор — он и так может пользоваться сервисом, через мессенджер и может со своего десктопного IP телефона и скачав приложение провайдера — что в этом плохого?
Я думаю что люди в таких сервисах неглупые сидят и понимают что это все только им на пользу а не во вред, как вы тут пытаетесь сами себе представить.
Ох щит…
Тоесть… вы предлагаете шифровать sip/rtp трафик пропуская через свой сервер и передавая вам логин/пароль? Это просто эпик фейл, каждые пару месяцев появляются новости про очередной «слив» пользовательских данных через левую компанию/приложение.
Для внутренней телефонии есть готовые програмные ats с возможностью шифрования(если звонок ходит через «дикий» интернет без туннелей), для звонков в телефонные сети шифрование уже особой роли не играет, оно заканчивается на операторе предоставляющем номер и начиная с оператора «кому надо» смогут звонок перехватить.
Тоесть… вы предлагаете шифровать sip/rtp трафик пропуская через свой сервер и передавая вам логин/пароль? Это просто эпик фейл, каждые пару месяцев появляются новости про очередной «слив» пользовательских данных через левую компанию/приложение.
Для внутренней телефонии есть готовые програмные ats с возможностью шифрования(если звонок ходит через «дикий» интернет без туннелей), для звонков в телефонные сети шифрование уже особой роли не играет, оно заканчивается на операторе предоставляющем номер и начиная с оператора «кому надо» смогут звонок перехватить.
Ох щит…
Тоесть… вы предлагаете шифровать sip/rtp трафик пропуская через свой сервер и передавая вам логин/пароль? Это просто эпик фейл, каждые пару месяцев появляются новости про очередной «слив» пользовательских данных через левую компанию/приложение.
Опять смешались в кучу мед, пчелы и т.д.
Давайте на вашем примере я объясню, еще раз.
1. Ваши данные SIP аккаунта (логин и пароль) ВСЕГДА знают 2 стороны — VOIP провайдер, который вам их и выдал и софтфон, в который вы их вносите.
Это — ВСЕГДА.
2. Ваш логин и пароль с 5 рублями на счету в СИпнете или еще где-то нас не интересуют.
3. По вашему логину и паролю, если вы пользуетесь нормальным SIP провайдером как правильно нельзя войти в личный кабинет.
4. Все что именно мы о вас знаем — это ваш логин в M1 Messenger, и… все.
Т.е. мы не знаем о вас НИЧЕГО.
У нас нет регистрации по номеру телефона, мы не читаем вашу записную книжку и не храним ее у себя на сервере, как это делают другие SIP софтфоны и мессенджеры.
О каких пользовательских данных идет речь?
Вы нас с кем-то путаете.
5. Для особо впечатлительных людей типа вас у нас есть другой функционал — каждому пользователю выдается свой SipUri вида userid@sip1.m1online.net в мессенджере.
Что означает что вы можете взять и зарулить ЛЮБОЙ виртуальный номер на мессенджер по SipUri НЕ ПРЕДОСТАВЛЯЯ никаких SIP данных нам.
Т.е. вы можете принимать входящие звонки как с виртуальных номеров, так и из других SIP сетей абсолютно анонимно, с шифрованием и с пушем.
Для внутренней телефонии есть готовые програмные ats с возможностью шифрования(если звонок ходит через «дикий» интернет без туннелей), для звонков в телефонные сети шифрование уже особой роли не играет, оно заканчивается на операторе предоставляющем номер и начиная с оператора «кому надо» смогут звонок перехватить.
В статье речь идет ТОЛЬКО о мобильных клиентах SIP, где нет всего вами перечисленного.
Вы в любом случае становитесь ПОСРЕДНИКОМ который на каком-то этапе шифрует трафик, тоесть о безопасности речи быть не может т.к.:
1. На каком-то этапе трафик не шифрован
2. Вопрос доверия непонятной облачной конторе, которая вдобавок зависит от другой облачной конторы(aws)
1. На каком-то этапе трафик не шифрован
2. Вопрос доверия непонятной облачной конторе, которая вдобавок зависит от другой облачной конторы(aws)
Вы в любом случае становитесь ПОСРЕДНИКОМ который на каком-то этапе шифрует трафик, тоесть о безопасности речи быть не может т.к.:
1. На каком-то этапе трафик не шифрован
Согласитесь, что быть наполовину зашфированным лучше, чем не быть совсем :)
Причем эта половина — сторона клиента — самая уязвимая.
2. Вопрос доверия непонятной облачной конторе, которая вдобавок зависит от другой облачной конторы(aws)
Ну, доверяя нам, вы практически ничем не рискуете — мессенджер без регистрации по номеру телефона, мы не считываем ваши СМС, у нас нет допуска к вашей записной книжке — у нас нет никаких методов вашей идентификации, если вы этого боитесь и вы это можете проверить — среди мессенджеров у нас самое малое количество разрешений для приложения.
К тому же по SIP вы можете получать звонки по SipUri, т.е. вообще не сообщая нам данные вашего SIP аккаунта.
А вообще все мы зависим в жизни от чего-либо — от солнечного излучения, от воздуха и воды и т.д.
А облачное решение, тем более от AWS — мирового лидера, гораздо стабильней домашнего компа со старыми винтами, если вы это имеете ввиду.
Ну, доверяя нам, вы практически ничем не рискуете
1. SIP credentials используемого провайдера хранятся на ваших серверах. В случае взлома они утекут.
2. Нешифрованное плечо разговора. Да и вообще, к чему мне пропускать свой траффик через дополнительный узел в сети, если E2E как не было, так и нет? Плюс, это повлияет на качество голоса, привнеся дополнительную задержку.
1. SIP credentials используемого провайдера хранятся на ваших серверах. В случае взлома они утекут.
Вы так говорите, как будто это так легко сделать. Он защищен с нашей стороны лучше чем у большинства VOIP провайдеров.
2. Нешифрованное плечо разговора. Да и вообще, к чему мне пропускать свой траффик через дополнительный узел в сети, если E2E как не было, так и нет? Плюс, это повлияет на качество голоса, привнеся дополнительную задержку.
Я вот этого не понимаю — можете объяснить, чем вы руководствуетесь, делая такие претензии?
Для лучшего понимания я вам поясню:
У вас сейчас нет НИЧЕГО.
Нет ни пуша, ни шифрования, ни защиты от блокировок.
Еще раз — нет НИЧЕГО.
Вам предлагают улучить то чем вы сейчас пользуетесь, качественно, без танцев с бубнами и других трудозатрат.
Но нет, вы говорите о каком-то е2е шифровании, которого у вас нет и не будет в обозримом будущем практически НИКОГДА.
Оно вам нужно? Зачем? Если вы терминируетесь на землю или GSM, то какое может быть е2е шифрование?
Но вам оно почему-то надо.
Это один момент.
Второй — никакого изменения в качестве шифрованного и нешифрованного трафика нет.
Он защищен с нашей стороны лучше чем у большинства VOIP провайдеров.
Жду ссылку на независимое исследование, на основании которого вы делаете такое утверждение.
У вас сейчас нет НИЧЕГО.
Нет ни пуша, ни шифрования, ни защиты от блокировок.
Еще раз — нет НИЧЕГО.
Вам предлагают улучить то чем вы сейчас пользуетесь, качественно.
Откуда вы знаете, чем именно я пользуюсь, что у меня есть, а чего у меня нету?
Оно вам нужно? Зачем?
Нужно. Зачем — хочется.
Второй — никакого изменения в качестве шифрованного и нешифрованного трафика нет.
Добавление еще одного узла в маршрут, на котором вдобавок хз что творят с RTP, так или иначе внесет изменения в качество голоса. Чем меньше узлов между абонентами А и Б — тем лучше, это аксиома. К тому же вон выше коллеги из Zadarma подтянулись и, разумеется, сняли с себя всю ответственность. Любой провайдер на их месте поступит так же.
p.s. знаете, в чем ваша ошибка? В том, что вы пытаетесь пиарить сомнительного качества продукт через все еще технический ресурс, где люди могут сходу увидеть и понять его недостатки. Тут надо бы рекламировать где-нибудь на более развлекательных сайтах, подчеркивая, что «всех прослушивают! батарейка садится! а вот у нас!!» Одноклассники там, я не знаю, вирусный пост в Контакте запустить.
Но не здесь.
Жду ссылку на независимое исследование, на основании которого вы делаете такое утверждение.
Сами попробуйте сломать, потом напишите что у вас получилось — это и будет независимым исследованием, вы же как я понимаю никому не верите, кроме себя.
Нужно. Зачем — хочется.
Ну сделайте е2е шифрование при терминировании в землю, потом расскажите как вы опровергли все законы физики.
Чисто физически добавление еще одного узла в маршрут, на котором вдобавок хз что творят с траффиком непременно внесет изменения в качество голоса. Чем меньше узлов между абонентами А и Б — тем лучше, это аксиома.
Чисто физически ваши уши не услышат добавление задержки в 200 мс, вот это даже не аксиома, а исследования, причем независимые ;)
К тому же вон выше коллеги из Zadarma подтянулись и, разумеется, сняли с себя всю ответственность. Любой провайдер на их месте поступит так же.
Естественно, они не отвечают, абсолютно также как и за поведение любого шлюза или IP телефона или софтфона на их сети.
Коллеги из Задарма предельно корректно высказались, а вот вы как-то их слова неправильно понимаете, с уклоном в отрицательность.
Они для этого и делают своего SIP клиента, чтобы за него отвечать.
p.s. знаете, в чем ваша ошибка? В том, что вы пытаетесь пиарить сомнительного качества продукт через все еще технический ресурс, где люди могут сходу увидеть и понять его недостатки.
А знаете в чем ваша ошибка?
Вы любой продукт будете смешивать с г..., видимо вы такой человек, с таким менталитетом.
Продукт нормальный, это даже не продукт, а одна-единственная фича от продукта, причем такие же точно продукты уже есть у других компаний, но они платные.
Если бы это была фича которую вообще никто не делал, то можно было бы тут поупражняться в сравнениях и добавлять всякие другие эпитеты, но!
Ровно тоже самое делает например Акробитс, довольно известная компания из Чехии.
У них тоже продукт сомнительного качества?
Они уже несколько лет все это делают и делают ровно также как я и описал, с промежуточным сервером и т.д.
Я понимаю что это хабр и т.д., но прежде чем наезжать на других, вы бы свою квалификацию в этом вопросе подтянули бы, чтобы не выглядеть как дед Щукарь.
Сами попробуйте сломать
Зачем? Бремя доказательства всегда лежит на утверждающем. Это же вы утверждаете, что защищены лучше большинства VOIP провайдеров, стало быть — можете подтвердить свои слова?
Ну сделайте е2е шифрование при терминировании в землю
Что именно значит «в землю»? В аналог? В SIP-девайс? Земля она разная бывает.
задержки в 200 мс
То есть вы гарантируете задержку не выше 200 мс?
Вы любой продукт будете смешивать с г..., видимо вы такой человек, с таким менталитетом.
«Критики, критики не любите.» (С) Кристобаль Хозевич Хунта
У них тоже продукт сомнительного качества?
Любой, я повторяю — любой сервис, который требует передачи ему логина/пароля от другого сервиса, не имеющего к нему отношения — это сервис сомнительного качества, мягко говоря. Мне честно говоря дика сама мысль о том, чтобы кому-то абсолютно неизвестному вот так просто взять и отдать какой-нибудь пароль.
А уж тем более — перенаправить через этого неизвестного весь свой голосовой траффик (это я о «звонках по SIP URI», да).
Что именно значит «в землю»? В аналог? В SIP-девайс? Земля она разная бывает.
Вопросов больше не имею…
То есть вы гарантируете задержку не выше 200 мс?
да
Любой, я повторяю — любой сервис, который требует передачи ему логина/пароля от другого сервиса, не имеющего к нему отношения — это сервис сомнительного качества, мягко говоря. Мне честно говоря дика сама мысль о том, чтобы кому-то абсолютно неизвестному вот так просто взять и отдать какой-нибудь пароль.
Вы или крестик или трусы…
Дело в том что ЛЮБОЕ SIP устройство потребует от вас логин пароль.
Еще раз — ЛЮБОЕ, понимаете?
ЛЮБОЙ софтовый SIP клиент, любой шлюз, любой IP тейлифон…
А согласно вашей логике, в любом из них может быть закладка…
Т.е. не передавая на сторону в данном случае логин/пароль вы тупо не сможете сервисом пользоваться, понимаете?
Ну вот такая она, SIP телефония и ничего вы с этим сделать не сможете.
Как жить, спросите вы наверное? Не знаю, я посоветую вам не пользоваться IP телефонией вообще, она идет вразрез с вашими жизненными правилами…
А уж тем более — перенаправить через этого неизвестного весь свой голосовой траффик (это я о «звонках по SIP URI», да).
Чем вам sipuri то неугодил — там паролей не надо вводить от одних сервисов в другой…
Вопросов больше не имею…
Нет, вы уж расшифруйте, пожалуйста, что такое по-Вашему, «терминация в землю». А то я «оригинацию из воздуха» тоже придумать могу, да.
Дело в том что ЛЮБОЕ SIP устройство потребует от вас логин пароль.
Еще раз — ЛЮБОЕ, понимаете?
ЛЮБОЙ софтовый SIP клиент, любой шлюз, любой IP тейлифон…
Не любое, кстати, вы зря так капсите.
А согласно вашей логике, в любом из них может быть закладка…
Может, конечно. Но в их случае — это может, то есть мой пароль из клиента может утечь, а может и не утечь, особенно если у клиента открытый кот, а в случае вашего сервиса я точно знаю, что утечка фактически не только происходит, но и является необходимой.
Чем вам sipuri то неугодил
перенаправить через этого неизвестного весь свой голосовой траффик
Вот чем.
Чисто физически ваши уши не услышат добавление задержки в 200 мс, вот это даже не аксиома, а исследования, причем независимые ;)Мдааа…
Задержка в 200мс считается нормальной для приемлемого качества голоса в разговоре. Если вы к моим 150 добавите свои 200 — будет 350, которые уже начинают напрягать.
Вы не понимайте все буквально, потому что вы сразу делаете какие-то выводы — услышали что-то- сразу подхватили.
Я сказал только одно — задержка до 200 мс не воспринимается человеческим ухом и все.
Но я нигде не сказал что мы вносим такую задержку!
По вашему комментарию можно разбирать кейс — Как распространяются слухи…
Я сказал только одно — задержка до 200 мс не воспринимается человеческим ухом и все.
Но я нигде не сказал что мы вносим такую задержку!
По вашему комментарию можно разбирать кейс — Как распространяются слухи…
1. Задержка 200 считается приемлемой при телефонном разговоре. Это не эквивалентно «не воспринимается человеческим ухом».
2. Я взял граничный случай. Он, конечно же, не будет провляться на всех маршрутах, но на некоторых — да. К примеру, у меня клиент находится в Израиле, сервер в Индии, коннект в вашим проксям в каких-то Голландиях или Штатах.
2. Я взял граничный случай. Он, конечно же, не будет провляться на всех маршрутах, но на некоторых — да. К примеру, у меня клиент находится в Израиле, сервер в Индии, коннект в вашим проксям в каких-то Голландиях или Штатах.
Человеческое ухо успешно отличает линк на 50мс задержки от линка на 100мс.
100+мс отличают ВСЕ.
100+мс отличают ВСЕ.
Чисто физически ваши уши не услышат добавление задержки в 200 мс, вот это даже не аксиома, а исследования, причем независимые ;)
Пробовал держать * на AWS несколько лет назад. ДЦ в Ирландии, ~50мс, если не ошибаюсь. Некомфортно.
(directmedia=no)
У вас голосовой кодек вносит сопоставимую задержку, видимо не в этом причина была.
Википедия пишет про 20 мс про g.711 и g.729, которые я использовал.
Ну и было с чем сравнивать, конечно. Другой Астер находился в моей сети.
Ну и было с чем сравнивать, конечно. Другой Астер находился в моей сети.
Согласитесь, что быть наполовину зашфированным лучше, чем не быть совсем :)
Вы что гуманитарий? Если шифрование защищает соединение только на половину, то цена этому шифрованию == 0.
Ну, доверяя нам, вы практически ничем не рискуете
Вы на технический ресурс пришли, тут таких аргументов недостаточно. Вы — посредник, у которого есть доступ к трафику и что вы с ним делаете — неизвестно, какое тут может быть доверие?
А облачное решение, тем более от AWS — мирового лидера, гораздо стабильней домашнего компа со старыми винтами, если вы это имеете ввиду.
А тут не в технической стабильности вопрос. Во первых, в РФ есть РоскомПозор, который славится коровыми блокировками aws и ему подобных. ВО вторых, aws юридически находится на территории США и подчиняется тамошним законым, скажут им запретить все соединения от пользователей опеделенной страны и что им делать останется?
Вы что гуманитарий? Если шифрование защищает соединение только на половину, то цена этому шифрованию == 0.
Как по мне, гуманитарий — это вы, потому что не понимаете простых и очевидных вещей.
Ну давайте я вам их и объясню:
1. SIP — это вам не закрытая экосистема мессенджера.
Чем отличается SIP?
Да тем что это открытый протокол и он соединяет различные системы телефонии, понимаете?
Это вы в своем мессенджере можете сделать Е2Е шифрование, потому что он закрытый и с другим сетями не коммуницирует.
А когда у вас звонок из смартфона пользователя приземляется на GSM сеть где-нибуть в Нью-Йорке и проходит 3-4 транзитных оператора, вы хоть обкакайтесь, вы НЕ СМОЖЕТЕ обеспечить Е2Е шифрование.
Вы это можете понять или нет?
Еще раз — это НЕ закрытая система одного мессенджера — это открытая сеть, которая сопрягается и с GSM и c PSTN и с различными ДРУГИМИ сетями SIP.
2. Защита в данном случае на стороне клиента.
Ну чтобы вам было понятно, приведу такой пример — у вас есть например городской телефон и он соединяется с распредшкафом где-нибудь на улице.
Любой монтер может открыть шкаф, подключиться к вашей линии и прослушивать.
Это просто вам для того чтобы у вас картинка в голове сложилась.
Вы можете сказать что кое-где сейчас оптика и т.д., но там будет примерно тоже самое — паралельно для снифа вам подключат комп.
Вот от таких вещей мы шифруем и защищаем.
А тут не в технической стабильности вопрос. Во первых, в РФ есть РоскомПозор, который славится коровыми блокировками aws и ему подобных.
Это легко обходится именно на AWS. На вашем хостере в РФ вы таких обходов в принципе сделать не сможете, так что AWS надо просто правильно готовить.
ВО вторых, aws юридически находится на территории США и подчиняется тамошним законым, скажут им запретить все соединения от пользователей опеделенной страны и что им делать останется?
Такие опасения высосаны из пальца — скорее РКН отключит РФ от всего мира, чем наоборот.
Следовать требованиям РКН — это самое последнее дело, о котором нужно думать и принимать во внимание.
Как по мне, гуманитарий — это вы, потому что не понимаете простых и очевидных вещей.
Даже читать не буду, ибо там бред. Вы не понимаете зачем нужно оконечное шифрование и предлагаете вклиниться в соединение клиент<->сервер под предлогом частичного шифрования.
Вот от таких вещей мы шифруем и защищаем.
Выше уже написали, что sip провайдеры начинают браться за голову и самостоятельно предлагают оконечное шифрование, вы тут лишнее звено.
Следовать требованиям РКН — это самое последнее дело, о котором нужно думать и принимать во внимание.
Идите самолетики из окон попускайте, очередные дигитал-резистанс.
Даже читать не буду, ибо там бред. Вы не понимаете зачем нужно оконечное шифрование и предлагаете вклиниться в соединение клиент<->сервер под предлогом частичного шифрования.
А вы почитайте и сами меньше будете бредить.
Вы хоть понимаете как устроены SIP звонки на GSM например?
Клиент-сервер провайдера-сервер транзитного оператора1-сервер транзитного оператора2-… сервер транзитного оператора т- терминационный шлюз оператора GSM.
И это только для одного напрвления, а их десятки тысяч.
Что вы там собрались е2е шифровать, объясните членораздельно плз.
Выше уже написали, что sip провайдеры начинают браться за голову и самостоятельно предлагают оконечное шифрование, вы тут лишнее звено.
Вам уже тоже выше писали — у каждого провайдера бубет СВОЕ приложение, если вы будете пользоваться разными, потому что они разный сервис предлагают, то вам надо будет иметь 5-10 РАЗНЫХ приложений.
Идите самолетики из окон попускайте, очередные дигитал-резистанс.
А вы предлагаете как в анекдоте с утра пораньше в субботу под очередную порцию в очередь выстаиваться, а то потом на дачу ехать?
Ваши данные SIP аккаунта (логин и пароль) ВСЕГДА знают 2 стороны — VOIP провайдер, который вам их и выдал и софтфон, в который вы их вносите.
Это — ВСЕГДА.
А как же, например, md5secret ??
Одна сторона «ВСЕГДА» знает — клиент.
Ну например здесь, на Хабре, были подозрения в отношении Zoiper.
А лицензия на представление таких услуг шифрования есть?
А можно узнать — за чей счет банкет? В смысле за счет чего содержание серверов под пуш окупается хотя бы? (сами же пишите что функциональные аналоги — платные)
За наш счет.
Дело в том что этот функционал в мессенджере не основной, а дополнительный, в отличии от аналогов.
Поэтому монетизация планируется на других сервисах.
Например предоставление виртуальных номеров сразу в мессенджере, без заморочек с настройками, через бота, платные звонки на PSTN и GSM и т.д.
Дело в том что этот функционал в мессенджере не основной, а дополнительный, в отличии от аналогов.
Поэтому монетизация планируется на других сервисах.
Например предоставление виртуальных номеров сразу в мессенджере, без заморочек с настройками, через бота, платные звонки на PSTN и GSM и т.д.
Решение напомнило мне одного клиента, который хотел опус для повышения качества голоса. ИЧСХ, он остался уверен, что я его обманывал, объясняя, что в существующей инфраструктуре он получит качество опуса только внутри АТС, при внешних же звонках 100% трафик где-то будет конвертироваться в ИКМ.
В чем смысл этой фичи? С теме провайдерами, у которых нет шифрования, его и не будет, а с теми у кого есть его можно получить и без вас.
В чем смысл этой фичи? С теме провайдерами, у которых нет шифрования, его и не будет, а с теми у кого есть его можно получить и без вас.
В чем смысл этой фичи? С теме провайдерами, у которых нет шифрования, его и не будет, а с теми у кого есть его можно получить и без вас.
Смысл в том что на стороне клиента у вас будет шифрованный трафик.
А также у вас будет работать пуш.
А также не будет детектироваться SIP трафик провайдерами, которые его лочат.
Например актуально в ОАЭ.
Смысл в том что на стороне клиента у вас будет шифрованный трафик.
Вам уже написали, что это должно работать на всей трассе. Это как QoS, поднять его внутри локалки можно, но вот лучше от этого не станет.
А также у вас будет работать пуш.
Оба пункта решаются поиском провайдера, у которого это есть. И поверьте, если задавать такие вопросы своему провайдеру, то шифрование появится. К примеру, я недавно делал интерфейс для включения TLS «одной кнопкой», его можно было и до этого настроить, но нужно было лезть в консоль и добавлять параметры конфигурации вручную. Но появился клиент, которому это важно, решили сделать быструю настройку.
А также не будет детектироваться SIP трафик провайдерами, которые его лочат.VPN в помощь. Получите все кроме пуша. Да и пуш, как я писал выше, можно получить пользуясь правильным провайдером.
Например актуально в ОАЭ.
Короче, в ногу выстрелили разместив этот пост.
Вам уже написали, что это должно работать на всей трассе. Это как QoS, поднять его внутри локалки можно, но вот лучше от этого не станет.
В данном случе лучше станет, не путайте теплое с мягким.
Оба пункта решаются поиском провайдера, у которого это есть.
Да и пуш, как я писал выше, можно получить пользуясь правильным провайдером.
Ну давайте, найдите мне правильно провайдера с пушем :))))))
Один МТТ сейчас, ну вот еще Задарма, но только iOS, еще кто?
Да нет никого практически!
Об этом и речь.
Короче, в ногу выстрелили разместив этот пост.
Вас это сильно беспокоит?
Разместите свой пост, посмеемся.
Ах, у вас НЕТ НИ ОДНОЙ ПУБЛИКАЦИИ?
Тогда что вы там про ногу говорите?
И кстати, википедия меня тоже поддерживает:
«Безопасность соединения
Многие потребительские реализации IP-телефонии не поддерживают криптографическое шифрование, несмотря на то, что наличие безопасного телефонного соединения намного проще внедрить в рамках IP-технологии, чем в традиционных телефонных линиях. В результате, при помощи анализатора трафика относительно несложно установить прослушивание IP-звонков, а при некоторых ухищрениях даже изменить их содержание.[3][4] „
Далее, следите за руками — например произошло чудо и у КАЖДОГО провайдера появился свой SIP клиент с пушем.
Но обычно пользователь пользуется сразу несколькими провадерам — ну вам-то это должно быть известно, вы же специалист, по одной кнопке TLS поднимаете.
Так вот, обычный сценарий пользователя — у него НЕСКОЛЬКО аккаунтов РАЗНЫХ провайдеров.
У одного и того же пользователя (я выше приводил примеры) может быть несколько учеток на одном клиенте в его смартфоне.
Потому что он может:
— работать в офисе и соответственно иметь офисный номер
— иметь номер другого города, тоже по работе, но тот номер не будет подчиняться правилам его внутренней АТС потому что выдан другим провайдером
— иметь учетную запись Задарма, Сипнет и т.д. для звонков своим родственникам, т.е. это уже частное использование
— иметь PSTN номер обычный городской, выданный телекомом по SIPу, что означает тоже частное использование.
А вы значит предлагаете поставить 5-10 приложений от разных провадеров и каждый раз пользоваться РАЗНЫМИ приложениями?
Когда можно их всех уместить в одно?
По моему, вы стреляете себе в гойлову…
В данном случе лучше станет, не путайте теплое с мягким.Ок. Берем участок Клиент <-> Провайдер. То что за провайдером нас не интересует, ибо никак и ничем ни вы ни клиент на это не повлияют.
Было
Клиент < — нешифрованный трафик -> Провайдер
Стало
Клиент < — шифрованный трафик -> ВЫ < — нешифрованный трафик -> Провайдер
В итоге, мы все еще имеем участок с нешифрованным трафиком между клиентом и провайдером, и при это в лице ваших серверов имеем дополнительные точки утечки информации и отказа.
Где стало лучше? Чем, простите меня, это лучше своего VPN пусть даже в том же AWS?
Рассказывайте эти сказки арабам из эмиратов. И даже они с большой вероятностью покрутят пальцем. Я тут недавно пересекался с одни, доказывал, что IP-камеры не будут работать с регистратором по САТ5 кабелю, нужен минимум САТ6.
Ну давайте, найдите мне правильно провайдера с пушем :))))))Ну если вы так считаете — предлагайте им свое В2В решение, на нем вы явно заработаете больше.
Один МТТ сейчас, ну вот еще Задарма, но только iOS, еще кто?
Да нет никого практически!
Об этом и речь.
Вас это сильно беспокоит?Но 15 лет опыта работы в связи. Включая управление отделом связи очень крупной компании с десятизначными оборотами в долларах.
Разместите свой пост, посмеемся.
Ах, у вас НЕТ НИ ОДНОЙ ПУБЛИКАЦИИ?
Тогда что вы там про ногу говорите?
Но обычно пользователь пользуется сразу несколькими провадерам — ну вам-то это должно быть известно, вы же специалист, по одной кнопке TLS поднимаете.Обычно пользователь пользуется одним провайдером. Поскольку затраты на абонентскую плату, поддержку, организацию — стоят дороже сэкономленных копеек. Тем более это ощутимо на западе, где нет такого дикого разброса в тарифах на сетевой и внешний номер. Но не суть.
Кстати, я не хвастался, что поднимаю TLS с закрытыми глазами, а показал вам пример, что такие вопросы — решаемы.
А вы значит предлагаете поставить 5-10 приложений от разных провадеров и каждый раз пользоваться РАЗНЫМИ приложениями?Я ничего не предлагаю, я описал ситуацию выше. Большинство пользователей устраивает один провайдер, а то, что описали вы, — как раз частный граничный случай, и это далеко не массовый рынок и глобальная потребность.
Но 15 лет опыта работы в связи. Включая управление отдела связи очень крупной компании с десятизначными оборотами в долларах.
Слушайте, если бы вы сказали что вы СОЗДАЛИ компанию с «десятизначными оборотами в долларах», это было бы другое дело, я бы внимал каждому вашему слову.
Но вы работаете по найму.
В РФ 80% населения работает по найму во всяких Газмясах с «десятизначными оборотами в долларах» и что из этого следует?
Я так понял, что по теме вы аргументы отметаете, на основании того, что мой опыт с вашей точки зрения не стоит ничего, мне нужно было создать национального оператора, чтобы высказывать обоснованную критику. Ну ок. Удачи.
Нет.
Речь идет о том, что вы, будучи эксплуатационщиком, работая в Газмясе и не создав ни одного продукта и не написав ни одной статьи, обрушиваетесь с критикой на создателей решения, утверждая что это никому не нужно.
Хотя актуальность проблемы подтверждается даже в википедии.
Т.е. судите по своему нерелевантному ни разу опыту.
Речь идет о том, что вы, будучи эксплуатационщиком, работая в Газмясе и не создав ни одного продукта и не написав ни одной статьи, обрушиваетесь с критикой на создателей решения, утверждая что это никому не нужно.
Хотя актуальность проблемы подтверждается даже в википедии.
Т.е. судите по своему нерелевантному ни разу опыту.
Откуда у вас такие выводы о моем опыте?
Вот вам пример. Пару месяцев назад я подключал колцентр для друзей. За пару дней договорился с компаниями в разных странах о трех номерах, и подключил их на облачную АТС одной из этих компаний, с настроенными LCR и принудительными выборами маршрутов. Чем это отличается от вашего решения, если для облачной АТС будет существовать клиент с пушем? Зачем мне отдавать свои данные третьей стороне, которая не будет нести никакой ответственности и поддерживать SLA? Причем, вы упорото доказываете, что повышаете безопасность, хотя на самом деле только снижаете ее и надежность заодно. Если бы вы не защищали свой продукт, я бы подумал, что вы это сами не понимаете.
Вот вам пример. Пару месяцев назад я подключал колцентр для друзей. За пару дней договорился с компаниями в разных странах о трех номерах, и подключил их на облачную АТС одной из этих компаний, с настроенными LCR и принудительными выборами маршрутов. Чем это отличается от вашего решения, если для облачной АТС будет существовать клиент с пушем? Зачем мне отдавать свои данные третьей стороне, которая не будет нести никакой ответственности и поддерживать SLA? Причем, вы упорото доказываете, что повышаете безопасность, хотя на самом деле только снижаете ее и надежность заодно. Если бы вы не защищали свой продукт, я бы подумал, что вы это сами не понимаете.
В коллцентре не нужен пуш от слова совсем.
Вы сравниваете теплое с мягким.
Наше решение для малого бизнеса и частного использования, т.е. для людей, которые не в Газмясе работают.
И какие пару дней? Это все здесь описали, делается для частника за 5 минут онлайн.
Вы сравниваете теплое с мягким.
Наше решение для малого бизнеса и частного использования, т.е. для людей, которые не в Газмясе работают.
И какие пару дней? Это все здесь описали, делается для частника за 5 минут онлайн.
Во-первых, читайте внимательно. Какая разница, если облачная АТС умеет делать пуш?
Во-вторых, ваше постоянное упоминание сферического Газмяса в вакууме показывает только вашу же недалекость в плане понимания как работает крупный крупный бизнес. И далеко не факт, что вы вообще понимаете как работает бизнес.
Во-вторых, ваше постоянное упоминание сферического Газмяса в вакууме показывает только вашу же недалекость в плане понимания как работает крупный крупный бизнес. И далеко не факт, что вы вообще понимаете как работает бизнес.
мимо
Основная проблема вот в чем.
Даже для ОТКРЫТОГО варианта SIP протокола бесплатных codebase мессенджеров без глюков вообще говоря, нет.
Если мы(ну или другая команда) теперь берем какой из них и начинаем делать «шифрование» или там «блокчейн звонков » или еще чтото, то получается что мы к существующим багам(берется, обычно, linphone) добавляем свои.
Становится совсем весело.
А существующие стабильные мессенджеры(xlite, zoiper etc) не деляться своим кодом под такие проекты. Наверно, представляют последствие.
В результате на данный момент стабильная комбинация — только с использованием openvpn туннеля.
Шифрование не end-to-end, имхо, бессмысленно чуть менее чем полностью. Есть смысл только в том, что некоторые за него платят.
Даже для ОТКРЫТОГО варианта SIP протокола бесплатных codebase мессенджеров без глюков вообще говоря, нет.
Если мы(ну или другая команда) теперь берем какой из них и начинаем делать «шифрование» или там «блокчейн звонков » или еще чтото, то получается что мы к существующим багам(берется, обычно, linphone) добавляем свои.
Становится совсем весело.
А существующие стабильные мессенджеры(xlite, zoiper etc) не деляться своим кодом под такие проекты. Наверно, представляют последствие.
В результате на данный момент стабильная комбинация — только с использованием openvpn туннеля.
Шифрование не end-to-end, имхо, бессмысленно чуть менее чем полностью. Есть смысл только в том, что некоторые за него платят.
Недавно смотрел. Вроде есть платные стеки для мобильных платформ, тот же zoiper. На них все также плохо?
На мобильных вообще все плохо. Только начали критичные баги фиксить в последний год-два.
На пк было плохо лет 10, вот лет 5 как побороли болячки в ПЛАТНЫХ стеках, в бесплатных все плохо.
Вопрос в том, что мессенджеры как в статье это обычно бесплатный стек(если бы был платный, они бы были обязаны про его использование сообщить) + как видим нет специалиста по безопасности(ну как можно говорить про шифрование, если траффик идет через некий сервер некой компании и там шифруется, никаких данных про аудит нет).
Андроидовский пуш тоже та еще штучка, я писал пуш-сервер для kamailio. Работает только там, где все идеально — в центре городов в основном. Ничего не гарантируется.
На пк было плохо лет 10, вот лет 5 как побороли болячки в ПЛАТНЫХ стеках, в бесплатных все плохо.
Вопрос в том, что мессенджеры как в статье это обычно бесплатный стек(если бы был платный, они бы были обязаны про его использование сообщить) + как видим нет специалиста по безопасности(ну как можно говорить про шифрование, если траффик идет через некий сервер некой компании и там шифруется, никаких данных про аудит нет).
Андроидовский пуш тоже та еще штучка, я писал пуш-сервер для kamailio. Работает только там, где все идеально — в центре городов в основном. Ничего не гарантируется.
На пк было плохо лет 10, вот лет 5 как побороли болячки в ПЛАТНЫХ стеках, в бесплатных все плохо.
А Sofia? Вроде более-менее нормально все у нее было, не?
Хотя мне бы очень хотелось увидеть еще и нормальный (не на Java!) open-source SIGTRAN-стек. Но чота их не видать, хоть сам собирайся с силами и пили. Хотя я знаю, почему их не видать — это сугубо операторское решение, они за деньги покупают.
Андроидовский пуш тоже та еще штучка, я писал пуш-сервер для kamailio.
Ну строго говоря, «пуш» — это вроде маркетинговое название чисто эппловской технологии, у гугла оно называется GCM, или я что-то недопонял. Но суть та же, да. А вот про сервер для Kamailio интересно, деталями не поделитесь ли?
Естественно, там NDA. Могу только сказать, что kamailio очень плохо реагирует на любые блокирующие вызовы и их необходимо делать через локальный проксирующий сервер. А гугл не гарантирует ответ на сам api в realtime(ну в realtime c точки зрения kamailio, для которого норма 5к сообщений в секунду).
Естественно, там NDA
А. Ну тогда ой. Моя NDA тоже еще очень не скоро кончится, так что понимаю :)
kamailio, для которого норма 5к сообщений в секунду
Kamailio хорошая молотилка, да. Немного больная на голову, но хорошая.
p.s. а про софию-то?
Я с другой стороны работаю, с серверной частью.
Смотря с чем сравнивать. Если с linphone — то все прекрасно.
А так вон даже pjsip в астериске уже несколько лет фиксят, а он так и повисает под нагрузкой. А PJSIP считался самым стабильным.
Хотя с другой стороны — то, что стек вешается на 100500м сообщение вообще побоку для клиентском сборки. Там просто столько не будет.
Смотря с чем сравнивать. Если с linphone — то все прекрасно.
А так вон даже pjsip в астериске уже несколько лет фиксят, а он так и повисает под нагрузкой. А PJSIP считался самым стабильным.
Хотя с другой стороны — то, что стек вешается на 100500м сообщение вообще побоку для клиентском сборки. Там просто столько не будет.
Я с другой стороны работаю, с серверной частью.
Так Sofia как раз серверная же часть… SIP-часть FreeSWITCH на ней сделана.
А так вон даже pjsip в астериске уже несколько лет фиксят,
Не люблю астериск уже много-много лет.
Не то, чтобы не люблю FS. Просто как-то нет особых преимуществ перед правильно приготовленным астериском. Все, что декларируется — не совсем правда. Чето они перемудрили.
Ну FS не виснет. Вроде. Если cps < 50.
Просто то, что оно хорошо работает в linux не значит, что в андроиде работает. Очень уж там кастрировано все.
Ну FS не виснет. Вроде. Если cps < 50.
Просто то, что оно хорошо работает в linux не значит, что в андроиде работает. Очень уж там кастрировано все.
Ну, в своей нише FS хорош. Хотя я как клиент на андроиде его не заводил, только как сервер на линуксе было, да. Ну и модульность его доставляет, точно так же, как и xml конфиги :)
Незнаю. Астериск вон тоже модульный.
После появления timerfd и нового rtp стека fs както вобще не выдается по производительности.
Тут ведь в чем вопрос. Все решения, которые под OSS быстро кочуют из одного проекта в другой(я вон недавно переносил из FS детект из mod_amdv). А у FS меньше база тестируемая, сильно меньше количество пользователй. Из чего вылезают недостатки.
xml конфиги, имхо, зло. Фигня это когда один символ в конфиге делает productional сервер неработоспособным полностью.
После появления timerfd и нового rtp стека fs както вобще не выдается по производительности.
Тут ведь в чем вопрос. Все решения, которые под OSS быстро кочуют из одного проекта в другой(я вон недавно переносил из FS детект из mod_amdv). А у FS меньше база тестируемая, сильно меньше количество пользователй. Из чего вылезают недостатки.
xml конфиги, имхо, зло. Фигня это когда один символ в конфиге делает productional сервер неработоспособным полностью.
Незнаю. Астериск вон тоже модульный.
А ему уже можно безболезненно оторвать SIP-стек, например?
Фигня это когда один символ в конфиге делает productional сервер неработоспособным полностью.
Он же валидируется при reloadxml и выдает ошибку, если что. Но это субъективщина, признаю — я просто люблю xml :)
А ему уже можно безболезненно оторвать SIP-стек, например?А выгрузить? Не то?
Не «выгрузить», а в принципе «не загружать»? Я давно не смотрел на Астериск, не знаю, умеет он такое или нет?
Он всегда умел.
Более того, в данный момент у него ДВА сип стека.
Смотрите modules.conf
Я ж говорю, все в рекламе FS не соответсвует действительности, когда идет разговор о астериске. Просто вот такой подход к делу.
Даже производительность, в общем, не отличается(просто FS все опции включены на fast а в астериске — на compatible).
Более того, в данный момент у него ДВА сип стека.
Смотрите modules.conf
Я ж говорю, все в рекламе FS не соответсвует действительности, когда идет разговор о астериске. Просто вот такой подход к делу.
Даже производительность, в общем, не отличается(просто FS все опции включены на fast а в астериске — на compatible).
Ну да, я не зря сказал, что давно на * не смотрел. Спасибо за инфу.
Да ладно. modules.conf было раньше версии 0.88. Это 15+лет.
Модульность FS состояло в том, что там SIP stack был разделен с rtp и с дополнительными функциями типа presense. В астериске с 11й версии — тоже так. PJSIP вообще сплошной набор хаков и хуков.
Модульность FS состояло в том, что там SIP stack был разделен с rtp и с дополнительными функциями типа presense. В астериске с 11й версии — тоже так. PJSIP вообще сплошной набор хаков и хуков.
Модульность FS состояло в том, что там SIP stack был разделен с rtp и с дополнительными функциями типа presense.
Ну там они вообще все делили, что могли, на разные модули, имхо.
PJSIP вообще сплошной набор хаков и хуков.
А какой лучше, кстати? Старый или таки новый?
Новый быстрее.
Если надо чегото добавить — в новый проще(старый пипец какая мешанина на данном этапе).
Новый модульный(разбит на 10+ модулей).
Вот только есть небольшая засада. С тех пор как в вели раз в полгода я играю в игру «найди и зарепорть баг в chan_pjsip». Пока всегда заканчивалося возвратом на chan_sip. Просто виснит, зараза, под нагрузкой. А запустить в дебагере ту же нагрузку пока не получалося(не хватает мощности).
Трачу пару дней, иногда чегото нахожу, иногда нет. На этом все заканчивается.
Та же самая фигня с app_conference, кстати. Тоже лучше, быстрее, но виснит под нагрузкой(если 200+ конференций, то гдето за полдня виснет).
Если надо чегото добавить — в новый проще(старый пипец какая мешанина на данном этапе).
Новый модульный(разбит на 10+ модулей).
Вот только есть небольшая засада. С тех пор как в вели раз в полгода я играю в игру «найди и зарепорть баг в chan_pjsip». Пока всегда заканчивалося возвратом на chan_sip. Просто виснит, зараза, под нагрузкой. А запустить в дебагере ту же нагрузку пока не получалося(не хватает мощности).
Трачу пару дней, иногда чегото нахожу, иногда нет. На этом все заканчивается.
Та же самая фигня с app_conference, кстати. Тоже лучше, быстрее, но виснит под нагрузкой(если 200+ конференций, то гдето за полдня виснет).
А на каких объемах зависает? У меня сейчас в разработке 15 стоит с pjsip он немного проще работает с доменами, что решает некоторые вопросы. Собственно пока из-за этого я его выбрал.
При cps 50 гдето раз в день +-
При cps выше 50 может и за час-два.
Само хреново, что он об этом не пишет. Все каналы остаются, просто перестает принимать invite
chan_sip работает месяцами с теми же нагрузками.
При cps выше 50 может и за час-два.
Само хреново, что он об этом не пишет. Все каналы остаются, просто перестает принимать invite
chan_sip работает месяцами с теми же нагрузками.
Тля. Могу только надеяться, что у меня таких нагрузок не будет.
Кстати, app_conference и без особых нагрузок. У меня был билд на котором частенько зависали каналы на конфернции.
Кстати, app_conference и без особых нагрузок. У меня был билд на котором частенько зависали каналы на конфернции.
Вы то можете надеятся, а вот мамкины хакеры с sipsak могут с вами не согласится.
У меня сейчас все только набирает обороты. Не поздно спрыгнуть, можно даже два стека будет сразу делать.
Но за инфу спасибо в любом случае.
Но за инфу спасибо в любом случае.
Но за инфу спасибо в любом случае.
Плюсану, этот вечерний тред внезапно интересный :)
Ну freepbx же его основным поставило. Значит не все так плохо. Просто у меня в последнем проекте, например, расчетный cps — 100 с сервера.
Fail2ban и firewalld с ipset + правилами от основных brootforce tools не забывайте.
Fail2ban и firewalld с ipset + правилами от основных brootforce tools не забывайте.
Меня если честно бесит невозможность нормально реализовать план набора по условию. Они в документации даже пишут «может оно вам не надо, может лучше curl?».
«план набора по условию»?
кондиционный роутинг, простой gotoif как в астериске.
Ну либо я туплю, либо одно из двух. Там же есть conditions в диалплане, можно передавать звонок из контекста в контекст на основании этих условий.
p.s. а мы про FS или про * ???
p.s. а мы про FS или про * ???
Лучше odbc или fastagi. Сurl очень долго.
Если вам нужны сложные условия — запускайте внешний сервер условий(привет микросервисы). Свич не должен этим заниматься.
Но вообще говоря с помощью правильно составленного диалплана И подготовки секций диалплана внешним скриптом реализуются практически любые условия(dialplan — полная грамматика).
Если вам нужны сложные условия — запускайте внешний сервер условий(привет микросервисы). Свич не должен этим заниматься.
Но вообще говоря с помощью правильно составленного диалплана И подготовки секций диалплана внешним скриптом реализуются практически любые условия(dialplan — полная грамматика).
Я решил и дальше использовать астериск. FS только на факссервере, у него немного выше success rate на приеме.
А в уже готовой АТС(тоже *) я пытался как можно меньше использовать realtime. У меня статический конфиг генерируется. Раньше тянул из базы но потом понял, что смысла на single tenant нет и перешел на curl.
А в уже готовой АТС(тоже *) я пытался как можно меньше использовать realtime. У меня статический конфиг генерируется. Раньше тянул из базы но потом понял, что смысла на single tenant нет и перешел на curl.
В realtime dialplan — нет смысла. func_odbc + func_realtime очень удобно и закрывает почти все кейсы. curl это оверхед значительный. Если вы чтото не можете получить через func_odbc, то лучше делайте fastagi сервис «уточнений», там все проще значительно.
dialplan у меня realtime static, просто работает через res_curl драйвер. Это намного проще реализовать, чем писать семистраничные вьюхи в базе или перезаписывать базу на каждый чих. Перезагружается он не так часто, поэтому я считаю этот момент не критичным.
А вот с multitenant придется больше уходить в func_odbc и fastagi для ловли ивентов.
А вот с multitenant придется больше уходить в func_odbc и fastagi для ловли ивентов.
Не вижу преимуществ у такого подхода.
Если база падает — то все перестает работать. Если генерить файлики, то хоть сообщит о том, что база упала и базовые вещи будут работать.
Если база падает — то все перестает работать. Если генерить файлики, то хоть сообщит о том, что база упала и базовые вещи будут работать.
У меня не свитч, а — АТС. C кучей сервисов. Если у меня упадет база — упадет все.
Ну если вы не делаете разницы между «извините, у вас проблема с АТС, обратитесь к администратору» и отбоем в трубке, то да, пофигу.
Я лично считаю, что как минимум АТС должна позволить позвонить администратору когда случайно место закончилося(самый частый кейс в поддержке freepbx, кстати).
Я лично считаю, что как минимум АТС должна позволить позвонить администратору когда случайно место закончилося(самый частый кейс в поддержке freepbx, кстати).
Олдовые железные АТСы умели при полном пропадании питания напрямую коммутировать СО на определенный ext, чтобы хотя бы какая-нибудь связь оставалась :)
Это реализуется второй регистрацией на телефоне секретаря или девайсами вида fxo+fxs(они тоже замыкают линию). Вопрос только в том, что в современных офисах вообще уже не ставят железных линий… Все по SIP.
fxo+fxs
Ох. Одно время было модно при помощи такой вот схемы порт у той же АТС «удлинять».
Вопрос только в том, что в современных офисах вообще уже не ставят железных линий… Все по SIP.
Да ну фиг его знает, есть же всякие IP-АТС с возможностью подключения аналогов. Один хрен, аналоговый телефон намного дешевле воипного просто by design. Так что я думаю все же где-то есть.
А еще есть (мало, но есть!) обычная домашняя двухпроводная телефония, там же тоже не SIP. Но это не офис, да.
Ок. Работал когда-то в энтерпрайзе. Стояли у нам меридианы, один первый и несколько 61 и 81 опций. На них висело порядка 2к пользователей. Менять их тогда, в кризис/стогнацию, никто не собирался. Но уже тогда я забанил закупку аппаратов. И новые ставили IP. Даже телефон за 100-120 долларов окупался сразу(а можно было взять и за 60), если была необходимость в прокладке новой линии под аналог.
При подключении малого офиса с большой вероятность дешевле будет поставить маленький девайс и все ip-телефоны чем подключать линии, ставить какой-нить panasonic и т.д. Да и абонплата скорее всего будет ниже в итоге.
При подключении малого офиса с большой вероятность дешевле будет поставить маленький девайс и все ip-телефоны чем подключать линии, ставить какой-нить panasonic и т.д. Да и абонплата скорее всего будет ниже в итоге.
Стояли у нам меридианы, один первый и несколько 61 и 81 опций.
Меридиан хорошая штука. Может, получится купить в коллекцию хотя бы 11ю опцию. Посматриваю на Авито временами, но чот люди не хотят понимать, что то железо, за которое они заплатили 15 лет назад стопицот денег, сейчас не стоит почти ничего.
Даже телефон за 100-120 долларов окупался сразу(а можно было взять и за 60), если была необходимость в прокладке новой линии под аналог.
Да разве ж я спорю, что IP удобнее? :)
Это можно реализовать в плане набора и с базой. Я к тому, что при падении базы у меня слетит вся логика.
Место у меня контролируется, чиститься, и постоянно высылаются предупреждения — у заказчика до этого все клиента на freepbx висели)
Место у меня контролируется, чиститься, и постоянно высылаются предупреждения — у заказчика до этого все клиента на freepbx висели)
Я думаю имелось ввиду sofia на linux в сборке FS и sofia как библиотека для мобильного приложения.
Asterisk интересней юзать как медиасервер. А за проксей уже проще будет контролировать нагрузку. Все равно больше ресурсов сожрут медиа и приложения чем сигнализация.
А так-то да. Чем больше читаешь, тем больше видишь, что люди, которые когда-то говорили что sip proxy + media server — это круто, сейчас пишут, что для серьезных задач проприетарное решение — лучший выбор.
А так-то да. Чем больше читаешь, тем больше видишь, что люди, которые когда-то говорили что sip proxy + media server — это круто, сейчас пишут, что для серьезных задач проприетарное решение — лучший выбор.
Для серьезных нагрузок(реально серьезных) — надо использовать чистый прокси(kamailio/opensips) в два-три эшелона(первый выдает только SIP Redirect).
И проприетарные так делают(причем очень много из софтовых используют openser проект).
А для средних — правильно написанный диалплан дает до 2к звонков на современном сервере, запустить 10 серверов в кластере — вообще не вопрос в современном мире.
И проприетарные так делают(причем очень много из софтовых используют openser проект).
А для средних — правильно написанный диалплан дает до 2к звонков на современном сервере, запустить 10 серверов в кластере — вообще не вопрос в современном мире.
В том-то и дело, что почитывая последние каменты и userlist натолкнулся на мнение, что, когда важно скрыть топологию, все становиться грустно, якобы с включенным topoh расхождение в детализации в 10 тысяч минут.
Я пока сам ищу, что поставить. Судя по всему, придется делать в два уровня proxy+lb — proxy+registrar/sbc — media. Хотя с другой стороны — overhead.
Я пока сам ищу, что поставить. Судя по всему, придется делать в два уровня proxy+lb — proxy+registrar/sbc — media. Хотя с другой стороны — overhead.
правильно написанный диалплан дает до 2к звонков на современном сервереУ меня при такой нагрузке все упрется в приложения.
Ставьте balancer-> proxy/regsitrar->topoh(если уж он вам нужен)-> исходящую цепочку.
На overhead в случае kamailio/opensips — забейте. Основной overhead — хранение и доступ к данным(db, htable, nosql etc). Сам свич практически всегда не является бутылочным горлышком. Главное, не делайте из него блокируемых вызовов(включая долгие sql запросы) и кешируйте в памяти все что можно.
На overhead в случае kamailio/opensips — забейте. Основной overhead — хранение и доступ к данным(db, htable, nosql etc). Сам свич практически всегда не является бутылочным горлышком. Главное, не делайте из него блокируемых вызовов(включая долгие sql запросы) и кешируйте в памяти все что можно.
Я к тому, что архитектура получается на первый взгляд избыточна. Кроме того конфиг уж очень разрастается.
В любом случае, не простые несколько месяцев предстоят.
В любом случае, не простые несколько месяцев предстоят.
Ну конфиг balancer помещается на один экран.
Без балансера что-то крупнее чем на 1000 пользователей лучше не делать. Когда есть балансер всегда можно простым движением повыключать сервера или переключить версии, а без него — грусть-печаль.
Без балансера что-то крупнее чем на 1000 пользователей лучше не делать. Когда есть балансер всегда можно простым движением повыключать сервера или переключить версии, а без него — грусть-печаль.
Вот тут вы мне показали еще один плюс за балансер лицом в мир. Но нужно покурить еще, может можно будет по старинке master/slave для proxy-registrar.
Balancer должен быть совсем тупой и быстрый. Можно прокси запустить там же и даже в том же конфиге на другом порту. Главное, чтоб был балансер. Это самый простой путь получить scale/HA.
Нужно доки почитать, я пока не уверен на счет того, как мне реализовать трафик от медисерверов в сторону кластера проксей.
Если провайдер не умеет слать на другой адрес медиа(таких щас мало) — то rtproxy на основном адресе. Но управлять ей тоже должен прокси второго уровня.
Множественные rtpproxy ставятся на один адрес с использованием обычно iptables NAT. На разных портах.
Множественные rtpproxy ставятся на один адрес с использованием обычно iptables NAT. На разных портах.
Я не особо вижу смысла ставить несколько rtpproxy/engine на одном хосте.
rtpproxy не сильно быстрая вещь. Не сильно быстрее астериска. Если обьемы больше нескольких сотен каналов, то их таки надо несколько. Не обязательно на одном хосте, вы их можете поставить на другом на сером адресе, выполнить роутинг через основной сервер и на нем поднять ipnat(который ест ресурсов сильно меньше rtprpoxy).
Вариантов много.
Вот на вас ведется атака. Ну ок, подымаете еще 20 серверов, которые умеют pike и ждете.
Или у вас упал регион амазон, как в прошлом году было.
Вы переписываете ОДИН адрес у всех провайдеров и продолжаете работу.
Или вы получили неработающий билд на production. Перекидываете на бекап сервер и спокойно ищите проблему.
Balancer должен уметь одну вещь — по статическому листу отправлять на вторую линию, все.
Вот на вас ведется атака. Ну ок, подымаете еще 20 серверов, которые умеют pike и ждете.
Или у вас упал регион амазон, как в прошлом году было.
Вы переписываете ОДИН адрес у всех провайдеров и продолжаете работу.
Или вы получили неработающий билд на production. Перекидываете на бекап сервер и спокойно ищите проблему.
Balancer должен уметь одну вещь — по статическому листу отправлять на вторую линию, все.
У нас нет задачи делать шифрование в режиме клиента к любому серверу, именно потому что он может быть любым и мы не трогаем уже сложившуюся инфраструктуру — какой смысл навязывать свой сервер туда куда его никогда не поставят?
У нас-то есть свой сервер с шифрованием, а вся фишка в том что мы не меняем сервер у другой стороны.
А так-то — включаете в мессенджере режим транка и если другой сервер поддерживает стандартное TLS шифрование — включайте и все работает, но это будет транк, а не клиент.
А просто решение — связка сервер — клиенты под андроидом и iOS — это все работает у нас со стандартным TLS шифрованием, это вообще не вопрос.
Но идея-то не в этом, а в том чтобы уже работающий сервер без шифрования оставить.
С андроидовским пушем проблем нет.
У нас-то есть свой сервер с шифрованием, а вся фишка в том что мы не меняем сервер у другой стороны.
А так-то — включаете в мессенджере режим транка и если другой сервер поддерживает стандартное TLS шифрование — включайте и все работает, но это будет транк, а не клиент.
А просто решение — связка сервер — клиенты под андроидом и iOS — это все работает у нас со стандартным TLS шифрованием, это вообще не вопрос.
Но идея-то не в этом, а в том чтобы уже работающий сервер без шифрования оставить.
С андроидовским пушем проблем нет.
Я какбы не сомневался, что вы так гдето и ответите.
Тоесть доставка пуша за 30+ секунд в 20-30% случаев — не есть проблема, да? Ну ок.
Тоесть доставка пуша за 30+ секунд в 20-30% случаев — не есть проблема, да? Ну ок.
Что вы имеете ввиду под временем доставки пуша?
Есть обычный пуш, для сообщений, а есть звонковый, который «будит» заснувшее приложение и после того как оно проснулось, идет уже звонок, вы какое время имеете ввиду?
До момента получения сообщения или до момента когда сообщение пришло, разбудило приложение, приложение запустилось и потом начало звонить, т.е. непосредственно до самого звонка?
Есть обычный пуш, для сообщений, а есть звонковый, который «будит» заснувшее приложение и после того как оно проснулось, идет уже звонок, вы какое время имеете ввиду?
До момента получения сообщения или до момента когда сообщение пришло, разбудило приложение, приложение запустилось и потом начало звонить, т.е. непосредственно до самого звонка?
Хорошо что есть такие разработки делающие наш мир безопаснее, только остается один вопрос зачем оно Вам, какую цель вы преследуете если не коммерческую? Кроме того обнаружилась некая особенность, что не всегда к вам из РФ пробиться можно, вероятно в этом виноват РКН (попробуем это исправить), а VPN прибавят RTT, да даже без VPN к вам 130 мс от М9. Складывается впечатление, что продуктом будет проблематично пользоваться на территории РФ.
А в идеале конечно лучше не пользоваться всякими Задармами и прочими SIP провайдерами, так как любой ваш разговор «оседает» там через кого прошел, и восстанавливается даже средствами Wireshark за пару-тройку кликов. Задарма, например не соединяют абонента А и Б напрямую (по внутренней нумерации), даже если у них реальные IP адреса, а не NAT как обычно. Поэтому если хотите настоящей безопасности — только хардкор, только свои сервера и свое шифровальное оборудование, и желательно русское типа Застава, Кольчуга, ЗАЗ, а в качестве VoIP оборудования за всеми этими АПК, например что-нибудь из линейки BroadWorks, ИМХО конечно.
А в идеале конечно лучше не пользоваться всякими Задармами и прочими SIP провайдерами, так как любой ваш разговор «оседает» там через кого прошел, и восстанавливается даже средствами Wireshark за пару-тройку кликов. Задарма, например не соединяют абонента А и Б напрямую (по внутренней нумерации), даже если у них реальные IP адреса, а не NAT как обычно. Поэтому если хотите настоящей безопасности — только хардкор, только свои сервера и свое шифровальное оборудование, и желательно русское типа Застава, Кольчуга, ЗАЗ, а в качестве VoIP оборудования за всеми этими АПК, например что-нибудь из линейки BroadWorks, ИМХО конечно.
Многие потребительские реализации IP-телефонии не поддерживают криптографическое шифрование
Оно еще какое-то другое бывает?
Sign up to leave a comment.
Добавляем шифрование и push в обычный SIP