Об утверждении Требований к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользо…
Приказ Министерства связи и массовых коммуникаций Российской Федерации от 23.07.2015 № 279 "Об утверждении Требований к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий"
Текст — по данным портала официального опубликования правовых актов (publication.pravo.gov.ru). Скачать .doc · Печать
- Издан на основании
- 126-ФЗ; ч. 2 ст. 64 126-ФЗ
- Приложения
- Приложение 1. УТВЕРЖДЕНЫ приказом Минкомсвязи России ot 28.07_909/5т. № 777 · Приложение № 1 к Требованиям к оборудованию и программному обеспечению операторов почтовой · Приложение № 2 к Требованиям к оборудованию и программному обеспечению операторов почтовой · Приложение № 3 к Требованиям к оборудованию и программному обеспечению операторов почтовой · Приложение № 5 к Требованиям к оборудованию и программному обеспечению операторов почтовой · Приложение № 6 к Требованиям к оборудованию и программному обеспечению операторов почтовой · Приложение № 7 к Требованиям к оборудованию и программному обеспечению операторов почтовой · Приложение № 8 к Требованиям к оборудованию и программному обеспечению операторов почтовой
Текст распознан со скана официальной публикации (pravo.gov.ru) и может содержать ошибки распознавания. Официальным является опубликованный документ.
МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММ
(МИНКОМСВЯЗЬ РОСИИ ГиСТРИРОВАНО
Москва
ИЙСКОЙ ФЕДЕРАЦИИ
Об утверждении Требований к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных 06 оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий
В целях реализации требований части 2 статьи 64 Федерального закона от 7 июля 2003 г. № 126-ФЗ «О связи» (Собрание законодательства Российской Федерации, 2003, № 28, ст. 2895; № 52, ст. 5038; 2004, № 35, ст. 3607; № 45, ст. 4377; 2005, № 19, ст. 1752; 2006, № 6, ст. 636; № 10, ст. 1069; № 31, ст. 3431, ст. 3452; 2007, № 1, ст. 8; № 7, ст. 835; 2008, № 18, ст. 1941; 2009, № 29, ст. 3625;
2010, № 7, ст. 705; № 27, ст. 3408; № 31, ст. 4190; 2011, № 9, ст. 1205; № 25, ст. 3535; № 27, ст. 3880; № 29, ст. 4291; № 30, ст. 4590; № 45, ст. 6333; № 49, ст. 7061; № 50, ст. 7351, ст. 7366; 2012, № 31, ст. 4322, ст. 4328; № 53, ст. 7578; 2013, № 19, ст. 2326; № 27, ст. 3450; № 43, ст. 5451; № 44, ст. 5643; № 48, ст. 6162; № 49, ст. 6339, ст. 6347; № 52, ст. 6961, ст. 5038; 2014, № 6, ст. 560; № 14, ст. 1552; № 19, ст. 2302; № 26, ст. 3366; № 30, ст. 4229), пунктов 4, 6, 11 Правил взаимодействия операторов связи с уполномоченными государственными = органами, осуществляющими оперативно-разыскную деятельность, ° утвержденных постановлением. Правительства Российской Федерации от 27 августа 2005 г. № 538 (Собрание законодательства Российской Федерации, 2005, № 36, ст. 3704; 2007, № 48, ст. 6010; 2008, № 42, ст. 4832; 2013, № 15, ст. 1804),
ПРИКАЗЫВАЮ:
1. Утвердить прилагаемые Требования к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий (далее — Требования).#❝
2. Операторы почтовой связи обязаны обеспечить выполнение Требований не позднее одного года со дня утверждения плана мероприятий по внедрению технических средств, предусмотренного Правилами взаимодействия операторов связи с уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность, утвержденными постановлением Правительства Российской Федерации от 27.08.2005 № 538.#❝
3. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.#❝
4. Контроль за исполнением настоящего приказа возложить на заместителя Министра связи и массовых коммуникаций Российской Федерации М.Я. Евраева.#❝
УТВЕРЖДЕНЫ приказом Минкомсвязи России ot 28.07_909/5т. № 777#❝
Требования к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий#❝
1. Общие требования к информационным системам, содержащим базы данных абонентов оператора связи и предоставленных им услугах связи#❝
Технические средства оперативно-розыскных мероприятий, содержащие базы данных операторов почтовой связи (далее — Onc’), необходимые для обеспечения проведения оперативно-розыскных мероприятий на сетях почтовой связи, предназначены для накопления, хранения, обработки и предоставления уполномоченным государственным органам, осуществляющим в соответствии с Федеральным законом от 12.08.1995 № 144-ФЗ «Об оперативно-розыскной деятельности» (Собрание законодательства Российской Федерации, 1995, № 33, ст.#❝
3349; 1997, № 29, ст. 3502; 1998, № 30, ст. 3613; 1999, № 2, ст. 233; 2000, № 1, ст. 8; 2001, № 13, ст. 1140; 2003, № 2, ст. 167; № 27, ст. 2700; 2004, № 27, ст. 2711; № 35, ст. 3607; 2005, № 49, ст. 5128; 2007, № 31, ст. 4008, ст. 4011; 2008, № 18, ст. 1941; № 52, ст. 6227, ст. 6235, ст. 6248; 2011, № 1, ст. 16; № 48, ст. 6730; № 50, ст. 7366; 2012, № 29, ст. 3994; № 49, ст. 6752; 2013, № 14, ст. 1661; № 26, ст. 3207; № 44, ст. 5641; № 51 ст. 6689) оперативно-розыскную деятельность (далее — уполномоченные органы), информации о пользователях услуг связи, оказанных им услугах связи, а также иной информации.#❝
1.1. Настоящие требования распространяются на ТС OPM, используемые и/или подлежащие установке на сетях операторов связи, осуществляющих деятельность в области оказания услуг почтовой связи.#❝
1.2. Устанавливаемые операторами связи на информационные системы операторов почтовой связи ТС ОРМ должны представлять собой АПК, обеспечивающий процессы сбора, регистрации, обработки, хранения и передачи уполномоченным органам информации о пользователях услугами почтовой связи и предоставленных им услугах связи, поступающей от одного или нескольких операторов почтовой связи.#❝
1.3. ИС ОПС обеспечивают передачу на ТС OPM информации обо всех оказанных услугах почтовой связи и пользователях услугами почтовой связи в соответствии с Приложением №1.#❝
2.1.1. организацию БД для накопления, хранения в течение трех лет и обработки информации о пользователях услуг связи, оказанных им услугах связи, иной информации;#❝
2.1.2. прием и первичную обработку информации о пользователях услуг связи и оказанных им услугах связи из ИС ОПС от одного или нескольких операторов связи для занесения в БД ТС ОРМ;#❝
2.1.3. добавление в БД ТС ОРМ информации об оказанных услугах почтовой связи, независимо OT. того, присутствует или нет в БД TC OPM информация об абонентах (пользователях), которым услуги связи предоставляются;#❝
2.1.4. ИС ОПС выполняют передачу информации на ТС ОРМ о пользователях услуг связи и оказанных им услугах почтовой связи не реже одного раза в час;#❝
2.1.5. зациту от несанкционированного доступа к данным ТС ОРМ с помощью программных и технических средств, а также организационных мер;#❝
2.1.6. круглосуточный автоматизированный удаленный доступ к ТС ОРМ со стороны ПУ уполномоченных органов;#❝
2.1.7. прием из ПУ различных видов запросов о пользователях услуг связи и оказанных им услугах связи;#❝
2.1.9. регистрацию и хранение поступающих запросов, удаление запросов уполномоченными пользователями.#❝
22. ТС OPM должны являться завершенным модульным АПК, предоставляющим возможность оператору связи ввода в эксплуатацию с любого набора услуг, согласно лицензиям на предоставление услуг связи. Модульное построение должно обеспечивать возможность расширения (замены) состава аппаратных и программных средств ТС ОРМ для улучшения эксплуатационных характеристик ТС ОРМ по мере увеличения количества абонентов, возрастания объемов обрабатываемой информации, расширения функций системы без изменения информации, хранящейся в уже сформированных базах данных.#❝
2.5. Доступ технического персонала оператора связи к ТС ОРМ должен осуществляться через модуль доступа, который обеспечивает запись команд управления ТС ОРМ и построение парольной системы.#❝
2.6. TC OPM должны исключать возможность передачи любой информации, касающейся функционирования ТС ОРМ на оборудование ИС ОПС.#❝
2.8. Проведение организационно-технических мероприятий должно обеспечивать защиту ТС ОРМ от несанкционированного доступа:#❝
2.11. Источник информации должен иметь возможность осуществлять ввод информации в ТС OPM в соглаёованном с поставщиком TC OPM формате в автоматическом и/или автоматизированном режиме.#❝
2.12. Для технического персонала оператора связи TC OPM должны предоставлять следующие функции:#❝
2.13. Технический персонал оператора связи, обслуживающий ТС ОРМ, должен иметь доступ только через специальные технические средства защиты.#❝
2.14. Если в связи со структурой организации сети связи ОПС обслуживает одновременно несколько входящих в его структуру территориальнораспределенных филиалов по субъектам Российской Федерации (отдельных юридических лиц), то ТС ОРМ могут накапливать информацию об абонентах и оказанных им услугах связи для нескольких филиалов ОПС.#❝
При обращении ПУ с поисковыми задачами к ТС ОРМ ПУ должен иметь возможность явно задавать перечень филиалов, для которых должна выполняться поисковая задача.#❝
При явном указании списка филиалов оператора в параметрах поисковой задачи, запрос в целом должен выполняться в соответствии с временными характеристиками, приведенными в Разделе 3 «Требования, предъявляемые к временным характеристикам ТС OPM и БД» настоящих Требований. Обновление в БД ТС ОРМ информации об абонентах и оказанных им услугах связи но каждому филиалу (другому юридическому лицу) должно выполняться в соответствии сп. 2.1.4. настоящих Требований.#❝
2.15. В случае, если какая-либо составная часть информации об абонентах оператора связи хранится в неструктурированном строковом виде (т.е. не разделенная на составные части в соответствии с описанием таких данных об абонентах согласно Приложению № 7), при выполнении запросов об абонентах ТС ОРМ должны осуществлять полнотекстовый поиск по такой неструктурированной информации, используя поисковые критерии задачи.#❝
3.1. Время выполнения задач в БД ТС ОРМ поиска информации о пользователях и оказанных им услугах связи не превышает значений, приведенных в Таблице 1.#❝
Требования к временным характеристикам поиска информации в ТС ОРМ разделяются по следующим классам:#❝
— класс 1 (K1) включает критерии: — идентификатор почтового отправления; — класс 2 (К2) включает критерии:#❝
— фамилия, имя, отчество (при наличии), наименование организации пользователя услугами почтовой связи;#❝
— почтовый адрес пользователя услугами почтовой связи; — паспортные данные пользователя услугами почтовой СВЯЗИ, — номер договора на оказание услуг почтовой СВЯЗИ,#❝
3.2. ТС OPM должны поддерживать возможность выполнения комбинированных запросов. Комбинированными запросами являются поисковые критерии согласно п. 3.1., объединенные логическими операциями.#❝
ТС OPM должны поддерживать следующие логические операции для объединения критериев: «И», «ИЛИ» операции группировки критериев «(», «)» и логическое «НЕ».#❝
Использование критериев с использованием операции логического «НЕ» допускается только совместно с другими критериями, не являющимися логическим отрицанием, и объединяется с ними с помощью логических операций объединения критериев. Результирующий критерий должен иметь хотя бы одну логическую операцию «И».#❝
К времени поиска информации в БД ТС ОРМ при выполнении комбинированных поисковых запросов предъявляются следующие требования:#❝
— при выполнении поискового запроса по двум поисковым критериям в ` зависимости от вида логической операции:#❝
— для операции «И»: Т(АВ) — максимум (T(A), T(B))*C, но меньше, чем T(A) + T(B), где С — константа (допускается значение больше единицы), T(A), Т(В) - время выполнения поисковых запросов по каждому из критериев, Т(АВ) - время выполнения поискового запроса по критериям, объединенным операцией «И»);#❝
— для операции «ИЛИ»: Т(АВ) меньше или равно T(A) + T(B), где A, Впоисковые критерии, Т(А), Т(В) — время выполнения поисковых запросов по каждому из критериев, Т(АВ) — время выполнения поискового запроса по критериям, объединенным операцией «ИЛИ»);#❝
— для операции «НЕ»: Т(А(«НЕ» B)) меньше либо равно T(AB), где А, В — поисковые критерии, Т(АВ) время выполнения поискового критерия без операции логического «НЕ»;#❝
— при выполнении комбинированного поискового запроса но большему числу критериев (больше двух), требования ко времени поиска должны формироваться аналогично описанному выше способу с учетом операций группировки критериев:#❝
Приложение № 1 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России ot 3.07. 2279 № LIP#❝
ТС ОРМ должны позволять накапливать следующую информацию о пользователях услугами почтовой связи: — ДЛЯ абонента - юридического лица:#❝
почтовый индекс; для юридических лиц, с которыми заключен договор на оказание услуг полное наименование юридического лица, идентификатор филиала оператора связи;#❝
фамилию, имя, отчество (при наличии) контактного лица; контактные телефоны; | список контактных электронных адресов;#❝
Информация накапливается для юридических лиц, заключивших договоры на предоставление услуг почтовой связи.#❝
ТС ОРМ должны позволять накапливать следующую информацию об отправителе, получателе почтового отправления: — для абонента - физического лица: — фамилия, имя, отчество (при наличии);#❝
— полное наименование юридического лица; фамилия, имя отчество (при наличии) отправителя (контактного лица); — контактные телефоны;#❝
1.3. ТС ОРМ должны позволять накапливать следующую информацию об оказанных услугах почтовой связи:#❝
— информация об отправителе (юридическое или физическое лицо); — информация о получателе (юридическое или физическое лицо); — информация об узле назначения (получателя):#❝
тип операции по обработке отправления на узле почтовой связи; — информация об узле обработки почтового отправления:#❝
Приложение № 2 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России ot J3.07 2/5 № 274#❝
1.2.1. Сетевой интерфейс первого уровня с протоколом TCP/IP используется для первичного подключения аппаратуры передачи данных — модемов, маршрутизаторов и т.п.#❝
1.2.2. Для каждой ТС ОРМ внутри сетевого интерфейса первого уровня рекомендуется создавать свою виртуальную сеть VPN (Virtual Private Network) для туннелирования всего рабочего TCP/IP трафика между ТС ОРМ и пунктом управления, которая должна соответствовать спецификации L2TP, IPSec VPN.#❝
1.3. . Пропускная способность каналов передачи данных между TC OPM и ПУ в точках подключения соответствует ‘данным, приведенным в Таблице | Приложения № 2:#❝
Таблица 1 Количество почтовых отправлений ОПС (миллион/сутки), 0, 1 10 100 не более 1 Скорость передачи данных 1 20 10 10000 (кбит/сек), не менее 024 48 000 1.4. Взаимодействие ТС ОРМ с оборудованием ПУ на транспортном уровне осуществляется по схеме «клиент — сервер»: — вкачестве «сервера» должна выступать TC OPM; — вкачестве «клиента» выступает оборудование ПУ.#❝
1.4.6. xn 1, кпд 2, umm 3, кпд 4 представляют собой ТСР-соединения, создаваемые для подключения на заранее определенные порты оборудования ТС ОРМ. ТС ОРМ выполняет прослушивание данных портов для создания TCPсоединений с ПУ.#❝
1.5. ПУ выполняет попытки установления подключения с ТС ОРМ в соответствии с задаваемым интервалом по предоставленным ТС ОРМ ТСР-портам.#❝
1.5.1. Установление ПУ соединений с ТС OPM по каналам кпд 1, кид 2 осуществляется в следующей последовательности:#❝
— выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения;#❝
— выполняется процедура взаимной SSL/TLS аутентификации в соответствии с п. 1.20 настоящего Приложения#❝
1.5.2. Установление ПУ соединений с TC OPM по каналам кпд Зи кал 4 осуществляется независимо друг от друга и от наличия установленных соединений по каналам кпд 1 икпд 2:#❝
1.6. После успешной аутентификации ПУ посылает на ТС ОРМ команды в соответствии с Приложением № 7.#❝
1.7. ПУ разрывает соединения с ТС OPM, если в течении трех периодов приема «сигнала» Heartbeat в каналах не было сетевой активности. При отсутствии подтверждения посланного «сигнала» Heartbeat в течении времени «максимальный размер задержки подтверждения запроса или сигнала» TC OPM разрывает соединения с ПУ по соответствующему каналу.#❝
1.8. TC OPM должны обеспечивать одновременное подключение нескольких ПУ. Максимальное количество одновременно подключенных ПУ для одной ТС ОРМ - 100. ТС ОРМ обслуживает подключенные ПУ независимо друг от друга.#❝
1.9. В ТС ОРМ на одновременном выполнении могут находиться не менее 50 одновременно запущенных задач, осуществляющих подготовку данных.#❝
1.10. Каждому идентифицированному на ТС ОРМ ПУ назначается приоритет выполнения задач. В случае поступления на ТС ОРМ задач от различных ПУ вероятность постановки на выполнение задачи конкретного ПУ зависит от назначенного приоритета данного ПУ и приоритетов других ПУ. Распределение вероятности запуска задач от различных ПУ задается приоритетом каждого конкретного ПУ. Конфигурация по умолчанию должна обеспечивать равномерное распределение вероятности запуска задач от каждого ЦУ. ТС ОРМ должны обеспечивать возможность конфигурирования приоритетов ПУ. ТС ОРМ должны обеспечивать одновременное выполнение задач по каждому идентифицированному ПУ:#❝
1.11. Единицей обмена в кпд 1, кпд 2, кпд 3 и кпд 4 является «Сообщение» (Message). Форматы «Сообщений» описаны в Приложении № 7 на языке абстрактного описания синтаксиса (ASN.1) согласно ГОСТ Р ИСОЛМЭК 8824-1- 2001. Способ кодирования сериализованных «Сообщений» соответствует отличительным (DER) по ГОСТР ИСОЛМЭК 8825-1-2003.#❝
1.12. Интерфейс взаимодействия между ПУ и TC ОРМ предусматривает наличие следующих видов «Сообщений»:#❝
1.13. Интерфейс взаимодействия между ПУ и TC OPM по каналу кпд 3 предусматривает наличие следующих видов «Сообщений»: |#❝
1.14. Интерфейс взаимодействия между ПУ и ТС ОРМ по каналу кпд 4 предусматривает наличие следующих видов «Сообщений»:#❝
115. ТС ОРМ выполняет любые действия, связанные с выдачей информации о пользователях услуг связи и предоставленных им услугах связи, управлением и мониторингом КТС и ПО ТС ОРМ только по «запросам» ПУ.#❝
1.15.2. TC OPM должны обеспечивать одновременную передачу блоков. данных отчетов для нескольких завершенных поисковых задач по каналу кпд 2. ТС OPM должны обеспечивать возможность многократной передачи отчетов выполненных задач на ПУ.#❝
1.15.3. По запросу ПУ «Запрос загрузки данных» канала кпд 1 TC OPM должны обеспечивать передачу блоков отчетов по каналу KIT 2 по запрошенной задаче без внесения дополнительных временных задержек между операциями по получению записей результата задачи и преобразования их в блоки.#❝
1.15.4. На каждый «запрос» по кпд 1 ТС OPM на ПУ посылается «ответ» о принятии к обработке этого запроса. ТС ОРМ обеспечивают посылку по кпд 1 на ПУ следующих «ответов»:#❝
1.15.5. По «Запросу на создание задачи по обработке информации» ТС ОРМ обеспечивают подготовку и выдачу информации из БД ТС ОРМ для следующих групп задач:#❝
В группу «Задачи пополнения справочников (нормативно-справочная информация)» входят запросы на получение информации справочников:#❝
— «Задача на поиск информации об идентификаторах абонентов сети оператора связи зарегистрированных на физическое или юридическое лицо» (AbonentsTask).#❝
Поиск информации выполняется в накапливаемой TC ОРМ информации о юридических лицах, заключивших договоры на предоставление услуг почтовой Связи.#❝
В случае, если в качестве параметров «задачи на поиск соединений абонентов» указаны только диапазон времени и (опционально) филиал оператора#❝
1.15.6. По «Запросу на создание задачи по обработке неформализованных `данных» ТС OPM обеспечивают подготовку и выдачу информации из БД ТС OPM по следующим видам запросов:#❝
1.15.8. ТС ОРМ по «задаче поиска неформализованных данных» могут предоставлять доступ ПУ к системным журналам ТС ОРМ.#❝
1159. ТС ОРМ должны обеспечивать выполнение поисковых задач по строковым критериям, содержащими символы маскирования, включающие:#❝
1.15.10. В случае возникновения в ТС ОРМ исключительных ситуаций на ПУ передаются следующие «Сообщения» типа «Сигналы», содержащие информацию об уровне важности исключительной ситуации, ее влиянии на сохранность данных и выполнение задач:#❝
— «Нет данных (связи) с ИС ОПС» — посылается в случае отсутствия OT ИС ОПС информации в течение трех часов либо при отсутствии связи с ИС ОПС;#❝
1.20. — При установлении соединения ПУ и ТС ОРМ должны быть взаимно аутентифицированы. Аутентификация выполняется установлением SSL/TLSсоединения поверх установленного ТСР-соединения между ПУ и ТС ОРМ. Для взаимной аутентификации ПУ и ТС ОРМ предварительно создаются Х.509- сертификаты, которые сообщаются ПУ и ТС ОРМ. В случае невозможности аутентифицировать одну из сторон ТСР-соединение разрывается. Созданный для ПУ сертификат используется для аутентификации только одного данного ПУ на одной ТС OPM по всем каналам передачи данных — кпд 1, кид 2, кид 3, кпд 4. ПУ и ТС OPM должны использовать TLS версии 1.0. Требования к сертификатам (длины ключей, прочие параметры) должны согласовываться для каждой пары ТС ОРМ и ПУ отдельно. | |.#❝
1.21. Открытие сессии осуществляется выполнением процедуры аутентификации согласно п. 1.20 настоящего Приложения перед началом выполнения всех запросов. Открытие сессии осуществляется посылкой по каналу управления от ПУ кТС ОРМ «Запроса на открытие сессии» (ConnectRequest).#❝
1.22. «Запрос на открытие сессии» устанавливает следующие параметры сессии:#❝
1.22.1. ТС ОРМ при получении сообщения «Запрос на открытие сессии», анализируют параметр «размер окна для канала передачи данных», определяет максимально возможный размер окна, не превышающий полученного от ПУ. ТС ОРМ определяют минимальные значения таймаутов из параметров сессии, выбирая их не меныше, чем переданные в сообщении «Запрос на открытие сессии» (ConnectRequest). Рассчитанные значения размеров окна и таймаутов ТС ОРМ передает на ПУ в сообщении «Ответ на открытие сессии» (ConnectResponse).#❝
1.23. Закрытие сессии осуществляется посылкой по каналу управления или каналу мониторинга от ПУ к ТС ОРМ «Запроса на закрытие сессии» или по истечению допустимого времени отсутствия активности ТС ОРМ, с посылкой сообщения-сигнала «Прерывание текущей сессии по таймауту». При этом ТС ОРМ и ПУ осуществляют разрыв текущих ТСР соединений канала управления и канала данных или канала мониторинга или канала неформатированных данных#❝
124. ПУ посылает ТС ОРМ «запросы» асинхронно, независимо от получения от ТС ОРМ «ответа» о приеме предыдущего «запроса».#❝
1.25. «Запрос на создание задачи по обработке информации» приводит к созданию в ТС ОРМ задачи по обработке данных в БД ТС ОРМ, которой присваивается номер (идентификатор) задачи, передаваемый в «Ответе на запрос создания задачи» (TaskResponse). Идентификаторы задач генерируются ТС ОРМ независимо от сессий и являются уникальными в данной ТС ОРМ. ТС ОРМ присваивают идентификаторы задачам и выполняет обработку задач независимо для различных ПУ. |#❝
1.26. ПУ получает информацию о ходе выполнения и завершения обработки задач в ИС, посылая запрос «Запрос готовности данных». После завершения выполнения задачи, данные, сформированные в результате выполнения задачи, становятся доступными для загрузки в ПУ или для удаления.#❝
127. ТС OPM при получении «Запрос загрузки данных» по кпд 1 формируют сообщения типа «отчет», состоящие из блоков данных обработанной задачи и передает их на ПУ по кпд 2.#❝
1.28. Количество строк в каждом блоке не превышает параметр «максимальный размер блока данных отчетов», заданный при открытии сессии.#❝
1.29. В каждом последовательном блоке данных из серии указываются идентификатор задачи, сгенерировавшей данный отчет, общее количество блоков в отчете, порядковый номер каждого блока.#❝
1.30. Данные задачи, полученные в одной сессии, могут быть считаны и/или удалены в другой сессии ПУ, инициировавшим данную задачу. Данные по#❝
При получении задачи «запрос загрузки данных» (DataLoadRequest) от ПУ, не являющегося инициатором данной задачи, ТС ОРМ посылают ответ на «запрос загрузки данных», в котором указывается отсутствие результата исполнения задачи (data-exists), а в поле «краткое описание ошибки» (error-description) записывается расшифровка отказа в доступе к данным задачи. Далее ТС ОРМ посылают на этот ПУ «сигнал» попытки несанкционированного доступа (unauthorized-access) и ожидают его подтверждения.#❝
Приложение № 3 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России#❝
12. Если $91/П.-соединения по каналам управления и данных установлены, а сессия не открыта, TC OPM должны реагировать только на сообщение «Запрос на открытие сессии». При попытке посылок каких-либо других сообщений со стороны ПУ TC OPM должны разорвать TCP соединения по каналу управления и каналу данных и перевести канальный уровень подключения в исходное состояние.#❝
1.3. При получении сообщения «Запрос на открытие сессии» ТС ОРМ создают список поддерживаемых ТС ОРМ типов запросов, отчетов и сигналов (в том числе и предыдущих версий) и отсылают его.#❝
1.4. После отсылки списка поддерживаемых типов ТС ОРМ ожидают от ПУ списка поддерживаемых им запросов, отчетов и сигналов. Список поддерживаемых ПУ типов должен являться подмножеством списка типов в ТС ОРМ.#❝
1.5. При получении от ПУ списка поддерживаемых ПУ запросов ТС ОРМ посылают сообщение «Ответ на согласование списка поддерживаемых типов» и создает сессию.#❝
1.6. После создания сессии кпд 1 ТС OPM переводятся в режим ожидания команд от ПУ. При поступлении команды со стороны ПУ производится ее выполнение и формируется результат. Результат в виде сообщения «ответа» отправляется на ПУ. - 1.7. В случае серьезного сбоя в TC OPM, вызванного причинами, не предусмотренными режимом нормального функционирования системы, по каналу управления передаётся «сигнал» — «Критическая ошибка ПО, потеря. данных, дальнейшая работа невозможна», с соответствующим описанием проблемы. Все задачи, которые были в процессе выполнения, когда произошел сбой, а также данные выполненных задач, поврежденные в результате произошедшего сбоя, имеют «признак результата выполнения задачи» (TaskResult) равный значению «ошибка»(етгог) с соответствующим описанием проблемы. В случае, если для восстановления работоспособности ТС ОРМ требуется их перезагрузка, то по каналу управления выдается прерывание «Перезапуск ПО». В этом случае TC OPM и ПУ закрывают все открытые на текущий момент сессии.#❝
1.8. В случае наличия признаков сбоя или ошибки выполнения конкретной задачи ТС ОРМ в режиме нормального функционирования по каналу управления передаётся прерывание «Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна», с соответствующим описанием проблемы. Результат выполнения данной задачи имеет «признак результата выполнения задачи» (TaskResult), равный значению «ошибка»(етог), с соответствующим описанием проблемы.#❝
19. Ha каждый «сигнал», переданный TC OPM, ITY должно ответить сообщением «подтверждение сигнала» по кпд 1. Отсутствие подтверждения в течение времени RequestResponseTimeout, которое задается при открытии сессии,#❝
1.10. При отсутствии команд ПУ в течение «максимального времени неактивности» (session-timeout, задается в ConnectRequest), ТС OPM посылают Ha ПУ «сигнал» Heartbeat и ожидает его подтверждения аналогично описанному в п.#❝
1.11. Диаграмма состояний переходов ПУ по кпд 1 приведена на 1 настоящего Приложения. | accept accept, SSL/TLS handshake Установление TCPсоединения#❝
Таймаут выполнения поддерживаемых типов И команды {гезропзе-бтеоц!) paseo СОРМ р либо ошибка ТСРсоединения#❝
„7 = 7S . “< = 7S подтвержденного списка юддерживаемых типо! { Обработка команды { Обработка сигнала ) дер ` `` 7 \ и `- -_- -“ = `- —- 7“ 7#❝
Ожидание результата Таймаут выполнения (response) команды (request-responsetimeout) или ошибка TCPсоединения#❝
1.12. ПУ с задаваемым интервалом выполняет попытки установления TCPсоединения с TC OPM по заданному порту кпд 1. После установления соединения выполняется взаимная $5/ТГ5-аутентификация.#❝
1.14. После установления ТСР-соединения по кпд 2 и прохождения по нему взаимной аутентификации TC OPM и ПУ, ПУ по кпд | посылает команду создания сессии (ConnectRequest).#❝
1.15. ПУ ожидает сообщения «ответ» от ТС ОРМ на отправленную команду в течение времени «таймаут ответа на запрос» (request-response-timeout).#❝
1.16. Если сообщение не получено в течение времени «таймаут ответа Ha запрос», ПУ разрывает соединения с ТС ОРМ по кпд 1 и кид 2 и переводит их в изначальное состояние (п. 1.12). Время ожидания сообщения «ответ» не зависит от приема сообщений «сигналов», поступающих в этот интервал времени.#❝
1.17. При получении сообщения «Ответ на запрос создания сессии» ПУ создает список поддерживаемых ПУ типов запросов, отчетов и сигналов и отправляет его ТС ОРМ. Список поддерживаемых ПУ типов должен быть подмножеством списка типов TC OPM, полученных в п. 1.15 настоящего Приложения.#❝
1.18. После отправки сообщения «Согласование поддерживаемых типов со стороны ПУ» ПУ ждет ответа на сообщение от ТС ОРМ. Поведение ПУ при ожидании ответа аналогично описанному в п. 1.16 настоящего Приложения.#❝
1.19. Если во время ожидания сообщения «ответ» ТС ОРМ посылают на ПУ сообщение «сигнал» (в т.ч. Heartbeat), то ПУ посылает «подтверждение» о принятии «сигнала» (в тм. Heartbeat) и продолжает ожидать сообщение «ответ» на отосланную команду.#❝
1.20. После создания сессии ПУ посылает поступающие команды на TC OPM и ожидает сообщений «ответов» на них в соответствии с п. 1.15, 1.16, 1.19 настоящего Приложения.#❝
1.21. Если при ожидании поступления в ПУ команд ТС ОРМ не посылала «сигнал» Heartbeat в течение трех интервалов «максимального времени неактивности» (session-timeout, задается в ConnectRequest) ПУ разрывает соединения с TC OPM по кпд | и кпд 2 и переводит их в изначальное состояние (п. 1.12 настоящего Приложения).#❝
1.22. При поступлении команды «запрос на закрытие сессии» (DisconnectRequest) ПУ отсылает ее Ha ТС ОРМ, ожидает сообщения «ответ» в соответствии с п. 1.15, 1.16, 1.19 настоящего Приложения, после чего разрывает соединение по кпд 2 и кпд | и переводит их в изначальное состояние (п. 1.12 настоящего Приложения).#❝
Приложение № 4 к Требованиям оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России#❝
1.1. TC OPM обеспечивают подключение ПУ и обработку поступающих запросов по каналу кпд 2 в соответствии с приведенными диаграммами состоянии переходов.#❝
1.2. Рисунок Приложения 4. pt SSLTLS handshake эссе Ожидание ТСР- Установление ТСР- SSUTLS соединения соединения аутентификация#❝
_---- -.-- —— и Подтверждение блока Прерывание № x {AcknowledgementPOU) | передачи Запуск процедуры see 7 ~ oo 2-4“ передачи Таймаут Yc Pa = . „7 “A { Посылка сигнала ) 4 Начало передачи ) Проверка списка эктмвных х Heartbeat ‘eo р” эьдьч передачи данных < - ed у#❝
13. ТС ОРМ по ТСР-порту кпд 2 ожидают входящих соединений. После установления соединения выполняется взаимная SSL/TLS-aytenTugukaua.#❝
14. Если на TC OPM была передана «запрос загрузки данных» (DataLoadRequest), TC OPM посылают «ответ на запрос загрузки данных» (DataLoadResponse) по каналу кпд 1 и начинает передачу данных блоков отчетов по кпд 2 при их наличии. ПУ может получить блоки отчетов по кпд 2 до получения «ответа на запрос загрузки данных» (DataLoadResponse) по кпд 1.#❝
1.5. Если количество переданных без получения «подтверждения» о принятии серии блоков «отчетов» по всем задачам, по которым выполняется загрузка на ПУ данных, меньше «окна канала передачи данных» (параметр data-packet-window-size в запросе создания сессии ConnectRequest), то TC OPM выполняют подготовку новых блоков отчетов по загружаемым задачам и посылают их на ПУ. Количество подготовленных и переданных без получения «подтверждения» блоков не должно превышать размера окна канала передачи данных.#❝
1.6. Максимальная задержка подтверждения приема блока данных со стороны ПУ не превышает параметр «таймаут подтверждения приема блока данных отчета» (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не отправляются и по каналу управления передается «сигнал» «Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна» с соответствующим описанием проблемы, при этом в ноле areference-message” сообщения «сигнал» указывается идентификатор сообщения блока отчета, по которому не поступило подтверждение приема.#❝
1.7. При получении «подтверждения» блока «отчета» ТС ОРМ должны записать информацию об ошибочно принятом НУ блоке и ошибочных записях в блоке в специальный журнал, передача последующих блоков по задаче на ПУ не прерывается. ТС ОРМ должны предоставлять техническому персоналу оператора связи доступ к журналу с записями об ошибочно принятых на ПУ блоках отчетов и средства исправления ошибочных данных в отчетах. Подтвержденные блоки исключаются из окна канала передачи данных (в окне канала передачи данных остаются только неподтвержденные блоки).#❝
1.8. В случае разрыва TCP/IP соединения кпд 2 при существующем соединении кпд 1 по кпд 1 передаётся прерывание «Незначительная опгибка ПО, данные не потеряны, дальнейшая работа возможна» с соответствующим описанием проблемы, работа в данном случае не прекращается, выполняется установление соединения по кпд 2 в соответствии с п. 1.20 Приложения 2.#❝
1.9. Передача блоков данных может быть прервана в случае получения ТС ОРМ «запроса прерывания загрузки данных».#❝
1.10. Всли по кнд 2 не производится передача блоков отчетов в течение «максимального времени неактивности» (session-timeout при создании сессии ConnectRequest), TC OPM посылают на ПУ «сигнал» Heartbeat и ожидает ero подтверждения аналогично описанному в п. 1.9 Приложения 3.#❝
1.11. Диаграмма состояний переходов ПУ по кпд 2 приведена на Рисунок Приложения № 4.#❝
1.12. ПУ с задаваемым интервалом выполняет попытки установления TCPсоединения с ТС OPM по заданному порту кпд 2. После установления соединения выполняется взаимная 55Г./ТГ.$-аутентификация.#❝
1.13. При поступлении «запроса загрузки данных конкретной задачи» (DataLoadRequest) ПУ ожидает начала передачи данных в течение времени «таймаут начала передачи блоков отчетов» (data-load-timeout в ConnectRequest). Если данные не поступают в течение вышеописанного периода, то ПУ разрывает соединения по каналам кпд | и кпд 2 и переводит соединения в изначальное состояние (п. 1.12 Приложения 3, п. 1.12 настоящего Приложения).#❝
1.14. При поступлении блока отчета ITY производит декодирование полученного блока и сохранение декодированных данных.#❝
1.15. В ответ на переданный блок данных ПУ посылает сообщение «подтверждение» получения блока отчета. Количество последовательно переданных ТС OPM блоков данных без подтверждения со стороны ПУ определяется параметром «размер окна канала передачи данных», который согласовывается при создании сессии. При подтверждении блока отчета ПУ может сигнализировать об ошибке декодирования блока. В этом случае в сообщении «подтверждение» приема для ошибочно декодированного блока ПУ, в случае возможности, указывает номер записи в блоке, начиная с которой декодирование не удалось.#❝
1.16. Если при ожидании поступления в ПУ блоков отчетов ТС ОРМ не посылала «сигнал» Heartbeat в течение трех интервалов «максимального времени неактивности» (session-timeout, задается в ConnectRequest), ПУ разрывает соединения с TC OPM по кпд | и кпд 2 и переводит их в изначальное состояние _ (п. 1.12 Приложения № 3, п. 1.12 настоящего Приложения).#❝
Приложение № 5 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России oT 24 027.705№ 279#❝
1.1. ТС ОРМ обеспечивают подключение ПУ и обработку поступающих запросов по каналу кпд 3 (канал мониторинга).#❝
1.2. TC OPM обеспечивают прием и обработку следующих ВИДОВ запросов от ПУ по каналу кпд3З (канал мониторинга):#❝
1.3. Ha каждый запрос по кпдЗ TC OPM посылает ответ на ПУ, содержащий результат обработки соответствующего запроса — «ManagementResponse».#❝
1.6. ТС OPM по ТСР-порту кпд 3 ожидают входящих соединений. После установления соединения выполняется взаимная 55Т./ТТ.5-аутентификация.#❝
1.7. Если З5Е/ТТ $ -соединение по кпд 3 установлено, а сессия не открыта, ТС ОРМ должны реагировать только на сообщение «Запрос на открытие сессии».#❝
1.8. После создания сессии ТС OPM переводятся в режим ожидания команд от ПУ. Обработка поступающих команд и посылка сигналов производится аналогично описанному в пи. 1.5-1.9 Приложения № 3#❝
1.9. ПУ с задаваемым интервалом выполняет попытки установления TCPсоединения с TC OPM по заданному порту. После установления соединения выполняется взаимная 551./Т1.5-аутентификация.#❝
1.11. Ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ТС ОРМ сигналов по кпд 3 производится ПУ аналогично описанному в пп. 1.15-1.21 Приложения № 3.#❝
1.12. TC OPM должны обеспечивать получение следующих видов информации о структуре и функционировании ТС ОРМ по запросу ПУ:#❝
1.13. В части структуры и состава КТС ТС ОРМ, состава и состоянии интерфейсов взаимодействия КТС ТС ОРМ, ТС ОРМ должны по запросу ПУ предоставлять следующую информацию:#❝
— перечень коммутационного и серверного оборудования, средств хранения данных с его идентификацией; ,#❝
1.14. В части точек подключения ТС OPM к сети оператора связи, интерфейсов ввода информации в ТС ОРМ, ТС ОРМ должны по запросу ПУ предоставлять текущую информацию на момент формирования запроса, содержащую:#❝
1.15. В части состава общесистемного и специального программного обеспечения ТС ОРМ, их текущего состояния, ТС ОРМ по запросу ПУ следующую. информацию:#❝
— текущее состояние (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя; |#❝
Приложение № 6 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России ot 23.02, 20/5 № 279#❝
1.1. ТС OPM обеспечивают подключение ПУ и обработку поступающих запросов по каналу кнд 4 (канал неформатированных данных).#❝
1.3. Ha каждый запрос по кпд 4 TC OPM посылают ответ на ПУ, содержащий результат обработки соответствующего запроса.#❝
14. TC. OPM должны накапливать информацию с неформатированными данными в специальном буфере. Данные в буфере упорядочиваются согласно времени их поступления. Длительность временного хранения информации в буфере — 10 суток.#❝
1.5. ТС ОРМ должны записывать в буфер информацию об оказанных услугах связи, абонентах, с которыми заключены договоры на оказание услуг почтовой связи и справочные данные об операторах (филиалах оператора почтовой связи), отделениях почтовой связи и типах документов, удостоверяющих личность, в виде текстовых файлов.#❝
1.6. ТС OPM должны записывать информацию в буфер циклически, т.е. при переполнении буфера старая информация в нем перезаписывается.#❝
1.7. Диаграмма состояний переходов ТС ОРМ по кпд 4 приведена на Рисунок Приложения № 6.#❝
Ожидание команды ты Команда от ПУ == yo (request) “SN { Выполнение команды Посылка сигнала ) N р х и > - ^ - -- —_-- ~~ -- --- AcknowledgementPDU. --- от ПУ _- -- a“ ~ \ 7 Подтверждение блока ` (AcknowledgementPDU) va < 27 Запуск процедуры Посылка сигнала Выполнение команды передачи Ошибка при Нет ошибок выполнении команды ~~. роверка истечения интервала data- Ox ~ ` packet-response-timeout (а идание Посылка результата ConnectRequest) для блоков в «окне» подтверждения (response) Посылка сигнала ) сигнала U7 Her _- ТР. Возможна посылка соединения результата#❝
1.8. ТС OPM ожидают и устанавливают соединение аналогично описанному в пи. 1.5, 1.6 Приложения № 5.#❝
1.10. При приеме команды «запрос на начало передачи неформатированных данных» ТС ОРМ, находясь в режиме ожидания команд, отсылает «ответ на запрос начала передачи неформатированных данных» и переводит канал кпд 4 в режим передачи данных.#❝
1.11. При приеме команды «запрос Ha остановку передачи неформатированных данных» ТС ОРМ, находясь в режиме ожидания команд, посылает «ответ на запрос остановки передачи неформатированных данных» с отрицательным результатом.#❝
1.12. В режиме передачи данных посылка блоков отчетов и их подтверждение производится аналогично описанному в пп. 1.5, 1.7, 1.10 Приложения № 4.#❝
1.13. Максимальная задержка подтверждения приема блока данных со стороны ПУ не превышает параметр «таймаут подтверждения приема блока данных отчета» (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не отправляются, ТС ОРМ разрывают соединение по кпд 4 и переводит кпд 4 в изначальное состояние. Передача неформатированных данных соответствующего типа производится из буфера кпд 4 (см. п. 1.5 настоящего Приложения).#❝
1.14. При приеме команды «запросе на остановку передачи неформатированных данных» ТС ОРМ, находясь в режиме передачи данных, посылает «ответ на запрос остановки передачи неформатированных данных», завершает посылку блоков данных и переводится в режим ожидания команд.#❝
1.15. При приеме команды «запрос на начало передачи неформатированных данных» ТС ОРМ, находясь в режиме передачи данных, посылает «ответ на запрос начала передачи неформатированных данных» с отрицательным результатом, при этом передача неформатированных данных не прекращается.#❝
1.16. Исходные данные о соединениях в виде неформатированных данных записываются в буфер независимо от текущего режима работы канала кпд 4 ТС ОРМ.#❝
1.17. Если команда «запрос на остановку передачи неформатированных данных» поступила в момент передачи из буфера файловых данных, то передаваемый файл должен сохраняться в буфере и быть доступным для передачи после посылки команды «запрос на начало передачи неформатированных данных» с учетом ограничений по длительности хранения, указанным в п. 1.5.#❝
1.18. Диаграмма состояний переходов ПУ по кид 4.#❝
Невозможна аутентификация ПУ и ИС COPY accept, SSL/TLS ПУи ИС СОРМ однозначно handshake аутентифицированы#❝
(response-timeout) либо ошибка Ожидание ответа на согласования создание сессии со списком поддерживаемых типов ИС СОРМ#❝
Таймаут выполнения Истечение трех команды (response-timeout) ' периодов «сигнала» либо ошибка ТСР-#❝
Сообщение «ВеройРро» Сигнал Ожидание ответа на _---#~ < Да--о согласование списка ca Команда для у ~ а ` оддерживаемых типов / Обработка отчета выполнения 7 ` Р | ) oo { Обработка сигнала ) N (ReportPDU) 57 ~ N ~ „“ и х < „“ -----7 { Обработка команды ) -----7 ы и — ~ „#❝
1.19. ПУ с задаваемым интервалом выполняет попытки установления TCPсоединения с TC OPM по заданному порту. После установления соединения выполняется взаимная З5Т./ТТ.5-аутентификация.#❝
1.20. ПУ по кпд 4 посылает команду создания сессии (ConnectRequest).#❝
‚ 1.21. Ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ТС ОРМ сигналов по кпд 4 производится ПУ аналогично описанному в пи. 1.15 — 1.21 Приложения № 3, за исключением команд «запрос на начало, остановку передачи неформатированных данных» (DataStartRequest/ DataStopRequest).#❝
1.22. При посылке команды «запрос на начало/остановку передачи неформатированных данных», ПУ ожидает результата (DataStartResponse) аналогично описанному в пп. 1.15 — 1.16 Приложения 3, после чего переводит канал кпд 4 в режим передачи данных.#❝
Приложение № 7 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой CBA3H при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России#❝
Структура разделения ASN.1 модулей протокола взаимодействия ПУ и ТС ОРМ приведена на Рисунке 4 Приложения № 7. |#❝
списка типов запросов к ТС ОРМ; списка видов поисковых критериев к ТС ОРМ; списка типов отчетов, формируемых ТС OPM; выполняется ввод новых версий сообщений протокола.#❝
В соответствии с Рисунок , Рисунок в протокольных ASN.1 модулях выполняется подстановка соответствующих версий форматов поисковых критериев, отчетов, справочников, «сообщений» интерфейса взаимодействия ПУ и ТС ОРМ.#❝
— видов «Сообщений» верхнего уровня интерфейса взаимодействия ПУ и ТС OPM, составляющих кпд 1, кд 2, кпд 3, кпд 4;#❝
16. (Соответствующие идентификаторы используются в других ASN.1- модулях интерфейса взаимодействия ПУ и ТС ОРМ (Рисунок настоящего Приложения с модулями), при этом идентификатор определяет конкретную версию и расширения формата соответствующего элемента (поисковых критериев, отчетов, справочников «сообщений» — в соответствии с Рисунок , Рисунком 3 настоящего Приложения).#❝
1.7. Предоставленный TC OPM при создании сессии перечень идентификаторов и согласованное из него ПУ подмножество в целом определяют конкретные возможности взаимодействия ПУ и ТС OPM в соответствии с выбранными идентификаторами.#❝
1.8. Расширение интерфейса взаимодействия ПУ и ТС ОРМ обеспечивается введением новых идентификаторов, определяющих соответствующие расширенные элементы (поисковые критерии, отчеты, справочники, «сообщения»). Кодирование новых вводимых идентификаторов элементов осуществляется в соответствии со структурами на Рисунок , Рисунок настоящего Приложения и стандартным кодированием А$М.1-модуля «Classification.asm».#❝
= abonent _] [ connection | | dictionary ‘| person | № post-connection | | telcos | organization | al money-type | || зреданпитьег | ice] =#❝
[ чзе‘злэудиернзо< | use'sjuauoqyisod | | use’sedA13s0q | | use'sasseippy | | чзе’иодеошезею инАПОМ эчиЛЕчнонои OHLOBWEOD use‘sjusuoqypeysanbay изе-виопозииооразэпЬэн изв pazi|BUO4JUONSHSE L USB'aSUaSAlqSySeL use’sjusuOgySysSeL#❝
Приложение № 8 к Требованиям к оборудованию и программному обеспечению операторов почтовой связи для обеспечения доступа к базам данных об оказанных услугах почтовой связи и пользователях услугами почтовой связи при проведении оперативно-розыскных мероприятий, утвержденным приказом Минкомсвязи России от 22.02 205% 279#❝
AddressType ::= ENUMERATED { physical (0), --- физический legal (1), --- юридический delivery (2), --- доставки счета receive (3), — -- приезда курьера common (4), --- общий other (5) --- другой#❝
ReportedAddress ::= SEQUENCE { address-info AddressInfoReport, --- адрес title AddressType OPTIONAL 7 --- тип адреса#❝
} AddressInfoReport ::= CHOICE { struct-info[0] AddressStructInfoReport, --- структурированный адрес#❝
AddressStructInfoReport ::= SEQUENCE { zip [9] ТЕЗ бете (SIZE (1 .. 32)) OPTIONAL, индекс, 71р-код country [1] UTF8String (SIZE (1 .. 128)) OPTIONAL, region [2] UTF8String (SIZE (1 .. 128)) OPTIONAL, zone [3] UTE8String (SIZE (1 .. 128)) OPTIONAL, муниципальный округ city [4] UTF8String (SIZE (1 .. 128)) OPTIONAL, поселок, деревня street [5] UTES8String (SIZE (1 .. 128)) OPTIONAL, building [6] UTF8String (SIZE (1 .. 128)) OPTIONAL, строение | build-sect [7] UTF8String (SIZE (1 .. 128)) OPTIONAL, apartment [8] UTFS8String (SIZE (1 .. 128)) OPTIONAL офис } RequestedAddress ::= SEQUENCE { address-info RequestedAddressInfo, title AddressType OPTIONAL } RequestedAddressInfo ::= CHOICE { struct-info[0] RequestedAddressStructinfo, структурированный адрес unstruct-info[1] UTF8String(SIZE (1 .. 1024)) неструктурированный адрес } RequestedAddressStructInfo ::= SEQUENCE { country [0] UTFS8String (SIZE (1 .. 128)), region [1] | UTF8String (SIZE (1.. 128)) OPTIONAL, zone [2] UTF8String (SIZE (1 .. 128)) OPTIONAL, муниципальный округ city [3] | UTF8String (SIZE (1 .. 128)) OPTIONAL, поселок, дерев НЯ street [4] UT8String (SIZE (1 .. 128)) OPTIONAL, building [5] UTF8String (SIZE (1 .. 128)) OPTIONAL, строение | build-sect [6] ОТЕЗ$ что (SIZE (1 .. 128)) OPTIONAL, apartment [7] UTF8String (SIZE (1 .. 128)) OPTIONAL, офис zip [8] UTFS8String (SIZE (1 .. 32)) OPTIONAL индекс, 71р-код#❝
BEGIN EXPORTS TAGGED, sorm-message-session, sorm-message-trap, sorm-message-task, sorm-message-report, sorm-message-management, sorm-message-unformatted, sorm-post-abonent-report, sorm-post-office, sorm-post-office-identifier, sorm-report-post-connection, sorm-request-post-connection, sorm-post-abonent-mailing, sorm-requested-post-abonent-person-mailing, sorm-requested-post-abonent-organization-mailing, sorm-reported-post-abonent-person-mailing, sorm-reported-post-abonent-organization-mailing, sorm-post-abonent, sorm-post-abonent-person, sorm-post-abonent-organization, sorm-post-type, sorm-post-type-package, sorm-post-type-money-order, sorm-post-type-secogram, sorm-post-type-postal-wrapper, sorm-post-type-postcard, sorm-post-type-ems, sorm-post-type-small-packet, sorm-post-type-bag-international, sorm-request-dictionaries, sorm-report-dictionary-telcos,#❝
43 sorm-report-dictionary-post-offices, sorm-report-dictionary-doc-types, sorm-request-presense, sorm-report-presense-abonents, sorm-report-presense-connections, sorm-report-presense-dictionaries, sorm-request-abonent, sorm-request-contract, sorm-requested-abonent-organization, sorm-requested-abonent-person, | sorm-report-abonent-abonent, sorm-report-abonent-person, sorm-report-abonent-organization#❝
-- Подструктура сообщений sorm-message-session OID ::= "280" sorm-message-trap OID ::= "6" sorm-message-task OID ::= "282" sorm-message-report OID ::= "7" sorm-message-management ОП ::= "284" sorm-message-unformatted OID ::= "285"#❝
-- Идентификаторы sorm-request-post-connection OID ;:= "21" sorm-post-abonent-mailing ODD ::= "22" sorm-requested-post-abonent-person-mailing ODD ::= "23" sorm-requested-post-abonent-organization-mailing ODD ::= "24"#❝
44 sorm-reported-post-abonent-person-mailing ОП ::= "25" sorm-reported-post-abonent-organization-mailing OID ::= "26" -- Абоненты sorm-request-abonent ОП ::= "180" sorm-request-contract OID ::= "181" sorm-requested-abonent-organization OID ::= "182" sorm-requested-abonent-person OID ::= "183" sorm-report-abonent-abonent OID ::= "30" sorm-report-abonent-person OID ::= "32" sorm-report-abonent-organization OID ::= "33"#❝
-- Пользователи услуг почтовой связи sorm-post-abonent OID ::= "2" sorm-post-abonent-report OID ::= "3" sorm-post-abonent-person OID ::= "4" sorm-post-abonent-organization ОП) ::= "5"#❝
-- Виды почтовых отправлений sorm-post-type OID ::= "60" sorm-post-type-package OID ::= "61" sorm-post-type-money-order OID ::= "62" sorm-post-type-mail OID ::= "63" sorm-post-type-secogram OID ::= "64" sorm-post-type-postal-wrapper OID ::= "65" sorm-post-type-posteard OID ::= "66" sorm-post-type-ems OID ::= "67" sorm-post-type-small-packet OLD ::= "68" sorm-post-type-bag-international OID ::= "69"#❝
-- Справочники sorm-request-dictionaries OID ::= "110" | sorm-report-dictionary-telcos OID ::= "111" sorm-report-dictionary-money-types OID ::= "412" sorm-report-dictionary-post-offices ODD ::= "113" sorm-report-dictionary-doc-types OID ::= "114"#❝
45 sorm-report-presense-abonents OID ::= "120" sorm-report-presense-connections OID ::= "121" sorm-report-presense-dictionaries OID ::= "123" END#❝
IMPORTS DateAndTime FROM Sorm TAGGED, sorm-request-dictionaries, sorm-report-dictionary-telcos, sorm-report-dictionary-post-offices FROM Classification#❝
-- Запрос DictionaryTask ::= SEQUENCE { id TAGGED.&id ({DictionaryTaskVariants}), data TAGGED.&Data ({DictionaryTaskVariants} {@id})#❝
-- Отчёт DictionaryReport ::= SEQUENCE { id TAGGED.&id ({DictionaryRecordsVariants}), --- идентификтор записи справочника data TAGGED.&Data({DictionaryRecords Variants} {@id}) --- данные записи справочника#❝
TelcosRecord ::= SEQUENCE { telco-id § TelcoID, | --- номер филиала или оператора связи begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, | --- время конца действия oe description UTFS8String (SIZE (1 .. 256)). --- описание#❝
MoneyType ::= SEQUENCE { value REAL, —- сумма платежа type-id PrintableString (SIZE (1 .. 3)) --- код валюты по ISO 4217 } .#❝
PostOfficeRecord ::= SEQUENCE { telco-id Тесо О, --- номер филиала или оператора связи ’ index-post PrintableString (SIZE (6 .. 10)) OPTIONAL, —--- индекс узла/отделения почтовой связи office-type ENUMERATED { --- тип узла/отделения почтовой связи international-point (0), --- международное место почтового обмена customs (1), --- место таможенного досмотра regional-centre (2), --- региональный центр simple (3) --- узел почтовой связи }, begin-time DateAndTime, --- время начала действия end-time [0] DateAndTime OPTIONAL, — время конца действия full-name [1] UTES8String (SIZE (1 .. 128)) OPTIONAL, --- полное наименование отделения почтовой связи office-address [2] ReportedAddress OPTIONAL, --- адрес узла/отделения почтовой связи contact [3] UTFS8String (SIZE (1 .. 128)) OPTIONAL, --- контактные телефоны public-point-data [4] UTF8String (SIZE (1 .. 128)) OPTIONAL --- информация о пункте коллективного доступа, расположенного в узле/отделении почтовой связи docTypesRecords TAGGED ::= { OID {sorm-report-dictionary-doc-types} DATA SEQUENCE OF DocTypesRecord }#❝
DocTypesRecord ::= SEQUENCE { telco-id TelcoLD, --- идентификатор оператора связи или филиала doc-type-id INTEGER (1 .. 65535), --- идентификатор типа документа begin-time DateAndTime, --- время начала действия end-time DateAndTime OPTIONAL, --- время конца действия description UTF8String (SIZE (1 .. 256) --- описание (наименование) } END#❝
managementMessage TAGGED ::= { OID { sorm-message-management } DATA CHOICE { request [0] ManagementRequest, response [1] ManagementResponse -#❝
--- тип сообщения "команда управления ТС OPM" ManagementRequest ::= CHOICE { get-structure [0] GetStructureRequest, --- запрос Ha получение | структуры TC OPM - КТС и модулей СПО get-module-config [1] GetModuleConfigRequest, --- запрос на ‘получение конфигурации КТС/модуля СПО set-module-config [2] SetModuleConfigRequest, --- запрос на изменение конфигурации КТС/модуля CHO | check-module [3] | CheckModuleRequest, --- запрос на получение состояния модуля#❝
--- запрос Ha получение конфигурации КТС/модуля СПО GetModuleConfigRequest::= CHOICE { hw-modules-list [0] RequestedHardwareModules, —- перечень идентификаторов узлов КТСТС ОРМ sw-modules-list [1] RequestedSoftwareModules --- перечень идентификаторов модулей СПО ТС ОРМ } .#❝
RequestedHardwareModules ::= = SEQUENCE OF Moduleld —-- перечень идентификаторов узлов КТСТС ОРМ RequestedSoftwareModules ::= SEQUENCE OF Moduleld --- перечень идентификаторов модулей СПО TC OPM#❝
--- запрос на изменение конфигурации КТС/модуля СПО SetModuleConfigRequest::= SEQUENCE { module-id Moduleld, --- идентификатор конфигурируемого модуля module-config ConfiguratedModule --- устанавливаемая в модуль конфигурация } Сопйзигае9 Module ::= CHOICE { sw-module [0] SormSoftwareModule, --- для узла КТС hw-module [1] SormHardwareModule --- для узла СПО }#❝
RequestedModulesList ::= CHOICE { sw-modules [0] RequestedHardwareModules, --- идентификаторы узлов КТС, для которых запрашивается состояние hw-modules [1] RequestedSoftwareModules --- идентификаторы модулей TC OPM, для которых запрашивается состояние#❝
--- параметр модуля ModuleParameter ::= SEQUENCE { parameter-name UTF8String (SIZE (1 .. 256)), --- наименование параметра read-only BOOLEAN, --- контролируемый или измеряемый параметр parameter-value ParameterValue --- значение параметра }#❝
--- варианты значений параметров ParameterValue ::= CHOICE { string [0] UTF8String (SIZE (1 .. 256)), integer [1] INTEGER (0 .. 999999999), boolean [2] BOOLEAN }#❝
SormSoftwareModule ::= SEQUENCE { module-id Moduleld, --- уникальный идентификатор данного модуля hardware-module-id Moduleld, --- идентификатор КТС, на котором работат данный блок модуля СПО block-name INTEGER (0 .. 1024), --- номер блока СПО модуля module-name UTFS8String (SIZE (1 .. 512)), --- наименование модуля module-type INTEGER (1 .. 512), --- идентификатор типа модуля module-parameters ModuleParameters, --- список параметров модуля sub-modules-list SubmodulesList OPTIONAL --- субмодули }#❝
SormHardwareModule ::= SEQUENCE { module-id Moduleld, --- уникальный идентификатор данного модуля block-name INTEGER (0 .. 1024), --- номер блока КТС#❝
51 module-name UTF8String (SIZE (1 .. 512), --- наименование модуля module-parameters HwParameterGroups --- значение группы параметров КТС#❝
HwParameterGroup ::= SEQUENCE { group-name UTFS8String (SIZE (1 .. 512)), --- наименование группы параметров для КТС module-parameters ModuleParameters --- перечень параметров для КТС#❝
HwParameterGroups ::= SEQUENCE OF HwParameterGroup SormSoftwareModules ;: = SEQUENCE OF SormSoftwareModule SormHardwareModules :: = SEQUENCE OF SormHardwareModule#❝
--- тип сообщения "ответ Ha команду управления TC OPM" ManagementResponse ::= CHOICE { get-structure [0] GetStructureResponse, --- ответ на запрос получения структуры TC OPM - КТС и модулей СПО get-module-config [1] GetModuleConfigResponse, --- ответ на запрос получения конфигурации КТС/модуля CUO set-module-config [2] SetModuleConfigResponse, --- ответ на запрос изменения конфигурации КТС/модуля СПО check-module [3] | CheckModuleResponse, --- ответ Ha запрос получения состояния модуля get-module-types [4] Се МодшеТурезВезровзе_ --- ответ на запрос получения типов модулей КТС и СПО }#❝
--- ответ на запрос получения структуры TC OPM - КТС и модулей СПО GetStructureResponse ::= SEQUENCE { sw-modules SormHardwareModules, . --- перечень всех узлов КТС | hw-modules SormSoftwareModules --- перечень всех модулей СПО ТС ОРМ }#❝
52 sw-modules SormHardwareModules, --- конфигурации запрошенных узлов КТС hw-modules SormSoftwareModules --- конфигурации запрошенных модулей СПО ТС ОРМ }#❝
--- отчет на запрос изменения конфигурации КТС/модуля СПО SetModuleConfigResponse::= ConfiguratedModule --- установленная в модуль конфигурация#❝
--- ответ на запрос получения состояния модуля CheckModuleResponse ::= CHOICE { hw-modules [0] SormHardwareModules, --- текущее состояние запрошенных модулей СПО TC OPM sw-modules [1] SormSoftwareModules --- текущее состояние запрошенных узлов КТС }#❝
--- ответ на запрос получения типов модулей КТС и СПО GetModuleTypesResponse ::= SEQUENCE OF ModuleType#❝
ModuleType ::= SEQUENCE { module-type INTEGER (1 .. 512), --- идентификатор типа модуля type-description UTF8String (SIZE (1 .. 128)) --- расшифровка типа модуля } END#❝
EXPORTS PostContractAbonent, Requested PostMailingA bonent, ReportedPostMailingAbonent, PassportInfoReport, PersonNamelInfo;#❝
IMPORTS TAGGED, sorm-post-abonent, sorm-post-abonent-person, sorm-post-abonent-organization, sorm-post-abonent-mailing, sorm-requested-post-abonent-person-mailing, sorm-requested-post-abonent-organization-mailing, sorm-reported-post-abonent-person-mailing, sorm-reported-post-abonent-organization-mailing#❝
PostContractAbonent ::= SEQUENCE { id TAGGED.&id ({AbonentsContractData}), data TAGGED.&Data({AbonentsContractData} {@id})#❝
AbonentsContractData TAGGED ::= { postContractAbonent postContractAbonent TAGGED ::= { OID sorm-post-abonent DATA PostAbonentContractRecord#❝
} PostAbonentContractRecord ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или филиала abonent AbonentContractData, --- информация об абоненте (клиенте оператора связи) contract-data PostContract OPTIONAL --- информация о заключенном договоре (в случае юридических лиц, предоставляется только для принадлежности)#❝
} PostContract ::= SEQUENCE { begin-date DateAndTime, | --- дата и время заключения договора contract UTFS8String (SIZE (1 .. 64)), --- номер договора#❝
54 end-date [0] DateAndTime OPTIONAL, --- дата и время расторжения договора bank [1] UTFS8String (SIZE(1 .. 256)) OPTIONAL, --- банк абонента (используемый при расчетах с оператором связи) bank-account [2] UTF8String (SIZE(1 .. 512)) OPTIONAL, — --- счет абонента в банке (используемый при расчетах с оператором связи) corr-account [3] UTF8String (SIZE(1 .. 512)) OPTIONAL, --- корреспондентский счет#❝
Крр [4] UTFS8String (517Е(9 .. 64)) OPTIONAL, --КИП bik [5] UTFE8String (SIZEQ .. 64)) OPTIONAL, -—-БИК contacts [6] SEQUENCE OF ContactInfo OPTIONAL, --- контактные лица addresses [7] . SEQUENCE OF PostContractAddress OPTIONAL --- адреса по договору#❝
} PostContractAddress ::= SEQUENCE { address ReportedAddress, --- адрес, указанный в контракте index-post PrintableString (SIZE (1 .. 10)) OPTIONAL --- почтовый индекс адреса#❝
--- контактная информация по договору ContactInfo ::= SEQUENCE { contact PersonNamelInfo, --- ФИО отправителя/контактное лицо | phone-list [0] SEQUENCE OF UTF8String (SIZE (1 ..32)) OPTIONAL, --- список контактных телефонов#❝
AbonentContractData ::= SEQUENCE { id TAGGED.&id ({AbonentsContractDataVariants}), data TAGGED.&Data({AbonentsContractData Variants} {@id})#❝
AbonentsContractData Variants TAGGED ::= { abonentContractPerson | --- информация об абоненте - физическом лице abonentContractOrganization информация об абоненте - юридическом лице#❝
} AbonentContractPerson ::= SEQUENCE { name-info PersonNamelnfo, --- ФИО birth-date GeneralizedTime OPTIONAL, | --- дата рождения passport-info PassportInfoReport OPTIONAL, --- паспортные данные phone-fax UTES8String (SIZE (1 .. 128)) OPTIONAL --- контактные телефоны, факс#❝
РегзопМашет®о ::= CHOICE { struct-name[0] PersonStructNameInfoReport, --- структурированное ФИО unstruct-name[1] UTF8String(SIZE( .. 1024)) --- неструктурированное ФИО#❝
} PersonStructNamelInfoReport ::= SEQUENCE { given-name UTFS8String (SIZE (1 .. 128)), —- имя initial UTFS8String (SIZE (1 .. 128)), --- отчество (при наличии) family-name UTF8String (SIZE (1 .. 128)) --- фамилия }#❝
PassportInfoReport::= SEQUENCE { ident-card-info IdentCardInfoReport, --- описание удостоверения личности doc-type-id INTEGER (0 .. 65535) OPTIONAL ` --- идентификатор типа документа, удостоверяющего личность#❝
IdentCardInfoReport ::= | CHOICE { struct-info [0] IdentCardStructInfoReport, структурированная информация | unstruct-info [1] UTF8String (SIZE (1 .. 512)) неструктурированная информация#❝
IdentCardStructInfoReport ::= SEQUENCE { ident-card-serial UTF8String (SIZE (1..16)), --- серия удостоверения личности ident-card-number NumericString (SIZE (1..16)), --- номер удостоверения личности | ident-card-description UTF8String (SIZE (1 .. 256)) --- когда и кем выдано abonentContractOrganization TAGGED ::= { OID { sorm-post-abonent-organization } DATA AbonentContractOrganization#❝
} AbonentContractOrganization ::= SEQUENCE { full-name UTF8String (SIZE (1 .. 256)), --- полное наименование inn [0] NumericString (SIZE (10..12)) OPTIONAL, = --- ИНН ogrn [1] UTFS8String (ЭТИХ .. 32)) OPTIONAL, --- ОГРН okpo [2] ОТЕ8$ те (SIZE(1 .. 32)) OPTIONAL, --- ОКПО index-post [3] PrintableString (SIZE (1 .. 10)) OPTIONAL -- почтовый индекс#❝
--- поисковые критерии в информации об абоненте отправителе/получателе почтового отправления RequestedPostMailingAbonent ::= SEQUENCE { id TAGGED.&id ({RequestedAbonentsMailingData}), data TAGGED.&Data({RequestedAbonentsMailingData} {@id})#❝
RequestedA bonentsMailingData TAGGED ::= { requestedMailingPerson | --- информация 06 абоненте - физическом лице | requested MailingOrganization | --- информация об абоненте - юридическом лице requestedMailingPerson TAGGED ::= { OID { sorm-requested-post-abonent-person-mailing } DATA RequestedA bonentMailingPerson#❝
57 requested MailingOrganization TAGGED ::= { OID { sorm-requested-post-abonent-organization-mailing } DATA RequestedAbonentMailingOrganization#❝
RequestedAbonentMailingPerson ::= SEQUENCE { name-info [0] | PersonNameInfo OPTIONAL, birth-date [1] | GeneralizedTime OPTIONAL, рождения passport-info [2] PassportInfoReport OPTIONAL, данные phone-fax [3] UTF8String (SIZE (1 .. 128)) OPTIONAL, контактные телефоны, факс address [4] RequestedAddress OPTIONAL адрес#❝
Requested A bonentMailingOrganization ::= SEQUENCE { full-name [0] UTF8String (SIZE (1 .. 256)) OPTIONAL, наименование contact [1] UTF8String (SIZE (1 .. 256)) OPTIONAL, отправителя/контактное лицо phone-fax [2] UTFS8String (SIZE (1 .. 128)) OPTIONAL, контактные телефоны, факс index-post [3] PrintableString (SIZE (1 .. 10)) OPTIONAL, индекс address [4] адрес#❝
ReportedPostMailingAbonent ::= SEQUENCE { personality-info ReportedPostMailingA bonentinfo, phone-fax [0] UTF8String (SIZE (1 .. 128)) OPTIONAL, контактные телефоны, факс contract [1] UTF8String (SIZE (1 .. 64)) OPTIONAL, contact-address [2] ReportedAddress OPTIONAL#❝
--- номер договора --- адрес oo информация об абоненте отправителе/получателе почтового отправления в записи блока отчета ReportedPostMailingAbonentInfo ::= SEQUENCE { id TAGGED.&id ({ReportedAbonentsMailingData}), data TAGGED.&Data({ReportedA bonentsMailingData} {@id})#❝
ReportedAbonentsMailingData TAGGED ::= { reportedMailingPerson | --- информация 06 абоненте - физическом лице reported MailingOrganization --- информация об абоненте - юридическом лице reported MailingPerson TAGGED ::= { OID { sorm-reported-post-abonent-person-mailing } DATA ReportedAbonentMailingPerson reportedMailingOrganization TAGGED ::= { .#❝
} ReportedAbonentMailingPerson ::= SEQUENCE { name-info [0] PersonNameInfo OPTIONAL, --- ФИО birth-date [1] GeneralizedTime OPTIONAL, --- дата рождения passport-info [2] PassportInfoReport OPTIONAL --- паспортные данные } ReportedAbonentMailingOrganization ::= SEQUENCE { full-name [0] UT¥F8String (SIZE (1 .. 256)) OPTIONAL, | --- полное наименование - contact [1] UTFS8String (SIZE (1 .. 256)) OPTIONAL, --- ФИО отправителя/контактное лицо index-post [3] PrintableString (SIZE (1 .. 10)) OPTIONAL --- почтовый индекс } END#❝
--- идентификаторы отделения почтовой связи PostOffice ::= SEQUENCE { id TAGGED.&id ({PostOfficeVariants}), data TAGGED.&Data ({PostOffice Variants} {@id})#❝
--- варианты запрашиваемых идентификаторов PostOffice Variants TAGGED ::= { postOfficeldentifier . --- идентификатор почтового отделения#❝
PostOfficeldentifier ::= SEQUENCE { index-post PrintableString (SIZE (1..10)) OPTIONAL, — —- индекс отделения почтовой связи full-name UTF8String (SIZE (1 .. 128)) ОРТТОМАГ, --- полное наименование отделения почтовой связи#❝
60 sorm-post-ty pe, sorm-post-type-mail, sorm-post-type-package, sorm-post-type-money-order, sorm-post-type-secogram, sorm-post-type-postal-wrapper, sorm-post-type-postcard, sorm-post-type-ems, sorm-post-type-small-packet, sorm-post-type-bag-international#❝
PostType ::= SEQUENCE { id TAGGED. &id ({ReportedPostVariants}), data TAGGED.&Data ({ReportedPostVariants} {@id})#❝
} Reported PostVariants TAGGED ::= { postMail --- письмо | postPackage --- посылка | postMoneyOrder --- денежный перевод | postSecogram --- секограмма | postalWrapper --- бандероль | роз Сага --- почтовая карточка | ро5 ЕМУ --- экспресс-отправление |postPacket — --- пакет | postBagInternational --- мешок, международное } MailingType ::= ENUMERATED { simple (0), -- простое почтовое отправление registered (1), | -- заказное почтовое отправление international (3), | -- международное почтовое отправление#❝
61 ordinary (4), отправление with-declared-value (5), объявленной ценностью with-declared-value-and-cod (6)#❝
--- письмо PostMailContent ::= SEQUENCE { type-mail MailingType, pay-on-delivery [2] MoneyType OPTIONAL, платеж first-class [3] ВООГЕАМ OPTIONAL отправление первым классом#❝
PostPackageContent ::= SEQUENCE { type-package MailingType, pay-on-delivery [2] MoneyType OPTIONAL#❝
--- тип посылки --- наложенный платеж amount MoneyType, --- величина почтового перевода inn [1] NumericString (SIZE (10 ..12 )) OPTIONAL, --- ИНН correspondent-account [2] NumericString (SIZE (20 )) OPTIONAL, ~— — кор. счет current-account [3] PrintableString (SIZE (20.. 25 )) OPTIONAL, — — рас. счет name-bank [4] UTF8String (SIZE (1.. 256 )) OPTIONAL, --- наименование банка bic [5] NumericString (SIZE (9 )) OPTIONAL, --- BUK message [6] UTF8String (SIZE (1.. 70 )) OPTIONAL -- Сообщение }#❝
--- бандероль postalWrapper TAGGED ::= { OID { sorm-post-type-postal-wrapper } DATA PostalWrapperContent#❝
} --- бандероль PostalWrapperContent ::= SEQUENCE { type-wrapper MailingType, --- тип бандероли pay-on-delivery [2] МопеуТуре OPTIONAL, --- наложенный платеж first-class [3] BOOLEAN OPTIONAL --- почтовое отправление первым классом }#❝
PostEMSContent ::= SEQUENCE { type-ems MailingType, --- тии экспресс-отправления pay-on-delivery [2] МопеуТуре OPTIONAL --- наложенный платеж } --- пакет postPacket TAGGED ::= { OID { sorm-post-type-small-packet } DATA PostPacketContent#❝
--- мешок, международное postBagInternational TAGGED ::= { OID { sorm-post-type-bag-international } DATA PostBagContent#❝
--- характеристики отправления PostInfo ::= SEQUENCE { post-weight [0] Weight OPTIONAL, --- вес почтового отправления post-cost [1] MoneyType OPTIONAL, --- объявленная стоимость отправления post-description [2] UTF8String (SIZE а .. 1024)) OPTIONAL --- завявленное описание содержимого отправления#❝
-- вес почтового отправления Weight ::= SEQUENCE { weight [0] INTEGER OPTIONAL, --- грамм weight-text [1] UTF8String (SIZE (1 .. 16)) OPTIONAL = --- текстовое описание Beca#❝
reportMessage TAGGED ::= { OID { sorm-message-report } DATA CHOICE { report [0] Report, | --- тип сообщения "отчет" ack [1] Acknowledgement --- тип сообщения "подтверждение" } }#❝
-- Блок данных сообщения типа "отчет" Report ::= SEQUENCE { request-id MessageID, --- идентификатор запроса, запросивший отчёт task-id TaskID, --- идентификатор задачи, сгенерировавшей данный отчет | total-blocks-number INTEGER (1 .. 1000000000000), --- общее количество блоков в отчете block-number INTEGER (1 .. 1000000000000), --- порядковый номер текущего блока report-block ReportDataBlock --- блок данных отчета#❝
-- Чодтверждение приёма блока, передаётся с номером соощения соответствующему номеру сообщения блока отчёта Acknowledgement ::= SEQUENCE { successful BOOLEAN, --- признак успешного приёма блока broken-record INTEGER (10 .. 100000) OPTIONAL, --- HOMep записи в отчете, обработанной на ПУ с ошибкой error-description UTF8String (SIZE(1..1024)) OPTIONAL --- описание ошибки приёма блока в произвольной форме#❝
} ReportDataBlock ::= CHOICE { dictionary [0] DictionaryReport, --- отчеты задач пополнения справочников (нормативно-справочная информация) abonents [1] AbonentsReport, --- отчеты задач поисков по принадлежности абонентов connections [2] PostingReport, --- отчеты задач поисков по оказанным услугам почтовой связи presense [3] PresenseReport, --- отчеты задач по запросу наличия в ТС ОРМ информации попЕогтаН7е4 [4] NonFormalizedReport --- отчеты задач по обработке неформализованных данных }#❝
AbonentsReport ::= SEQUENCE { id TAGGED.&id ({AbonentsReportVariants}), data TAGGED.&Data({AbonentsReportVariants} {@id})#❝
AbonentsReportVariants TAGGED ::= { reportAbonent --- информация 06 абоненте reportAbonent TAGGED ::= { OID { sorm-post-abonent-report } DATA SEQUENCE OF PostContractAbonent#❝
IMPORTS DateAndTime FROM Sorm _ TelcoID FROM Dictionaries TAGGED, sorm-report-post-connection FROM Classification - PostOffice FROM Postldentifiers PostType,#❝
Роз Иво FROM PostTypes Reported PostMailingAbonent FROM PostAbonents Reported Address FROM Addresses#❝
PostRecord ::= SEQUENCE { id TAGGED.&id ({ReportedPostVariants}), data TAGGED.&Data ({ReportedPostVariants} {@id})#❝
} PostRecordContent ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или филиала post-id UTF8String (SIZE (1 .. 32)), --- идентификатор почтового отправления post-registration DateAndTime, --- дата регистрации почтового отправления sender-region-id | UTF8String (1..32), --- идентификатор региона отправителя receiver-region-id UTF8String (1..32), --- идентификатор региона получателя operation-type ENUMERATED { --- атрибут операции по обработке отправления international-import (0), --- импорт в пункт международного обмена customs-delivery (1), --- передано таможне international-office-receive (2), --- прибыло в место международного обмена international-office-send (3), --- покинуло место международного обмена post-office-receive (4), --- прибыло в сортировочный центр post-office-send (5), --- покинуло. сортировочный центр post-office-processing (6) --- обработано Ha сортировочном центре bs#❝
68 operation-description UTF8String (SIZE (1 .. 256)), --- описание операции sender-info ReportedPostMailingA bonent, --- информация 06 отправителе reciever-info Reported PostMailingA bonent, --- информадия об адресате почтового отправления receiver-post-office PostOffice, --- информация об узле назначения почтовой связи (получателя) post-office-type ENUMERATED { --- тип операции на узле почтовой связи receive (0), --- приема почтового отправления process (1), --- обработки почтового отправления delivery (2), --- выдачи почтового отправления delivery-failed (3) -- неудачная попытка вручения } post-office PostOffice, --- информация об узле почтовой связи delivery-address [0] ReportedAddress, --- адресе доставки отправления time-of-send [1] DateAndTime OPTIONAL, ~-- дата и время отправления time-of-receive [2] DateAndTime OPTIONAL, --- дата и время получения post-type [3] Роз Туре OPTIONAL, --- информация о почтовом отправлении post-info [4] PostInfo OPTIONAL, --- характеристики отправления total-parts [5] INTEGER (1..1000) OPTIONAL, --- общее количество составных частей отправления part-number [6] UTF8String (1..128) OPTIONAL,--- идентификатор составной части отправления third-part-payment [7] ReportedPostMailingAbonent OPTIONAL --- информация об оплачивающей третьей стороне#❝
--- отчет задачи по обработке неформализованных данных NonFormalizedReport ::= CHOICE { nonformalized-report [0] _NonFormalizedRecords, --- отчет по задаче обработки неформализованных данных nonformalized-presense [1] NonFormalizedPresenseInfo —- отчет по наличию неформализованных данных заданного вида#❝
NonFormalizedPresenselnfo ::= SEQUENCE OF StandardInterval -- - диапазоны времени за которые есть неформализованные данные#❝
--- запись неформализованных данных NonFormalizedRecord ::= SEQUENCE ОЕ NonFormalizedEntityAttributeData#❝
TAGGED, sorm-report-presense-abonents, sorm-report-presense-connections, sorm-report-presense-dictionaries#❝
---отчет по запросу наличия информации PresenseReport ::= SEQUENCE { id TAGGED.&id ({ReportedPresenses Variants}), data TAGGED.&Data ({ReportedPresenses Variants} {@id})#❝
ReportedPresensesVariants TAGGED ::= { abonentsPresence | connectionsPresence | dictionariesPresence#❝
_-- отчет по наличию информации по абонентам и их идентификаторам. --- Для каждого стандарта может быть указано более одного, либо ни --- одного интервала (фактические периоды наличия информации); abonentsPresence TAGGED ::= {#❝
--- отчет по наличию информации по оказанным услугам почтовой связи --- может быть указано более одного, либо ни одного, интервала (фактические периоды наличия информации); connectionsPresence TAGGED ::= { OID { sorm-report-presense-connections } DATA SEQUENCE OF ConnectionsPresenseRecord#❝
--- отчет о наличии информации справочников в ТС OPM --- если какой-либо из справочников не публикуется TC OPM, запись о нем отсутствует dictionariesPresence TAGGED ::= { OID { sorm-report-presense-dictionaries } DATA SEQUENCE OF DictionaryInfo#❝
_-- запись отчета о наличии информации справочников DictionaryInfo ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или филиала#❝
71 dict ObjectDescriptor, --- тип справочника, во которому есть информация --- (идентификатор запроса справочника) (Requested...) count INTEGER (1 .. 4294967295), --- количество записей в справочнике change-dates FindRange -— минимальное и максимальное дата/время изменения записей в справочнике#❝
--- интервал времени, на котором имеются данные по абонентам, соединениям StandardInterval ::= SEQUENCE { telco-id TelcoID, --- идентификатор оператора связи или филиала range FindRange --- интервал времени, на который имеются данные в ИС END#❝
IMPORTS TAGGED, sorm-request-abonent, sorm-requested-abonent-organization, sorm-requested-abonent-person FROM Classification#❝
RequestedAbonent ::= SEQUENCE { id TAGGED.&id ({Requested A bonentVariants}), data TAGGED.&Data ({RequestedAbonentVariants} {@id})#❝
RequestedAbonentVariants TAGGED ::= { requestedPostContractData | abonentContractPerson | requestedAbonentContractOrganization requestedPostContractData TAGGED ::= { OID { sorm-request-contract } DATA RequestedPostContract#❝
} RequestedPostContract ::= CHOICE { contract [0] UTF8String (SIZE (1 .. 64)), --- номер договора bank [1] UTFS8String (SIZE(1 .. 256)), --- банк абонента (используемый при расчетах с оператором связи) bank-account [2] UTF8String (SIZE(1 .. 512)), --- счет абонента в банке (используемый при расчетах с оператором связи) corr-account [3] UTF8String (SIZE(1 .. 512)), --- корреспондентский счет kpp [4] UTFS8String (SIZE(9 .. 64)), --- КПИ bik [5] UTES8String (SIZE( .. 64)), --- БИК contacts [6] RequestedContactInfo, --- контактное лицо addresses [7] RequestedPostContractAddress --- адрес по договору } RequestedPostContractAddress ::= CHOICE { address [0] RequestedAddress, --- адрес, указанный в контракте | index-post [1] PrintableString (SIZE (1 .. 10)) --- почтовый индекс адреса }#❝
--- контактная информация по договору RequestedContactInfo ::= CHOICE { contact [0] PersonNamelInfo, --- ФИО отправителя/контактное лицо#❝
73 phone [1] UTFS8String (SIZE (1 .. 32)), --- контактный телефон email [2] ‘UTF8String (SIZE (1 .. 128)) — е-мейл адрес#❝
Requested AbonentContractPerson ::= CHOICE { name-info [0] PersonNamelnfo, --- ФИО birth-date [1] GeneralizedTime , --- дата рождения passport-info [2] PassportInfoReport, --- паспортные данные phone-fax [3] UTF8String (SIZE (1 .. 128)) --- контактные телефоны, факс requested A bonentContractOrganization TAGGED ::= { OID { sorm-requested-abonent-organization } DATA RequestedAbonentContractOrganization#❝
RequestedAbonentContractOrganization ::= CHOICE { full-name [0] UTF8String (SIZE (1 .. 128)), --- полное наименование inn [1] NumericString (SIZE (10 .. 12 )), --- ИНН ogrn [2] UTES8String (SIZE(1 .. 32)), --- ОГРН © okpo [3] UTF8String (SIZE(I .. 32)), ° — ОКПО index-post [4] PrintableString (SIZE (1 .. 10)) --- почтовый индекс }#❝
FROM Sorm PostOffice FROM Postldentifiers PostType, Роз п FROM PostTypes RequestedPostMailingAbonent FROM PostAbonents Requested Address FROM Addresses#❝
RequestedConnection ::= SEQUENCE { id TAGGED. &id ({RequestedConnection Variants}), data TAGGED.&Data ({Requested ConnectionVariants} {@id})#❝
— варианты запрашиваемых параметров связей RequestedConnectionVariants TAGGED ::= {© requestedPostConnection = --- параметры записи о почтовом отправлении requestedPostConnection TAGGED ::= { OID { sorm-request-post-connection } DATA CHOICE { post-id [0] UTF8String (SIZE (1 ..32)), --- идентификатор почтового отправления - operation-type [1] ENUMERATED { --- атрибут операции по обработке отправления international-import (0), --- импорт в пункт международного обмена customs-delivery (1), --- передано таможне international-office-receive (2), --- прибыло в место международного обмена international-office-send (3), --- покинуло место международного обмена post-office-receive (4), --- прибыло в сортировочный центр post-office-send (5) -— покинуло сортировочный центр }, | operation-description UTF8String (SIZE (1 .. 256)), --- описание операции sender-info [3] RequestedPostMailingAbonent, --- информация об отправителе#❝
75 receiver-info [4] RequestedPostMailingAbonent, --- информация 06 адресате почтового отправления receiver-post-office [5] PostOffice, --- информация об узле почтовой связи post-office-type [6] ENUMERATED { --- тип операции на узле почтовой связи receive (0), --- приема почтового отправления process (1), --- обработки почтового отправления delivery (2), --- выдачи почтового отправления delivery-failed (3) --- неудачная попытка вручения }, post-office [7] PostOffice, --- информация об узле почтовой связи delivery-address [8] RequestedAddress, .--- адрес доставки отправления post-type [9] PostType, —- информация о почтовом отправлении post-info [10] PostIinfo --- характеристики отправления } } END#❝
DATA CHOICE { connect [0] ConnectRequest, --- запрос на открытие сессии | connect-response [1] ConnectResponse, --- ответ на запрос открытия сессии adjustment [2] AdjustmentRequest, = --- согласование поддерживаемых типов со стороны ПУ adjustment-response [3] AdjustmentResponse, --- ответ на запрос согласования данных#❝
76 disconnect [4] DisconnectRequest, --- запрос на закрытие сессии disconnect-response [5] DisconnectResponse --- ответ на запрос закрытия сессии#❝
ConnectRequest ::= SEQUENCE { session-timeout INTEGER (60 .. 2592000), --- максимальное время неактивности max-data-length INTEGER (10 .. 100000), --- максимальная длина блока отчета (в строках) data-packet-window-size INTEGER (4 .. 256), --- окно канала передачи данных#❝
--- отправлено без подтверждения приема data-load-timeout INTEGER (1 .. 60), --- таймаут начала передачи блоков отчетов request-response-timeout INTEGER (1 .. 60), --- Таймаут ответа на запрос data-packet-response-timeout INTEGER (1 .. 60) -~- таймаут подтверждения приема блока данных отчета#❝
-- ответ на запрос создания сессии ConnectResponse ::= SEQUENCE { confirmed-data-packet-window-size INTEGER (4 .. 256), —- подтвержденное окно передачи данных#❝
--- должно быть меньше или равно окну, переданному в ConnectRequest confirmed-session-timeout INTEGER (60 .. 2592000), --- подтвержденное максимальное время неактивности#❝
--- должно быть больше или равно значению, переданному в ConnectRequest confirmed-data-load-timeout | INTEGER (1.. 60), --- подтвержденный таймаут начала передачи блоков отчетов#❝
77 confirmed-request-response-timeout INTEGER (1 .. 60), --- подтвержденный таймаут ответа на запрос --- должен быть больше или равен значению, переданному в ConnectRequest supports SEQUENCE OF ObjectDescriptor --- весь список поддерживаемых ТС ОРМ типов запросов, типов отчётов#❝
--- согласование поддерживаемых типов со стороны ПУ AdjustmentRequest ::= SEQUENCE { supports SEQUENCE OF ObjectDescriptor --- список поддерживаемых ПУ типов запросов, типов отчётов --- данный список должен быть меньшим либо равным списку в сообщении ConnectRequest#❝
-- ответ на согласование списка поддерживаемых типов AdjustmentResponse ::= NULL --- ответ Ha запрос согласования данных#❝
IMPORTS TAGGED FROM Classification sessionMessage FROM Sessions trapMessage FROM Traps taskMessage FROM Tasks © reportMessage FROM Reports managementMessage FROM Management#❝
-- Оболочка сообщения СОРМ -- Message ::= SEQUENCE { version Version DEFAULT vers, --- версия протокола message-id MessagelID, --- номер запроса message-time DateAndTime, --- время и дата запроса operator-name PrintableString (SIZE (6 .. 128)) OPTIONAL, --- наименование оператора связи id TAGGED.&id ({SormPDUs}), --- идентификтор блока данных data TAGGED.&Data({SormPDUs}{@id}) --- данные блока данных#❝
SormPDUs TAGGED ::= { sessionMessage --- сообщения организации сессии trapMessage --- сообщения сигналов taskMessage --- сообщения работы с задачами reportMessage --- сообщения работы с отчётами managementMessage --- сообщения канала передачи мониторинга (КПМ) цпогта ед Message : --- сообщения канала передачи неформатированных данных (КИНФ)#❝
79 begin-find [0] DateAndTime OPTIONAL, --- время и дата начала поиска информации end-find [1] DateAndTime OPTIONAL | --- время и дата окончания поиска информации#❝
80 data-ready-request [0] DataReadyRequest, --- запрос готовности данных data-ready-response [1] DataReadyResponse, --- ответ на запрос готовности данных data-load-request [2] DataLoadRequest, --- запрос загрузки данных data-load-response [3] DataLoadResponse, --- ответ на запрос загрузки данных data-drop-request [4] DataDropRequest, --- запрос удаления данных data-drop-response [5] DataDropResponse, --- ответ Ha запрос удаления данных data-interrupt-request [6] DataInterruptRequest, --- запрос прерывания загрузки данных data-interrupt-response [7] DataInterruptResponse, --- ответ на запрос прерывания загрузки данных create-task-request [8] CreateTaskRequest, --- запрос на создание задачи по обработке информации create-task-response [9] CreateTaskResponse, --- ответ на запрос создания задачи uni-task-request [10] UNIControlTaskRequest, --- запрос на постановку/снятие объекта наблюдения на контроль uni-task-response [11] UNIControlTaskResponse, --- ответ на запрос постановки/снятия объекта наблюдения с контроля non-formalized-task-request [12] NonFormalizedTaskRequest, -~ - запрос на создание задачи по обработке неформализованных данных non-formalized-task-response [13] NonFormalizedTaskResponse ooo - ответ Ha запрос создания задачи по обработке неформализованных данных#❝
О каких нормах
Документы того же органа рядом по дате
- О внесении изменений в Порядок предоставления сведений о базе расчета обязательных отчислений (неналоговых платежей) в резерв универсального обслужива — Приказ Министерство связи и массовых коммуникаций России от 23.07.2015 № 275
- Об утверждении Обязательных метрологических требований к измерениям, относящимся к сфере государственного регулирования обеспечения единства измерений — Приказ Министерство связи и массовых коммуникаций России от 23.07.2015 № 277
- Об утверждении Требований к оборудованию автоматизированной сортировки почты, обеспечивающему выполнение установленных действий при проведении операти — Приказ Министерство связи и массовых коммуникаций России от 23.07.2015 № 276
- О внесении изменений в Положение о федеральной государственной информационной системе "Единая система идентификации и аутентификации в инфраструктуре, — Приказ Министерство связи и массовых коммуникаций России от 23.07.2015 № 278
- О внесении изменений в приказ Министерства связи и массовых коммуникаций Российской Федерации от 02.07.2012 № 167 "Об утверждении Административного ре — Приказ Министерство связи и массовых коммуникаций России от 28.07.2015 № 286
- Об утверждении формы декларации о соответствии средств связи — Приказ Министерство связи и массовых коммуникаций России от 29.07.2015 № 288
- Об утверждении состава, порядка, способов, сроков и периодичности размещения в государственной информационной системе жилищно-коммунального хозяйства — Приказ Министерство связи и массовых коммуникаций России от 24.08.2015 № 311/612/пр
- О внесении изменений в Административный регламент Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций по пр — Приказ Министерство связи и массовых коммуникаций России от 28.08.2015 № 315