Количество жил, шт.

Количество проволок и диаметр, шт. и мм

Наружный диаметр провода, мм

Сечение, мм2

Масса 1 км провода, кг

Электрическое сопротивление жил, Ом/км

Сила тока нагрузки, не более, А

1

7х1,79

15

16

159,29

1,9

75

1

7х2,23

15

25

159,29

2,3

75

2

7х1,79

13

16

159,29

1,9

70

2

7х2,23

15

25

159,29

2,3

95

3

7х1,79

22

16

294,48

1,9

70

3

7х2,23

26

25

434,19

2,3

95

3

7х2,69

30

35

600,04

5,6

115

3

7х3,28

41

50

815,64

7,3

140

3

7х3,82

45

70

1122,41

10,8

180

3

19х3,00

47

120

1620,18

16,8

250

4

7х1,79

22

16

1620,18

1,9

70

4

7х2,23

26

25

1620,18

2,3

95

• — ответвлений от ВЛ;
• — ввод питания в жилые помещения;
• — хоз. постройки;
• — прокладка по стенам зданий и сооружений.

• — ответвлений от ВЛ;
• — ввод питания в жилые помещения;
• — хоз. постройки;
• — прокладка по стенам зданий и сооружений.

Сетевая рабочая группа J.Розенберг
Запрос комментариев: 3261 Dynamicsoft
Устаревшие: 2543 H. Schulzrinne
Категория: Стандарты Track Columbia U.
                                                            Г. Камарильо
                                                                Ericsson
                                                             А. Джонстон
                                                                WorldCom
                                                             Дж.Петерсон
                                                                 Neustar
                                                               Р. Спаркс
                                                             Dynamicsoft
                                                              М. Хэндли
                                                                    ICIR
                                                             Э. Школьник
                                                                    AT&T
                                                               Июнь 2002 г.

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

Статус этой памятки

   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество и просит обсуждения и предложения по
   улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
   Официальные стандарты протокола »(STD 1) для состояния стандартизации
   и статус этого протокола. Распространение памятки не ограничено.

Уведомление об авторских правах

   Авторское право (C) The Internet Society (2002). Все права защищены.

Аннотация

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

