СРЕДСТВА ТЕХНИЧЕСКИЕ ТЕЛЕМАТИЧЕСКИХ СЛУЖБ

ПРОТОКОЛ SIP

ОБЩИЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

Редакция 1-2002

СОГЛАСОВАНЫ Руководителем ДЭС Минсвязи России В.Ю.Квицинским 03.07.2002

УТВЕРЖДЕНЫ Первым заместителем Министра Российской Федерации по связи и информатизации Ю.А.Павленко  03.07.2002

     1. НАЗНАЧЕНИЕ ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ

1.1. Настоящие общие технические требования (ОТТ) распространяются на оборудование телематических служб, реализующего функции взаимодействия элементов сети по протоколу SIP (протокол инициирования сеанса), и являются дополнением к РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования".

1.2. ОТТ предназначены для руководства при проведении сертификационных испытаний оборудования, поддерживающего протокол SIP.

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

1.4. ОТТ составлены на основе документов, список которых приведен в Приложении 4.

1.5. Данные ОТТ распространяются на следующую аппаратуру связи, реализующую функции передачи речевой информации по сетям с маршрутизацией пакетов по протоколу IP:

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

- аппаратура регистрации пользователя в сети (персональный компьютер, работающий по интерфейсам локальной сети);

- аппаратуру маршрутизации пакетов IP с функциями преобразования речевой информации в пакеты IP и взаимодействия с ТфОП (шлюз).

     2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К СЕРВЕРУ SIP

     2.1. Соединения

2.1.1. Протокол нижнего уровня

Сообщения SIP могут передаваться с использованием соединения TCP или UDP. Если порт не назначен, то, по умолчанию, используется порт 5060.

2.1.2. Установление соединения и закрытие соединения

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

Сервер должен держать открытым установленное TCP-соединение до завершения SIP-транзакции. Соединение может быть закрыто после окончания SIP-транзакции.

     3. ПЕРЕЧЕНЬ И СТРУКТУРА СООБЩЕНИЙ ПРОТОКОЛА SIP

     3.1. Требования к элементам сообщений

3.1.1. В сообщении SIP должен использоваться формат адреса URI в соответствии с п.2.2. Приложения 2.

3.1.2. В сообщении SIP должен использоваться один из форматов представления даты, приведенных в п.2.3.1. Приложения 2.

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

3.1.4. Описание Request-URI должно соответствовать описанию п.2.2. Приложения 2.

     3.2. Адресация

3.2.1. Объекты, поддерживающие SIP-протокол, используют систему адресации подобную адресу электронной почты - user@host. В качестве адреса используется специальный универсальный указатель ресурсов SIP URL, описание которого приведено в п.2.2. Приложения 2.

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

  1. а) user - имя пользователя, зарегистрированного в домене или на рабочей станции, или телефонный номер;

  2. б) host - имя домена, рабочей станции или шлюза.

3.2.3. В начале адреса ставится слово "sip:" - указатель SIP-адреса.

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

3.3.1. Если сервер отправляет ответ с типом информации, отличным от application/sdp, он должен указать данный тип в поле Content-Type. Обозначение типа должно соответствовать RFC 2068.

3.3.2. Если к телу сообщения применяется преобразование, тип преобразования должен быть указан в поле Content-Encoding в соответствии с п.9.8. Приложения 2.

     3.4. Запросы

3.4.1. Запросы образуют выходной поток. Структура запросов протокола SIP должна соответствовать п.3. и п.4. Приложения 2.

3.4.2. В сервере должна быть реализована обработка запросов с методами INVITE, АСК, BYE, CANCEL, REGISTER, OPTION.

3.4.3. Тело сообщения запроса INVITE, приглашающего принять участие в сеансе связи, должно содержать информацию об описании соответствующего сеанса связи. Описание может быть представлено в формате SDP в соответствии с RFC 2327. Описание протокола приведено в Приложении 3. Метод INVITE может использоваться для изменения характеристик уже организованных каналов с новым описанием сеанса связи.

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

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

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

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

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

3.4.9. Для обеспечения качества обслуживания QoS может применяться резервирование ресурсов для заданного сеанса связи в соответствии с протоколом RSVP (RFC 2205).

     3.5. Ответы

3.5.1. Ответы образуют входной поток. Структура ответов сервера должна соответствовать п.5. Приложения 2.

3.5.2. Сервер SIP v.2.0. должен поддерживать ответы с кодами статуса, приведенными в Таблице 1.

Таблица 1

Код

Описание

100

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

180

Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове.

181

Прокси-сервер переадресует вызов к другому пользователю.

182

Вызываемый пользователь временно не доступен, но входящий вызов поставлен в очередь. Когда вызываемый пользователь станет доступным, он передаст финальный ответ.

200

Команда успешно выполнена.

300

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

301

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

302

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

305

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

380

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

400

В запросе обнаружена синтаксическая ошибка.

401

Требуется проведение процедуры авторизации пользователя.

402

Требуется предварительная оплата услуг.

403

Запрос не будет обслуживаться сервером и не будет передаваться повторно.

404

Сервер не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI.

405

Не разрешается передавать запрос этого типа на адрес, указанный в поле request-URI. В поле Allow ответа указываются разрешенные типы запросов.

406

Ответы, генерируемые вызываемой стороной, не будут поняты вызывающей стороной.

407

Клиент должен подтвердить свое право доступа к прокси-серверу.

408

Сервер не может передать ответ в течение промежутка времени, указанного в поле Expire.

409

Обработка запроса register не может быть завершена из-за конфликта между действием, определенным в параметре action запроса, и текущим состоянием ресурсов.

410

Сервер больше не имеет доступа к запрашиваемому ресурсу и не знает, куда передавать запрос.

411

Требуется указать длину тела сообщения в поле Content-Length.

413

Размер запроса слишком велик для обработки.

414

Адрес, указанный в поле request-URI, оказался слишком большим, поэтому его интерпретация невозможна.

415

Запрос содержит не поддерживаемый формат тела сообщения.

420

Сервер не понял расширение протокола, специфицированное в поле Require.

480

Вызываемый пользователь временно недоступен.

481

Посылается в ответ на получение запроса BYE, не относящегося к текущим соединениям, или запроса CANCEL, не относящегося к текущим запросам.

482

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

483

Сервер обнаружил в поле Via, что принятый им запрос прошел через большее количество прокси-серверов, чем разрешено в поле Max-Forwards.

484

Сервер принял запрос с неполным адресом в поле То или Request-URI. Требуется дополнительная адресная информация.

485

Адрес вызываемого пользователя неоднозначен. В заголовке Contact ответа может содержаться список адресов, по которым этот запрос можно передать.

486

В настоящий момент вызываемый пользователь не желает или не может принять вызов на этот адрес. Ответ не исключает возможности связаться с пользователем по другому адресу.

500

Внутренняя ошибка сервера.

501

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

502

Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответов сервера, к которому он направил запрос.

503

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

504

Сервер, функционирующий в качестве шлюза или прокси-сервера, в течение установленного интервала времени не получил ответ от сервера, к которому он обратился для завершения обработки ответа.

505

Сервер не поддерживает данную версию протокола SIP.

600

Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время.

603

