в базе 1 113 607 документа
Последнее обновление: 05.05.2024

Законодательная база Российской Федерации

Расширенный поиск Популярные запросы

8 (800) 350-23-61

Бесплатная горячая линия юридической помощи

Навигация
Федеральное законодательство
Содержание
  • Главная
  • ПРИКАЗ Мининформсвязи РФ от 24.08.2006 N 113 "ОБ УТВЕРЖДЕНИИ ПРАВИЛ ПРИМЕНЕНИЯ ОКОНЕЧНОГО ОБОРУДОВАНИЯ, ВЫПОЛНЯЮЩЕГО ФУНКЦИИ СИСТЕМ КОММУТАЦИИ"
действует Редакция от 24.08.2006 Подробная информация
ПРИКАЗ Мининформсвязи РФ от 24.08.2006 N 113 "ОБ УТВЕРЖДЕНИИ ПРАВИЛ ПРИМЕНЕНИЯ ОКОНЕЧНОГО ОБОРУДОВАНИЯ, ВЫПОЛНЯЮЩЕГО ФУНКЦИИ СИСТЕМ КОММУТАЦИИ"

Приложение 11. ТРЕБОВАНИЯ К ПАРАМЕТРАМ ПРОТОКОЛА ИНИЦИИРОВАНИЯ СЕАНСА СВЯЗИ (ПРОТОКОЛА SIP)

1. Сообщения протокола SIP передаются с использованием соединения по протоколу управления передачей (далее - TCP) или соединения по протоколу UDP. Если порт не назначен, то по умолчанию используется порт 5060. При обмене сообщениями протокола SIP соединение инициируется как стороной клиента, так и стороной сервера при необходимости передачи ответа по заданному адресу. Сервер держит открытым установленное TCP-соединение до завершения SIP-транзакции.

2. В сервере реализуется обработка запросов с методами "приглашение" (далее - INVITE), "уведомление" (далее - ACK), "завершение" (далее - BYE), "отмена" (далее - CANCEL), "регистрация" (далее - REGISTER), "опции" (далее - OPTIONS). Регистр символа слова, обозначающего метод, является существенным.

3. Для приглашения принять участие в сеансе связи, передачи информации об описании соответствующего сеанса связи, а также для изменения характеристик уже организованных каналов с новым описанием сеанса связи используется метод INVITE. Для описания сеанса связи используется формат протокола описания параметров связи (далее - SDP).

4. Для подтверждения получения ответа от сервера и передачи окончательных параметров описания сеанса связи используется метод ACK.

5. Для предоставления вызываемой или вызывающей стороне возможности завершения соединения используется метод BYE.

6. Для предоставления возможности отмены обработки ранее переданных запросов используется метод CANCEL.

7. Для регистрации нового местоположения клиента используется метод REGISTER.

8. Для предоставления клиенту возможности запрашивать информацию о параметрах соединения с заданным универсальным идентификатором ресурса (далее - URI) до начала установления соединения используется метод OPTIONS.

9. Идентификатор ресурса (далее - Request-URI) определяет ресурс, к которому применяется запрос.

10. Начальная строка ответа "линия статуса" (далее - Status-Line) содержит версию протокола и дополнительную текстовую фразу, включающую поля "код статуса" (далее - Status-Code) и "текст причины" (далее - Reason-Phrase). Строка статуса не может разрываться символами "возврат каретки" (далее - CR) или "перевод строки" (далее - LF).

11. Поле Status-Code состоит из трех цифр, определяющих результат запроса. Поле Reason-Phrase включает краткое текстовое описание поля Status-Code.

12. Для запросов с методами ACK, INVITE и OPTIONS тело сообщения всегда содержит описание сессии. Метод BYE не содержит тела сообщения.

13. Тип тела сообщения определяется заголовком "тип содержимого" (далее - Content-Type).

14. Если к телу сообщения было применено кодирование, то оно определяется полем "метод кодирования" (далее - Content-Encoding). В других случаях поле Content-Encoding опускается.

15. Длина тела сообщения в байтах представлена в поле "размер содержимого" (далее - Content-Length).