Содержание

   1 Введение ........................................ 8
   2 Обзор функций SIP ....................... 9
   3 Терминология ......................................... 10
   4 Обзор работы ............................... 10
   5 Структура протокола ........................... 18
   6 Определения ......................................... 20
   7 Сообщения SIP ........................................ 26
   7.1 Запросы ............................................ 27
   7.2 Ответы ........................................... 28
   7.3 Поля заголовка ....................................... 29
   7.3.1 Формат поля заголовка ................................. 30
   7.3.2 Классификация поля заголовка ......................... 32
   7.3.3 Компактная форма ........................................ 32
   7.4 Органы .............................................. 33
   7.4.1 Тип тела сообщения ................................... 33
   7.4.2 Длина тела сообщения ................................. 33
   7.5 Фрейминг сообщений SIP ................................ 34
   8 Общее поведение агента пользователя ......................... 34
   8.1 Поведение UAC ........................................ 35
   8.1.1 Формирование запроса.............................. 35
   8.1.1.1 Request-URI ......................................... 35
   8.1.1.2 К .............................................. .... 36
   8.1.1.3 Из .............................................. .. 37
   8.1.1.4 Call-ID ............................................ 37
   8.1.1.5 CSeq .............................................. .. 38
   8.1.1.6 Макс-вперед ........................................ 38
   8.1.1.7 Через ................................................. 39
   8.1.1.8 Контакт ............................................. 40
   8.1.1.9 Поддерживаемые и требуемые ............................... 40
   8.1.1.10 Дополнительные компоненты сообщения ....................... 41
   8.1.2 Отправка запроса ................................. 41
   8.1.3 Обработка ответов ................................ 42
   8.1.3.1 Ошибки на уровне транзакции ........................... 42
   8.1.3.2 Нераспознанные ответы.............................. 42
   8.1.3.3 Переходные отверстия .............................................. .. 43
   8.1.3.4 Обработка ответов 3xx ........................... 43
   8.1.3.5 Обработка ответов 4xx ........................... 45
   8.2 Поведение БПЛА ........................................ 46
   8.2.1 Проверка метода ................................... 46
   8.2.2 Проверка заголовка ................................... 46
   8.2.2.1 Кому и URI запроса.................................. 46
   8.2.2.2 Объединенные запросы ..................................... 47
   8.2.2.3 Требовать ............................................. 47
   8.2.3 Обработка контента .................................. 48
   8.2.4 Применение расширений ................................. 49
   8.2.5 Обработка запроса .............................. 49

   8.2.6 Формирование ответа ............................. 49
   8.2.6.1 Отправка предварительного ответа...................... 49
   8.2.6.2 Заголовки и теги .................................... 50
   8.2.7 Поведение БПЛА без сохранения состояния .............................. 50
   8.3 Серверы перенаправления .................................... 51
   9 Отмена запроса ................................. 53
   9.1 Поведение клиента ..................................... 53
   9.2 Поведение сервера ..................................... 55
   10 Регистрации ....................................... 56
   10.1 Обзор ............................................ 56
   10.2 Создание запроса REGISTER ................... 57
   10.2.1 Добавление привязок ..................................... 59
   10.2.1.1 Установка срока действия контактных адресов 60
   10.2.1.2 Предпочтения среди контактных адресов ................. 61
   10.2.2 Удаление привязок ................................... 61
   10.2.3 Получение привязок................................... 61
   10.2.4 Обновление привязок ................................. 61
   10.2.5 Настройка внутренних часов .......................... 62
   10.2.6 Обнаружение регистратора ............................. 62
   10.2.7 Передача запроса .............................. 62
   10.2.8 Действия при ошибках ..................................... 63
   10.3 Обработка запросов РЕГИСТРА ........................ 63
   11 Запрос возможностей........................... 66
   11.1 Создание запроса OPTIONS ..................... 67
   11.2 Обработка запроса OPTIONS ....................... 68
   12 Диалоги ............................................. 69
   12.1 Создание диалога ................................ 70
   12.1.1 Поведение БПЛА ........................................ 70
   12.1.2 Поведение UAC ........................................ 71
   12.2 Запросы в диалоге............................ 72
   12.2.1 Поведение UAC ........................................ 73
   12.2.1.1 Генерация запроса .............................. 73
   12.2.1.2 Обработка ответов ............................ 75
   12.2.2 Поведение БПЛА ........................................ 76
   12.3 Завершение диалога ............................. 77
   13 Начало сеанса ................................ 77
   13.1 Обзор ............................................ 77
   13.2 Обработка UAC ...................................... 78
   13.2.1 Создание начального приглашения ......................... 78
   13.2.2 Обработка ответов на INVITE ......................... 81
   13.2.2.1 Ответы 1xx ....................................... 81
   13.2.2.2 Ответы 3xx ....................................... 81
   13.2.2.3 Ответы 4xx, 5xx и 6xx .......................... 81
   13.2.2.4 Ответы 2xx....................................... 82
   13.3 Обработка БПЛА ...................................... 83
   13.3.1 Обработка INVITE ........................... 83
   13.3.1.1 Прогресс ............................................ 84
   13.3.1.2 ПРИГЛАШЕНИЕ перенаправлено ........................... 84

   13.3.1.3 ПРИГЛАШЕНИЕ отклонено .............................. 85
   13.3.1.4 ПРИГЛАШЕНИЕ принято .............................. 85
   14 Изменение существующего сеанса....................... 86
   14.1 Поведение UAC ........................................ 86
   14.2 Поведение БПЛА ........................................ 88
   15 Завершение сеанса ............................... 89
   15.1 Завершение сеанса с помощью запроса BYE ............ 90
   15.1.1 Поведение UAC ........................................ 90
   15.1.2 Поведение БПЛА ........................................ 91
   16 Поведение прокси ...................................... 91
   16.1 Обзор ............................................ 91
   16.2 Прокси-сервер с отслеживанием состояния ..................................... 92
   16.3 Запрос на подтверждение .................................. 94
   16.4 Предварительная обработка информации о маршруте ..................... 96
   16.5 Определение целей запроса ......................... 97
   16.6 Пересылка запросов .................................. 99
   16.7 Обработка ответа................................. 107
   16.8 Таймер обработки C .................................. 114
   16.9 Обработка ошибок при транспортировке ........................... 115
   16.10 Обработка CANCEL ................................... 115
   16.11 Прокси-сервер без сохранения состояния ..................................... 116
   16.12 Сводка по обработке прокси-маршрута ...
   16.12.1 Примеры ............................................ 118
   16.12.1.1 Базовая трапеция SIP................................. 118
   16.12.1.2 Обход прокси строгой маршрутизации ................... 120
   16.12.1.3 Перезапись значений поля заголовка маршрута-записи ......... 121
   17 транзакции ........................................ 122
   17.1 Клиентская транзакция .................................. 124
   17.1.1 Клиентская транзакция INVITE ........................... 125
   17.1.1.1 Обзор транзакции INVITE ..................... 125
   17.1.1.2 Формальное описание.................................. 125
   17.1.1.3 Создание запроса ACK ..................... 129
   17.1.2 Клиентская транзакция без приглашения ....................... 130
   17.1.2.1 Обзор транзакции без приглашения INVITE .............. 130
   17.1.2.2 Формальное описание .................................. 131
   17.1.3 Сопоставление ответов с клиентскими транзакциями ........... 132
   17.1.4 Обработка ошибок при транспортировке ........................... 133
   17.2 Серверная транзакция.................................. 134
   17.2.1 Серверная транзакция INVITE ........................... 134
   17.2.2 Серверная транзакция без приглашения INVITE ....................... 137
   17.2.3 Сопоставление запросов с серверными транзакциями ........... 138
   17.2.4 Обработка ошибок при транспортировке ........................... 141
   18 Транспорт ........................................... 141
   18.1 Клиенты ............................................. 142
   18.1.1 Отправка запросов.................................... 142
   18.1.2 Получение ответов ................................. 144
   18.2 Серверы ............................................. 145
   18.2.1 Получение запросов .................................. 145

   18.2.2 Отправка ответов ................................... 146
   18.3 Обрамление ............................................. 147
   18.4 Обработка ошибок ...................................... 147
   19 Общие компоненты сообщений........................... 147
   19.1 Индикаторы унифицированных ресурсов SIP и SIPS ............ 148
   19.1.1 Компоненты URI SIP и SIPS ......................... 148
   19.1.2 Требования к экранированию символов ..................... 152
   19.1.3 Примеры URI SIP и SIPS ........................... 153
   19.1.4 Сравнение URI ...................................... 153
   19.1.5 Формирование запросов из URI ......................... 156
   19.1.6 Связь SIP URI и телефонных URL...................... 157
   19.2 Теги опций ......................................... 158
   19.3 Теги ................................................ 159
   20 полей заголовков ....................................... 159
   20.1 Принять .............................................. 161
   20.2 Принятие-кодирование ..................................... 163
   20.3 Accept-Language ..................................... 164
   20.4 Информация о предупреждении .......................................... 164
   20.5 Разрешить ............................................... 165
   20.6 Информация об аутентификации ................................. 165
   20.7 Авторизация ....................................... 165
   20.8 Call-ID ............................................. 166
   20.9 Информация о вызове ........................................... 166
   20.10 Контакт ............................................. 167
   20.11 Content-Disposition................................. 168
   20.12 Кодирование содержимого .................................... 169
   20.13 Content-Language .................................... 169
   20.14 Content-Length ...................................... 169
   20.15 Content-Type ........................................ 170
   20.16 CSeq ................................................ 170
   20.17 Дата ................................................ 170
   20.18 Информация об ошибке.......................................... 171
   20.19 Истекает ............................................. 171
   20.20 С ................................................ 172
   20.21 In-Reply-To ......................................... 172
   20.22 Макс-вперед ........................................ 173
   20.23 Мин. Истекает ......................................... 173
   20.24 MIME-версия ........................................ 173
   20.25 Организация........................................ 174
   20.26 Приоритет ............................................ 174
   20.27 Проверка подлинности прокси .................................. 174
   20.28 Прокси-авторизация ................................. 175
   20.29 Требование прокси ....................................... 175
   20.30 Рекорд-Маршрут ........................................ 175
   20.31 Ответить ........................................... 176
   20.32 Требовать............................................. 176
   20.33 Retry-After ......................................... 176
   20.34 Маршрут ............................................... 177

   20.35 Сервер .............................................. 177
   20.36 Тема ............................................. 177
   20.37 Поддерживается ........................................... 178
   20.38 Отметка времени ........................................... 178
   20.39 К.................................................. 178
   20.40 Не поддерживается ......................................... 179
   20.41 User-Agent .......................................... 179
   20.42 Через ................................................ 179
   20.43 Предупреждение ............................................. 180
   20.44 WWW-аутентификация .................................... 182
   21 Коды ответа ...................................... 182
   21.1 Предварительная 1xx..................................... 182
   21.1.1 100 Попытка .......................................... 183
   21.1.2 180 Звонок ......................................... 183
   21.1.3 181 Переадресация вызова ......................... 183
   21.1.4 182 В очереди .......................................... 183
   21.1.5 183 Ход сеанса ................................ 183
   21.2 Успешно 2xx ...................................... 183
   21.2.1 200 ОК.............................................. 183
   21.3 Перенаправление 3xx ..................................... 184
   21.3.1 300 вариантов выбора ................................ 184
   21.3.2 301 перемещен навсегда ............................... 184
   21.3.3 302 перемещен временно ............................... 184
   21.3.4 305 Использовать прокси ....................................... 185
   21.3.5 380 Альтернативная служба ............................. 185
   21.4 Ошибка запроса 4xx................................. 185
   21.4.1 400 неверный запрос ..................................... 185
   21.4.2 401 Неавторизованный .................................... 185
   21.4.3 402 Требуется платеж ................................ 186
   21.4.4 403 Запрещено ....................................... 186
   21.4.5 404 не найдено ....................................... 186
   21.4.6 405 Метод запрещен .............................. 186
   21.4.7 406 Неприемлемо.................................. 186
   21.4.8 407 Требуется аутентификация прокси ................... 186
   21.4.9 408 Тайм-аут запроса ................................. 186
   21.4.10 410 Gone ............................................ 187
   21.4.11 413 Слишком большой объект запроса ........................ 187
   21.4.12 414 Request-URI Too Long ............................ 187
   21.4.13 415 Неподдерживаемый тип носителя .......................... 187
   21.4.14 416 Неподдерживаемая схема URI.......................... 187
   21.4.15 420 Bad Extension ................................... 187
   21.4.16 Требуется расширение 421 .............................. 188
   21.4.17 423 Интервал слишком короткий .............................. 188
   21.4.18 480 Временно недоступен ......................... 188
   21.4.19 481 Вызов / транзакция не существует ................. 188
   21.4.20 Обнаружено 482 петли ................................... 188
   21.4.21 483 Too Many Hops................................... 189
   21.4.22 484 Адрес неполный .............................. 189

   21.4.23 485 Неоднозначно ....................................... 189
   21.4.24 486 Здесь занято ....................................... 189
   21.4.25 487 Запрос прекращен .............................. 190
   21.4.26 488 Здесь неприемлемо ............................. 190
   21.4.27 491 Запрос на рассмотрении ................................. 190
   21.4.28 493 Невозможно расшифровать.................................. 190
   21.5 Отказ сервера 5xx .................................. 190
   21.5.1 500 Внутренняя ошибка сервера ........................... 190
   21.5.2 501 Не реализовано ................................. 191
   21.5.3 502 Плохой шлюз ..................................... 191
   21.5.4 503 Служба недоступна ............................. 191
   21.5.5 504 Тайм-аут сервера ................................. 191
   21.5.6 Версия 505 не поддерживается........................... 192
   21.5.7 513 Сообщение слишком велико ............................... 192
   21.6 Глобальные отказы 6xx ................................. 192
   21.6.1 600 Везде занято ................................. 192
   21.6.2 603 Отклонение ......................................... 192
   21.6.3 604 Нигде не существует ......................... 192
   21.6.4 606 Неприемлемо .................................. 192
   22 Использование HTTP-аутентификации........................ 193
   22.1 Платформа ........................................... 193
   22.2 Аутентификация между пользователем ......................... 195
   22.3 Проверка подлинности прокси-сервера ........................ 197
   22.4 Схема дайджест-аутентификации .................... 199
   23 S / MIME .............................................. 201
   23.1 Сертификаты S / MIME ................................. 201
   23.2 Обмен ключами S / MIME................................. 202
   23.3 Защита тел MIME ................................ 205
   23.4 Конфиденциальность и целостность заголовка SIP с использованием S / MIME:
              Туннельный SIP ....................................... 207
   23.4.1 Свойства целостности и конфиденциальности SIP
              Заголовки ............................................. 207
   23.4.1.1 Целостность ........................................... 207
   23.4.1.2 Конфиденциальность ..................................... 208
   23.4.2 Целостность туннелирования и аутентификация .............. 209
   23.4.3 Туннельное шифрование ................................ 211
   24 Примеры ............................................ 213
   24.1 Регистрация ........................................ 213
   24.2 Настройка сеанса ....................................... 214
   25 Расширенный BNF для протокола SIP .................. 219
   25.1 Основные правила ......................................... 219
   26 соображения безопасности: модель угроз и безопасность
              Рекомендации по использованию ............................... 232
   26.1 Атаки и модели угроз ........................... 233
   26.1.1 Взлом регистрации .............................. 233
   26.1.2 Выдача себя за сервер .............................. 234
   26.1.3 Подделка тел сообщений ....................... 235
   26.1.4 Завершение сеансов............................... 235

   26.1.5 Отказ в обслуживании и усиление ................. 236
   26.2 Механизмы безопасности ................................. 237
   26.2.1 Безопасность транспортного и сетевого уровней ................ 238
   26.2.2 Схема URI SIPS ..................................... 239
   26.2.3 HTTP-аутентификация ................................. 240
   26.2.4 S / MIME ............................................ .. 240
   26.3 Реализация механизмов безопасности.................... 241
   26.3.1 Требования к разработчикам SIP ................ 241
   26.3.2 Решения безопасности .................................. 242
   26.3.2.1 Регистрация ........................................ 242
   26.3.2.2 Междоменные запросы ................................ 243
   26.3.2.3 Одноранговые запросы ............................... 245
   26.3.2.4 Защита от DoS-атак ...................................... 246
   26.4 Ограничения ......................................... 247
   26.4.1 Дайджест HTTP ......................................... 247
   26.4.2 S / MIME ............................................ .. 248
   26.4.3 TLS .............................................. ... 249
   26.4.4 SIPS URI ........................................... 249
   26.5 Конфиденциальность ............................................. 251
   27 Вопросы IANA ................................. 252
   27.1 Теги параметров ......................................... 252
   27.2 Коды предупреждений .......................................... 252
   27.3 Имена полей заголовка .................................. 253
   27.4 Коды метода и ответа ........................... 253
   27.5 Тип MIME "сообщение / sip". ....................... 254
   27.6 Новые регистрации параметров Content-Disposition ... 255
   28 Изменения по сравнению с RFC 2543 ............................... 255
   28.1 Основные функциональные изменения............................ 255
   28.2 Незначительные функциональные изменения ............................ 260
   29 Нормативные ссылки ................................ 261
   30 Информативные ссылки .............................. 262
   Таблица значений таймера ............................... 265
   Благодарности ................................................ 266
   Адреса авторов ............................................. 267
   Полное заявление об авторских правах ....................................... 269

1. Введение

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

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

