Средства технические телематических служб. Протокол SIP. Общие технические требования. Редакция 1-2002

2.1. Версия SIP

Версия содержится в поле SIP-Version в первой строке сообщения.

Данные ТТ соответствуют описанию SIP протокола с версией "SIP/2.0".

2.2. Универсальный указатель расположения ресурса

2.3. Формат даты и времени

2.4. Наборы символов

SIP-протокол является протоколом, ориентированным на текстовом представлении символов, и использует набор символов ISO 10646 кодировки UTF-8.

Получатели должны определять завершение линии по символу CRLF, отправители должны включать в окончание линии символы CR и LF.

2.5. Кодирование содержимого

Значения кодирования содержимого указывают на факт использования преобразования кодировки (например, сжатие), которое применялось, либо могло быть применено к содержанию.

content-coding = token

Определены следующие значения token: gzip (GNU zip согласно RFC 1952), compress (LWZ). Все значения content-coding должны быть зарегистрированы в IANA.

2.6. Типы информации

Для обеспечения открытого определения и согласования типа информации используются поля заголовка Content-Type и Accept.

Между элементами type и subtype, а также между parameter и value не должны использоваться символы LWS в качестве разделителя.

Значения media-type должны соответствовать RFC 2068.

2.7. Параметр качества содержимого

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

2.8. Теги опций

Теги опций используются для добавления дополнительных возможностей SIP протокола, которые используются в полях Require и Unsupported.

Новые теги для создания дополнительных возможностей должны быть зарегистрированы в IANA (Internet Assigned Numbers Authority) в соответствии с процедурой, приведенной в RFC 2543 (раздел 4.4).

3.1. Типы сообщений

Сообщения разделяются на запросы клиента к серверу и ответы сервера клиенту.

Запросы и ответы используют общий формат сообщений RFC 822 для передачи содержания (полезной нагрузки сообщения). Оба типа сообщения состоят из начальной строки, одной или более строк заголовка, пустой строки, указывающей на конец заголовка, и необязательного тела сообщения.

Сервер должен игнорировать пустые строки, поступающие перед Request-Line.

3.2. Заголовки сообщений

Поля заголовка SIP, включая поля общего заголовка, заголовка запроса, заголовка ответа и заголовка содержания, должны соответствовать формату п.3.1. RFC 822. Поля заголовка могут занимать несколько строк, но строки, следующие за первой, должны начинаться с 1 *CRLF.

Порядок полей в заголовке не имеет значения. Но прокси не должен изменять порядок полей в перенаправляемом сообщении, а также вносить изменения в заголовки, передаваемые от одного до другого оконечного устройства. Прокси-сервер может вносить изменения в заголовки, формируемые на промежуточных стадиях передачи сообщения.

Каждый заголовок имеет следующий формат:

3.3. Тело сообщения

Тело сообщения используется для переноса тела содержания и отличается от тела содержания только тогда, когда применено кодирование при передаче.

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

Все ответы могут содержать тело сообщения. Ответы с кодом 1хх содержат консультативную информацию о состоянии выполняющегося запроса, ответы с кодом 2хх на запрос INVITE содержат параметры описания сессии, в ответах с кодом 3хх может содержаться информация об альтернативных действиях или службах.

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

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

3.4. Длина сообщения

Длина тела сообщения в байтах представлена в поле Content-Length.

3.5. Общие поля заголовка

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

Нераспознанные поля заголовка должны обрабатываться как поля заголовка содержания.

4.1. Request-Line (Строка запроса)

Request-Line начинается с метки метода, за которой следует Request-URI и версия протокола, заканчивающаяся CRLF. Элементы разделены символами SP. Появление символов CR или LF, кроме заключительной последовательности CRLF, запрещено.

4.2. Поля заголовка запроса.

Поля заголовка запроса позволяют клиенту передать дополнительную информацию о запросе и о самом клиенте.

5.1. Status-Line (Строка статуса)

Строка статуса содержит версию протокола и дополнительную текстовую фразу. Строка статуса не может разрываться символами CR или LF.

5.2. Поля заголовка ответа

Поля заголовка ответа позволяют серверу передать дополнительную информацию, которая не может быть передана в строке статуса Status-Line.

6.1. Поля заголовка содержания

7.1. Метод INVITE

