Вопрос вообще ставить нужно иначе: какова поддержка уже существующих программных продуктов?
Понятно, что "пока его нет, ни кто и не поддерживает", но, с другой стороны, если я работаю с AI мне нужны текущие устоявшиеся аппаратные ресурсы.
Суда по ушам, торчащим в статье, речь идёт, в основном, о свистелках вроде "улучшения видеопотока" или "чат ассистента".
По хорошему, нужно разбираться что же там встроено, какие есть средства работы с этим и что оно может, по сравнению, скажем, с ПК на котором стоит хотя бы A4500 от Nvidia.
Проект отличный, но в настоящее время применений не имеет.
Такие системы хороши в опасных для человека местах, хороши для выполнения рутинных операций, где антропоморфность играет роль, интересны в целом как движение вперёд.
Просто сегодня нет применения: в большинстве случаев удобнее использовать специализированный инструмент, скорость работы или автономность "ещё не та", а говоря про, скажем, радиоактивные или химически опасные зоны - электроника не вытягивает.
То, что проект не помрёт - сомнений нет, но он будет жить в других видах и функциях.
Вообще я борьба с ветряными мельницами - дело такое. Этот сервис монетизации подвергается слабо - или мы продаем данные пользователей или мы продаем подписку.
При том, что сам вендор активно "не хочет" такого сопряжения, я бы надавил "общественностью" на открытие gateway API. Это бы позволило встраивать сервис нативно. В текущем же варианте, я бы держался от этого всего за пару км. Утечки через такие прокси - явление постоянное.
Есть Е2Е шифрование. Мы или реализуем передачу нерасшифрованного сообщения до нашего приложения и расшифровываем его там, или вынуждены перешифровывать сообщение на нашем гейтвее.
Если реализуется последнее, а судя по тексту, это именно так, то таким сервисом пользовать не стоит от слова совсем.
iMessage оно не столько про сообщения, сколько про экосистему. Если нет интеграции с экосистемой Google и ее партнёров, таких как Samsung/Xiaomi и так далее, ценность такого приложения резко падает.
Не поймите превратно - гейтвей это хорошо, но не так, как это описано у этих товарищей .
На самом деле, я почти отказался от SipMessage. Найти андроид клиент, который бы не зависимо о пущей или настроить эти самые пуш - сложнее, чем слать смс в виде письма.
Есть производители оборудования. Модемы, телефоны, станки, буровые - много-много всего.
Их нужно как-то в сети идентифицировать, понять что это за абонент, вообще наш он или нет?
Эта информация, по мимо ещё некоторых настроек и пишется в "sim".
Если, как раньше, дать вам возможность копировать это все хозяйство, то сеть становится "совсем уже интернет" - у вас будут коллизии, когда 2 и более одинаковых абонента одновременно в сети, когда вы не можете доверять номеру звонящего и так далее по нарастающей.
Собственно, дело даже не в том, что люди абьюзили и "говорили за счёт других", а в том, что оператор теряет контроль над своей сетью. И законодатели, которые четко следят за сетями связи такое не одобряют.
Отсюда и идут все эти шифрованные карты, огораживание и закрытость для простого смертного стандарта.
Вы спросите, ну вот есть же интернет... Есть. Вы готовы обеспечить 100%ю совместимость во всех сетях ретроспективно по разном уровне ПО, типах шифрования и так далее?
По этому, если уже выпущен стандарт, то там ничего не поменять "патчами". Вы не можете "пушнуть обнову" чисто по своему желанию - это привет из старых времён. И базовая станция не умеет так работать. Понятно, что сегодня, когда "все VoIP" это выглядит странно, но мне это нравится. Хотя бы с этой стороны к вам в оборудование никто не лезет.
Как я понимаю мой случай, если я использую soft phone, делая вызов через sip в сторону гейтвея с gsm модемом, канал local существует до момента ответа гейтвея. Далее он "оптимизируется" из контекста, оставляя прямой канал между приложением и гейтвеем.
В случае без iax, происходит 2 sip вызова, образуется 2 local канала, оба из которых "оптимизируются".
В случае с iax, по сути, так же.
Джиттер применяется на iax "ногу" вызова. Если вы можете прокомментировать ситуацию - буду благодарен.
Джиттер в SIP, как я понял, настраивается а диалплане и требует компиляции Астерикса с его поддержкой (может оно и по дефолта там, но не уверен).
Смена кодека... возможно, если клиенты начали с opus. Оно перекодирует его в uLaw.
В моем случае, я добился большей пропускной способности и меньшего количества соединений через не самый стабильный туннель при передаче голоса. Нет отдельного rtp + sip.
Интересно, какие ещё параметры не передаются в IAX2?
Я ни коем разом не считаю себя спецом по VoIP & Asterisk. Это, скорее, заметки на полях и плод моего обобщения.
Мне проще кидать звонки/сообщения траншами, так как я сразу передаю/получаю информацию о CallerID. Возможно, в "разорванной" схеме можно придумать как это передавать, но получится сложнее кмк.
Вот в такой конструкции можно ловить запросы по конкретному IP. Добавьте туда "port" и получится нужная связка.
Другое дело, что если применять sockstun или его аналоги (tun2socks) то получаетя некая петля, когда пакеты не понимают куда им деваться (мы же шлем их на адрес интерфейса tunX и его же указываем в "ip" ). Как эту петлю побороть я не придумал, но это решается виртуальными адресами на любом другом интерфейсе. И все - вот нам VPN готов вообще без каких-либо канальных демонов. Т.е. это почти аналогично cloak, ток приходится применить еще одно средство проксирования.
З.Ы. И да, это дикий геморой с прописыванием адресов тут там и здесь ручками. Но увы, так как изначально решение не подразумевало классического "сетевого" транспорта, то приходится мучаться. Тема для крутого стартапа =)
При таком кривом подходе, мы можем через наш SOCKS5 пойти на 8.8.8.8:22 и нас "сплюнет" на нужный outbound, который может быть простым freedom с перенаправлением на адрес по выбору (локалхост:порт).
Такой вариант рабочий, но мне не нравится. Возможно я вообще не туда копаю, а смотреть нужно в сторону tproxy?..
Вопрос вообще ставить нужно иначе: какова поддержка уже существующих программных продуктов?
Понятно, что "пока его нет, ни кто и не поддерживает", но, с другой стороны, если я работаю с AI мне нужны текущие устоявшиеся аппаратные ресурсы.
Суда по ушам, торчащим в статье, речь идёт, в основном, о свистелках вроде "улучшения видеопотока" или "чат ассистента".
По хорошему, нужно разбираться что же там встроено, какие есть средства работы с этим и что оно может, по сравнению, скажем, с ПК на котором стоит хотя бы A4500 от Nvidia.
Дело не совсем в этом.
Проект отличный, но в настоящее время применений не имеет.
Такие системы хороши в опасных для человека местах, хороши для выполнения рутинных операций, где антропоморфность играет роль, интересны в целом как движение вперёд.
Просто сегодня нет применения: в большинстве случаев удобнее использовать специализированный инструмент, скорость работы или автономность "ещё не та", а говоря про, скажем, радиоактивные или химически опасные зоны - электроника не вытягивает.
То, что проект не помрёт - сомнений нет, но он будет жить в других видах и функциях.
Все верно, спасибо.
Вообще я борьба с ветряными мельницами - дело такое. Этот сервис монетизации подвергается слабо - или мы продаем данные пользователей или мы продаем подписку.
При том, что сам вендор активно "не хочет" такого сопряжения, я бы надавил "общественностью" на открытие gateway API. Это бы позволило встраивать сервис нативно. В текущем же варианте, я бы держался от этого всего за пару км. Утечки через такие прокси - явление постоянное.
Ооох.
Green/blue bubble - шоб я так жил! То, что мир окуклился в рамках платфор и это теперь слабо связанные пузыри - понятно.
Но моё сообщение было не про это вот все.
Мое сообщение было про технологичность решения.
В любом случае спасибо за разъяснения.
Это, наверное, покажется странным ..
В некоторых странах уже периодически электричество бесплатно.
Так что не эра наступает, а...
Какой же бред сивой кобылы!
Есть Е2Е шифрование. Мы или реализуем передачу нерасшифрованного сообщения до нашего приложения и расшифровываем его там, или вынуждены перешифровывать сообщение на нашем гейтвее.
Если реализуется последнее, а судя по тексту, это именно так, то таким сервисом пользовать не стоит от слова совсем.
iMessage оно не столько про сообщения, сколько про экосистему. Если нет интеграции с экосистемой Google и ее партнёров, таких как Samsung/Xiaomi и так далее, ценность такого приложения резко падает.
Не поймите превратно - гейтвей это хорошо, но не так, как это описано у этих товарищей .
На самом деле, я почти отказался от SipMessage. Найти андроид клиент, который бы не зависимо о пущей или настроить эти самые пуш - сложнее, чем слать смс в виде письма.
Ответ лежит в другой плоскости.
Сегодня цмс это хэдлесс решение - элемент большой картины. Многие "хомяки" переехали в облако, магазины - в шопифай.
С селф-хостед дело, действительно, не очень. Фронтир или на TypeScript или на Vue/Angular и присела.
Вы это, простите, себе как представляете?
Есть производители оборудования. Модемы, телефоны, станки, буровые - много-много всего.
Их нужно как-то в сети идентифицировать, понять что это за абонент, вообще наш он или нет?
Эта информация, по мимо ещё некоторых настроек и пишется в "sim".
Если, как раньше, дать вам возможность копировать это все хозяйство, то сеть становится "совсем уже интернет" - у вас будут коллизии, когда 2 и более одинаковых абонента одновременно в сети, когда вы не можете доверять номеру звонящего и так далее по нарастающей.
Собственно, дело даже не в том, что люди абьюзили и "говорили за счёт других", а в том, что оператор теряет контроль над своей сетью. И законодатели, которые четко следят за сетями связи такое не одобряют.
Отсюда и идут все эти шифрованные карты, огораживание и закрытость для простого смертного стандарта.
Вы спросите, ну вот есть же интернет... Есть. Вы готовы обеспечить 100%ю совместимость во всех сетях ретроспективно по разном уровне ПО, типах шифрования и так далее?
По этому, если уже выпущен стандарт, то там ничего не поменять "патчами". Вы не можете "пушнуть обнову" чисто по своему желанию - это привет из старых времён. И базовая станция не умеет так работать. Понятно, что сегодня, когда "все VoIP" это выглядит странно, но мне это нравится. Хотя бы с этой стороны к вам в оборудование никто не лезет.
Да, все так. Я даже понимаю, что в большинстве случаев SIPa более чем достаточно.
Да, про /n и /j я знаю.
И да, iax очень "ограничивает". Возможно, интеграция в мое решение iax - не такая уж и хорошая идея. Я, даже, спорить не буду.
Как я понимаю мой случай, если я использую soft phone, делая вызов через sip в сторону гейтвея с gsm модемом, канал local существует до момента ответа гейтвея. Далее он "оптимизируется" из контекста, оставляя прямой канал между приложением и гейтвеем.
В случае без iax, происходит 2 sip вызова, образуется 2 local канала, оба из которых "оптимизируются".
В случае с iax, по сути, так же.
Джиттер применяется на iax "ногу" вызова. Если вы можете прокомментировать ситуацию - буду благодарен.
Вы хотите сказать, что в случае транка, все звонки считаются local?
Джиттер в SIP, как я понял, настраивается а диалплане и требует компиляции Астерикса с его поддержкой (может оно и по дефолта там, но не уверен).
Смена кодека... возможно, если клиенты начали с opus. Оно перекодирует его в uLaw.
В моем случае, я добился большей пропускной способности и меньшего количества соединений через не самый стабильный туннель при передаче голоса. Нет отдельного rtp + sip.
Интересно, какие ещё параметры не передаются в IAX2?
Done
Ну, я же писал - все зависит от реализации.
Я ни коем разом не считаю себя спецом по VoIP & Asterisk. Это, скорее, заметки на полях и плод моего обобщения.
Мне проще кидать звонки/сообщения траншами, так как я сразу передаю/получаю информацию о CallerID. Возможно, в "разорванной" схеме можно придумать как это передавать, но получится сложнее кмк.
А ещё есть вот такой тред на официальном форуме Quectel
Ели кому интересно про FreePBX, то вот
И там ошибка
Вот в такой конструкции можно ловить запросы по конкретному IP. Добавьте туда "port" и получится нужная связка.
Другое дело, что если применять sockstun или его аналоги (tun2socks) то получаетя некая петля, когда пакеты не понимают куда им деваться (мы же шлем их на адрес интерфейса
tunXи его же указываем в"ip"). Как эту петлю побороть я не придумал, но это решается виртуальными адресами на любом другом интерфейсе. И все - вот нам VPN готов вообще без каких-либо канальных демонов. Т.е. это почти аналогично cloak, ток приходится применить еще одно средство проксирования.З.Ы. И да, это дикий геморой с прописыванием адресов тут там и здесь ручками. Но увы, так как изначально решение не подразумевало классического "сетевого" транспорта, то приходится мучаться. Тема для крутого стартапа =)
Сам спросил, сам и добавлю =)
"routing": {"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"user": "user@myserver",
"ip": "8.8.8.8",
"outboundTag": "ssh"
},
{
"type": "field",
"user": "user@myserver",
"outboundTag": "proxy"
}
]
},
При таком кривом подходе, мы можем через наш SOCKS5 пойти на 8.8.8.8:22 и нас "сплюнет" на нужный outbound, который может быть простым freedom с перенаправлением на адрес по выбору (локалхост:порт).
Такой вариант рабочий, но мне не нравится. Возможно я вообще не туда копаю, а смотреть нужно в сторону tproxy?..