Приложение 11. ПРАВИЛА ПРИМЕНЕНИЯ ОКОНЕЧНОГО ОБОРУДОВАНИЯ, ВЫПОЛНЯЮЩЕГО ФУНКЦИИ СИСТЕМ КОММУТАЦИИ

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-транзакцию.