Вызываемый пользователь не может или не желает принимать входящие вызовы. В ответе может быть указано подходящее время для вызова.

604

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

606

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

3.5.3. В ответе сервера обязательно должно присутствовать поле Date, содержащее дату и время генерации сообщения сервером.

3.5.4. В таблице 2 приведены категории ответов, генерируемые различными SIP-объектами.

Таблица 2

Свойства

Сервер переадресации

Прокси-
сервер

Агент пользователя сервера

Сервер регистрации

Действия аналогичные действиям SIP-клиента

Нет

Да

Нет

Нет

Возврат ответа с кодами 1хх

Да

Да

Да

Да

Возврат ответа с кодами 2хх

Нет

Да

Да

Да

Возврат ответа с кодами 3хх

Да

Да

Да

Да

Возврат ответа с кодами 4хх

Да

Да

Да

Да

Возврат ответа с кодами 5хх

Да

Да

Да

Да

Возврат ответа с кодами 6хх

Нет

Да

Да

Да

Включение поля Via

Нет

Да

Нет

Нет

Обработка АСК

Да

Да

Да

Нет

     4. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ ВЗАИМОДЕЙСТВИЯ SIP-ОБЪЕКТОВ

     4.1. Действия SIP-клиента

4.1.1. Инициатор может использовать два метода для приглашения ответчика на конференцию: послать запрос на локальный прокси-сервер или послать запрос непосредственно вызываемой стороне в соответствии с заданным Request-URI.

4.1.2. Для первого случая вызывающий клиент посылает запрос на разрешенный SIP- сервер. Запрос и все ответы с него образуют SIP-транзакцию. Ответы содержат некоторые значения полей Call-ID, Cseq, To, From, которые соответствуют посланному запросу.

4.1.3. Для второго случая вызывающий клиент должен сам определить протокол, порт, IP-адрес вызываемой стороны, используя SRV-запросы к серверу DNS в соответствии с RFC 2052.

4.1.4. Клиент может кэшировать успешные ответы DNS-сервера, которые должны быть аннулированы по истечении срока жизни.

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

4.1.6. Если прокси-сервер продвигает запрос, то он должен добавить в начало списка продвижения заголовок Via. Via используется для обратного продвижения ответа. В ответе каждый хост должен удалить свое значение Via.

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

     4.2. Функционирование SIP-клиентов и серверов

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

4.2.2.Серверы могут выдать один или более промежуточных ответов в любое время перед посылкой окончательного ответа. Если прокси-сервер с сохранением состояния, агент пользователя сервера, сервер переадресации или сервер регистрации не могут ответить на запрос окончательным ответом в течение 200 мс, то они должны выдать промежуточный ответ с кодами 1хх. Сервер без сохранения состояния не должен выдавать промежуточных ответов.

4.2.3. Если прокси-сервер с сохранением состояния получил ответ на запрос, информации о котором он не имеет, и заголовок Via описывает протокол TCP, то он должен установить TCP-соединение по заданному адресу и передать ответ.

4.2.4. Прокси-сервер с сохранением состояния должен удерживать соединение не менее 32 сек при получении первого заключительного ответа не с кодом 200 для случая повторной передачи ответа.

4.2.5. Групповые запросы по UDP должны содержать поле Request-URI, соответствующее данной административной системе. Ответ на групповой запрос должен быть групповым. Серверы на групповые запросы не должны выдавать ответы отличные от 2хх или 6хх. Сервер может подавить ответы с другими кодами, полученные от других серверов. Сервер может задержать отправку ответов для равномерного их распределения в течение 1 сек. Прокси-сервер или агент пользователя клиента должны послать запрос CANCEL при получении первого ответа с кодом 2хх или 6хх на групповой запрос.

4.2.6. Повторная передача запросов BYE, CANCEL, OPTIONS или REGISTER осуществляется SIP-клиентом только при использовании в качестве транспорта протокола UDP. Временные интервалы для повторной передачи рассчитываются следующим образом. Первая повторная передача через интервал Т1, вторая - 2*Т1, третья - 4*Т1 и так далее пока значение не достигнет интервала Т2, все последующие передачи через интервал Т2. При получении первого промежуточного ответа повторная передача осуществляется через интервал Т2. Значения интервалов Т1 и Т2 должны быть не меньше 500 мс и 4 сек соответственно. Сервер должен кэшировать окончательный ответ в течение 10*Т2. Число повторных передач должно быть ограничено для избежания перегрузок в сети. При получении запроса CANCEL каждый прокси-сервер должен генерировать соответствующее число запросов CANCEL на сгенерированные ранее повторные запросы.

4.2.7. Повторная передача запроса INVITE выполняется следующим образом. SIP-клиент начинает повторно передавать запрос INVITE с интервалом Т1, удваивая в дальнейшем этот интервал с каждым посланным пакетом. Клиент осуществляет повторную передачу пока не получит промежуточный или окончательный ответ, но не более 7 раз. Сервер посылает промежуточный ответ на каждый дублирующий запрос. Сервер повторно посылает окончательный ответ с интервалом Т1, удваивая его с каждым последующим пакетом, пока не получит запрос АСК, BYE, CANCEL или пока число посланных ответов не достигнет 7.

4.2.8. Запрос АСК не должен генерировать ответ для избежания формирования петли.

     4.3. Функционирование агента пользователя клиента и сервера

4.3.1. Для осуществления вызова агент пользователя клиента формирует запрос INVITE, в котором поле То содержит адрес вызываемой стороны, Request-URI содержит тот же самый адрес, поле From содержит адрес вызывающей стороны. Если адрес в поле From был сформирован другим агентом пользователя клиента, то вызывающая сторона должна включить параметр тега в поле From. Агент пользователя клиента может добавить в поле Contact адрес для обеспечения взаимодействия с вызывающей стороной.

4.3.2. После получения запроса INVITE вызывающая сторона может обработать, переадресовать или отклонить запрос. В ответ должны быть скопированы из запроса поля То, From, Call-ID, Cseq и Via. Дополнительно агент пользователя сервера может добавить в ответе параметр тега в поле То, если в запросе содержался более чем один заголовок Via.

4.3.3. На один посланный запрос INVITE может прийти несколько ответов. Каждый ответ отличается параметром тега в поле То и каждый соответствует отдельному маршруту вызова. Вызывающая сторона может подтвердить или завершить вызов с каждым отвечающим агентом пользователя сервера. Для подтверждения посылается запрос АСК, для завершения запрос BYE. Запросы АСК и BYE должны содержать те же поля То, From с любыми параметрами тегов, что и в ответе агента пользователя сервера с кодом 200. Request-URI может быть взят из поля Contact (если оно представлено) или из поля То из ответа с кодом 200. Для маршрута вызова То - удаленный адрес, From - локальный адрес.

4.3.4. После установления вызова вызывающая или вызываемая стороны могут генерировать запросы INVITE или BYE для изменения или завершения вызова. Для этого используются значения То и From из предыдущих запросов или ответов.

4.3.5. При получении последующих запросов сервер может их интерпретировать следующим образом:

- установить новое соединение, если Call-ID неизвестно, независимо от полей То и From;

- считать повторной передачей, если Call-ID, To, From, Cseq имеют те же значения, что и в предыдущем запросе;

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

     4.4. Функционирование прокси-сервера и сервера переадресации

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

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

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

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

