И опять статью маркетолог писал… ну что-же… в первой части вы описывали некую цифровую утопию, от который всем станет хорошо… а на деле представили очередной telegramm/whatsapp/etc… Коммикс про 14 стандартов уже кидали.
Вопросов четыре:
1. Что с клиентами под десктоп, чую что будет electron+js поделка очередная
2. И всетаки все централизовано, никакого p2p и сообщения между пользователями проходят через сервер, кстати про e2e шифрование в статье вроде ни слова.
3. Вы писали про проблему перенасыщения рынка различными im и преподносили свой продукт как серебряную пулю и что в итоге? Интегрировали sip и все? Ребят...«бизнес» умеет пользоваться sip и настраивать АТС, а для глупого «бизнеса» есть различные облачные АТС и пр. решения.
4. Для кого этот продукт? Хомячки(говорю про РФ) давно и плотно подсели на «большую тройку» im именно из-за привязки к телефонному номеру и отсутствия необходимости запоминать id/логины, они просто видят что человек из их адресной книги теперь доступен и могут писать/звонить ему. Для гиков/криптоанархистов/параноиков есть более интересные p2p решения и ваш централизованный продукт(в который еще и бот от amazon встроен, от того самого amazon чья «умная колонка» спалилась на записи всего что происходит вокруг) им явно будет не интересен.
И да, если вы пишите вторую часть… то оставьте только техническую часть, читать маркетинговую муть очень тяжело и думаю не только мне(по крайней мере на этом ресурсе).
Ну понял вы разрабатываете не im, а сервис которые имеет регистрацию во всех im и проксирует запросы от одного к другому, тоесть что-бы пользователь vasy@viber мог дозвониться до dima@telegram без установки нового для себя im. Ну ок, идея интересная, о необходимости такого много кто ныл на форумах. А что с технической частью, не думаю что вам удастся договориться владельцами всех(или большинства) im дать доступ для вашего проксирования, будете заводить «фантомные» аккаунты?
В нашем мессенджере под созданным логином можно подключить неограниченное количество VOIP линий и завести их на уже существующие, купленные бизнесом ранее, транки АТС и обрабатывать их в соответствии со сложившимся алгоритмом.
>Реалтайм — практически невозможно.
Как активный пользователь tox позволю не согласиться, с реалтаймом все прекрасно(да могут быть подвисания, но это уже от качества канала зависит). даже если оба клиента находятся за nat.
Тоесть очередной централизованный im с транспортами к другим сервисам?
Кстати, а почему SIP, по опыту работы с ip-телефонией он не очень хорош в 2 отношениях: прохождение NAT и шифрование(приходится отдельно шифровать sip и rtp трафик).
Честно, пытался прочитать вашу маркетинговую мешанину, но терпения не хватило. Ответьте на главный вопрос: Вы собираетесь делать очередной централизованный im или всетаки p2p решение?
Вопросов четыре:
1. Что с клиентами под десктоп, чую что будет electron+js поделка очередная
2. И всетаки все централизовано, никакого p2p и сообщения между пользователями проходят через сервер, кстати про e2e шифрование в статье вроде ни слова.
3. Вы писали про проблему перенасыщения рынка различными im и преподносили свой продукт как серебряную пулю и что в итоге? Интегрировали sip и все? Ребят...«бизнес» умеет пользоваться sip и настраивать АТС, а для глупого «бизнеса» есть различные облачные АТС и пр. решения.
4. Для кого этот продукт? Хомячки(говорю про РФ) давно и плотно подсели на «большую тройку» im именно из-за привязки к телефонному номеру и отсутствия необходимости запоминать id/логины, они просто видят что человек из их адресной книги теперь доступен и могут писать/звонить ему. Для гиков/криптоанархистов/параноиков есть более интересные p2p решения и ваш централизованный продукт(в который еще и бот от amazon встроен, от того самого amazon чья «умная колонка» спалилась на записи всего что происходит вокруг) им явно будет не интересен.
А все отбой, ничего интересного.
Как активный пользователь tox позволю не согласиться, с реалтаймом все прекрасно(да могут быть подвисания, но это уже от качества канала зависит). даже если оба клиента находятся за nat.
Кстати, а почему SIP, по опыту работы с ip-телефонией он не очень хорош в 2 отношениях: прохождение NAT и шифрование(приходится отдельно шифровать sip и rtp трафик).