Метод INVITE определяет, что клиент или служба приглашаются участвовать в сеансе. Тело сообщения содержит описание сеанса.

При двустороннем вызове вызывающая сторона указывает тип средств информации, необходимых при получении, и тип средств информации возможных при отправке, а также их параметры. Успешный ответ должен указать в теле сообщения необходимую информацию.

Этот метод используется также для изменения параметров существующего сеанса связи и для приглашения нового участника к уже установленному соединению. При изменении параметров уже существующего сеанса связи метод INVITE должен содержать поле Cseq со значением большим, чем предыдущий запрос клиента серверу.

Этот метод должен поддерживаться прокси-сервером, сервером переадресации и агентами пользователя, как сервера, так и клиента.

7.2. Метод АСК

Метод АСК подтверждает, что клиент получил окончательный ответ на окончательный запрос INVITE. Используются коды ответов 2хх. Метод может содержать в теле сообщения окончательное описание сеанса связи.

Этот метод должен поддерживаться прокси-сервером, сервером переадресации и агентами пользователя, как сервера, так и клиента.

7.3. Метод OPTIONS

Метод OPTIONS представляет собой запрос информации о факультативных возможностях терминального оборудования вызываемого пользователя. Данный метод позволяет клиенту определить возможности и (или) требования, связанные с данным ресурсом, а также возможности оборудования без выполнения установления соединения. Для установления соединения не используется.

Этот метод должен поддерживаться прокси-сервером, сервером переадресации, агентом пользователя сервера, сервером регистрации и клиентами.

7.4. Метод BYE

Метод BYE позволяет агенту пользователя клиента информировать сервер о завершении вызова.

Запрос может быть послан любой из сторон - вызывающей или вызываемой. Если INVITE запрос содержит заголовок Contact, то вызванная сторона посылает запрос BYE с указанием адреса из поля Contact, предпочтительнее, чем из поля From.

Сторона, получившая запрос BYE, должна прекратить передачу мультимедийной информации и подтвердить его выполнение ответом с кодом 200.

Этот метод должен поддерживаться прокси-сервером, может поддерживаться сервером переадресации, агентом пользователя сервера.

7.5. Метод CANCEL

Метод CANCEL отменяет обработку ранее посланных запросов с теми же, что и в запросе CANCEL, значениями полей Call-ID, To, From и Cseq, но не влияет на те запросы, обработка которых уже завершена. Агент пользователя клиента или прокси-клиент могут выдавать запрос в любое время.

Этот метод должен поддерживаться прокси-сервером, может поддерживаться всеми типами SIP-серверов.

7.6. Метод REGISTER

Метод REGISTER используется пользователем для сообщения своего текущего местоположения. Запрос обрабатывается в порядке поступления. Клиенты должны избежать посылки повторной противоречивой информации, пока предыдущий запрос не будет обработан.

При регистрации используются следующие поля заголовка:

- поле То содержит адресную часть, которую надо сохранить или модифицировать на сервере;

- поле From содержит адрес инициатора регистрации;

- поле Contact содержит новый адрес пользователя, по которому должны передаваться запросы INVITE, при отсутствии поля Contact в запросе означает, что регистрация осталась прежней;

- поле Request-URI содержит имя регистратора;

- поле Call-ID содержит идентификатор вызова;

- поле Cseq содержит номер последовательности в текущем сеансе;

- поле Expire содержит время, в течение которого регистрация действительна.

8.1. Первичная схема идентификации

Первичная схема основана на идентификации клиента по идентификатору и паролю.

Пример вызова, выдаваемого сервером для начала процедуры идентификации:

WWW-Authenticate: Basic realm="WallyWorld"

Ответный запрос клиента содержит мандат, состоящий из идентификатора и пароля пользователя, разделенных между собой двоеточием и закодированных в base64.

Пример ответного запроса клиента:

8.2. Обзорная схема идентификации

Ответ сервера для начала процедуры идентификации.

Заголовок запроса клиента на идентификацию.

8.3. Схема идентификации PGP

Заголовок ответа для начала процедуры идентификации.

Запрос клиента для идентификации.

9.1. Accept

Поле заголовка запроса Accept определяет типы информации, которые являются приемлемыми для ответа. Используется только в запросах INVITE, OPTIONS, REGISTER.