4.4.5. Прокси-сервер без сохранения состояния продвигает вперед в выходной поток клиента запросы и обратно во входной поток ответы.

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

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

4.4.8. Прокси-сервер с сохранением состояния удаляет при обработке из ответов поля Via, содержащие его адрес, и проверяет адреса в других полях Via. Для соединения UDP ответы посылаются по списку адресов, указанных в теге "maddr" (если он представлен), иначе по адресу, указанному в теге "received" (если он представлен), и в заключении по адресу из поля "sentby'. Прокси-сервер должен оставаться сервером с сохранением состояния при получении запросов по TCP-соединению. Сервер должен проверять, что установленное по заданному адресу TCP-соединение открыто. Ответы не с кодом 2хх могут повторно передаваться и по ТСР-соединению.

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

4.4.10. Прокси-сервер с сохранением состояния должен автоматически передавать повторно посланные промежуточные или окончательные ответы. Сервер может генерировать свои промежуточные ответы с кодом 1хх.

4.4.11. При получении запроса АСК сервером с сохранением состояния сравниваются значения полей То, From, Cseq, Call-ID со значениями из предыдущих запросов. Если они не соответствуют, то запрос обрабатывается аналогично запросу INVITE. Если они соответствуют, то сервер должен послать ответ с кодом 200 во входной поток, а запрос АСК передать дальше.

     4.5. Идентификация доступа

4.5.1. Для начала процедуры идентификации должен использоваться ответ 401 (или 407 для идентификации на прокси-сервере) с полем WWW-Authenticate (Proxy-Authenticate). В процедуре идентификации должно использоваться содержимое поля запроса Authorization (Proxy-Authorization). Если сервер не принимает сообщение клиента с полем Authorization (Proxy-Authorization), он снова должен выдать ответ 401.

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

4.5.3. Если сервер поддерживает обзорную схему идентификации доступа, ее реализация должна соответствовать п.8.2. Приложения 2.

4.5.4. Если сервер поддерживает схему идентификации доступа PGP, ее реализация должна соответствовать п.8.3. Приложения 2.

     4.6. Обеспечение широковещательной рассылки

4.6.1. Широковещательная рассылка обеспечивается посылкой множественных запросов с использованием протокола UDP. Запрос должен быть распространен только в пределах своей административной системы.

4.6.2. Широковещательный запрос имеет независимое Request-URI. Ответы на широковещательный запрос имеют TTL такое же, что и TTL в заголовке Via из полученного запроса.

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

4.6.4. Если запрос был послан, как широковещательный, то и ответ должен быть широковещательным.

4.6.5. Сервер не должен выдавать ответ на широковещательный запрос с кодом отличным от 2хх или 6хх. Сервер задерживает свои ответы в интервале от 0 до 1 сек.

4.6.6. Сервер может подавлять ответы, если они посланы подчиненным членом, или ответы с кодом 6хх, посланные от другого члена группы.

4.6.7. Сервер не должен отвечать на широковещательный запрос CANCEL.

4.6.8. Прокси-сервер или агент пользователя клиента должен послать CANCEL на полученный первый ответ с кодом 2хх или 6хх широковещательного запроса.

     5. ВЗАИМОДЕЙСТВИЕ ПРОТОКОЛА SIP С ДРУГИМИ ПРОТОКОЛАМИ, ОБЕСПЕЧИВАЮЩИМИ ПОДДЕРЖКУ ПЕРЕДАЧИ РЕЧЕВОЙ ИНФОРМАЦИИ ПО СЕТЯМ ПЕРЕДАЧИ ДАННЫХ С ПРОТОКОЛОМ IP

5.1. Сервер определения местоположения может использовать также один из следующих протоколов:

- протокол finger, который должен быть реализован в соответствии с RFC 1288;

- протокол rwois, который должен быть реализован в соответствии с RFC 2167;

- протокол LDAP, который должен быть реализован в соответствии с требованиями "Средства технические телематических служб. Сервер LDAP. Технические требования", утвержденными Минсвязи России 24.08.2001.

5.2. Для описания устанавливаемого сеанса связи может быть использован протокол описания параметров связи SDP в соответствии с RFC 2327.

5.3. Для передачи речевой информации используется транспортный протокол реального времени RTP, который должен соответствовать требованиям РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

5.4. Для обеспечения качества обслуживания трафика речевых приложений используется протокол резервирования ресурсов RSVP, который должен соответствовать требованиям RFC 2205.

5.5. Для синхронизации работы устройств управления шлюзами протокол SIP может взаимодействовать с протоколом управления шлюзами MGCP, который должен соответствовать с требованиями RFC 2705.

     6. ВЗАИМОДЕЙСТВИЕ С ТФОП

6.1. Взаимодействие с телефонной сетью общего пользования должно удовлетворять требованиям раздела 6.6. РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     7. ТРЕБОВАНИЯ К КОНСТРУКЦИИ

7.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к конструкции должна удовлетворять требованиям раздела 6.10 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     8. ТРЕБОВАНИЯ К ЭЛЕКТРОПИТАНИЮ

8.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к электропитанию должна удовлетворять требованиям раздела 6.11 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     9. ТРЕБОВАНИЯ К УСТОЙЧИВОСТИ К ВОЗДЕЙСТВИЮ ВНЕШНИХ ФАКТОРОВ

9.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к устойчивости к воздействию внешних факторов должна удовлетворять требованиям раздела 6.12 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     10. ТРЕБОВАНИЯ К НАДЕЖНОСТИ

10.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к надежности должна удовлетворять требованиям раздела 6.13 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     11. ТРЕБОВАНИЯ К ЭЛЕКТРОМАГНИТНОЙ СОВМЕСТИМОСТИ

11.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к электромагнитной совместимости должна удовлетворять требованиям раздела 6.14 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     12. ТРЕБОВАНИЯ К МАРКИРОВКЕ И УПАКОВКЕ

12.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к маркировке и упаковке должна удовлетворять требованиям раздело 6.15 и 6.16 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     13. ТРЕБОВАНИЯ К БЕЗОПАСНОСТИ ПЕРСОНАЛА

13.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IP с использованием SIP-протокола, в части требований к безопасности персонала должна удовлетворять требованиям раздела 7 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     14. ТРЕБОВАНИЯ К ТРАНСПОРТИРОВАНИЮ И ХРАНЕНИЮ

14.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом ЕР с использованием SIP-протокола, в части требований к транспортированию и хранению должна удовлетворять требованиям раздела 8 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     15. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ

15.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IР с использованием SIP-протокола, в части требований к документации должна удовлетворять требованиям раздела 9 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

     16. ТРЕБОВАНИЯ К ПРАВИЛАМ ПРИЕМКИ И МЕТОДАМ КОНТРОЛЯ

16.1. Аппаратура, реализующая передачу речевой информации по сети передачи данных с протоколом IР с использованием SIP-протокола, в части требований к правилам приемки и методам контроля должна удовлетворять требованиям раздела 10 РД 45.046-99 "Аппаратура связи, реализующая функции передачи речевой информации по сетям передачи данных с протоколом IP. Технические требования", утвержденного Гостелекомом России 12.11.99.

          
ПРИЛОЖЕНИЕ 1

     
ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

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