2 Обзор функциональности SIP

   SIP - это протокол управления на уровне приложений, который может устанавливать,
   изменять и завершать мультимедийные сеансы (конференции), например
   Звонки по интернет-телефонии. SIP также может приглашать участников на
   уже существующие сеансы, например, многоадресные конференции.СМИ могут
   быть добавленным в существующий сеанс (и удаленным из него). ГЛОТОК
   прозрачно поддерживает службы сопоставления имен и перенаправления, которые
   поддерживает личную мобильность [27] - пользователи могут поддерживать единую
   внешне видимый идентификатор независимо от их расположения в сети.

   SIP поддерживает пять аспектов установления и завершения мультимедиа.
   коммуникации:

      Местоположение пользователя: определение конечной системы, которая будет использоваться для
           общение;

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

      Возможности пользователя: определение медиа и медиа параметров
           быть использованным;

      Настройка сеанса: «звонок», установка параметров сеанса на
           как вызываемый, так и вызывающий абонент;

      Управление сеансом: включая передачу и завершение
           сеансы, изменение параметров сеанса и вызов
           Сервисы.SIP - это не вертикально интегрированная система связи. SIP - это
   скорее компонент, который можно использовать с другими протоколами IETF для
   построить полную мультимедийную архитектуру. Обычно эти
   архитектуры будут включать такие протоколы, как Транспорт в реальном времени
   Протокол (RTP) (RFC 1889 [28]) для передачи данных в реальном времени и
   обеспечение обратной связи QoS, протокол потоковой передачи в реальном времени (RTSP) (RFC)
   2326 [29]) для управления доставкой потокового мультимедиа, Медиа

   Протокол управления шлюзом (MEGACO) (RFC 3015 [30]) для управления
   шлюзы к коммутируемой телефонной сети общего пользования (PSTN) и
   Протокол описания сеанса (SDP) (RFC 2327 [1]) для описания
   мультимедийные сеансы.Следовательно, SIP следует использовать вместе
   с другими протоколами для предоставления полных услуг
   пользователей. Однако базовая функциональность и работа SIP делает
   не зависят ни от одного из этих протоколов.

   SIP не предоставляет услуги. Скорее, SIP предоставляет примитивы, которые
   можно использовать для реализации различных сервисов. Например, SIP может
   найти пользователя и доставить непрозрачный объект в его текущее местоположение.
   Если этот примитив используется для доставки описания сеанса, написанного на
   SDP, например, конечные точки могут согласовывать параметры
   сеанс.Если тот же примитив используется для доставки фотографии
   вызывающего абонента, а также описание сеанса, служба «АОН» может
   быть легко реализованным. Как показывает этот пример, единственный примитив - это
   обычно используется для предоставления нескольких различных услуг.

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

   SIP работает как с IPv4, так и с IPv6.

