Модуль Астериск в 1С - есть желающие сделать?

legzzi · 14 апр 2015, 19:40

собственно все в теме написано, нужен 1С программист который бы хотел себе сделать модуль Астериска (соответственно творчески подходит к созданию), со своей стороны сделаю все на стороне Астериска и поделюсь разработкой, от вас хотелось бы тоже самого но на стороне 1С.
пожалуйста в ПМ, контакты скайп в приоритете.

MuI_I_Ika · 14 апр 2015, 23:37

А у них вроде на сайте написано, что есть интеграция с 1С

http://asterisk.ru/

Asterisk IP АТС по-русски | asterisk.ru

Собственная сеть GSM

3 ноября 2022, 10:00

Sam Machin: "Перенесемся в 2018 год, когда мы начали оценивать целесообразность создания GSM-сети в EMF. Мы обратились ко всем, кого могли вспомнить, кто мог бы помочь, и нам предложили обратиться к Эндрю (Andrew Back).Я отправил ему электронное письмо, в котором упоминалось, что мы рассматриваем возможность использования оборудования Lime для запуска сети GSM, поскольку оно было и дешевым, и будет хорошо работать - я и не подозревал, что он на самом деле работает на Lime! "

"Доступ к радиочастотному спектру был подтвержден только за несколько недель до события, что оставило нам очень мало времени для поиска решения. Однако, используя готовые компоненты, такие как LimeSDR Mini и Raspberry Pi 3 Model B+, мы смогли собрать в общей сложности шестнадцать автономных базовых станций - в комплекте с корпусами и фитингами с соответствующим уровнем защиты (брандмауэр IP) - за считанные дни и при очень низких затратах.стоимость ", - объясняет Эндрю Бэк из Lime Microsystems. "Хотя конечный результат был тактическим решением и, возможно, не тем, что можно было бы внедрить в производственной сети, он очень наглядно продемонстрировал мощь недорогого высокопроизводительного SDR-оборудования в сочетании с обычными вычислительными системами и стеками с открытым исходным кодом".

"Lime был действительно полезен с точки зрения аппаратного обеспечения", - добавляет Мачин. "Поначалу я немного скептически относился к тому, что Raspberry Pi может работать с GSM, потому что, конечно, нам требовалось разумное количество вычислительной мощности. Я думаю, что Pi 3 в некотором роде пересек границу возможностей, и это своего рода удачная комбинация программного обеспечения с открытым исходным кодом, которое становится все более и более эффективным, а вычислительная мощность растет. Мы достигли своего рода переломного момента в оптимизированном программном обеспечении и более мощных процессорах ".

Raspberry Pi решил половину аппаратного уравнения, но именно открытое аппаратное решение LimeSDR Mini решило другую проблему: обеспечение доступного программно-определяемого радиочастотного сигнала в небольшом форм-факторе с низким энергопотреблением. В совокупности эти два устройства образуют систему гораздо меньших размеров, чем традиционная базовая станция GSM, и это, объясняет Мачин, является ключевым фактором. "Поскольку радиочастотная сторона Lime [SDR] обеспечивает передачу с низким энергопотреблением, вам не нужны длинные антенные кабели.

В традиционной GSM-инженерии вы бы поместили свою базовую станцию в шкаф у основания мачты, а затем проложили бы коаксиальный кабель к вашей антенне на вершине мачты, но потери, которые вы получите при этом с SDR, при запуске длинной коаксиальной кабель, был бы значительным. Вы потеряете так много своей мощности, просто поднимаясь на мачту. То, что мы сейчас делаем с низким энергопотреблением, мы фактически помещаем весь блок базовой станции на мачту, так что расстояние между радиочастотным блоком и антенной составляет, возможно, дюйм кабеля. Это очень маленький соединительный разъем ".

Сочетание Raspberry Pi и LimeSDR Mini приносит с собой еще одно важное преимущество: стоимость. "Сеть, которую мы построили ещё в 2014 году, использовала программно-определяемое радио (SDR) и вычислительное устройство, но я думаю, что даже для самых дешевых мы рассчитывали на 1500 долларов за каждую базовую станцию. Таким образом, за четыре года мы снизили, вероятно, в восемь раз стоимость, сложность, мощность и все остальное, что с этим связано, потому что материал стал физически меньше, а также дешевле ".

Читать полностью »Собственная сеть GSM

Что такое STIR/SHAKEN?

6 сентября 2021, 12:41

Как это работает?

STIR/SHAKEN (Secure Telephony Identity Revisited / Signature-based Handling of Asserted information using toKENs) это новая технология, которую телекоммуникационная отрасль использует для борьбы с телефонным мошенничеством. Мы все получали спам-звонки, и некоторые из нас, возможно, даже получили звонок с Caller ID абонента, который нам хорошо известен, но в итоге оказывались кем-то другим. Это было серьезной проблемой в течение многих лет, но с помощью STIR/SHAKEN мы можем резко снизить вероятность того, что это произойдет.