Маршрут вызова - идентификатор, состоящий из комбинации Call-ID, To, From.

Клиент - прикладная программа, посылающая SIP-запросы.

Конференция - мультимедийный сеанс, определенный общим описанием сеанса.

Выходной поток - запросы, посланные в течение сеанса, от вызывающей стороны к вызываемой стороне (агент пользователя клиента агенту пользователя сервера).

Окончательный ответ - ответ, завершающий SIP-транзакцию.

Инициатор - сторона, приглашающая на конференцию.

Приглашение - запрос, посланный пользователю, для участия в сессии.

Ответчик - участник или служба, которых вызывающая сторона пытается пригласить на конференцию.

Изоморфный запрос или ответ - два запроса или ответа, имеющие одни и те же значения полей заголовка Call-ID, To, From, Cseg.

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

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

Промежуточный ответ - ответ сервера, характеризующий процесс, но не завершение SIP-транзакции.

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

Сервер переадресации - сервер, который принимает SIP-запрос, отображает адрес в ноль или более новых адресов и возвращает эти адреса клиенту.

Сервер - прикладная программа, которая принимает запросы по порядку для их обслуживания и посылает обратно ответы на эти запросы.

Сеанс - набор мультимедийных отправителей и получателей и поток данных, направленных от отправителей получателям.

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

Входной поток - ответы, посланные от агента пользователя сервера агенту пользователя клиента.

Агент пользователя клиента - приложение клиента, которое инициирует SIP-запросы.

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

Запрос - сообщение запроса SIP.

Ответ - сообщение ответа SIP.

Содержание - информация, передаваемая в виде полезной нагрузки запроса или ответа. Содержание состоит из метаинформации в форме полей заголовка содержания и содержимого в форме тела содержания.

Заголовок сообщения SIP - 1. набор строк между первой строкой сообщения (start-line) и пустой строкой, отделяющей заголовок от тела сообщения. 2. строка (несколько строк), содержащая выражение, задающее значение для отдельного поля заголовка сообщения.

IANA (Internet Assigned Numbers Autority) - орган назначения чисел Интернет.

CR - символ возврата каретки

LF - символ перевода строки

MGCP - протокол управления шлюзами

LDAP - облегченный протокол доступа к директории

PGP - протокол шифрования сообщений

RSVP - протокол резервирования ресурсов

RTP - протокол транспортировки в реальном времени

RTCP - протокол контроля транспортировки информации в реальном времени

SDP - протокол описания параметров связи

SIP - протокол инициирования сеансов связи

SRV - тип ресурсной записи DNS, обозначающий местонахождение сервера в домене, который обеспечивает определенный сервис

TCP - протокол управления передачей данных

UDP - протокол передачи дейтаграмм пользователя

TTL - время существования

URI - единообразный идентификатор ресурса

URL - единообразный указатель ресурса

Finger - протокол проверки наличия пользователя по ID

Rwhois - протокол представления информации о сетевых объектах и ресурсах

ПРИЛОЖЕНИЕ 2

     
ОПИСАНИЕ ПРОТОКОЛА SIP

1. Базовые определения

Спецификация синтаксиса запросов и ответов SIP приводится в расширенной форме Наура-Бекуса, соответствующей RFC-822.

Базовые определения:

OCTET

= <8 бит любых данных>

CHAR

= <любой символ US-ASCII (октеты от 0 до 127)>

UPALPHA

= <любая прописная буква US-ASCII "A".."Z">

LOALPHA

= <любая строчная буква US-ASCII "a".."z">

ALPHA

= UPALPHA LOALPHA

DIGIT

= <любая цифра US-ASCII "0".."9">

CTL

= <любой управляющий символ US-ASCII
(октеты от 0 до 31) и DEL (127)>

CR

= <US-ASCII CR, возврат каретки (13)>

LF

= <US-ASCII LF, пропуск линии (10)>

SP

= <US-ASCII SP, пробел (32)>

НТ

= <US-ASCII HT, горизонтальная табуляция (9)>

<">

= <US-ASCII двойные кавычки (34)>

CRLF

= CR LF

Следующие определения используются для представления SIP URI.

unreserved

= alphanum mark

alphanum

= alpha digit

mark

=   "-" "_" "." "!" "~" "*" "'"

"("I")"

escaped

= "%" hex hex

Заголовок SIP может быть разбит на несколько линий. 2-я и далее линии заголовка должны начинаться с пробела или табуляции.

LWS

= [CRLF] 1 *( SP НТ )

Слова *TEXT-UTF8 могут содержать символы набора, отличного от ISO 10646 только в случае, если они закодированы в соответствии с RFC 2279.

TEXT-UTF8

= <любой символ в кодах UTF-8, кроме октетов CTL, но включая LWS>

HEX

= "А" "В" "С" "D" "Е" "F"

"а" "b" "с" "d" "е" "f' DIGIT

token

= 1 *<any CHAR, исключая CTLs или separators>

separators

= "(" ")" "<" ">" "@"

"," ";" ":" "\" <">

"/" "[" "]" "?" "="

"{" "}" SP HT

Если в значении поля заголовка содержатся специальные символы, эти специальные символы должны содержаться в строке в кавычках.

comment

= "(" *( ctext comment)")"

ctext

= <любой TEXT-UTF8 кроме "(" и ")">

Строка текста, заключенная в двойные кавычки ("строка в кавычках"), обрабатывается как единое слово.

quoted-string

= ( <"> *(qdtext) <"> )

qdtext

= <any TEXT except <">>

Конструкция квотирования "\<символ>" может использоваться только внутри "строки в кавычках" и комментария.

quoted-pair

= "\" CHAR

2. Элементы протокола

2.1. Версия SIP

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

SIP-Version

= "SIP" "/" 1*DIGIT "." 1*DIGIT

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

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

2.2.1. SIP-URL

URL - универсальный указатель расположения ресурса, используется в SIP-сообщениях для идентификации отправителя (From), текущей позиции (Request-URI) и окончательного получателя (То) SIP-запроса, и для определения адресов переадресации (Contact).

SIP-URL

= "sip:" [ userinfo "@" ] hostport url-parameters [ headers ]

userinfo

= user [":" password ]

user

= *( unreserved escaped "&" "=" "+" "$" "," )

password

= *( unreserved escaped "&" "=" "+" "$" "," )

hostport

= host [ ":" port ]

host

= hostname IPv4address

hostname

= *( domainlabel "." ) toplabel [ "." ]

domainlabe

= alphanum alphanum *( alphanum "-") alphanum

toplabel

= alpha alpha *( alphanum "-" ) alphanum

IPv4address

= 1*digit"." 1*digit "." 1*digit"." 1*digit

port

= *digit

url-parameters

= *( ";" url-parameter)

url-parameter

= transport-param user-param method-param ttl-param maddr-param other-param

transport-param

= "transport=" ( "udp" "tcp" )

ttl-param

= "ttl=" ttl

ttl

=1*3DIGIT

; от 0 до 255

maddr-param

= "maddr=" host

user-param

= "user=" ("phone" "ip" )

method-param

= "method=" Method

tag-param

= "tag=" UUID

UUID

= 1*( hex "-" )

other-param