3 Терминология

   В этом документе ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ
   РЕКОМЕНДУЕТСЯ »,« МОЖЕТ »и« ДОПОЛНИТЕЛЬНО »следует интерпретировать как
   описаны в BCP 14, RFC 2119 [2] и указывают уровни требований для
   совместимые реализации SIP.4 Обзор работы

   В этом разделе представлены основные операции SIP с использованием простых
   Примеры. Этот раздел носит учебный характер и не содержит
   любые нормативные положения.

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

   На рисунке 1 показан типичный пример обмена сообщениями SIP между
   два пользователя, Алиса и Боб.(Каждое сообщение помечено буквой
   "F" и число для ссылки в тексте.) В этом примере Алиса
   использует приложение SIP на своем ПК (называемое программным телефоном) для звонков
   Боб на своем SIP-телефоне через Интернет. Также показаны два SIP-прокси.
   серверы, которые действуют от имени Алисы и Боба для облегчения сеанса
   учреждение. Это типичное расположение часто называют
   «Трапеция SIP», как показано геометрической формой пунктирных линий
   на рисунке 1.

   Алиса «звонит» Бобу, используя его SIP-идентификатор, тип универсального ресурса.
   Идентификатор (URI) называется SIP URI.SIP URI определены в разделе
   19.1. Он имеет форму, аналогичную адресу электронной почты, обычно
   содержащий имя пользователя и имя хоста. В данном случае это
   sip: [email protected], где biloxi.com - это домен SIP Боба
   поставщик услуг. У Алисы есть SIP-URI sip: [email protected]
   Алиса могла ввести URI Боба или, возможно, щелкнуть гиперссылку
   или запись в адресной книге. SIP также предоставляет безопасный URI,
   называется SIPS URI. Например, sips: [email protected] Вызов
   в SIPS URI гарантирует, что безопасный, зашифрованный транспорт
   (а именно TLS) используется для передачи всех сообщений SIP от вызывающего абонента к
   домен вызываемого.Оттуда запрос безопасно отправляется на
   вызываемого, но с механизмами безопасности, которые зависят от политики
   домен вызываемого.

   SIP основан на HTTP-подобной модели транзакции запроса / ответа.
   Каждая транзакция состоит из запроса, который вызывает конкретный
   метод или функцию на сервере и хотя бы один ответ. В
   В этом примере транзакция начинается с отправки программного телефона Алисы
   запрос INVITE, адресованный на SIP URI Боба. INVITE - это пример
   метода SIP, определяющего действие, которое запрашивающая сторона (Алиса)
   хочет, чтобы сервер (Боб) взял.Запрос INVITE содержит номер
   полей заголовка. Поля заголовка - это именованные атрибуты, которые обеспечивают
   дополнительная информация о сообщении. Те, кто присутствует в
   ПРИГЛАСИТЬ: укажите уникальный идентификатор звонка, адресата
   адрес, адрес Алисы и информация о типе сеанса
   что Алиса хочет установить с Бобом. ПРИГЛАШЕНИЕ (сообщение F1 в
   Рисунок 1) может выглядеть так:

                     atlanta.com. . . biloxi.com
                 . прокси-сервер.. .
       Алисы. . . . . . . . . . . . . . . . . . . . Боба
      программный телефон SIP телефон
         | | | |
         | ПРИГЛАСИТЬ F1 | | |
         | ---------------> | ПРИГЛАСИТЬ F2 | |
         | 100 Попытка F3 | ---------------> | ПРИГЛАСИТЬ F4 |
         | <--------------- | 100 Попытка F5 | ---------------> |
         | | <-------------- | 180 Звонок F6 |
         | | 180 Звонок F7 | <--------------- |
         | 180 Звонок F8 | <--------------- | 200 ОК F9 |
         | <--------------- | 200 ОК F10 | <--------------- |
         | 200 OK F11 | <--------------- | |
         | <--------------- | | |
         | ACK F12 |
         | ------------------------------------------------- > |
         | Медиа-сессия |
         | <================================================ > |
         | BYE F13 ​​|
         | <------------------------------------------------ - |
         | 200 ОК F14 |
         | ------------------------------------------------- > |
         | |

         Рисунок 1: Пример настройки сеанса SIP с трапецией SIP

      ПРИГЛАСИТЬ глоток: bob @ biloxi.com SIP / 2.0
      Через: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4bK776asdhds
      Максимальное количество нападающих: 70
      Кому: Боб 
      От: Алиса ; tag = 1928301774
      Call-ID: [email protected]
      CSeq: 314159 ПРИГЛАСИТЬ
      Контакты: 
      Тип содержимого: application / sdp
      Длина содержимого: 142

      (SDP Алисы не показан)

   Первая строка текстового сообщения содержит имя метода.
   (ПРИГЛАШАТЬ).Следующие строки представляют собой список полей заголовка. Этот
   пример содержит минимально необходимый набор. Поля заголовка
   кратко описано ниже:

   Via содержит адрес (pc33.atlanta.com), по которому находится Алиса.
   ожидая получить ответы на этот запрос. Он также содержит
   параметр ветви, идентифицирующий эту транзакцию.

   Кому содержит отображаемое имя (Bob) и SIP или SIPS URI.
   (sip: [email protected]) к которому изначально был отправлен запрос
   направлен. Отображаемые имена описаны в RFC 2822 [3].From также содержит отображаемое имя (Алиса) и SIP или SIPS URI.
   (sip: [email protected]), указывающие на отправителя запроса.
   Это поле заголовка также имеет параметр тега, содержащий случайную строку
   (1928301774), который был добавлен к URI программным телефоном. Это использовано
   в целях идентификации.

   Call-ID содержит глобальный уникальный идентификатор для этого вызова,
   генерируется комбинацией случайной строки и программного телефона
   имя хоста или IP-адрес. Комбинация тегов To, From,
   и Call-ID полностью определяет одноранговые отношения SIP
   между Алисой и Бобом и называется диалогом.CSeq или Command Sequence содержит целое число и имя метода. В
   Номер CSeq увеличивается для каждого нового запроса в диалоговом окне и
   - традиционный порядковый номер.

   Контакт содержит SIP или SIPS URI, который представляет прямой путь к
   связаться с Алисой, обычно состоящий из имени пользователя с полным
   доменное имя (FQDN). Хотя полное доменное имя является предпочтительным, многие конечные системы делают
   не имеют зарегистрированных доменных имен, поэтому IP-адреса разрешены.
   В то время как поле заголовка Via сообщает другим элементам, куда отправлять
   ответ, поле заголовка контакта сообщает другим элементам, куда отправлять
   будущие запросы.Max-Forwards служит для ограничения количества переходов, которые может выполнить запрос.
   путь к месту назначения. Он состоит из целого числа, равного
   уменьшается на единицу на каждом шаге.

   Content-Type содержит описание тела сообщения (не показано).

   Content-Length содержит количество октетов (байтов) тела сообщения.

   Полный набор полей заголовка SIP определен в Разделе 20.

   Детали сеанса, такие как тип носителя, кодек или
   частота дискретизации, не описываются с использованием SIP.Скорее, тело
   SIP-сообщение содержит описание сеанса, закодированное в некоторых
   другой формат протокола. Одним из таких форматов является описание сеанса.
   Протокол (SDP) (RFC 2327 [1]). Это сообщение SDP (не показано в

   пример) передается в сообщении SIP аналогично
   вложение документа, передаваемое в сообщении электронной почты или в Интернете
   страница переносится в сообщении HTTP.

   Поскольку программный телефон не знает местонахождение Боба или SIP
   сервер в билокси.com домен, программный телефон отправляет ПРИГЛАШЕНИЕ на
   SIP-сервер, обслуживающий домен Алисы, atlanta.com. Адрес
   SIP-сервера atlanta.com можно было настроить в
   софтфон, или, например, он мог быть обнаружен DHCP.

   SIP-сервер atlanta.com - это тип SIP-сервера, известный как прокси.
   сервер. Прокси-сервер получает SIP-запросы и пересылает их на
   от имени отправителя запроса. В этом примере прокси-сервер получает
   запрос INVITE и отправляет ответ 100 (пытается) обратно в
   софтфон.Ответ 100 (Попытка) означает, что ПРИГЛАШЕНИЕ
   был получен, и что прокси работает от ее имени для маршрутизации
   ПРИГЛАШЕНИЕ в пункт назначения. В ответах SIP используется трехзначный
   код, за которым следует описательная фраза. Этот ответ содержит
   тот же To, From, Call-ID, CSeq и параметр ветвления в Via как
   ПРИГЛАСИТЬ, который позволяет программному телефону Алисы соотносить этот ответ с
   отправленное ПРИГЛАШЕНИЕ. Прокси-сервер atlanta.com находит прокси
   сервер на biloxi.com, возможно, путем выполнения определенного типа DNS
   (Служба доменных имен), чтобы найти SIP-сервер, который обслуживает
   билокси.com домен. Это описано в [4]. В результате это
   получает IP-адрес прокси-сервера biloxi.com и пересылает,
   или прокси, запрос INVITE там. Перед отправкой запроса,
   прокси-сервер atlanta.com добавляет дополнительное поле заголовка Via
   значение, которое содержит собственный адрес (ПРИГЛАШЕНИЕ уже содержит
   Адрес Алисы на первой Виа). Прокси-сервер biloxi.com
   получает ПРИГЛАШЕНИЕ и отвечает 100 (пытается) ответом на
   прокси-сервер atlanta.com, чтобы указать, что он получил
   ПРИГЛАСИТЬ и обрабатывает запрос.Прокси-сервер обращается к
   база данных, обычно называемая службой определения местоположения, которая содержит
   текущий IP-адрес Боба. (В следующем разделе мы увидим, как
   эта база данных может быть заполнена.) Прокси-сервер biloxi.com добавляет
   другое значение поля заголовка Via с собственным адресом для сообщения INVITE и
   проксирует его на SIP-телефон Боба.

   SIP-телефон Боба получает ПРИГЛАШЕНИЕ и предупреждает Боба о входящем
   звонок от Алисы, чтобы Боб мог решить, отвечать ли на звонок,
   то есть звонит телефон Боба.SIP-телефон Боба показывает это в 180
   (Ringing) ответ, который направляется обратно через два прокси в
   обратное направление. Каждый прокси использует поле заголовка Via для
   определить, куда отправить ответ и удаляет собственный адрес из
   вершина. В результате, хотя поиски DNS и службы определения местоположения
   требуется для маршрутизации начального ПРИГЛАШЕНИЯ, ответ 180 (звонок) может
   возвращаться вызывающей стороне без поиска или без состояния

   поддерживается в прокси. Это также имеет желаемое свойство:
   каждый прокси, который видит ПРИГЛАШЕНИЕ, также увидит все ответы на
   ПРИГЛАСИТЬ.Когда программный телефон Алисы получает ответ 180 (звонок), он проходит
   эту информацию Алисе, возможно, используя звуковой сигнал обратного вызова или
   отображение сообщения на экране Алисы.

   В этом примере Боб решает ответить на звонок. Когда он поднимает
   телефон, его SIP-телефон отправляет ответ 200 (OK), чтобы указать, что
   на звонок ответили. 200 (OK) содержит тело сообщения
   с медиа-описанием SDP типа сеанса, в котором Боб
   готов установить с Алисой.В результате получается двухфазный
   обмен сообщениями SDP: Алиса отправила одно Бобу, а Боб отправил одно
   обратно к Алисе. Этот двухфазный обмен обеспечивает базовое согласование
   возможностей и основан на простой модели предложения / ответа SDP
   обмен. Если Боб не хотел отвечать на звонок или был занят
   другой вызов, вместо
   200 (ОК), что привело бы к тому, что сеанс мультимедиа не
   установлено. Полный список кодов ответов SIP находится в разделе
   21.200 (OK) (сообщение F9 на рисунке 1) может выглядеть следующим образом:
   Боб отправляет его:

      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP server10.biloxi.com
         ; branch = z9hG4bKnashds8; получено = 192.0.2.3
      Через: SIP / 2.0 / UDP bigbox3.site3.atlanta.com
         ; branch = z9hG4bK77ef4c2312983.1; получено = 192.0.2.2
      Через: SIP / 2.0 / UDP pc33.atlanta.com
         ; branch = z9hG4bK776asdhds; получено = 192.0.2.1
      Кому: Боб ; tag = a6c85cf
      От: Алиса ; tag = 1928301774
      Идентификатор звонка: a84b4c76e66710 @ pc33.atlanta.com
      CSeq: 314159 ПРИГЛАСИТЬ
      Контакты: 
      Тип содержимого: application / sdp
      Длина содержимого: 131

      (SDP Боба не показан)

   Первая строка ответа содержит код ответа (200) и
   фраза причины (ОК). Остальные строки содержат поля заголовка.
   Поля заголовка Via, To, From, Call-ID и CSeq копируются из
   запрос INVITE. (Имеется три значения поля заголовка Via - одно
   добавлен SIP-телефоном Алисы, еще один добавлен atlanta.com прокси и
   один добавлен прокси biloxi.com.) SIP-телефон Боба добавил тег
   в поле заголовка Кому. Этот тег будет включен
   обе конечные точки в диалоговом окне и будут включены во все будущие

   запросы и ответы в этом звонке. Поле заголовка контакта
   содержит URI, по которому с Бобом можно напрямую связаться по его SIP-телефону.
   Content-Type и Content-Length относятся к телу сообщения (не
   показано), который содержит медиа-информацию SDP Боба.

   В дополнение к поисковым запросам DNS и службы определения местоположения, показанным в этом
   Например, прокси-серверы могут принимать гибкие «решения по маршрутизации» для
   решить, куда отправить запрос.Например, если SIP-телефон Боба
   вернул ответ 486 (здесь занято), прокси-сервер biloxi.com
   может проксировать ПРИГЛАШЕНИЕ на сервер голосовой почты Боба. Прокси-сервер может
   также отправьте ПРИГЛАШЕНИЕ в несколько мест одновременно. Этот
   Тип параллельного поиска известен как разветвление.

   В этом случае 200 (OK) маршрутизируется обратно через два прокси и
   принимается программным телефоном Алисы, который затем останавливает сигнал обратного вызова
   и указывает, что на звонок ответили. Наконец, Алиса
   программный телефон отправляет сообщение подтверждения, ACK, на SIP-телефон Боба
   для подтверждения получения окончательного ответа (200 (OK)).В этом
   Например, ACK отправляется прямо с программного телефона Алисы на SIP Боба.
   телефон, минуя два прокси. Это происходит потому, что конечные точки
   узнали адреса друг друга из полей заголовка контакта
   через обмен INVITE / 200 (OK), который не был известен, когда
   было отправлено первоначальное ПРИГЛАШЕНИЕ. Поиск, выполняемый двумя прокси
   больше не нужны, поэтому прокси выпадают из потока вызовов. Этот
   завершает трехстороннее рукопожатие INVITE / 200 / ACK, используемое для установления
   SIP-сессии.Полная информация о настройке сеанса находится в Разделе 13.

   Медиа-сессия Алисы и Боба уже началась, и они отправляют медиа
   пакеты, использующие формат, на который они согласились при обмене SDP.
   Как правило, сквозные медиапакеты идут по другому пути, чем
   сигнальные сообщения SIP.

   Во время сеанса Алиса или Боб могут решить изменить
   характеристики медиа-сеанса. Это достигается
   отправка повторного ПРИГЛАШЕНИЯ, содержащего новое описание мультимедиа. Это повторное
   INVITE ссылается на существующий диалог, чтобы другая сторона знала
   что это изменить существующий сеанс вместо того, чтобы устанавливать
   новая сессия.Другой абонент отправляет 200 (ОК), чтобы принять изменение.
   Запрашивающая сторона отвечает на 200 (ОК) ACK. Если другой
   сторона не принимает изменение, он отправляет ответ об ошибке, например
   488 (здесь неприемлемо), который также получает ACK. Тем не менее
   сбой re-INVITE не приводит к сбою существующего вызова -
   сеанс продолжается с использованием ранее согласованных
   характеристики. Полная информация о модификации сеанса находится в разделе
   14.

   По окончании разговора Боб сначала отключается (вешает трубку) и
   генерирует сообщение BYE.Это BYE направляется непосредственно к Алисе.
   софтфон, опять же в обход прокси. Алиса подтверждает получение
   BYE с ответом 200 (OK), который завершает сеанс и
   транзакция BYE. ACK не отправляется - ACK отправляется только в
   ответ на ответ на запрос INVITE. Причины этого
   специальная обработка для INVITE будет обсуждаться позже, но относится к
   механизмы надежности в SIP, время, которое может занять
   звонящий телефон, на который нужно ответить, и разветвление.Именно по этой причине,
   обработка запросов в SIP часто классифицируется как INVITE или не
   ПРИГЛАСИТЬ, имея в виду все другие методы, кроме ПРИГЛАШЕНИЯ. Полная информация
   о завершении сеанса - в Разделе 15.

   В разделе 24.2 полностью описаны сообщения, показанные на рисунке 1.

   В некоторых случаях это может быть полезно для прокси в сигнальном тракте SIP.
   чтобы увидеть весь обмен сообщениями между конечными точками в течение
   сессия. Например, если прокси-сервер biloxi.com хотел
   остаются в пути обмена сообщениями SIP за пределами первоначального ПРИГЛАШЕНИЯ, он
   добавьте в ПРИГЛАШЕНИЕ обязательное поле заголовка маршрутизации, известное как Запись-
   Маршрут, содержащий URI, разрешающий имя хоста или IP-адрес
   прокси.Эта информация будет получена как SIP Боба,
   телефон и (из-за того, что поле заголовка Record-Route передается обратно в
   программный телефон Алисы 200 (OK)) и сохраняется в течение всего
   диалог. Затем прокси-сервер biloxi.com получит и прокси-сервер
   ACK, BYE и 200 (OK) до BYE. Каждый прокси может независимо
   решают получать последующие сообщения, и эти сообщения пройдут
   через всех доверенных лиц, которые решили его получить. Эта возможность
   часто используется для прокси, которые предоставляют функции во время разговора.Регистрация - еще одна распространенная операция в SIP. Регистрация одна
   способ, которым сервер biloxi.com может узнать текущее местоположение Боба.
   При инициализации и через определенные промежутки времени SIP-телефон Боба отправляет
   РЕГИСТРАЦИЯ сообщений на сервер в домене biloxi.com, известный как SIP
   регистратор. Сообщения REGISTER связывают SIP или SIPS URI Боба.
   (sip: [email protected]) с машиной, в которой он сейчас
   регистрируется (передается как SIP или SIPS URI в поле заголовка контакта).Регистратор записывает эту ассоциацию, также называемую привязкой, в
   база данных, называемая службой определения местоположения, где она может использоваться
   прокси в домене biloxi.com. Часто сервер-регистратор для
   домен совпадает с прокси для этого домена. Это
   Важная концепция, что различие между типами SIP серверов
   логично, а не физически.

   Боб не ограничивается регистрацией с одного устройства. Например,
   и его SIP-телефон дома, и телефон в офисе могли отправлять
   регистрации.Эта информация хранится вместе в местоположении

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

   Служба определения местоположения - это просто абстрактное понятие. Это вообще
   содержит информацию, которая позволяет прокси-серверу вводить URI и получать
   набор из нуля или более URI, которые сообщают прокси, куда отправлять
   запрос. Регистрация - это один из способов создания этой информации, но
   не единственный способ.Функции произвольного отображения можно настроить на
   на усмотрение администратора.

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

   Полный набор сведений о SIP-сообщении для этого примера регистрации
   находится в разделе 24.1.

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