Звездочка используется для группирования типов информации в диапазоны. При этом "*/*" означает все типы данных, а "тип/*" - все подтипы данного типа.

Если заголовок Accept не представлен, то по умолчанию используется значение application/sdp.

Например:

Accept: application/sdp;leve|=|, application/x-private, text/html

9.2. Accept-Encoding

Поле заголовка запроса аналогично полю Accept, но определяет приемлемые методы кодирования содержимого, представленного в ответе.

Например:

Accept-Encoding: compress, gzip

9.3. Accept-Language

Поле заголовка запроса аналогично полю Accept, но определяет приемлемые естественные языки, используемые в ответе.

По умолчанию определитель качества q=1.

Например:

Accept-Language: da, en-gb; q=0.8, en; q=0.7

Означает: я предпочитаю датский, но также приемлемыми являются британский английский и другие типы английского языка.

9.4. Allow

Поле заголовка сущности Allow содержит список методов, поддерживаемых для ресурса, указанного в Request-URI. Поле заголовка Allow должно присутствовать в ответе с кодом 405 (метод не поддерживается) и может быть представлено в методе OPTIONS.

Например:

Allow: REGISTER, INVITE, OPTIONS

9.5. Authorization

Клиент, желающий идентифицироваться (обычно после ответа 401), может выполнить процедуру идентификации, включив в заголовок ответа поле Authorization.

9.6. Call-ID

Поле общего заголовка Call-ID уникально определяет идентификатор клиента, иницирующего вызов. Разные клиенты, инициирующие вызов к одной конференции, будут иметь различные идентификаторы.

"host" - полное доменное имя или глобальный IP-адрес.

Например:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

9.7. Contact

Поле общего заголовка Contact применяется в запросах INVITE, ACK, REGISTER и в ответах с кодами 1хх, 2хх, 3хх и 485.

В запросах INVITE и АСК поле заголовка определяет позицию отправителя запроса, что позволяет вызываемой стороне посылать запросы (BYE).

q: значение "qvalue" определяет предпочтительное местоположение пользователя, измеряется десятичным числом от 0 до 1.

action: параметр "action" используется только при регистрации с запросом REGISTER. Он определяет желание клиента переназначать будущие запросы, предназначенные ему, прокси-сервером или сервером переадресации.

expires: параметр "expires" указывает время истечения действия заданного URI. Измеряется в секундах.

Например:

9.8. Content-Encoding

Поле заголовка содержания Content-Encoding используется, как модификатор к типу информации. Присутствие данного поля показывает, что к телу содержания было применено дополнительное кодирование содержимого.

Если было применено несколько кодирований, они должны быть перечислены в порядке, в котором они применялись.

9.9. Content-Length

Поле заголовка сущности Content-Length указывает на размер тела сообщения, в октетах.

Например:

Content-Length: 3495

9.10. Content-Type

Поле заголовка содержания Content-Type указывает на тип информации тела сообщения. Заголовок определяет формат описания сеанса. Само описание включается в тело сообщения.

Например:

9.11. CSeq

Клиенты должны добавлять CSeq в каждый запрос. Это уникальный идентификатор запроса, относящийся к одному сеансу. Он служит для корреляции запроса с ответом на него и состоит из натурального числа из диапазона от 1 до и типа запроса. Ответы на запросы должны содержать то же самое значение CSeq. Сервер должен проверять значение в каждом принимаемом запросе и считать запрос новым, если значение Cseq больше предыдущего.

Например:

CSeq: 4711 INVITE

9.12. Date

Поле общего заголовка Date представляет дату и время генерации сообщения.

Данное поле должно быть включено во все ответы.

9.13. Encryption

Поле общего заголовка Encryption определяет, каким образом кодировано содержимое.

Метод запроса и Request-URI не должны подвергаться кодированию.

Например:

INVITE sip:watson@boston.bell-telephone.com SIP/2.0

Via: SIP/2.0/UDP 169.130.12.5

From: <sip:a.g.bell@bell-telephone.com>

To: T. A. Watson <sip:watson@bell-telephone.com>

Call-ID: 187602141351@worcester.bell-telephone.com

Content-Length: 885

Encryption: PGP version=2.6.2, encoding=ascii

hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red

h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3 vbDdVdaFciwEVAcuXs

ODx1NAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7W1RSBc7vNPEA3nyqZGBTwhxRSbIR

RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA

zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu

X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6

IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHox1A2/

GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E

WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5a1X4M251HQd9FR9Zmq6Jed

wbWvia6cAIfsvIZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO

z/1xGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+

6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhR105OiJIGr9S1Uhen1Zv916RuXsOY/EwH2

z8X9N4MhMyXEVuC9rt8/AUhmVQ==

=bOW+

9.14. Expires

Поле общего заголовка Expires указывает дату и время, после который содержимое сообщения будет считаться устаревшим. Формат этого поля должен соответствовать RFC 1123. Заголовок определен только для методов REGISTER и INVITE.

Например:

9.15. From

Запросы и ответы должны содержать общее поле заголовка From , определяющего инициатора запроса. Сервер копирует поля заголовка из запроса в ответ.

Например:

From: "A. G. Bell" <sip:agb@bell-telephone.com>

From: sip:+12125551212@server.phone2net.com

From: Anonymous <sip:c8oqz84zk7z@privacy.org>

9.16. Hide

Поле Hide используется клиентом при необходимости скрыть путь, указанный в поле Via от последующих серверов прокси и агентов пользователя.

При использовании формы "Hide: route" все следующие серверы прокси должны скрыть предыдущие переходы. При использовании формы "Hide: hop" только следующий сервер должен удалить информацию, касающуюся текущего перехода, и удалить опцию Hide, если не хочет остаться анонимом.

9.17. Max-Forwards

Данное поле запроса может использоваться с любым SIP-методом для ограничения числа прокси-серверов или шлюзов, которые могут перенаправлять запрос.

Значение поля представляет собой десятичное число, показывающее остающееся число разрешенных пересылок сообщения. Каждый сервер, обрабатывающий запрос, должен изменить значение данного поля.

Прокси, получивший запрос с полем Max-Forwards=0, не должен направлять данное сообщение дальше, а должен выдать ответ с кодом 483.

9.18. Organization

Organization - поле общего заголовка, которое содержит название организации, откуда происходит запрос или ответ.

9.19. Priority

Priority - поле общего заголовка, которое определяет степень скорости обслуживания, запрошенной клиентом.

Например:

Subject: A tornado is heading our way!

Priority: emergency

Subject: Weekend plans

Priority: non-urgent

9.20. Proxy-Authenticate

Поле заголовка ответа Proxy-Authenticate должно быть включено в ответ с кодом 407. Значение данного поля состоит из вызова, указывающего схему идентификации и параметры, применимые к прокси с данным Request-URI. Только агент пользователя клиента может проходить процедуру идентификации на сервере-прокси.

9.21. Proxy-Authorization

Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать самого себя по отношению к прокси, для которого требуется идентификация. Значение поля состоит из мандатов, содержащих идентифицирующую информацию об агенте пользователя для прокси и (или) пространство запрашиваемого ресурса.

В отличие от поля Authorization, поле Proxy-Authorization используется только ближайшим внешним прокси, который затребовал идентификацию, используя поле Proxy-Authenticate. В прокси может быть реализован механизм сборной идентификации клиента совместно с другими серверами прокси.

9.22. Proxy-Require

Поле заголовка Proxy-Require используется для определения прокси-ориентированных способностей, которые должны быть поддержаны прокси-сервером. Любые неподдерживаемые способности должны быть отрицательно подтверждены прокси-сервером. Прокси-сервер будет обрабатывать это поле аналогично полю Require.

9.23. Record-Route

Поле Record-Route включается в запрос или ответ каждым прокси-сервером, встречающимся в пути следования обработки запроса по маршруту вызова. Он содержит глобальное значение Request-URI однозначно определяющее прокси-сервер. Каждый прокси-сервер добавляет в сообщение свой Request-URI.

Сервер копирует Record-Route в заголовок ответа для кода 2хх. Вызывающий агент пользователя клиента копирует поле Record-Route в последующие запросы, связанные с данным маршрутом вызова, изменяя порядок в запросе.

Вызывающий агент пользователя не должен использовать Record-Route в запросе, в котором содержатся поля Route.

Например:

Record-Route: <sip:a.g.bell@bell-telephone.com>,

<sip:a.bell@ieee.org>

9.24. Require