= ( token ( token "=" ( token quoted-string )))

headers

= "?" header *( "&" header)

header

= hname "=" hvalue

hname

= 1*uric

hvalue

= *uric

uric

= reserved unreserved escaped

reserved

= ";" "/" "?" ":" "@" "&" "=" "+" "$" ","

digits

= 1*DIGIT

Если host является шлюзом IP-телефонии, то поле user представляет телефонный номер и описывается, как телефонный абонент.

telephone-subscriber

= global-phone-number local-phone-number

global-phone-number

= "+" 1 *phonedigit [isdn-subaddress] [post-dial]

local-phone-number

= 1*(phonedigit dtmf-digit pause-character) [isdn-subaddress] [post-dial]

isdn-subaddress

= ";isub=" 1*phonedigit

post-dial

= ";postd=" 1*(phonedigit dtmf-digit pause-character)

phonedigit

= DIGIT visual-separator

visual-separator

= "-" "."

pause-character

= one-second-pause wait-for-dial-tone

one-second-pause

= "p"

wait-for-dial-tone

= "w"

dtmf-digit

= "*" "#" "A" "В" "С" "D"

Если port не указан, то предполагается порт по умолчанию 5060.

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

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

2.3.1. Полная дата

Существует одна допустимая форма представления даты/времени:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, с учетом изменений, внесенных RFC 1123

Время и дата, указанные в метках даты/времени, должны соответствовать Среднему Гринвичскому времени

SIP-date

= rfc1123-date

rfc1123-date

= wkday "," SP date1 SP time SP "GMT"

date1

= 2DIGIT SP month SP 4DIGIT

; день месяц год (Например, 02 Jun 1982)

time

= 2DIGIT ":" 2DIGIT ":" 2DIGIT

; 00:00:00-23:59:59

wkday

= "Mon" "Tue" "Wed" "Thu" "Fri" "Sat" "Sun"

weekday

= "Monday" "Tuesday" "Wednesday" "Thursday" "Friday" "Saturday" "Sunday"

month

= "Jan" "Feb" "Mar" "Apr" "May" "Jun" "Jul" "Aug"

"Sep" "Oct" "Nov" "Dec"

2.3.2. Период в секундах

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

delta-seconds

= 1 *DIGIT

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.

media-type

= type "/" subtype *( ";" parameter )

type

= token

subtype

= token

parameter

= attribute "=" value

attribute

= token

value

= token quoted-string

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

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

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

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

qvalue

= ( "0" [ "." 0*3DIGIT ] )

 ( "1" [ "." 0*3( "0" ) ] )

2.8. Теги опций

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

option-tag

= token

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

     3. Сообщение SIP

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

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

SIP-message

= Request Response

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

generic-message

= start-line

*message-header

CRLF [ message-body ]

start-line

= Request-Line Status-Line

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

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

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

message-header

= (general-header

request-header

response-header

entity-header )

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

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

message-header

= field-name ":" [ field-value ] CRLF

field-name

= token

field-value

= *( field-content LWS )

field-content

= < ОКТЕТы состоят или из *TEXT-UTF8

или комбинации token, separators, quoted-string>

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

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

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

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

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

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

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

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

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

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

general-header

= Accept

Accept-Encoding

Accept-Language

Call-ID

Contact

CSeq

Date

Encryption

Expires

From

Record-Route

Timestamp

To

Via

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

     4. Запрос

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

Request

= Request-Line

*( general-header

request-header

entity-header )

CRLF

[ message-body ]

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

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

Request-Line  

= Method SP Request-URI SP SIP-Version CRLF

4.1.1. Method (Метод)

Регистр символа слова, обозначающего метод, является существенным.

Method

= "INVITE" "ACK" "OPTIONS" "BYE"

"CANCEL" "REGISTER"

4.1.2. Request-URI (URI запроса)

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

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

Request-URI

= "*" absoluteURI abs_path

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

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

request-header

= Authorization

Contact

Hide

Max-Forwards

Organization

Priority

Proxy-Authorization

Proxy-Require

Route

Require

Response-Key

Subject

User-Agent

     5. Ответ

После получения и обработки сообщения запроса сервер отвечает сообщением ответа:

Response

= Status-Line

*( general-header

response-header

entity-header )

CRLF

[ message-body ]

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

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

Status-Line

= SIP-Version SP Status-Code SP Reason-Phrase CRLF

5.1.1. Status-Code (код статуса) и Reason-Phrase (причина)

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

Status-Code

= Informational

Success

Redirection

Client-Error

Server-Error

Global-Failure

extension-code

extension-code

= 3DIGIT

Reason-Phrase

= *<TEXT-UTF8, исключая CR, LF>

Informational

= "100"; запрос обрабатывается

"180"; Местоположение определено

"181"; Запрос переадресован

"182"; Вызов поставлен в очередь

Success

= "200"; Команда успешно выполнена

Redirection

= "300"; Вызываемый пользователь доступен по нескольким адресам

"301"; Пользователь изменил местоположение

"302"; Пользователь временно изменил местоположение

"303"; Другие

"305"; Необходимо использование прокси

"380"; Альтернативный вызов

Client-Error

= "400"; Синтаксическая ошибка в запросе

"401"; Неправомочный пользователь, требуется авторизация

"402"; Требуется предварительная оплата услуг

"403"; Запрещен

"404"; Не найден пользователь в заданном домене

"405"; Недопустимый метод

"406"; Неприемлем ответ

"407"; Требуется аутентификация к прокси

"408"; Таймаут запроса

"409"; Конфликт при выполнении REGISTER

"410"; Нет доступа к заданному ресурсу

"411"; Требуется длина

"413"; Запрос слишком большой для обработки

"414"; Адрес, указанный в URI, слишком большой

"415"; Неподдерживаемый формат тела сообщения

"420"; Неизвестное расширение протокола

"480"; Временно не доступный пользователь

"481"; Вызванная транзакция не существует

"482"; Обнаружена петля в маршруте вызова

"483"; Слишком много передач

"484"; Неполный адрес

"485"; Неоднозначный

"486"; Занято

Server-Error

= "500"; Внутренняя ошибка сервера

"501"; Функции, необходимые для обработки запроса, не существуют

"502"; Некорректный ответ от сервера серверу

"503"; Недоступный сервер

"504"; Таймаут сервера

"505"; Версия SIP не поддерживается

Global-Failure

= "600"; Пользователь занят, обратиться в другое время

"603"; Пользователь не принимает входящие вызовы

"604"; вызываемого пользователя не существует

"606"; Неприемлемы параметры сеанса связи

Первая цифра поля Status-Code определяет класс ответа:

1хх

Информационный

Запрос получен, продолжаю процесс обработки

2хх

Успех

Команда получена, понята и принята

3хх

Перенаправление

Должны быть предприняты дальнейшие действия для завершения запроса

4хх

Ошибка клиента

Запрос содержит синтаксическую ошибку или не может быть выполнен

5хх

Ошибка сервера

Сервер не может выполнить очевидно правильный запрос.

6хх

Глобальная ошибка

Запрос не может быть выполнен ни на каком сервере.

От реализаций SIP не требуется различать значения всех указанных кодов статуса. Но реализации должны различать класс статуса (первую цифру кода). Нераспознанный ответ любого класса должен обрабатываться как код х00 данного класса, но не должен кэшироваться.

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