5 Структура протокола

   SIP структурирован как многоуровневый протокол, что означает, что его
   поведение описывается с помощью набора достаточно независимых
   этапы обработки со слабой связью между каждым этапом. В
   поведение протокола описывается как уровни с целью
   презентация, позволяющая описать функции, общие для
   элементы в одном разделе.Это не требует реализации
   в любом случае. Когда мы говорим, что элемент «содержит» слой, мы имеем в виду
   он соответствует набору правил, определенных этим уровнем.

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

   Самый низкий уровень SIP - это его синтаксис и кодировка.Его кодировка
   задается с использованием расширенной грамматики Бэкуса-Наура (BNF). В
   полный BNF указан в разделе 25; обзор SIP
   структуру сообщения можно найти в разделе 7.

   Второй уровень - это транспортный уровень. Он определяет, как клиент
   отправляет запросы и получает ответы и как сервер получает
   запрашивает и отправляет ответы по сети. Все элементы SIP
   содержат транспортный уровень. Транспортный уровень описан в
   Раздел 18.

   Третий уровень - это уровень транзакций.Сделки - это
   фундаментальная составляющая SIP. Транзакция - это запрос, отправленный
   клиентская транзакция (с использованием транспортного уровня) на сервер
   транзакции, а также все ответы на этот запрос, отправленные из
   серверная транзакция возвращается клиенту. Уровень транзакции обрабатывает
   повторные передачи на уровне приложений, сопоставление ответов на запросы,
   и таймауты на уровне приложения. Любая задача, которую клиент пользовательского агента
   (UAC) выполняется с помощью серии транзакций.Обсуждение транзакций можно найти в разделе 17. Пользовательские агенты.
   содержат уровень транзакций, как и прокси с отслеживанием состояния. Без гражданства
   прокси не содержат уровня транзакций. Уровень транзакции
   имеет клиентский компонент (называемый клиентской транзакцией) и
   серверный компонент (называемый серверной транзакцией), каждый из которых
   представлены конечным автоматом, который построен для
   обрабатывать конкретный запрос.

   Слой выше уровня транзакции называется пользователем транзакции.
   (ВТ).Каждый из SIP-объектов, кроме прокси без сохранения состояния, является
   пользователь транзакции. Когда TU хочет отправить запрос, он создает
   экземпляр клиентской транзакции и передает ему запрос вместе с
   IP-адрес назначения, порт и транспорт, на который нужно отправить
   запрос. ЕП, который создает клиентскую транзакцию, также может ее отменить.
   Когда клиент отменяет транзакцию, он запрашивает остановку сервера.
   дальнейшей обработки, вернуться к состоянию, которое существовало до
   транзакция была инициирована, и сгенерировать конкретный ответ об ошибке на
   та сделка.Это делается с помощью запроса CANCEL, который
   представляет собой собственную транзакцию, но ссылается на транзакцию как
   отменен (Раздел 9).

   Элементы SIP, то есть клиенты и серверы пользовательских агентов, без сохранения состояния
   прокси-серверы и регистраторы с отслеживанием состояния содержат ядро, которое
   отличает их друг от друга. Ядра, кроме безгражданства
   прокси, являются пользователями транзакций. Пока поведение UAC и UAS
   ядер зависит от метода, есть общие правила для всех
   методы (раздел 8).Для UAC эти правила регулируют построение
   запроса; для UAS они регулируют обработку запроса и
   создание ответа. Поскольку регистрации играют важную роль в
   SIP, UAS, который обрабатывает РЕГИСТР, получает специальное имя
   регистратор. Раздел 10 описывает поведение ядра UAC и UAS для
   РЕГИСТРАЦИЯ метод. Раздел 11 описывает поведение ядра UAC и UAS для
   метод OPTIONS, используемый для определения возможностей UA.

   Некоторые другие запросы отправляются в диалоговом окне.Диалог - это
   одноранговая связь SIP между двумя пользовательскими агентами, которая сохраняется
   на некоторое время. Диалог облегчает последовательность сообщений и
   правильная маршрутизация запросов между пользовательскими агентами. ПРИГЛАШЕНИЕ
   метод - единственный способ, определенный в этой спецификации, чтобы установить
   диалог. Когда UAC отправляет запрос, который находится в контексте
   диалог, он следует общим правилам UAC, как описано в Разделе 8, но
   также правила для запросов в середине диалога. В разделе 12 обсуждаются диалоги.
   и представлены процедуры их строительства и обслуживания,
   в дополнение к построению запросов в диалоге.Самый важный метод в SIP - это метод INVITE, который используется
   чтобы установить сеанс между участниками. Сессия - это
   сбор участников и потоков мультимедиа между ними, для
   цели общения. В разделе 13 обсуждается, как проходят занятия.
   инициируется, что приводит к появлению одного или нескольких диалогов SIP. Раздел 14.
   обсуждает, как характеристики этого сеанса изменяются посредством
   использование запроса INVITE в диалоговом окне. Наконец, раздел 15
   обсуждает, как завершается сеанс.Процедуры Разделов 8, 10, 11, 12, 13, 14 и 15 касаются
   полностью с ядром UA (Раздел 9 описывает отмену, которая
   применяется как к ядру UA, так и к ядру прокси). В разделе 16 обсуждается
   прокси-элемент, который упрощает маршрутизацию сообщений между пользователями
   агенты.

