Роман, доброго дня!
Не обижайтесь, пожалуйста, но мне кажется — Вам стоит повнимательнее изучить основы построения сотовых систем связи, инфраструктурные ограничения существующего оборудования и т.д. И тогда многие из поставленных Вами вопросов отпадут сами собой. В идеальном мире требований приказов и инструкций на инфраструктуре однородного и современного оборудования все вышеперечисленное в Вашей статьей вполне реализуемо, но все не так просто в реальном мире.
Еще раз — ничего личного и никаких претензий к самой статье.
Возможно не очень удачный пример я выбрал для демонстрации принципов тарифной сетки. Тем не менее, в общем случае, затраты оператора при инциации вызова из «чужой» мобильной сети и переадресации его на «чужую» мобильную сеть выше всего. Не готов объяснить причины такого дисбаланса стоимости, но увы, такова данность на текущий момент.
Честно говоря VoIP лишь транспорт для последней мили или SIP направление переадресации трафика.
На МгМн сети все равно трафик «ходит» классический.
Таким образом, сэкономить мы можем только на «приземлении» трафика на SIP, о чём я и написал.
Признак REVC обычно передается в сигнализации обмена между МгМн коммутаторами.
Дальнейшее решение о тарификации принимается на уровне биллинга опертора. У нас это решение принимает платформа 8-800 в зависимости от направления вызова.
А чем Вас смутил формат timestamp(14) для даты/времени? Это обычная практика работы с типами данных даты/времени, в том числе и в БД (посмотрите, например, описание типов данных в SQL).
Насколько мне известно, КДУ 800 выделяется оператору на всю территорию РФ и маршрутизируется на всей территории одинаково. В рамках одного номера мы можем настроить маршрутизацию по регионам, т.е. переадресовывать вызовы из одной области (региона, города и т.д.) на один номер, из другой области — на другой. Но заключить договор на оказание услуг связи с двумя разными юр. лицами на один и тот-же номер думаю, юридически не возможно.
Кстати, какому именно оператору принадлежит номер и вообще законодательные акты по организации услуг связи можно посмотреть на сайте Россвязи.
Номер с которого будет осуществляться «атака» скорее всего сразу станет известен.
Хотя нужно различать два варианта — просто попытка дозвона на Ваш номер, без установления соединения (или очень короткое — буквально пара секунд) и дозвон и занятие линии на максимальное время.
В первом случае будет создана ситуация, когда на Ваш номер просто будет трудно дозвониться, но стоимость этого трафика для Вас будет близка к нулю. Во втором случае «атакующие» вызовы будут попадать на Ваших операторов или «висеть» в очереди на IVR и будет не сложно установить откуда (с какого номера передаресации) пришел вызов. Здесь помогут ограничители количество СЛ для Вашего номера.
Вообще я сомневаюсь, что «атака» будет столь сложной и Ваш конкурент арендует большое количество каналов с выходом через разных операторов связи, что-бы удерживать эту «атаку» сколь либо долго и Вы успели понести существенные затраты.
Впрочем, все это сродни известной войны брони и снаряда — силы всегда примерно равны, но вот затраты на каждый шаг вперед могут не стоить того эффекта, который они приносят :-)
Доброго дня!
Увы, я не сервис инженер и «назубок» всё описание протоколов не знаю. Да и не вижу возможности сколь либо подробно описывать даже основы camel/inap в формате Хабра. Впрочем, если зададите какие-то конкретные вопросы — попробую на них ответить.
Безусловно, исходным источником знаний о протоколах является документация на языке источника — английском.
Ссылку на Б.С. Гольдштейна давал как пример книги, из которой можно получить информацию об основах построения IN сетей и сервисов на русском языке.
Доброго дня.
Нет, такого «динамического» списка пока нет.
Если вопрос в том, что какой-то провайдер устроит «атаку» на Ваш номер, то проще заблокировать его номер переадресации, с которым он выходит в телекомсеть.
Доброго вечера.
Спасибо, вопрос важный. Собственно это один из вопросов, который хотелось бы осветить подробно.
В этой, первой, статье я описал кратко саму схему работы 8-800, а далее — буду описывать практические варианты применения на примере уже созданных нашими Клиентами сервисов. В том числе отдельно рассажу и решение Вашего вопроса, равно как и тему тарификации сервиса 8-800 в общем.
Авансом, если коротко, трафик нужно прогнозировать, анализировать и соответствующим образом планировать технические средства маршрутизации на случай пиковой или «фродовой» нагрузки.
IVR (Interactive Voice Response) может использоваться как конечная или промежуточная точка маршрутизации в сервисе 8-800, например может (да и должен) быть установлен на номере (495)123-45-67 (по схеме). Но отношению к маршрутизации сервиса 8-800 на сети оператора IVR обычно не имеет.
Что касается русскоязычных телекоммуникационных терминов — хорошо, добавлю в краткий словарик их международные аббревиатуры.
Честно говоря, Ваша тема сервиса 8-800 вообще не касается.
При установлении исходящего соединения коммутатор технологически может установить в принципе любой номер (или даже текст) вместо исходного. Как частный случай — номер КДУ 8-800. Вопрос только в пропуске трафика при переходе вызова из сети одного оператора в сеть другого. Есть регламентирующие документы на эту тему.
По оформлению — прошу прощения, первый опыт, если возможно исправлю.
По тарификации 8-800 — будет отдельная публикация, ибо вопрос очень не простой.
Ну а краткость и простота изложения была основной идеей. Уверен, что первоисточников для получения подробной технической информации о SS7, IN и сервисах на ней — более чем достаточно.
Не обижайтесь, пожалуйста, но мне кажется — Вам стоит повнимательнее изучить основы построения сотовых систем связи, инфраструктурные ограничения существующего оборудования и т.д. И тогда многие из поставленных Вами вопросов отпадут сами собой. В идеальном мире требований приказов и инструкций на инфраструктуре однородного и современного оборудования все вышеперечисленное в Вашей статьей вполне реализуемо, но все не так просто в реальном мире.
Еще раз — ничего личного и никаких претензий к самой статье.
Возможно не очень удачный пример я выбрал для демонстрации принципов тарифной сетки. Тем не менее, в общем случае, затраты оператора при инциации вызова из «чужой» мобильной сети и переадресации его на «чужую» мобильную сеть выше всего. Не готов объяснить причины такого дисбаланса стоимости, но увы, такова данность на текущий момент.
Честно говоря VoIP лишь транспорт для последней мили или SIP направление переадресации трафика.
На МгМн сети все равно трафик «ходит» классический.
Таким образом, сэкономить мы можем только на «приземлении» трафика на SIP, о чём я и написал.
Признак REVC обычно передается в сигнализации обмена между МгМн коммутаторами.
Дальнейшее решение о тарификации принимается на уровне биллинга опертора. У нас это решение принимает платформа 8-800 в зависимости от направления вызова.
А чем Вас смутил формат timestamp(14) для даты/времени? Это обычная практика работы с типами данных даты/времени, в том числе и в БД (посмотрите, например, описание типов данных в SQL).
Передал Вашу проблему в ТП МегаФон, в ближайшее время они свяжутся с Вами.
Кстати, какому именно оператору принадлежит номер и вообще законодательные акты по организации услуг связи можно посмотреть на сайте Россвязи.
Да, SCP «8-800» это один из узлов софтовой IN платформы, говоря простым языком.
Хотя нужно различать два варианта — просто попытка дозвона на Ваш номер, без установления соединения (или очень короткое — буквально пара секунд) и дозвон и занятие линии на максимальное время.
В первом случае будет создана ситуация, когда на Ваш номер просто будет трудно дозвониться, но стоимость этого трафика для Вас будет близка к нулю. Во втором случае «атакующие» вызовы будут попадать на Ваших операторов или «висеть» в очереди на IVR и будет не сложно установить откуда (с какого номера передаресации) пришел вызов. Здесь помогут ограничители количество СЛ для Вашего номера.
Вообще я сомневаюсь, что «атака» будет столь сложной и Ваш конкурент арендует большое количество каналов с выходом через разных операторов связи, что-бы удерживать эту «атаку» сколь либо долго и Вы успели понести существенные затраты.
Впрочем, все это сродни известной войны брони и снаряда — силы всегда примерно равны, но вот затраты на каждый шаг вперед могут не стоить того эффекта, который они приносят :-)
Увы, я не сервис инженер и «назубок» всё описание протоколов не знаю. Да и не вижу возможности сколь либо подробно описывать даже основы camel/inap в формате Хабра. Впрочем, если зададите какие-то конкретные вопросы — попробую на них ответить.
Безусловно, исходным источником знаний о протоколах является документация на языке источника — английском.
Ссылку на Б.С. Гольдштейна давал как пример книги, из которой можно получить информацию об основах построения IN сетей и сервисов на русском языке.
Нет, такого «динамического» списка пока нет.
Если вопрос в том, что какой-то провайдер устроит «атаку» на Ваш номер, то проще заблокировать его номер переадресации, с которым он выходит в телекомсеть.
Печально, очередное «белое» пятно на карте, при чем у всех 4-х операторов.
https://geo.minsvyaz.ru/#/-1/-1/12/45.66901082669685/42.10585817269818/4
Спасибо, вопрос важный. Собственно это один из вопросов, который хотелось бы осветить подробно.
В этой, первой, статье я описал кратко саму схему работы 8-800, а далее — буду описывать практические варианты применения на примере уже созданных нашими Клиентами сервисов. В том числе отдельно рассажу и решение Вашего вопроса, равно как и тему тарификации сервиса 8-800 в общем.
Авансом, если коротко, трафик нужно прогнозировать, анализировать и соответствующим образом планировать технические средства маршрутизации на случай пиковой или «фродовой» нагрузки.
Что касается русскоязычных телекоммуникационных терминов — хорошо, добавлю в краткий словарик их международные аббревиатуры.
Честно говоря, Ваша тема сервиса 8-800 вообще не касается.
При установлении исходящего соединения коммутатор технологически может установить в принципе любой номер (или даже текст) вместо исходного. Как частный случай — номер КДУ 8-800. Вопрос только в пропуске трафика при переходе вызова из сети одного оператора в сеть другого. Есть регламентирующие документы на эту тему.
По оформлению — прошу прощения, первый опыт, если возможно исправлю.
По тарификации 8-800 — будет отдельная публикация, ибо вопрос очень не простой.
Ну а краткость и простота изложения была основной идеей. Уверен, что первоисточников для получения подробной технической информации о SS7, IN и сервисах на ней — более чем достаточно.