response-header

= Allow

Proxy-Authenticate

Retry-After

Server

Unsupported

Warning

WWW-Authenticate

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

     6. Содержание

Содержание состоит из полей заголовка содержания.

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

entity-header

= Content-Encoding

Content-Length

Content-Type

     7. Определения методов

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. Идентификация доступа

Механизм идентификации клиента не обязателен для реализации.

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

Сообщение ответа 401 (или 407 для прокси-сервера) используется сервером-источником для начала процедуры идентификации клиента. Данный ответ должен содержать поле заголовка WWW-Authenticate (Proxy-Authenticate), содержащее как минимум один вызов, применимый к запрошенному ресурсу.

auth-scheme

= token

auth-param

= token "=" quoted-string

challenge

= auth-scheme 1 *SP realm *( "," auth-param)

realm

= "realm" "=" realm-value

realm-value

= quoted-string

Атрибут realm (область), являющийся нечувствительным к регистру символов, должен присутствовать во всех вызовах процедуры идентификации независимо от схемы. Значение realm-value совместно с URL определяет защищаемую область.

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

credentials

= basic-credentials

auth-scheme #auth-param

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

Если сервер не принимает запрос с мандатами, он может выдать ответ 401. При этом ответ 401 должен содержать поле заголовка WWW-Authenticate.

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

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

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

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

WWW-Authenticate: Basic realm="WallyWorld"

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

basic-credentials

= "Basic" SP basic-cookie

basic-cookie

= <закодированный в base64 user-pass,
кроме неограниченного до 76 символов на линию>

user-pass

= userid ":" password

userid  

= *<TEXT кроме ":">

password

= *TEXT

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

Authorization:

Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

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

WWW-Authenticate

= "WWW-Authenticate" ":" "Digest"

digest-challenge

digest-challenge

= 1#( realm [ domain ] nonce

[ digest-opaque ] [ stale ] [ algorithm ])

realm

= "realm" "=" realm-value

realm-value

= quoted-string

domain

= "domain" "=" <"> 1#URI <">

nonce

= "nonce" "=" nonce-value

nonce-value

= quoted-string

opaque

= "opaque" "=" quoted-string

stale

= "stale" "=" ( "true" "false" )

algorithm

= "algorithm" "=" ( "MD5" token )

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

Authorization

= "Authorization" ":" "Digest" digest-response

digest-response

= 1#( username realm nonce digest-uri

response [ digest ] [ algorithm ] opaque )

username

= "username" "=" username-value

username-value

= quoted-string

digest-uri

= "uri" "=" digest-uri-value

digest-uri-value

= request-uri

response

= "response" "=" response-digest

digest

= "digest" "=" entity-digest

response-digest

= <"> *LHEX <">

entity-digest

= <"> *LHEX <">

LHEX

= "0" "1" "2" "3" "4" "5" "6" "7" "8" "9" "a" "b" "c" "d" "e" "f

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

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

WWW-Authenticate

= "WWW-Authenticate" ":" "pgp" pgp-challenge

pgp-challenge

= * (";" pgp-params )

pgp-params

= realm pgp-version pgp-algorithm nonce

realm

= "realm" "=" realm-value

realm-value

= quoted-string

pgp-version     

= "version" "="

<"> digit *( "." digit) *letter <">

pgp-algorithm

= "algorithm" "=" ( "md5" "sha1" token)

nonce

= "nonce" "=" nonce-value

nonce-value = quoted-string

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

Authorization

= "Authorization" ":" "pgp" *( ";" pgp-response )

pgp-response

= realm pgp-version j pgp-signature signed-by nonce

pgp-signature

= "signature" "=" quoted-string

signed-by

= "signed-by" "="<"> URI <">

     9. Определения полей заголовка

В таблице 2.1 приведен перечень SIP-заголовков и их связь с запросами и ответами протокола SIP v.2.0. Описание заголовков приведено ниже.

Таблица 2.1

Название заголовка

Место использования

АСК

BYE

CAN

INV

ОРТ

REG

Accept

Заголовок в запросах

F

F

F

О

О

О

Accept

Заголовок в ответе 415

F

F

F

О

О

О

Accept-Encoding

Заголовок в запросах

F

F

F

О

О

О

Accept-Encoding

Заголовок в ответе 415

F

F

F

О

О

О

Accept-Language

Заголовок в запросах

F

О

О

О

О

О

Accept-Language

Заголовок в ответе 415

F

О

О

О

О

О

Allow

Заголовок в ответе 200

F

F

F

F

М

F

Allow

Заголовок в ответе 405

О

О

О

О

О

О

Authorization

Заголовок в запросах

О

О

О

О

О

о

Call-ID

Общий заголовок - копируется из запросов в ответы

М

М

М

М

М

М

Contact

Заголовок в запросах

О

F

F

О

О

О

Contact

Заголовок в ответах 1хх

F

F

F

О

О

F

Contact

Заголовок в ответах 2хх

F

F

F

О

О

О

Contact

Заголовок в ответах 3хх

F

О

F

О

О

О

Contact

Заголовок в ответе 485

F

О

F

О

О

О

Content-Encoding

Заголовок содержания

О

F

F

О

О

О

Content-Length

Заголовок содержания

О

F

F

О

О

О

Content-Type

Заголовок содержания

*

F

F

*

*

*

Cseq

Общий заголовок - копируется из запросов в ответы

М

М

М

М

М

М

Date

Заголовок в ответах

О

О

О

О

О

О

Encryption

Заголовок в ответах

О

О

О

О

О

О

Expires

Заголовок в ответах

F

F

F

О

F

О

From

Общий заголовок - копируется
из запросов в ответы

М

М

М

М

М

М

Hide

Заголовок в запросах

О

О

О

О

О

О

Max-Forwards

Заголовок в запросах

О

О

О

О

О

О

Organization

Общий заголовок

F

F

F

О

О

О

Proxy-Authenticate

Заголовок в ответе 407

О

О

О

О

О

О

Proxy-Authorization

Заголовок в запросах

О

О

О

О

О

О

Proxy-Require

Заголовок в запросах

О

О

О

О

О

О

Priority

Заголовок в запросах

F

F

F

О

F

F

Require

Заголовок в запросах

О

О

О

О

О

О

Retry-After

Заголовок в запросах

F

F

F

F

F

О

Retry-After

Заголовок в ответах 404, 480, 486, 503, 600 и 603

О

О

О

О

О

О

Response-Key

Заголовок в запросах

F

О

О

О

О

О

Record-Route

Заголовок в запросах

О

О

О

О

О

О

Record-Route

Заголовок в ответах 2хх

О

О

О

О

О

О

Route

Заголовок в запросах

О

О

О

О

О

О

Server

Заголовок в ответах

О

О

О

О

О

О

Subject

Заголовок в запросах

F

F

F

О

F

F

Timestamp

Общий заголовок

О

О

О

О

О

О

To

Общий заголовок - копируется
из запросов в ответы

М

М

М

М

М

М

Unsupported

Заголовок в ответе 420

О

О

О

О

О

О

User-Agent

Общий заголовок

О

О

О

О

О

О

Via