16. В качестве адреса в объектах, поддерживающих протокол SIP, используется универсальный указатель расположения ресурсов URL. Если этот адрес используется для идентификации отправителя, то он записывается в поле "отправитель" (далее - From), если получателя - в поле "получатель" (далее - To), если для определения адресов переадресации - в поле "контакт" (далее - Contact), если для идентификации текущего объекта, формирующего запрос, - в поле Request-URI.

17. Адрес состоит из двух частей:

1) имя домена, рабочей станции, шлюза или адрес IP;

2) имя ресурса, зарегистрированного в домене.

18. В начале адреса ставится слово "sip:" или "sips:".

19. Параметры "транспорт" (далее - transport), "список адресов" (далее - maddr), "время жизни" (далее - ttl) не используются в полях From, To и Request-URI.

20. Сервер SIP поддерживает ответы с кодами статуса, приведенными в таблице 1. Первая цифра поля Status-Code определяет класс ответа.

Таблица 1

Первая цифра кода статуса Класс ответа Примечание
1xx Информационный Запрос получен, продолжаю процесс обработки
2xx Успех Команда получена, понята и принята
3xx Перенаправление Должны быть предприняты дальнейшие действия для завершения запроса
4xx Ошибка клиента Запрос содержит синтаксическую ошибку или не может быть выполнен
5xx Ошибка сервера Сервер не может выполнить очевидно правильный запрос
6xx Глобальная ошибка Запрос не может быть выполнен ни на одном сервере

21. Запрос ACK не генерирует ответ для избежания формирования петли.

22. При изменении местоположения вызываемая сторона, используя метод REGISTER, регистрирует свое новое местоположение. Информация о новом местоположении пользователя возвращается сервером переадресации в поле Contact.

23. Если оборудование, выполняющее функции маршрутизации и управления пакетами IP, содержащими речевую, видео- и мультимедиа информацию (прокси-сервер), продвигает запрос, то оно добавляет в начало списка продвижения заголовок "через" (далее - Via). В ответе каждый хост удаляет свое значение Via. Прокси-сервер не добавляет, не удаляет и не изменяет тело сообщения.

24. Для предотвращения зацикливания прокси-сервер проверяет наличие своего адреса в поле Via при получении входящего запроса и обрабатывает только те ответы, в которых в поле Via содержится его адрес. Поля To, From, "идентификатор вызова" (далее - Call-ID) и Contact копируются из исходных полей. Идентификатор Request-URI содержит адрес, по которому направляется запрос.

25. Прокси-сервер с сохранением состояния функционирует как сервер при получении запросов и как клиент при генерации исходящих запросов, за исключением случая при получении ответа с кодом 2xx на запрос INVITE. Вместо генерации ACK он направляет ответ с кодом 2xx обратно во входной поток вызывающей стороны.

26. Если прокси-сервер при продвижении запроса генерирует несколько разветвленных запросов, то вызываемый агент пользователя возвращает ответ только на первый пришедший запрос с заданным Call-ID.

27. Серверы при получении от клиента изоморфного запроса отбрасывают запрос и выдают соответствующий ответ. Если заголовок From не соответствует существующим маршрутам, то создается новый маршрут вызова. Если Call-ID не соответствует текущим сеансам, то создается новый маршрут со значениями To, From и Call-ID из заголовков запроса. Заголовок To не содержит отметок об обработке информации (тегов).

28. Сервер определения местоположения не посылает SIP-запросы. После получения запроса, отличного от CANCEL, сервер определения местоположения формирует список альтернативных значений местоположения и возвращает окончательный ответ класса 3xx или отклоняет запрос. При получении запроса CANCEL формируется ответ с кодом 2xx. Этот ответ завершает SIP-транзакцию.

Приложение 12
к Правилам применения
оконечного оборудования,
выполняющего функции
систем коммутации

  • Главная
  • ПРИКАЗ Мининформсвязи РФ от 24.08.2006 N 113 "ОБ УТВЕРЖДЕНИИ ПРАВИЛ ПРИМЕНЕНИЯ ОКОНЕЧНОГО ОБОРУДОВАНИЯ, ВЫПОЛНЯЮЩЕГО ФУНКЦИИ СИСТЕМ КОММУТАЦИИ"