6 Определения

   Следующие термины имеют особое значение для SIP.

      Адрес записи: адрес записи (AOR) - это SIP или SIPS URI.
         который указывает на домен со службой определения местоположения, которая может отображать
         URI другого URI, где пользователь может быть доступен.Обычно служба определения местоположения заполняется через
         регистрации. AOR часто называют "общественным
         адрес »пользователя.

      Пользовательский агент с обратной связью: Пользовательский агент с обратной связью (B2BUA) является
         логический объект, который получает запрос и обрабатывает его как
         сервер пользовательского агента (UAS). Чтобы определить, как запрос
         нужно ответить, он действует как клиент пользовательского агента (UAC) и
         генерирует запросы. В отличие от прокси-сервера, он поддерживает диалог
         состояние и должен участвовать во всех запросах, отправленных в диалогах
         он установил.Поскольку это объединение UAC и
         UAS, никаких явных определений для его поведения не требуется.

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

      Call Leg: другое имя для диалога [31]; больше не используется в этом
         Технические характеристики.

      Состояние вызова: прокси-сервер имеет состояние вызова, если он сохраняет состояние для
         диалог от инициирующего ПРИГЛАШЕНИЯ к завершающемуся BYE
         запрос.Прокси-сервер с отслеживанием состояния вызова всегда имеет состояние транзакции,
         но обратное не всегда верно.

      Клиент: клиент - это любой сетевой элемент, который отправляет SIP-запросы.
         и получает ответы SIP. Клиенты могут или не могут взаимодействовать
         напрямую с человеком-пользователем. Клиенты и прокси-серверы пользовательских агентов
         клиентов.

      Конференция: мультимедийный сеанс (см. Ниже), содержащий
         несколько участников.

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

      Диалог: диалог - это одноранговые SIP-отношения между двумя
         UA, который сохраняется в течение некоторого времени. Диалог устанавливается
         Сообщения SIP, например ответ 2xx на запрос INVITE. А
         диалог идентифицируется идентификатором вызова, локальным тегом и
         удаленный тег. Диалог раньше назывался ветвью вызова в RFC.
         2543.Downstream: направление пересылки сообщений внутри транзакции.
         это относится к направлению, в котором поток запросов от пользователя
         клиент агента на сервер агента пользователя.

      Окончательный ответ: ответ, который завершает транзакцию SIP, как
         против предварительного ответа, которого нет. Все 2xx, 3xx,
         Ответы 4xx, 5xx и 6xx являются окончательными.

      Заголовок: заголовок - это компонент сообщения SIP, который передает
         информация о сообщении. Он структурирован как последовательность
         полей заголовка.Поле заголовка: поле заголовка является компонентом сообщения SIP.
         заголовок. Поле заголовка может отображаться как одно или несколько полей заголовка.
         ряды. Строки поля заголовка состоят из имени поля заголовка и нуля
         или несколько значений поля заголовка. Несколько значений поля заголовка в

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

      Значение поля заголовка: значение поля заголовка - это одно значение; а
         поле заголовка состоит из нуля или более значений поля заголовка.Домашний домен: домен, предоставляющий услуги пользователю SIP.
         Обычно это домен, присутствующий в URI в
         адрес записи регистрации.

      Информационный ответ: То же, что и предварительный ответ.

      Инициатор, вызывающий абонент, вызывающий абонент: сторона, инициирующая сеанс
         (и диалог) с запросом INVITE. Вызывающий сохраняет это
         роль с момента отправки начального ПРИГЛАШЕНИЯ, установленного
         диалоговое окно до его завершения.Приглашение: запрос INVITE.

      Приглашенный, приглашенный пользователь, вызываемая сторона, вызываемый: сторона, которая
         получает запрос INVITE с целью установления
         новая сессия. Вызываемый сохраняет эту роль с момента
         получает ПРИГЛАШЕНИЕ до завершения диалога
         установлено этим ПРИГЛАШЕНИЕМ.

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

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

      Свободная маршрутизация: прокси-сервер считается свободным маршрутизацией, если он следует
         процедуры, определенные в данной спецификации для обработки
         поле заголовка маршрута. Эти процедуры разделяют
         место назначения запроса (присутствует в Request-URI) от

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

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

      Метод: метод - это основная функция, для которой предназначен запрос.
         вызвать на сервере. Метод переносится в запросе
         само сообщение. Примеры методов - INVITE и BYE.

      Исходящий прокси: прокси, который получает запросы от клиента, даже
         хотя это может быть не сервер, разрешенный Request-URI.Обычно UA настраивается вручную с исходящим прокси,
         или можете узнать об одном из протоколов автоматической настройки.

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

      Прокси, прокси-сервер: посредник, который действует как
         сервер и клиент с целью отправки запросов на
         от имени других клиентов. Прокси-сервер в основном играет
         роль маршрутизации, что означает, что ее задача - гарантировать, что
         запрос отправляется другому объекту «ближе» к целевой
         пользователь.Прокси-серверы также полезны для применения политики (для
         например, убедитесь, что пользователю разрешено звонить). А
         прокси интерпретирует и при необходимости переписывает определенные части
         сообщение-запрос перед его пересылкой.

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

      Сервер перенаправления: сервер перенаправления - это сервер пользовательского агента, который
         генерирует 3xx ответа на полученные запросы, направляя
         клиент для связи с альтернативным набором URI.Регистратор: Регистратор - это сервер, который принимает запросы РЕГИСТРАЦИИ.
         и помещает информацию, которую он получает в этих запросах, в
         служба определения местоположения для обрабатываемого домена.

      Обычная транзакция: Обычная транзакция - это любая транзакция с
         метод, отличный от INVITE, ACK или CANCEL.

      Запрос: SIP-сообщение, отправленное от клиента на сервер, для
         цель вызова определенной операции.

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

      Набор маршрутов: набор маршрутов представляет собой набор упорядоченных URI SIP или SIPS.
         которые представляют собой список прокси, которые необходимо пройти, когда
         отправка конкретного запроса. Набор маршрутов можно узнать,
         через заголовки, такие как Record-Route, или его можно настроить.

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

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

      Сессия: Из спецификации SDP: «Мультимедийный сеанс - это
         набор мультимедийных отправителей и получателей и потоков данных
         перетекает от отправителя к получателю.Мультимедийная конференция - это
         пример мультимедийного сеанса. "(RFC 2327 [1]) (сеанс
         как определено для SDP, может включать один или несколько сеансов RTP.) Как
         определено, вызываемый может быть приглашен несколько раз, разными
         звонки в тот же сеанс. Если используется SDP, сеанс
         определяется конкатенацией имени пользователя SDP, идентификатора сеанса,
         тип сети, тип адреса и элементы адреса в источнике
         поле.

      SIP-транзакция: SIP-транзакция происходит между клиентом и
         сервер и содержит все сообщения из первого отправленного запроса
         от клиента к серверу до окончательного (не 1xx) ответа

         отправлено с сервера клиенту.Если запрос INVITE
         и окончательный ответ не-2xx, транзакция также
         включает ACK в ответ. ACK для ответа 2xx на
         запрос INVITE - это отдельная транзакция.

      Спираль: спираль - это SIP-запрос, который направляется прокси,
         пересылается вперед и снова приходит к этому прокси, но
         на этот раз отличается, что приведет к другому
         решение обработки, чем исходный запрос. Обычно это
         означает, что Request-URI запроса отличается от предыдущего
         прибытие.В отличие от петли, спираль не является ошибкой. А
         Типичная причина этого - переадресация звонков. Пользователь звонит
         [email protected] Прокси-сервер example.com пересылает его Джо
         ПК, который, в свою очередь, пересылает его на адрес [email protected] Этот
         запрос передается обратно на прокси example.com. Однако,
         это не петля. Поскольку запрос нацелен на
         другого пользователя, это считается спиралью и является действительным
         состояние.

      Прокси-сервер с отслеживанием состояния: логический объект, который поддерживает клиента и
         конечные автоматы транзакций сервера, определенные этой спецификацией
         во время обработки запроса, также известного как транзакция
         прокси с отслеживанием состояния.Дальнейшее поведение прокси с отслеживанием состояния
         определено в Разделе 16. Прокси-сервер (транзакция) с отслеживанием состояния не
         то же, что и прокси-сервер с отслеживанием состояния вызова.

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

      Строгая маршрутизация: прокси-сервер называется строгой маршрутизацией, если он следует
         правила обработки маршрутов RFC 2543 и многие предыдущие работы в
         текущие версии этого RFC.Это правило заставляло прокси
         уничтожить содержимое Request-URI, когда заголовок Route
         поле присутствовало. Строгий режим маршрутизации в этом
         спецификации в пользу свободной маршрутизации. Прокси
         которые выполняют строгую маршрутизацию, также известны как строгие маршрутизаторы.

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

      Пользователь транзакции (TU): уровень обработки протокола, который
         находится над уровнем транзакции.Пользователи транзакции включают
         ядро UAC, ядро ​​UAS и ядро ​​прокси.

      Восходящий поток: направление пересылки сообщений внутри транзакции.
         это относится к направлению, в котором ответы исходят от пользователя
         сервер агента обратно к клиенту пользовательского агента.

      Кодировка URL: строка символов, закодированная в соответствии с RFC 2396,
         Раздел 2.4 [5].

      Клиент пользовательского агента (UAC): клиент пользовательского агента является логическим объектом.
         который создает новый запрос, а затем использует клиента
         государственная машина транзакции для его отправки.Роль ОАК длится
         только на время этой транзакции. Другими словами, если
         часть программного обеспечения инициирует запрос, она действует как UAC для
         продолжительность этой транзакции. Если он получает запрос
         позже он принимает на себя роль сервера пользовательского агента для
         обработка этой транзакции.

      Ядро UAC: набор функций обработки, необходимых для UAC, который
         находятся над транзакционным и транспортным уровнями.

      Сервер пользовательского агента (UAS): сервер пользовательского агента - это логическая сущность.
         который генерирует ответ на SIP-запрос.Ответ
         принимает, отклоняет или перенаправляет запрос. Эта роль длится
         только на время этой транзакции. Другими словами, если
         часть программного обеспечения отвечает на запрос, она действует как БПЛА для
         продолжительность этой транзакции. Если он генерирует запрос
         позже он принимает на себя роль клиента пользовательского агента для
         обработка этой транзакции.

      Ядро БПЛА: Набор функций обработки, необходимых для БПЛА, который
         находится над транзакционным и транспортным уровнями.Пользовательский агент (UA): логический объект, который может действовать как пользователь
         клиент агента и сервер пользовательского агента.

   Роль UAC и UAS, а также прокси-серверов и серверов перенаправления:
   определяется для каждой отдельной транзакции. Например, пользователь
   агент, инициирующий вызов, действует как UAC при отправке начального ПРИГЛАШЕНИЯ
   запроса и как UAS при получении запроса BYE от вызываемого.
   Точно так же одно и то же программное обеспечение может выступать в качестве прокси-сервера для одного
   запроса и в качестве сервера перенаправления для следующего запроса.Указанные выше прокси, серверы местоположения и регистраторы являются логическими.
   сущности; реализации МОГУТ объединить их в одно приложение.

7 сообщений SIP

   SIP - это текстовый протокол, использующий кодировку UTF-8 (RFC 2279
   [7]).

   Сообщение SIP - это либо запрос от клиента к серверу, либо
   ответ сервера клиенту.

   И запросы (раздел 7.1), и сообщения ответа (раздел 7.2) используют
   базовый формат RFC 2822 [3], хотя синтаксис отличается
   набор символов и особенности синтаксиса.(SIP допускает поля заголовка,
   не будут допустимыми полями заголовка RFC 2822, например.) Оба типа
   сообщений состоят из начальной строки, одного или нескольких полей заголовка,
   пустая строка, указывающая конец полей заголовка, и необязательный
   тело сообщения.

         generic-message = начальная строка
                             *Заголовок сообщения
                             CRLF
                             [тело сообщения]
         start-line = Строка запроса / Строка состояния

   Начальная строка, каждая строка заголовка сообщения и пустая строка ДОЛЖНЫ быть
   завершается последовательностью перевода строки с возвратом каретки (CRLF).Обратите внимание, что
   пустая строка ДОЛЖНА присутствовать, даже если тело сообщения отсутствует.

   За исключением указанной выше разницы в наборах символов, большая часть SIP
   синтаксис поля сообщения и заголовка идентичен HTTP / 1.1. Скорее
   вместо того, чтобы повторять здесь синтаксис и семантику, мы используем [HX.Y] для обозначения
   согласно разделу X.Y текущей спецификации HTTP / 1.1 (RFC 2616 [8]).

   Однако SIP не является расширением HTTP.

