УПАТС, СОРМ и ФСБ

[megahertz0]

Итак, к нам обратился один отель с целью модернизации АТС и расширения ее до 550 номеров. Заодно решили срулить к нам с другого оператора.

Никакой магии, но внезапно основным из требований в ТЗ является возможность сливать внутренние вызовы в пределах АТС на пульт управления в ФСБ. При этом станция будет работать как УПАТС с внутренний номерами, мы только подаем транк с городскими номерами. Из общения с заказчиком выяснилось, что в связи с проведением олимпиады (да, мы из Сочи) и тем что они отель, органы хотят слушать внутренние разговоры.

У нас есть сданный СОРМ, в том числе и с возможностью перехвата голосового трафика в пакетной сети. При этом телефония у нас полностью IP, по E1 стыки только на город и МГ. Транзитный коммутатор сертифицирован (MERA MVTS), трафик с него сливается в СОРМ (Омега). Т.е. вызовы через свою сеть мы сливать можем. Но как быть с внутренними вызовами в пределах присоединенных УПАТС?

Разумеется начальство обратилось к куратору из ФСБ. Товарищи они весьма деревянные, но суть разговора свелась к тому, что согласно новым требованиям оператор должен предоставлять доступ не только к вызовам, прошедшим через его сеть, что мы и делаем, но и к вызовам в пределах присоединенных УПАТС. Правда нормативного документа, регламентирующего этот момент я не видел. Сказали что так надо))).

Короче какой-то абсурд получается. А если абон берет у нас 4 порта FXO, втыкает в офисный мини-панасоник, то нам тоже надо как-то сливать его внутренний трафик? А если сип-транк и заворачивает его в свой астериск?

Если такая практика пойдет и дальше, то это какая-то жопа. А если у абона стоит вообщеастериск и СОРМ к нему никак не прикрутить? Или колл-менеджер по сип-транку?

В общем, хотел спросить, выдвигают ли органы подобные требования еще где-то? И чем они руководствуются?

[adnull]

Бред. У вас точка разграничения на порту их атс. Какой к черту сорм во внутренней сети?

[MATPOC]

Никакой магии, но внезапно основным из требований в ТЗ является возможность сливать внутренние вызовы в пределах АТС на пульт управления в ФСБ. При этом станция будет работать как УПАТС с внутренний номерами, мы только подаем транк с городскими номерами.

У нас есть сданный СОРМ, в том числе и с возможностью перехвата голосового трафика в пакетной сети. При этом телефония у нас полностью IP, по E1 стыки только на город и МГ. Транзитный коммутатор сертифицирован (MERA MVTS), трафик с него сливается в СОРМ (Омега). Т.е. вызовы через свою сеть мы сливать можем. Но как быть с внутренними вызовами в пределах присоединенных УПАТС?

Если такая практика пойдет и дальше, то это какая-то жопа. А если у абона стоит вообще астериск и СОРМ к нему никак не прикрутить?

 

Вы говорите, что СОРМ Омега умеет понимать VoIP, так что проще у клиента поставить любую SIP АТС и сливать этот голосовой поток на ваш СОРМ.

[Stahlhammer]

Я так понял гбисты требуют реализовать мониторинг вызовов с владельца УПАТС? Тогда вы то тут причем?

[RialCom.ru]

да при том, что клиент уйдет на того оператора, кто решит эту СОРМовскую задачу ;)

[alex_611]

да при том, что клиент уйдет на того оператора, кто решит эту СОРМовскую задачу ;)

 

Как по мне, так попахивает обычным разводом руководства отеля на деньги =)

[Дятел]

А отель имеет лицензию? Если нет - то он не субъект регулирования, и СОРМ ему не полагается.

[megahertz0]

Вы говорите, что СОРМ Омега умеет понимать VoIP, так что проще у клиента поставить любую SIP АТС и сливать этот голосовой поток на ваш СОРМ.

Тогда надо будет поднимать вызовы внутри УПАТС клиента до уровня транзитного коммутатора (MVTS). Не комильфо это. Вызовы же через нашу сеть на МГ/МН и город мы и так сливаем.

А отель имеет лицензию? Если нет - то он не субъект регулирования, и СОРМ ему не полагается.

Лицензии на телефонию отель не имеет. Но порядочное заведение тарифицирует вызовы постояльцев и потом предъявляет счет при выезде, как правило такой функционал есть во многих HRS. Разумеется по тарифам раза в 2-3 больше, чем у оператора, к которому он присоединен, т.е. не по себестоимости. Как их за это не дрючат - хз, но факт имеет место быть.

Я так понял гбисты требуют реализовать мониторинг вызовов с владельца УПАТС? Тогда вы то тут причем?

При том, что клиент нашими силами хочет поставить станцию. Не просто подключиться. По большому счету требуют не столько от нас, сколько от отеля.

Суть вопроса в том, что я не вижу документа, который бы регламентировал момент с мониторингом вызовов. Если там такие же заморочки как с СОРМом для операторов связи, то это один разговор. Надо ставить сертифицированное железо, прогонять поток от него до КГБшников, сдавать все это и т.д. Если это никак не регламентировано, то мы просто ставим астериск, прикручиваем к нему необходимое количество FXO-шлюзов и где надо IP-телефонов. А затем просто пишем все вызовы внутри астера на фтп и даем КГБшникам от него логин. Если надо будет - сами зайдут и сольют.

[MATPOC]

Вы говорите, что СОРМ Омега умеет понимать VoIP, так что проще у клиента поставить любую SIP АТС и сливать этот голосовой поток на ваш СОРМ.

Тогда надо будет поднимать вызовы внутри УПАТС клиента до уровня транзитного коммутатора (MVTS). Не комильфо это. Вызовы же через нашу сеть на МГ/МН и город мы и так сливаем.

Нет, достаточно просто зеркалировать голосовой трафик УПАТС к вам на порт СОРМа. Для этого нужно заставить ходить голосовой трафик только через УПАТС, запретить прямые соединения между SIP терминалами.

[megahertz0]

Дело в том, что у меня голосовые вланы терминируются на l3 свитчах агрегации, далее трафик попадает в магистральный влан со внутренним пирингом и только потом из ядра в влан с астериском, на котором непосредственно регистрируются шлюзы и сип-транки. Как раз этот влан и влан между мерой и астером мы и сливаем через SPAN в СОРМ. Т.е. между астером и абоном есть минимум 3 хопа. Так что просто слить еще один влан не получится.

[MATPOC]

Дело в том, что у меня голосовые вланы терминируются на l3 свитчах агрегации, далее трафик попадает в магистральный влан со внутренним пирингом и только потом из ядра в влан с астериском, на котором непосредственно регистрируются шлюзы и сип-транки. Как раз этот влан и влан между мерой и астером мы и сливаем через SPAN в СОРМ. Т.е. между астером и абоном есть минимум 3 хопа. Так что просто слить еще один влан не получится.

Получится - ERSPAN over layer 3 links, либо программно - этот вопрос обсуждался в теме Отзеркалировать порт с трафиком radius

[AlexPan]

У нас было сформулировано так, что все звонки с реальных или на реальные телефонные номера должны быть доступны в СОРМ. Звонки с внутреннего номера на внутренний им не нужны.

 

Не зависимо от всего, все звонки с отельной АТС маршртизируются к вам в аплинковый Е1, а потом вы их маршрутизируете обратно. Вот они в СОРМ и попадут. В крайнем случае побольше потоков сделаете. Это если АТС. Если IP АТС, то так же маршрутизацию на ваш основной каллсвитч делаете и обратно.