Общий заголовок - копируется из запросов в ответы

М

М

М

М

М

М

Warning

Заголовок в ответах

О

О

О

О

О

О

WWW-Authenticate

Заголовок в ответе 401

О

О

О

О

О

О

F - запрещено использовать заголовок

О - необязательное присутствие заголовка

М - обязательное присутствие заголовка

* - используется в случае, когда тело сообщения не пустое.

9.1. Accept

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

Accept

= "Accept" ":"

#( media-range [ accept-params ] )

media-range

= ( "*/*"

 (type "/" "*" )

 (type "/" subtype)

) *(";" parameter)

accept-params

= ";" "q" "=" qvalue *( accept-extension )

; параметры указывают относительный фактор качества

; (от 0 до 1). По умолчанию - 1.

accept-extension

= ";" token [ "=" (token quoted-string ) ]

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

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

Например:

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

9.2. Accept-Encoding

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

Accept-Encoding

= "Accept-Encoding" ":"

#( content-coding )

Например:

Accept-Encoding: compress, gzip

9.3. Accept-Language

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

Accept-Language

= "Accept-Language" ":"

1#( language-range [";" "q" "=" qvalue ] )

language-range

= ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) "*" )

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

Например:

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

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

9.4. Allow

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

Allow

= "Allow" ":" l#method

Например:

Allow: REGISTER, INVITE, OPTIONS

9.5. Authorization

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

Authorization

= "Authorization" ":" credentials

9.6. Call-ID

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

Call-ID

= ( "Call-ID" "i" ) ":" local-id "@" host

local-id

= 1*uric


"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).

Contact

= ( "Contact" "m" ) ":"

("*" (1# ((name-addr addr-spec )

[ *( ";" contact-params ) ] [ comment ] )))

name-addr

= [ display-name ] "<" addr-spec ">"

addr-spec

= SIP-URL URI

display-name

= *token quoted-string

contact-params

= "q"       "=" qvalue

"action" "=" "proxy" "redirect"

"expires" "=" delta-seconds <"> SIP-date <">

extension-attribute

extension-attribute

= extension-name [ "=" extension-value ]

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

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

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

Например:

Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>

;q=0.7; expires=3600,

"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1

9.8. Content-Encoding

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

Content-Encoding

= ( "Content-Encoding" "e")":"

1 #content-coding

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

9.9. Content-Length

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

Content-Length

= ( "Content-Length" "I" ) ":" 1*DIGIT

Например:

Content-Length: 3495

9.10. Content-Type

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

Content-Type

= ( "Content-Type" "с") ":" media-type

Например:

Content-Type: application/sdp

Content-Type: text/html; charset=ISO-8859-4

9.11. CSeq

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

CSeq

= "CSeq" ":" 1*DIGIT Method

Например:

CSeq: 4711 INVITE

9.12. Date

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

SIP-date

= rfc1123-date

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

9.13. Encryption

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

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

Encryption

= "Encryption" ":" encryption-scheme 1*SP

#encryption-params

encryption-scheme

= token

encryption-params

= token "=" (token quoted-string )

Например:

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.

Expires

= "Expires" ":" ( SIP-date delta-seconds )

Например:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Expires: 5

9.15. From

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

From

= ( "From" "f' ) ":" ( name-addr addr-spec )

*(";" addr-params )

addr-params

= tag-param

tag-param

= "tag=" UUID

UUID

= 1*(hex|"-")

Например:

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

= "Hide" ":" ( "route" "hop" )

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

9.17. Max-Forwards

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

Max-Forwards

= "Max-Forwards" ":" 1*DIGIT

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

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

9.18. Organization

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

Organization

= "Organization" ":" * TEXT-UTF8

9.19. Priority

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

Priority

= "Priority" ":" priority-value

priority-value

= "emergency" "urgent" "normal" "non-urgent"

Например:

Subject: A tornado is heading our way!

Priority: emergency

Subject: Weekend plans

Priority: non-urgent

9.20. Proxy-Authenticate

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

Proxy-Authenticate

= "Proxy-Authenticate" ":" challenge

9.21. Proxy-Authorization

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

Proxy-Authorization

= "Proxy-Authorization" ":" credentials

В отличие от поля 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

= "Record-Route" ":" l#name-addr

Например:

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

<sip:a.bell@ieee.org>

9.24. Require

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

Require

= "Require" ":" l#option-tag

Например:

C->S:

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

Require: com.example.billing

Payment: sheep_skins, conch_shells

S->C:

SIP/2.0 420 Bad Extension

Unsupported: com.example.billing

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

9.25. Response-Key

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

Response-Key

= "Response-Key" ":" key-scheme l*SP#key-param

key-scheme

= token

key-param

= token "=" (token quoted-string)

9.26. Retry-After

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

Retry-After

= "Retry-After" ":" ( SIP-date delta-seconds )

[ comment ] [";" "duration" "=" delta-seconds ]

Например:

Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)

Retry-After: Mon, 01 Jan 9999 00:00:00 GMT

(Dear John: Don't call me back, ever)

Retry-After: Fri, 26 Sep 1997 21:00:00 GMT; duration=3600

Retry-After: 120

9.27. Route

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

Route

= "Route" ":" 1# name-addr

9.28. Server

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

Server

= "Server" ":" 1 *( product comment )

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

9.29. Subject

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

Subject

= ( "Subject" "s" ) ":" *TEXT-UTF8

Например:

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

9.30. Timestamp

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

Timestamp

= "Timestamp" ":" *(DIGIT) ["." *(DIGIT) ] [ delay ]

delay

= *(DIGIT) [ "." *(DIGIT) ]

9.31. To

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

То

= ( "То" "t" ) ":" ( name-addr addr-spec )

*( ";" addr-params )

Кроме 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 представляет список возможностей, не поддерживаемых сервером.

Unsupported

= "Unsupported" ":" l#option-tag

9.33. User-Agent

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

User-Agent

= "User-Agent" ":" 1*( product comment)

9.34. Via

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

Via

= ( "Via" "v") ":" 1#( sent-protocol sent-by

*( ";" via-params ) [ comment ] )

via-params

= via-hidden via-ttl via-maddr via-received via-branch

via-hidden

= "hidden"

via-ttl

= "ttl" "=" ttl

via-maddr

= "maddr" "=" maddr

via-received

= "received" "=" host

via-branch

= "branch" "=" token

sent-protocol

= protocol-name "/" protocol-version "/" transport

protocol-name

= "SIP" token

protocol-version

= token

transport

= "UDP" "TCP" token

sent-by

= (host [ ":" port ] ) ( concealed-host)

concealed-host

= token

ttl

=1*3DIGIT    ; от 0 до 255

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

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

По умолчанию ро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 используется для переноса дополнительной информации о статусе ответа, которая не была отражена в коде статуса ответа.

Warning

= "Warning" ":" l#warning-value

warning-value

= warn-code SP warn-agent SP warn-text

wam-code

= 3DIGIT

warn-agent

= ( host [ ":" port ] ) pseudonym

; имя или псевдоним сервера, добавившего поле заголовка Warning

warn-text

= quoted-string

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

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

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

Код

Описание

300

Несовместимый сетевой протокол. Один или более сетевых протоколов, заданных в описании сессии, не доступен.