Поле заголовка запросов используется клиентом для уведомления агента пользователя сервера о дополнительных возможностях, необходимых для поддержки правильного порядка обработки запроса. При невозможности предоставления данных возможностей сервер отвечает ответом с кодом 420.

Например:

Прокси-сервер и сервер переадресации должны игнорировать требования, которые не поддерживаются.

9.25. Response-Key

Поле Response-Key используется в заголовке запроса клиентом, если он хочет, чтобы вызываемая сторона использовала в ответах заданную схему кодирования.

9.26. Retry-After

Поле заголовка ответа Retry-After может использоваться с ответом 503 для указания насколько долго сервис будет недоступен данному клиенту.

Например:

9.27. Route

Поле заголовка запроса Route определяет маршрут следования запроса. Каждый хост из заданного списка удаляет первую запись по мере обработки запроса, затем прокси-сервер направляет запрос на следующий хост из этого списка.

9.28. Server

Поле заголовка ответа Server содержит информацию о программном обеспечении, используемом на сервере-источнике для обработки запроса.

Прокси не должен изменять заголовок Server при направлении ответа.

9.29. Subject

Используется для краткого описания природы вызова.

Например:

Subject: Tune in - they are talking about your work!

9.30. Timestamp

Поле общего заголовка используется клиентом для описания, когда был послан запрос серверу. Сервер должен вернуть то же самое значение и значение приращения, указывающего время получения запроса. Используется для синхронизации времени.

9.31. To

Поле общего заголовка То определяет получателя запроса.

Кроме SIP-адреса данное поле может содержать параметр "tag" для идентификации конкретного терминала адресата в том случае, когда все его терминалы зарегистрированы под одним адресом SIP URL.

SIP-URL не должен содержать параметры "transport-param", "maddr-param", "ttl-param" или элементы "headers". Сервер, который получил SIP-URL с данными элементами, должен удалить их перед началом обслуживания.

Например:

То: The Operator <sip:operator@cs.columbia.edu>;tag=287447

To: sip:+12125551212@server.phone2net.com

9.32. Unsupported

Поле заголовка ответа Unsupported представляет список возможностей, не поддерживаемых сервером.

9.33. User-Agent

Поле заголовка запроса User-Agent содержит информацию об агенте пользователя клиента, отправившего запрос. Клиенты не обязательно должны включать данное поле в запрос.

9.34. Via

Поле общего заголовка Via должно использоваться шлюзами и серверами прокси для указания промежуточных получателей и протоколов, с помощью которых было передано сообщение между клиентом и запрашиваемым сервером или между сервером-источником и клиентом.

Вместо настоящего имени узла может указываться псевдоним.

Каждый получатель сообщения должен добавить свою информацию таким образом, чтобы, в конечном счете, список соответствовал порядку пересылавших сообщение приложений.

По умолчанию роrt=5060.

Если прокси-сервер получил сообщение, в котором в цепочке Via стоит его имя, то он должен выдать ответ с кодом 482 (зацикливание).

Добавление информации в поле Via является необязательным.

Прокси, если он выполняет функции межсетевого экрана, может стереть информацию, добавленную в поле Via, либо заменять смежные цепочки идентификаторов получателей на единое имя.

Прокси не должен заменять смежные цепочки идентификаторов получателей на единое имя, если в данной цепочке присутствуют идентификаторы различных протоколов получателей.

Например:

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060

Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3

Via: SIP/2.0/UDP first.example.com:4000;ttl=16;maddr=224.2.0.1;branch=a7c6a8dlze (Example)

Via: SIP/2.0/UDP adk8

9.35. Warning

Поле заголовка ответа Warning используется для переноса дополнительной информации о статусе ответа, которая не была отражена в коде статуса ответа.

В тесте warn-text используется набор символов, соответствующий реальному языку человека получателя ответа.

Прокси-сервер не должен удалять поля Warning, полученные в ответе. Прокси-сервер должен добавлять поля Warning перед любыми полями Autorization, но после уже существующих в ответе полей Warning.

Определены следующие коды warn-code:

9.36. WWW-Authenticate

Поле заголовка ответа WWW-Authenticate должно быть включено в сообщение ответа 401. Значение поля состоит из, как минимум, одного вызова, указывающего на схему идентификации и параметров, применимых для данного Request-URI. Содержимое параметра "realm" должно быть выдано на экран пользователю.