Технология STIR/SHAKEN основана на сертификатах Х.509, использует закрытые и открытые ключи для идентификации источника вызова. Это устанавливает цепочку доверия от одной организации к другой. Доверенные поставщики будут хранить закрытый ключ, который они используют для подписи заголовков SIP (в частности, заголовок удостоверения будет иметь эту подпись), и они предоставят открытый ключ другим пользователям для загрузки и проверки по закрытому ключу. В этом заголовке хранится много информации, включая аттестацию, идентификатор вызывающего абонента, URL-адрес открытого ключа и многое другое. Аттестация будет использоваться для определения того, какой уровень доверия пытается установить этот звонок. Оттуда получатель вызова может решить, что он хотел бы сделать с этой информацией. :

Вот пример того, как может выглядеть заголовок идентификатора

Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cDovL3Rlc3RpbmcxMjMifQ==.eyJvcmlnIjp7InRuIjoiMTIzNDU2NyJ9LCJhdHRlc3QiOiJCIiwib3JpZ2lkIjoiYXN0ZXJpc2siLCJpYXQiOjE1OTA1ODgzODV9.MEUCIQCmINlklk+fCxEEjgbbwE5X7DAEy19aPRfLvypXrKUwpwIgaDtEzKZoGRa/Omof9iC6tPQPzsKazN1hygDWOc9uWXQ=;info=alg=ES256;ppt=shaken

Заголовок, payload и подпись кодируются BASE64 и разделяются точками. Вот пример заголовка:

eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cDovL3Rlc3RpbmcxMjMifQ==

