Кратко
- Работа Eve Schooler над MMCC и первой версией SIP помогла выделить узкую функцию: найти адресата, описать сеанс и получить ответ, не передавая будущие звук и видео.
- Это разделение сделало коммуникации модульными, но распределило власть между идентификацией, достижимостью, допуском, согласованием, защитой медиа и качеством связи.
Internet-Draft от февраля 1996 года, авторами которого были Mark Handley и Eve Schooler, назывался «Session Invitation Protocol». Название точно ограничивало обещание. Документ не строил законченную телефонную сеть поверх Интернета. Он описывал, как пригласить пользователя в сеанс, отыскать его текущий контакт с помощью пересылки или перенаправления и передать описание предполагаемой связи.
Сам разговор мог идти иным путём. Приглашение не резервировало пропускную способность, не распределяло право голоса на конференции и не переносило аудио- или видеопакеты. Сигнал создавал условия для общения, не присваивая себе все его функции.
Как из конференции выделили приглашение
До SIP Schooler работала в Information Sciences Institute Университета Южной Калифорнии над MMCC. В её открытом резюме эта система описана как средство управления сеансами в территориально распределённых пакетных сетях: многостороннее установление связи, неоднородные конфигурации, распространение сведений о качестве обслуживания и повторная синхронизация. Первый проект SIP прямо указывает на работу Schooler над MMCC как на один из источников.
Однако опыт сложной конференционной системы привёл не к переносу всех её возможностей в новый стандарт, а к сокращению задачи. Проект разделял сеанс, о котором объявили заранее и который участник нашёл сам, и направленное приглашение. Обнаружение сеанса называлось ортогональным модели управления конференцией. После нахождения адреса приглашённому отправлялось описание в формате SDP; тот мог согласиться, отказаться или перенаправить запрос. Способность сети обеспечить заявленное качество оставалась отдельным вопросом.
В 1999 году RFC 2543 за авторством Handley, Henning Schulzrinne, Schooler и Jonathan Rosenberg определил SIP как сигнализацию прикладного уровня для создания, изменения и завершения мультимедийных сеансов. Сменивший его RFC 3261 разложил назначение на поиск пользователя, сведения о его доступности и возможностях, установление и управление сеансом. SIP был представлен как компонент, работающий вместе с другими протоколами, а не как вертикально интегрированная система.
Это коллективная история. Первый текст написали Handley и Schooler; опубликованная спецификация вобрала работу Schulzrinne, Rosenberg и более широкого сообщества IETF. Вклад Schooler важен тем, что опыт распределённых конференций помог превратить приглашение в самостоятельную задачу. Называть её единственным изобретателем SIP было бы неверно. Нельзя приписывать ей и авторство RFC 3261: у этого документа другой состав авторов.
Три маршрута в одном звонке
Простой обмен SIP показывает границу на практике. Пользовательский агент посылает INVITE. Регистратор принимает привязки публичного адреса к текущим контактам; служба определения местоположения и прокси направляют запрос к одному из них. Получатель возвращает успешный окончательный ответ, а ACK завершает исходное рукопожатие. В простом случае прокси после этого могут уйти с активного сигнального пути. RTP-пакеты со звуком или видео обычно идут по маршруту, отличному от SIP-сообщений.
Наличие SDP внутри приглашения не превращает его в медиа. SDP описывает типы потоков, транспортные адреса и параметры. Модель предложения и ответа помогает сторонам согласовать совместимое описание. Но описание аудио не является аудио. За передачу в реальном времени отвечает RTP или сопоставимый механизм.
Поэтому за словом «звонок» скрываются как минимум три процесса: сигнализация достигает личности или домена; согласование сопоставляет возможности устройств; медиапоток доставляет содержание. Повторный INVITE может изменить описание уже после создания диалога. Срок действия приглашения не устанавливает продолжительность разговора. Состояния связаны, но не обязаны иметь общий маршрут и жизненный цикл.
Модульность позволила частям меняться независимо. Новый кодек не требовал перестраивать глобальный поиск пользователей. Конференционное приложение могло отдельно реализовать очередь выступлений или голосование. Резервирование сетевых ресурсов оставалось другим механизмам. SIP организовывал передачу управления между компонентами, а не поглощал их обязанности.
Посредник не слышит, но решает
Отсутствие на медиамаршруте не означает отсутствия власти. Регистратор влияет на то, какие устройства представляют адрес. Прокси может разрешить, отклонить или перенаправить приглашение. Домен вправе потребовать аутентификацию и записывать попытки связи. Для управления достижимостью не требуется видеть ни одного RTP-пакета.
Та же точность нужна в вопросах защиты. SIPS может охранять SIP-сигнализацию по цепочке защищённых соединений до домена получателя. Это само по себе не шифрует RTP. Защищённый конверт ещё не делает разговор конфиденциальным.
В реальных сетях разделённые пути нередко снова соединяются. Пограничные контроллеры сеансов, B2BUA, медиаретрансляторы, системы записи и средства обхода NAT могут оставаться на пути сигнализации, медиа или обоих. RFC 7092 классифицирует B2BUA потому, что такой узел не просто прозрачно пересылает запрос: он завершает один диалог и создаёт другой, применяя правила и меняя параметры.
Следовательно, граница SIP — инструмент диагностики, а не гарантия прямого медиамаршрута. Пользователь может быть найден, но не иметь общего кодека с вызывающим. Сигнализация может завершиться успешно, а медиапакеты — застрять в межсетевом экране. Личность может быть подтверждена, а разговор — остаться незашифрованным. Приглашение отдельно от разговора сделало различимыми разные места отказа и контроля.
Источники
- Профессиональная страница Eve Schooler
- Резюме Eve M. Schooler
- Handley и Schooler — первый проект Session Invitation Protocol
- Карточка RFC 2543
- RFC 2543 — SIP
- RFC 3261 — SIP
- RFC 3264 — модель предложения и ответа SDP
- RFC 4566 — SDP
- RFC 3550 — RTP
- RFC 3665 — примеры базовых сценариев SIP
- RFC 7092 — классификация SIP B2BUA
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