301

Несовместимый формат сетевого адреса. Один или более форматов сетевого адреса, заданных в описании сессии, не доступен.

302

Несовместимый транспортный протокол. Один или более транспортных протоколов, заданных в описании сессии, не доступен.

303

Несовместимая полоса пропускания устройства. Размеры полосы пропускания одного или нескольких устройств, заданных в описании сессии, не понятны

304

Тип канала не доступен. Один или более типов каналов, заданных в описании сессии, не доступен.

305

Несовместимый формат канала. Один или более форматов канала, заданных в описании сессии, не доступны.

306

Атрибут непонятен. Один или более атрибутов канала, заданных в описании сессии, не понятны.

307

Параметры описания сессии не понятны.

330

Групповое соединение не доступно.

331

Одиночное соединение не доступно.

370

Недостаточная полоса пропускания.

399

Различные предупреждения

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

9.36. WWW-Authenticate

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

WWW-Authenticate

= "WWW-Authenticate" ":" l#challenge

ПРИЛОЖЕНИЕ 3

     
ОПИСАНИЕ ФОРМАТА СООБЩЕНИЙ SDP

Спецификация синтаксиса SDP приводится в расширенной форме Наура-Бекуса, соответствующей RFC-2234.

аnnouncement   =

  proto-version

origin-field

session-name-field

information-field

uri-field

email-fields

phone-fields

connection-field

bandwidth-fields

time-fields

key-field

attribute-fields

media-descriptions

proto-version  =

"v=" 1 *DIGIT CRLF

origin-field =       

"o=" username space

sess-id space sess-version space

nettype space addrtype space

addr CRLF

session-name-field =

"s=" text CRLF

information-field =

["i=" text CRLF]

uri-field =

["u=" uri CRLF]

email-fields =       

*("e=" email-address CRLF)

phone-fields =       

*("p=" phone-number CRLF)

connection-field =    

["c=" nettype space addrtype space connection-address CRLF]

; поле должно быть представлено в каждом описании сеанса или уровня сеанса

bandwidth-fields =    

*("b=" bwtype ":" bandwidth CRLF)

time-fields =        

1 *( "t=" start-time space stop-time *(CRLF repeat-fields) CRLF) [zone-adjustments CRLF]

repeat-fields =      

"r=" repeat-interval space typed-time 1 *(space typed-time)

zone-adjustments =   

time space ["-"] typed-time *(space time space ["-"] typed-time)

key-field =

["k=" key-type CRLF]

key-type =

"prompt" "clear:" key-data |"base64:" key-data "uri:" uri

key-data =

email-safe "~" "

attribute-fields =    

*("a=" attribute CRLF)

media-descriptions =

*( media-field

information-field

*(connection-field)

bandwidth-fields

key-field

attribute-fields )

media-field =        

"m=" media space port ["/" integer] space proto 1 *(space fmt) CRLF

media =

1 *(alpha-numeric)

; типично "audio", "video", "application" или "data"

fmt =

1 *(alpha-numeric)

; типично RTP нагрузка для audio и video сессии

proto =     

1 *(alpha-numeric)     

; типично "RTP/AVP" или "udp" для IР4

port=

1*(DIGIT)

; должно изменяться в пределах от "1024" до "65535" для UDP сессии

attribute =

(att-field ":" att-value) att-field

art-field =     

1 *(alpha-numeric)

att-value =

byte-string

sess-id =

1 *(DIGIT)

; должно быть уникально для данного отправителя username/host

sess-version =     

  1 *(DIGIT)

; 0 для новой сессии

connection-address =

multicast-address addr

multicast-address =

  3*(decimal-uchar ".") decimal-uchar "/" ttl [ "/" integer ]

; групповая адресация в пределах от 224.0.0.0 до 239.255.255.255

ttl =

decimal-uchar

start-time =         

time "0"

stop-time =     

time "0"

time =

POS-DIGIT 9*(DIGIT)

repeat-interval =  

typed-time

typed-time =         

1 *(DIGIT) [fixed-len-time-unit]

fixed-len-time-unit =

"d" "h" "m" "s"

bwtype =     

1 *(alpha-numeric)

bandwidth =

1*(DIGIT)

username =

safe

; довольно широкое определение, но не включает пространство

email-address =      

email email"(" email-safe ")" email-safe "<" email ">"

email =     

; определено в соответствии с RFC 822

uri=

; определено в соответствии с RFC1630

phone-number =       

phone phone "(" email-safe ")" email-safe "<" phone ">"

рhone  =     

"+" POS-DIGIT 1 *(space "-" DIGIT)

; должно иметься пространство или дефис между международным кодом и остальной частью числа

nettype =

"IN"     

; список может быть расширен

addrtype =     

"IP4" "IP6"         

; список может быть расширен

addr =     

FQDN unicast-address

FQDN =     

4*(alpha-numeric "-" ".")

; полное доменное имя определенное в соответствии с RFC1035

unicast-address =

IP4-address IP6-address

IP4-address =        

bl "." decimal-uchar "." decimal-uchar "." b4

bl =

decimal-uchar

; меньше "224"; не "0" или "127"

b4 =

decimal-uchar

; не "0"

IP6-address =         

; в стадии определения

text =

byte-string

; по умолчанию IS0-10646 UTF8

; ISO 8859-1 требует "a=charset:ISO-8859-1"

; используется атрибут session-level

byte-string =        

1 *(0х01..0x09 0x0b 0x0c 0x0e..0xff)

; любой байт, исключая NUL, CR или LF

decimal-uchar =      

DIGIT

POS-DIGIT DIGIT

 ("1"2*(DIGIT))

("2" ("0" "1" "2" "3" "4") DIGIT)

("2" "5" ("0" "1" "2" "3" "4" "5" ))

integer =     

POS-DIGIT *(DIGIT)

alpha-numeric =      

ALPHA DIGIT

DIGIT =     

"0" POS-DIGIT

POS-DIGIT =

"1" "2" "3" "4" "5" "6" "7" "8" "9"

ALPHA =

"a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k"  

"l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v"

"w" "x" "y" "z" "A" "B" "C" "D" "E" "F "G"

"H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R"

"S" "T" "U" "V" "W" "X" "Y" "Z"

email-safe =         

safe space tab

safe =

alpha-numeric "'" "'" "-" "." "/" ":" "?" """

"#" "$" "&" "*" ";" "=" "@" "["

"]" "^" "_" "`" "{" "I" "}" "+" "~"

space =     

%d32

tab =

%d9

CRLF=

%d13.10

ПРИЛОЖЕНИЕ 4

ЛИТЕРАТУРА

1. RFC 2543 "SIP: протокол инициирования сеанса", март 1999 года.

2. RFC 2068 "Протокол передачи гипертекста - НТТР/1.1", январь 1997 года.

3. RFC 2069 "Дополнение к HTTP - обзорная схема идентификации доступа", январь 1997 года.

4. RFC 2327 "SDP: протокол описания сеанса", апрель 1998 года.

5. RFC 2052 "Записи DNS для определения местоположения службы (DNS SRV)", октябрь 1996 года.

6. RFC 2205 "Протокол резервирования ресурсов (RSVP) - функциональная спецификация версии 1", октябрь 1997 года.