Если расшифровать BASE64 (через https://www.base64decode.org например) то получим:

{"alg":"ES256","ppt":"shaken","typ":"passport","x5u":"http://testing123"}

Заголовком является JSON-объект, как миниму содержащий алгоритм кодирования, ppt, тип и URL публичного ключа. На момент написания этой заметки ppt должен иметь значение "shaken и тип - "passport"..

Теперь payload:

eyJvcmlnIjp7InRuIjoiMTIzNDU2NyJ9LCJhdHRlc3QiOiJCIiwib3JpZ2lkIjoiYXN0ZXJpc2siLCJpYXQiOjE1OTA1ODgzODV9

После расшифровки BASE64 получим:

{"orig":{"tn":"1234567"},"attest":"B","origid":"asterisk","iat":1590588385}

Payload является также JSON-объектом, который содержит номер caller ID, аттестацию, ID оригинатора и метку времени. Большая часть приведенной здесь информации будет использована для сравнения с условиями, которые необходимо выполнить для успешного выполнения вызова.

Подпись следует за payload (полезной информацией), вплоть до точки с запятой. После этого у нас есть:

info=alg=ES256;ppt=shaken

Таким образом вся информация, которую мы разобрали в этих разделах, является необходимой и достаточной для проверки того, чтобы подтвердить что звонок действительно поступил оттуда, откуда он сказал, что поступил!

Конфигурация STIR/SHAKEN

Астериск уже имеет встроенный механизм поддержки STIR/SHAKEN. Это реализовано в виде опции в секции "endpoint" файла pjsip.conf:

[my_endpoint]
type=endpoint
stir_shaken=yes

По умолчанию для этого параметра установлено значение нет. Если вы хотите, чтобы ваши звонки поддерживали STIR/SHAKEN, вам нужно включить эту опцию для этих конечных пиров. Это все, что вам нужно сделать в pjsip.conf. Остальное настраивается в файле stir_shaken.conf. Вот пример того, как может выглядеть этот файл конфигурации:

[general]
ca_file=/etc/asterisk/stir/ca.crt
ca_path=/etc/asterisk/stir/ca
cache_max_size=1000
curl_timeout=2
signature_timeout=15

[my_cert]
type=certificate
path=/etc/asterisk/stir/mycert.pem
public_key_url=http://testing.com/test.crt
caller_id_number=1234567
attestation=C
origid=MyAsterisk

Использование STIR/SHAKEN в Диал-плане

Еще одна интересная вещь, которую вы можете сделать, - это проверять результаты STIR/SHAKEN в диалплане. Функция STIR_SHAKEN сообщит вам результат проверки, чтобы вы могли использовать его по своему усмотрению. Возможными результатами являются "Проверка отсутствует", "Ошибка подписи", "Несоответствие проверки" и "Проверка пройдена". Если результат "Проверка отсутствует", это означает, что не было никакой информации для обработки (без заголовка идентификации). "Несоответствие проверки" означает, что информация внутри полезной нагрузки не соответствует информации в сообщении SIP. "Проверка пройдена" означает, что проверка ПЕРЕМЕШИВАНИЯ/ВСТРЯХИВАНИЯ прошла успешно. "Ошибка подписи" означает, что либо подпись и открытый ключ не совпадают, либо подпись не удалась по другой причине. Основываясь на этих результатах, вы можете выбрать действия, которые можно предпринять. Вот несколько примеров:

exten => example1,1,STIR_SHAKEN(count)

exten => example2,1,STIR_SHAKEN(0, verify_result)

exten => example3,1,STIR_SHAKEN(5, identity)

exten => example4,1,STIR_SHAKEN(2, attestation)

Вы уже знаете, что означает verify_result, но есть и другая информация, которую также можно получить и обрабатывать.
Если просто вызвать функцию count, она вернет, сколько существует идентификаторов STIR/SHAKEN.
Затем вы можете просмотреть их все и получить информацию по каждому. Вот тут-то и появляются цифры. Чтобы получить результат проверки, вы должны сначала ввести индекс удостоверения, для которого вам нужна информация, а затем имя нужной вам информации. В настоящее время вы можете получить verify_result, идентификацию и аттестацию.

Выводы

Вот и всё как это устроено! Настройка довольно минимальна, но влияние, которое она окажет на клиентов, огромно. Выполнив описанные выше действия по настройке Asterisk для STIR/SHAKEN, вы сможете предотвратить несколько спам-звонков, сэкономив время и деньги. В будущем, по мере дальнейшего развития технологий и промышленности, будет проделана дополнительная работа по STIR/SHAKEN, но основа уже заложена и может быть использована сейчас. Попробуйте и помогите нам улучшить Asterisk своими отзывами!

Что такое STIR/SHAKEN?

Стремительное развитие WebRTC

23 июля 2021, 09:48

Часто спрашивают: "Безопасен ли WebRTC?" Одним словом...да.

WebRTC защищен и использует различные меры безопасности, чтобы гарантировать сохранность вашей информации. В целом - развивайте свой бизнес с помощью WebRTC, которая является технологией, обеспечивающей взаимодействие между интернет-браузерами и мобильными приложениями. Это известно также как веб-связь в режиме реального времени, расшифровывая аббревиатуру. Это упрощает передачу и интеграцию аудио, видео и данных из открытых источников, которые относятся к категории решений для веб-приложений в режиме реального времени.

Приложения для видео-конференцсвязи во время пандемии получили гигантскую прибыль. WebRTC как механизм, лежащий в основе этого, обеспечивает одноранговую связь между браузерами. Разработчики WebRTC отмечают, что это базовая, но сложная технология. Прямолинейность сводится к простоте исполнения. Возможно использовать от пяти до десяти строк кода для сортировки общей видеосвязи между двумя программами. Одновременно с этим постоянно возникает "однако", когда мы занимаемся разработками в этой области. В случае WebRTC основным тестом является бэкэнд: разработчики должны гарантировать, что решение работает в разных компаниях.

Элементы защиты WebRTC:

Часто спрашивают: "Безопасен ли WebRTC?" Одним словом...да. WebRTC защищен и использует различные меры безопасности, чтобы гарантировать сохранность вашей информации. К ним относятся:

Защита браузера:

Как мы знаем, WebRTC санкционируется напрямую между программами без требования к модулям. Это, естественно, делает WebRTC более безопасным, поскольку обеспечивает дополнительную степень защиты от вредоносных программ или других назойливых программ, которые могут быть скрыты в виде модуля. Кроме того, поскольку WebRTC предлагается как часть программы, любые потенциальные угрозы безопасности или слабые места, как правило, будут быстро устраняться с помощью автоматического обновления продавцами программ.

Доступ к средствам массовой информации:

Технология WebRTC работает в 2021 году после того, как COVID-19, в частности, устраняет возможные проблемы, связанные с разрешением доступа к медиа активам, требуя специального разрешения на использование камеры или усилителя. Для приложения WebRTC невозможно получить доступ к гаджету без согласия. Кроме того, это будет продемонстрировано в пользовательском интерфейсе клиента и на его оборудовании в любой момент, когда используется гаджет.

Шифрование:

Шифрование является обязательной частью WebRTC и разрешено на всех этапах создания и поддержания соединения. Для звука и видео ключевая информация затем может быть использована для создания ключей AES (Advanced Encryption Standard), которые, таким образом, используются SRTP (Безопасный транспортный протокол реального времени) для шифрования и декодирования носителей. Эта аббревиатура "богатая куча инноваций" означает очень надежные ассоциации, которые трудно разорвать с текущими инновациями. И WebRTC, и ORTC заказывают этот конкретный стек, который, в свою очередь, жизнеспособен и совместим с фреймворками VoIP.

Стремительное развитие WebRTC

Семь ошибок безопасности (инфраструктура как код)

13 февраля 2021, 23:59

Проблема №1: Ярлыки безопасности

Проблема номер один - это неспособность обеспечить надлежащую безопасность, потому что для этого требуется много времени и знаний. Например, инженеры DevOps могут не требовать сертификатов на основе протокола SSL/TLS для всех микросервисов или не применять соответствующие роли управления идентификацией и доступом (IAM) к облачным ресурсам. Такие упущения могут сделать организации уязвимыми для злоумышленников, которые смогут сделать практически все, как только получат доступ к системе.

Соблюдение требований как кодекс может помочь решить эту проблему. Эта категория программного обеспечения применяет подход "инфраструктура как код" для автоматизации внедрения, проверки и мониторинга состояния соответствия требованиям, связанным с безопасностью, защитой данных и различными бюджетными ограничениями. Различные инструменты сканирования безопасности и тестирования на проникновение могут быть вставлены в конвейер DevOps, так что сканирование среды на предмет безопасности становится частью регулярного процесса развертывания при вводе версий в производство.

Проблема № 2: Не реализована сквозная автоматизация

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

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

Проблема № 3: Недостаточное автоматизированное тестирование

Разработчики признают ценность автоматизированного тестирования для своих приложений, но многие инженеры DevOps забывают применять подобное тестирование к своей инфраструктуре в качестве кода. Однако, как и приложения, инфраструктура по мере развития кода продолжает развиваться, и эти изменения могут привести к ошибкам, которые нарушают код. По этой причине крайне важно применять автоматизированное тестирование как к приложениям, так и к инфраструктуре как к коду, чтобы гарантировать правильную работу конфигураций инфраструктуры.

Проблема № 4: Игнорирование лучших практик оптимизации затрат

Мы видели реальные примеры, когда развертывание может стоить либо 1000, либо 100 000 долларов в месяц, в зависимости от того, как управляется облачная инфраструктура. Оптимизация может принимать форму правильного определения размера ресурсов, использования преимуществ спотовых экземпляров, идентификации незанятых ресурсов или работы на нескольких облачных платформах.

Тем не менее, в спешке, чтобы получить проект с нуля, некоторые инженеры DevOps забывают реализовать оптимизацию затрат в своей инфраструктуре как к коду. Конечно, потребуется больше времени для внедрения лучших практик оптимизации затрат, но ежемесячная экономия затрат на облачные технологии обеспечит быструю окупаемость этих инвестиций.

Проблема № 5: Создание облачного мусора

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

Проблема №6: Жесткое кодирование значений параметров

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

Проблема № 7: Монолитные скрипты

Иногда инженеры DevOps объединяют множество задач в один большой монолитный сценарий автоматизации. Если им нужен похожий сценарий, они скопируют и вставят исходный сценарий и перепишут несколько параметров. Такой подход приводит к инфраструктуре как коду, который становится слишком сложным для поддержания и расширения. Лучший подход-разбить код инфраструктуры на отдельные модули или стеки, а затем объединить их в автоматическом режиме во время развертывания. Есть несколько преимуществ для этого подхода. Во-первых, инженеры DevOps имеют больший контроль над тем, кто имеет доступ к различным частям их инфраструктурного кода. Во-вторых, это позволяет командам повторно использовать работу в будущих проектах. В-третьих, это помогает командам DevOps поддерживать и тестировать модули.

Семь ошибок безопасности (инфраструктура как код)

WebRTC теперь официальный стандарт

2 февраля 2021, 13:50

26 января 2021 года

Web Real-Time Communications (WebRTC) https://www.w3.org и https://www.ietf.org

Консорциум World Wide Web Consortium (W3C) и Целевая группа по разработке Интернета (IETF) объявили сегодня, что Web Real-Time Communications (WebRTC), которые поддерживают множество сервисов, теперь является официальным стандартом, обеспечивающим аудио-и видеосвязь в любом месте Сети.

WebRTC, состоящий из JavaScript API для веб-коммуникаций в реальном времени и набора коммуникационных протоколов, позволяет любому подключенному устройству в любой сети быть потенциальной конечной точкой связи в Интернете. WebRTC уже служит краеугольным камнем онлайн-коммуникаций и услуг совместной работы.

"Сегодняшнее знаковое достижение является своевременным. Столкнувшись с глобальной пандемией коронавируса COVID-19, мир становится все более виртуальным. Это делает Интернет еще более важным для общества в области обмена информацией, коммуникаций в реальном времени и развлечений",-сказал д-р Джефф Джаффе, генеральный директор W3C. "Отрадно видеть, что наши технологии играют ключевую роль в создании такой критически важной цифровой инфраструктуры. Сочетание универсального охвата Интернета с богатством живых аудио-и видеопереговоров изменило то, как мир общается."

https://www.ietf.org/blog/webrtc-standardized/