Руслан Малиновский, поговорил тут с пацанами по вашей теме. В общем, мои вышеизложенные предложения в любом случае рискованные. Если со стороны проверяющих будет спец по телефонии, то шансы, что вас нахлабучат практически 100%. Лицензия нужна!
Тут таким образом чистых вариантов два: первый - это получение лицензии, второй - пилить модуль для астерисков, который будет взимодействовать с вашим основным сервисом и предлагать этот модуль установить на атс заказчика. Что-то типа itgrix (интеграция астериск для битрикс24).
Прошу прощения, что ввел в заблуждение.
Руслан Малиновский, мммм.... тут я всё - сдулся. ) Не подскажу.
Технически можно направлять запись звонка на железо заказчика (заказчик на своем железе может делать все что угодно с контентом звонков, главное дать в линию инфу, что разговор записывается). А ваш сервис по API подтягивает эти записи с сервера заказчика себе в бэкенд и отображает во фронте личного кабинета заказчика. Плюс всякие заялаления о неразглашении и конфиденциальности между собой составите.
Я мало представляю, как эту схему можно размотать на нарушения. Но тут ложка дёгтя - согласится ли заказчик прописать такой пункт в договоре, и вообще насколько приемлемо поднимать перед ним такой вопрос.
Всё что знал по-фински, сказал (с). Чем смог, короче.
Руслан Малиновский, если я правильно понял этот коммент, то смотрите:
Я предложил не писать в договоре фразу "маршрутизация телефонных звонков" только для того, чтобы у потенциального проверяющего не сработал триггер "опа, звонки" и он не стал тратить своё и ваше время и нервы на погружение в детали. Исход будет зависеть от морально-волевых качеств проверяющего и компетентности юриста,
Если же напишете "обслуживание сценариев работы транка, который предоставляет заказчик", то тут все прозрачно и действительно отражает суть того, что вы делаете.
Мало того, технически можно настроить сервер телефонии так, что через него не будет идти медиа-трафик (rtp. голосовая связь). Сервер будет просто соединять двух абонентов напрямую, а через себя пропускать только служебные пакеты управления этим соединением.
Но не это главное. Главное то, что вы - не оператор связи, который предоставляет выход в сети общего пользования.
Транк вам дает заказчик и говорит настройте логику работы мне, плиз. Не вы заказчику свой транк даёте и берете за это деньги, а он - вам.
Руслан Малиновский, Да. И думаю в договоре лучше не писать "маршрутизация звонков", а написать "обслуживание и настройка сценариев транка, который обязуется предоставить заказчик". Что-то типа этого.
Но опять же, уточню, я - технарь. не - юрист (лишь, лет 20 назад был связан с контролирующими органами в сфере связи и информатизации). И как технарь, исходя из ваших комментариев к вопросу, я лично не вижу в вашей схеме факта оказания услуг связи. Но так или иначе мой коммент нельзя рассматривать, как достоверный. Просто попробуйте подойти к формулировке с этой точки зрения.
Руслан Малиновский, Я не юрист. Но чисто логически можно посмотреть так: Вы управляете сценариями работы транка заказчика. Заказчик просто даёт вам полномочия настраивать условия эксплуатации транка. Вы не оператор, вы не выделяете номера PSTN, вы просто интегрируете (по просьбе заказчика, на возмездной основе) транки заказчиков в свой сервис, по предоставленным заказчиком sip (whatever)-кредам.
Заказчик уже и так платит оператору сети общего пользования согласно его тарифам, грубо говоря поминутно. Вы не - автобусный парк, вы - лишь проверяете проездные билеты в одном из автобусов, который арендует у автопарка ваш заказачик, и по просьбе этого заказчика.
Вы настраиваете "логику" обработки вызовов, вы не арендуете пул номеров с целью перепродажи.
Еще база, грубо обобщенная, для понимания такая - лицензируются те услуги связи, качество которых выражается в цифровых значениях и прописано в нормативах. Например, количество неудачных вызовов из выполненных 10. И так как, вы не можете на это никак повлиять, потому что не владеете/не_арендуете программно-аппаратный комплекс или транспортные сети, вы не берете поминутную плату за совершенный вызов и прошедший через сервер на котором у вас приземлён транк (или взаимодействует, как пир, с сервером телефонии заказчика), вы не оказываете услуги связи.
Как обычно, огромное спасибо! GRE работает на все деньги!!!
А ведь изначально выбрал ip-ip, предполагая, что это самый простой туннель и с минимумом оверхэда в ip-пакете.
Это логично, бесспорно. Но мне для начала в режиме онлайн хотелось бы увидеть, кто именно вызывает нагрузку. Урезать можно, но это как гадание на кофейной гуще. Ибо сервисы не стендэлоун каждый, а связка.
Посмотрел описание. Там оверхед для меня. :) И насколько понял видео не пишет, только скриншоты.
Но спасибо в любом случае. Добавил в закладки, на будущее.
Я бы для начала изучил какую ответственность Вы, как настройщик, несёте за то, что "сливаете" данные одного из сегментов "Безопасного города" в облако (читать третьим лицам). Да и потом как бы не пришлось доказывать следователю, что вы действовали не по злому умыслу и, что организованный Вами "стык" не несёт в себе уязвимостей для атаки на всю сеть.
Когда опубликовал вопрос, потом понял, что предложат зашифровать весь хоум и, что я был не совсем корректен в описании своих "хотелок". Предполагаем, что пришли с аудитом. Нужно показать рабочую систему, но без раскрытия данных в этих двух файлах. Лайтовая версия трукриптовского скрытого раздела, когда вводя тот или иной пароль, система загружается либо в decoy, либо в hidden. Поэтому, да, был не прав спрашивая про ввод пароля на этапе входа в систему - тут именно спрятянный в дебрях скрипт вызывать уже после входа. Но вот чем?
p.s. Арчлинукс при установке ни о чём не спрашивает. :)
Тут таким образом чистых вариантов два: первый - это получение лицензии, второй - пилить модуль для астерисков, который будет взимодействовать с вашим основным сервисом и предлагать этот модуль установить на атс заказчика. Что-то типа itgrix (интеграция астериск для битрикс24).
Прошу прощения, что ввел в заблуждение.