7.1 Запросы

   SIP-запросы отличаются наличием строки запроса для начала:
   линия.Строка запроса содержит имя метода, URI запроса и
   версия протокола, разделенная одним символом пробела (SP).

   Строка запроса заканчивается CRLF. CR или LF не допускаются, кроме
   последовательность CRLF конца строки. Линейные пробелы (LWS) не допускаются.
   в любом из элементов.

         Строка запроса = Метод SP URI запроса SP Версия SIP CRLF

      Метод: В этой спецификации определены шесть методов: РЕГИСТРАЦИЯ для
           регистрация контактной информации, ПРИГЛАШЕНИЕ, ПОДТВЕРЖДЕНИЕ и ОТМЕНА для
           настройка сеансов, BYE для завершения сеансов и
           ВАРИАНТЫ для запроса серверов об их возможностях.ГЛОТОК
           расширения, задокументированные в стандартах, отслеживают RFC, могут определять
           дополнительные методы.

      Request-URI: Request-URI - это SIP или SIPS URI, как описано в
           Раздел 19.1 или общий URI (RFC 2396 [5]). Это указывает
           пользователь или сервис, которому адресован этот запрос.
           Request-URI НЕ ДОЛЖЕН содержать неэкранированные пробелы или элементы управления.
           символы и НЕ ДОЛЖНЫ заключаться в "<>".

           Элементы SIP МОГУТ поддерживать Request-URI со схемами, отличными от
           "sip" и "sips", например схема URI "tel" в RFC
           2806 [9].Элементы SIP МОГУТ переводить не-SIP URI с использованием любых
           механизм в их распоряжении, в результате чего SIP URI, SIPS URI,
           или какая-то другая схема.

      Версия SIP: как сообщения запроса, так и сообщения ответа включают
           используемая версия SIP и следуйте [h4.1] (с заменой HTTP
           по SIP, а HTTP / 1.1 заменен на SIP / 2.0) относительно версии
           заказ, соответствие требованиям и обновление версии
           числа. Чтобы соответствовать этой спецификации,
           приложения, отправляющие сообщения SIP, ДОЛЖНЫ включать версию SIP.
           компании «СИП / 2.0 ". Строка SIP-Version не чувствительна к регистру,
           но реализации ДОЛЖНЫ отправлять заглавные буквы.

           В отличие от HTTP / 1.1, SIP рассматривает номер версии как буквальный
           строка. На практике это не должно иметь значения.

7.2 Ответы

   Ответы SIP отличаются от запросов наличием строки состояния.
   как их стартовая линия. Строка состояния состоит из версии протокола.
   за которым следует числовой код состояния и связанная с ним текстовая фраза,
   с каждым элементом, разделенным одним символом SP.CR или LF не разрешены, кроме последней последовательности CRLF.

      Строка состояния = Версия SIP SP Код состояния SP Причина-фраза CRLF

   Код состояния - это трехзначный целочисленный код результата, который указывает
   результат попытки понять и удовлетворить запрос. В
   Reason-Phrase предназначен для краткого текстового описания
   Статус-код. Статус-код предназначен для использования автоматами,
   в то время как фраза-причина предназначена для человека. Клиент
   не требуется изучать или отображать Фразу-причину.Хотя эта спецификация предлагает конкретную формулировку по причине
   фраза, реализации МОГУТ выбрать другой текст, например, в
   язык, указанный в поле заголовка Accept-Language
   запрос.

   Первая цифра кода состояния определяет класс ответа.
   Последние две цифры не имеют роли категоризации. За это
   причина, любой ответ с кодом состояния от 100 до 199 является
   называемый «ответ 1xx», любой ответ с кодом состояния
   между 200 и 299 как «ответ 2xx» и так далее.SIP / 2.0 позволяет
   шесть значений для первой цифры:

      1xx: Предварительно - запрос получен, обработка продолжается.
           запрос;

      2xx: Success - действие успешно получено, понято,
           и принято;

      3xx: перенаправление - необходимо предпринять дальнейшие действия, чтобы
           заполнить заявку;

      4xx: ошибка клиента - запрос содержит неверный синтаксис или не может быть
           выполняется на этом сервере;

      5xx: Ошибка сервера - серверу не удалось выполнить явно
           действительный запрос;

      6xx: Global Failure - запрос не может быть выполнен ни при каких условиях.
           сервер.Раздел 21 определяет эти классы и описывает отдельные коды.

7.3 Поля заголовка

   Поля заголовка SIP аналогичны полям заголовка HTTP в обоих синтаксисах.
   и семантика. В частности, поля заголовка SIP следуют за [h5.2]
   определения синтаксиса заголовка сообщения и правила для
   расширение полей заголовка на несколько строк. Однако последний
   указан в HTTP с неявными пробелами и сворачиванием. Этот
   спецификация соответствует RFC 2234 [10] и использует только явные
   пробелы и сворачивание как неотъемлемая часть грамматики.[h5.2] также указывает, что несколько полей заголовка одного поля
   имя, значение которого представляет собой список, разделенный запятыми, можно объединить в один
   поле заголовка. Это относится и к SIP, но конкретное правило
   разные из-за разной грамматики. В частности, любой SIP
   заголовок, грамматика которого имеет форму

      header = "имя-заголовка" Значение заголовка HCOLON * (значение заголовка ЗАПЯТАЯ)

   позволяет объединять поля заголовка с тем же именем в запятую.
   разделенный список. Поле заголовка контакта позволяет использовать разделенные запятыми
   list, если значение поля заголовка не равно «*».7.3.1 Формат поля заголовка

   Поля заголовка следуют тому же общему формату заголовка, что и приведенный в
   Раздел 2.2 RFC 2822 [3]. Каждое поле заголовка состоит из поля
   имя, за которым следует двоеточие (":") и значение поля.

      имя-поля: значение-поля

   Формальная грамматика для заголовка сообщения, указанная в разделе 25.
   позволяет использовать произвольное количество пробелов по обе стороны от
   двоеточие; однако реализации должны избегать пробелов между полями
   имя и двоеточие и используйте один пробел (SP) между двоеточием и
   значение поля.Тема: обед
      Тема: обед
      Тема: обед
      Тема: обед

   Таким образом, все вышеперечисленные действительны и эквивалентны, но последнее
   предпочтительная форма.

   Поля заголовка можно расширить на несколько строк, поставив перед каждой
   дополнительная строка хотя бы с одной SP или горизонтальной табуляцией (HT). Линия
   break и пробел в начале следующей строки
   рассматривается как один символ SP. Таким образом, следующие
   эквивалент:

      Тема: Я знаю, что вы там, возьмите трубку и поговорите со мной!
      Тема: Я знаю, что ты там,
               возьми трубку
               и поговори со мной!

   Относительный порядок полей заголовка с разными именами полей не
   значительное.Однако РЕКОМЕНДУЕТСЯ, чтобы поля заголовка
   необходим для обработки прокси (Via, Route, Record-Route, Proxy-Require,
   Max-Forwards и Proxy-Authorization, например) появляются в направлении
   вверху сообщения, чтобы облегчить быстрый анализ. Относительная
   порядок строк поля заголовка с одинаковым именем поля важен.
   Несколько строк поля заголовка с одним и тем же именем поля МОГУТ присутствовать в
   сообщение тогда и только тогда, когда все значение поля для этого поля заголовка
   определяется как список, разделенный запятыми (то есть, если следует грамматике
   определено в разделе 7.3). ДОЛЖНА быть возможность комбинировать несколько
   строки поля заголовка в одну пару "имя-поля: значение поля", без
   изменяя семантику сообщения, добавляя каждый последующий
   значение поля до первого, каждое через запятую. Исключения
   к этому правилу относятся WWW-Authenticate, Authorization, Proxy-
   Поля заголовка Authenticate и Proxy-Authorization. Множественный заголовок

   строки полей с этими именами МОГУТ присутствовать в сообщении, но поскольку
   их грамматика не соответствует общей форме, указанной в разделе 7.3,
   они НЕ ДОЛЖНЫ быть объединены в одну строку поля заголовка.

   Реализации ДОЛЖНЫ иметь возможность обрабатывать несколько строк поля заголовка.
   с тем же именем в любой комбинации одного значения в строке или
   Формы значений, разделенных запятыми.

   Следующие группы строк поля заголовка допустимы и эквивалентны:

      Маршрут: 
      Тема: Обед
      Маршрут: 
      Маршрут: 

      Маршрут: , 
      Маршрут: 
      Тема: Обед

      Тема: Обед
      Маршрут: , ,
             

   Каждый из следующих блоков действителен, но не эквивалентен
   другие:

      Маршрут: 
      Маршрут: 
      Маршрут: 

      Маршрут: 
      Маршрут: 
      Маршрут: 

      Маршрут: , ,
             

   Формат значения поля заголовка определяется для каждого имени заголовка. Это
   всегда будет либо непрозрачной последовательностью октетов TEXT-UTF8, либо
   сочетание пробелов, токенов, разделителей и строк в кавычках.
   Многие существующие поля заголовка будут соответствовать общей форме
   значение, за которым следует последовательность имени параметра, разделенная точкой с запятой,
   пары параметр-значение:

         имя-поля: значение-поля * (; имя-параметра = значение-параметра)

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

      Контакты: ; истекает = 3600

   эквивалентно

      КОНТАКТ: ; ExPiReS = 3600

   а также

      Content-Disposition: сеанс; обработка = необязательно

   эквивалентно

      content-disposition: Session; ОБРАБОТКА = НЕОБЯЗАТЕЛЬНО

   Следующие два поля заголовка не эквивалентны:

      Предупреждение: 370 devnull "Выберите трубу побольше"
      Предупреждение: 370 devnull "ВЫБЕРИТЕ БОЛЬШУЮ ТРУБУ"

7.3.2 Классификация поля заголовка

   Некоторые поля заголовка имеют смысл только в запросах или ответах. Эти
   называются полями заголовка запроса и полями заголовка ответа,
   соответственно. Если поле заголовка появляется в сообщении, не соответствующем
   свою категорию (например, поле заголовка запроса в ответе), он ДОЛЖЕН
   игнорировать. Раздел 20 определяет классификацию каждого заголовка.
   поле.

7.3.3 Компактная форма

   SIP предоставляет механизм для представления общих имен полей заголовков в
   сокращенная форма.Это может быть полезно, когда сообщения иначе
   стать слишком большим, чтобы его можно было перевозить на доступном ему транспорте
   (превышение максимальной единицы передачи (MTU) при использовании UDP, для
   пример). Эти компактные формы определены в разделе 20. Компакт
   форма МОЖЕТ быть заменена более длинной формой имени поля заголовка в
   в любое время без изменения семантики сообщения. Заголовок

   имя поля МОЖЕТ появляться как в длинной, так и в краткой форме в пределах одного
   сообщение. Реализации ДОЛЖНЫ принимать как длинные, так и короткие формы.
   каждого имени заголовка.7.4 Органы

   Запросы, включая новые запросы, определенные в расширениях к этому
   В спецификации МОЖЕТ содержать тела сообщения, если не указано иное.
   Интерпретация тела зависит от метода запроса.

   Для ответных сообщений метод запроса и статус ответа.
   код определяет тип и интерпретацию любого тела сообщения. Все
   ответы МОГУТ включать тело.

7.4.1 Тип тела сообщения

   Тип Интернет-носителя тела сообщения ДОЛЖЕН быть задан
   Поле заголовка Content-Type.Если тело подвергалось какой-либо кодировке
   например, сжатие, то это ДОЛЖНО быть указано в Content-
   Поле заголовка кодировки; в противном случае ДОЛЖНО быть опущено Content-Encoding.
   Если возможно, набор символов тела сообщения указывается как
   часть значения поля заголовка Content-Type.

   "Multipart" MIME-тип, определенный в RFC 2046 [11], МОЖЕТ использоваться в
   тело сообщения. Реализации, отправляющие запросы
   содержащие составные тела сообщения ДОЛЖНЫ отправлять описание сеанса
   как тело сообщения, не состоящее из нескольких частей, если удаленная реализация запрашивает
   это через поле заголовка Accept, которое не содержит multipart.Сообщения SIP МОГУТ содержать двоичные тела или части тела. Когда нет
   явный параметр charset предоставляется отправителем, подтипы медиа
   типа "текст" определены, чтобы иметь значение кодировки по умолчанию
   «UTF-8».

7.4.2 Длина тела сообщения

   Длина тела в байтах предоставляется заголовком Content-Length.
   поле. Раздел 20.14 описывает необходимое содержимое этого заголовка.
   поле подробно.

   Кодирование передачи HTTP / 1.1 "по частям" НЕ ДОЛЖНО использоваться для SIP.
   (Примечание: фрагментированная кодировка изменяет тело сообщения по порядку
   передать его как серию кусков, каждый со своим размером
   показатель.)

7.5 Фрейминг сообщений SIP

   В отличие от HTTP, реализации SIP могут использовать UDP или другие ненадежные
   протоколы дейтаграмм. Каждая такая дейтаграмма содержит один запрос или
   ответ. См. Раздел 18 об ограничениях на использование ненадежных
   транспорты.

   Реализации, обрабатывающие SIP-сообщения с потоковой ориентацией
   транспорты ДОЛЖНЫ игнорировать любые CRLF, появляющиеся перед стартовой строкой
   [h5.1].

      Значение поля заголовка Content-Length используется для определения конца
      каждое сообщение SIP в потоке. Он всегда будет присутствовать, когда SIP
      сообщения отправляются через потоковый транспорт.8 Общее поведение агента пользователя

   Пользовательский агент представляет собой конечную систему. Он содержит пользовательский агент
   клиент (UAC), который генерирует запросы, и сервер пользовательского агента
   (UAS), который им отвечает. UAC может генерировать
   запрос, основанный на некотором внешнем стимуле (пользователь нажимает кнопку,
   или сигнал на линии PSTN) и обработка ответа. БПЛА - это
   способен принимать запрос и генерировать ответ на основе
   пользовательский ввод, внешний стимул, результат выполнения программы или
   какой-то другой механизм.Когда UAC отправляет запрос, запрос проходит через некоторое количество
   прокси-серверы, которые перенаправляют запрос к UAS. Когда
   UAS генерирует ответ, ответ пересылается в UAC.

   Процедуры UAC и UAS сильно зависят от двух факторов. Во-первых, на основе
   от того, находится ли запрос или ответ внутри или вне диалога,
   во-вторых, в зависимости от метода запроса. Обсуждаются диалоги
   полностью в Разделе 12; они представляют собой одноранговые отношения
   между пользовательскими агентами и устанавливаются определенными методами SIP, такими как
   как ПРИГЛАСИТЬ.В этом разделе мы обсуждаем независимые от метода правила для UAC и
   Поведение UAS при обработке запросов вне диалога.
   Это, конечно, включает запросы, которые сами по себе устанавливают
   диалог.

   Процедуры безопасности для запросов и ответов вне диалога
   описаны в Разделе 26. В частности, существуют механизмы для
   UAS и UAC для взаимной аутентификации. Ограниченный набор конфиденциальности
   функции также поддерживаются за счет шифрования тел с использованием
   S / MIME.8.1 Поведение UAC

   В этом разделе рассматривается поведение UAC вне диалога.

8.1.1 Генерация запроса

   Действительный SIP-запрос, сформулированный UAC, ДОЛЖЕН как минимум содержать
   следующие поля заголовка: To, From, CSeq, Call-ID, Max-Forwards,
   и Via; все эти поля заголовка обязательны для всех SIP
   Запросы. Эти шесть полей заголовка являются фундаментальным элементом
   блоки сообщения SIP, так как они совместно обеспечивают большую часть
   службы маршрутизации критических сообщений, включая адресацию
   сообщения, маршрутизация ответов, ограничение распространения сообщений,
   упорядочивание сообщений и уникальная идентификация транзакций.Эти поля заголовка дополняют обязательную строку запроса,
   который содержит метод, Request-URI и версию SIP.

   Примеры запросов, отправленных вне диалога, включают ПРИГЛАШЕНИЕ на
   установить сеанс (раздел 13) и ОПЦИИ для запроса
   возможности (Раздел 11).

8.1.1.1 Request-URI

   Первоначальный Request-URI сообщения ДОЛЖЕН быть установлен на значение
   URI в поле Кому. Одно примечательное исключение - РЕГИСТР.
   метод; поведение для установки Request-URI для REGISTER приведено в
   Раздел 10.Это также может быть нежелательно по соображениям конфиденциальности или
   удобство установки в этих полях одного и того же значения (особенно если
   исходящий UA ожидает, что Request-URI будет изменен во время
   транзит).

   В некоторых особых случаях наличие уже существующего маршрута
   set может повлиять на Request-URI сообщения. Существующий ранее маршрут
   set - это упорядоченный набор URI, который идентифицирует цепочку серверов, чтобы
   который UAC будет отправлять исходящие запросы, не входящие в диалог.
   Обычно они настраиваются на UA пользователем или поставщиком услуг.
   вручную или через какой-либо другой механизм, отличный от SIP.Когда провайдер
   желает настроить UA с исходящим прокси, РЕКОМЕНДУЕТСЯ
   чтобы это было сделано, предоставив ему уже существующий маршрут, установленный с
   единственный URI исходящего прокси.

   При наличии уже существующего набора маршрутов процедуры для
   заполнение полей Request-URI и Route, подробно описанных в разделе
   12.2.1.1 ДОЛЖЕН выполняться (даже если диалоговое окно отсутствует), используя
   желаемый Request-URI в качестве удаленного целевого URI.

8.1.1.2 Кому

   В поле заголовка To в первую очередь указывается желаемый
   "логический" получатель запроса или адрес записи
   пользователь или ресурс, являющийся целью этого запроса.Это может или может
   не быть конечным получателем запроса. Поле заголовка Кому
   МОЖЕТ содержать URI SIP или SIPS, но может также использовать другой URI
   схемы (например, телефонный URL (RFC 2806 [9])), когда это необходимо.
   Все реализации SIP ДОЛЖНЫ поддерживать схему SIP URI. любой
   реализация, поддерживающая TLS, ДОЛЖНА поддерживать схему SIPS URI.
   Поле заголовка «Кому» позволяет отображать имя.

   UAC может узнать, как заполнить поле заголовка To для конкретного
   запрос несколькими способами.Обычно пользователь предлагает Кому
   поле заголовка через человеческий интерфейс, возможно, ввод URI
   вручную или выбрав его из какой-то адресной книги. Часто,
   пользователь вводит не полный URI, а скорее строку цифр
   или буквы (например, «боб»). Это на усмотрение UA.
   выбрать, как интерпретировать этот ввод. Используя строку для формирования
   пользовательская часть SIP URI подразумевает, что UA желает, чтобы имя было
   разрешено в домене справа (RHS) от входа в систему
   SIP URI (например, sip: bob @ example.com). Использование строки для
   пользовательская часть SIPS URI подразумевает, что UA желает
   безопасно общаться, и что имя должно быть разрешено в
   домен справа от знака at. RHS часто будет
   домашний домен отправителя запроса, что позволяет домашнему домену
   обработать исходящий запрос. Это полезно для таких функций, как
   «быстрый набор», требующий интерпретации абонентской части дома
   домен. URL-адрес телефона может использоваться, когда UA не желает указывать
   домен, который должен интерпретировать телефонный номер, который был
   ввод пользователем.Вернее, каждый домен, через который поступает запрос
   пропускам будет предоставлена ​​такая возможность. Например, пользователь в
   аэропорт может входить в систему и отправлять запросы через исходящий прокси в
   аэропорт. Если они введут «411» (это номер телефона местного
   справочная служба в США), что необходимо
   интерпретируется и обрабатывается исходящим прокси в аэропорту, а не
   домашний домен пользователя. В этом случае тел: 411 будет правильным
   выбор.

   Запрос вне диалога НЕ ДОЛЖЕН содержать тега To; тег в
   Поле To запроса идентифицирует однорангового участника диалога.поскольку
   диалог не установлен, тег отсутствует.

   Для получения дополнительной информации о поле заголовка Кому см. Раздел 20.39.
   Ниже приведен пример действительного поля заголовка To:

      Кому: Кэрол 

8.1.1.3 Из

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

: 11.11.2008
#: 73,157
: 1266

: 06.08.2003
#: 8,524
: 3623
:.

: 54

: 11.11.2008
#: 73,157
: 1266

: 11.11.2008
№: 73,157
: 1266

: 23.02.2005
#: 24,533
: 13257
:

: 132

: 11.11.2008
#: 73,157
: 1266

: 11.11.2008
№: 73,157
: 1266

: 23.02.2005
#: 24,533
: 13257
:

: 132

: 11.11.2008
#: 73,157
: 1266

: 11.11.2008
№: 73,157
: 1266