«Область применения. В этом документе описывается использование метода MESSAGE для отправки мгновенных сообщений с использованием метафоры, аналогичной метафоре двустороннего пейджера или телефона с поддержкой SMS. То есть @ нет явной связи между сообщениями. Каждое мгновенное сообщение является самостоятельным. - любой смысл «разговора» существует только в пользовательском интерфейсе клиента@ или, возможно, в собственном воображении пользователя. Мы противопоставляем это модели «сеанса»@, где есть явный разговор с четким началом и концом . В среде SIP@ сеанс обмена мгновенными сообщениями будет представлять собой мультимедийный сеанс, инициируемый транзакцией INVITE и завершающийся транзакцией BYE. Каждая модель имеет свою ценность. Большинство современных клиентов обмена мгновенными сообщениями предлагают оба варианта взаимодействия с пользователем. Пользователь может выбрать отправку мгновенных сообщений. на контакт @ или он может пригласить один или несколько контактов присоединиться к беседе. Модель пейджера имеет смысл, когда пользователь хочет отправить небольшое количество коротких мгновенных сообщений одному (или небольшому количеству) получателей. Модель сеанса имеет смысл для расширенных разговоров@ присоединение к группам чата@ если есть необходимость связать разговор с каким-либо другим сеансом, инициированным SIP@ и т. д. Может возникнуть соблазн имитировать сеанс мгновенных сообщений, инициируя диалог@, а затем отправляя запросы MESSAGE в контекст этого диалога. Это неадекватное решение для сеансов обмена мгновенными сообщениями@, поскольку этот подход заставляет запросы MESSAGE следовать по тому же сетевому пути, что и любые другие запросы SIP@, даже несмотря на то, что запросы MESSAGE, возможно, переносят медиа, а не сигнализацию. Приложения обмена мгновенными сообщениями обычно имеют большой объем сообщений@, и мы ожидаем, что объем обмена мгновенными сообщениями в сеансах будет еще выше. Это, скорее всего, вызовет проблемы с перегрузкой, если будет отправлено по транспорту без контроля перегрузки @, и в SIP нет четкого механизма, предотвращающего пересылку запроса MESSAGE через UDP на некоторых узлах. Кроме того, запросы MESSAGE, отправленные через существующий диалог, должны@ по природе SIP@ направляться в тот же пункт назначения, что и любой другой запрос, отправленный в этом диалоге. Это предотвращает любое разделение между конечной точкой IM и конечной точкой сигнализации. Это неприемлемое ограничение для сеансовой модели обмена мгновенными сообщениями. Авторы признают, что могут быть веские причины для отправки запросов MESSAGE в контексте диалога. Например, один участник голосового сеанса может пожелать отправить мгновенное сообщение другому участнику и связать это мгновенное сообщение с сеансом. Но реализации НЕ ДОЛЖНЫ создавать диалоги с основной целью связывания запросов MESSAGE друг с другом. Обратите внимание, что это заявление не запрещает использование SIP для инициирования мультимедийного сеанса, состоящего из IMs@, как и любого другого сеанса. Действительно@ мы ожидаем, что решение для сеансов обмена мгновенными сообщениями будет использовать эту метафору. Читателю следует избегать путаницы понятий SIP-диалога и медиа-сеанса».
RFC 3428-2002 История
2002RFC 3428-2002 Расширение протокола инициации сеанса (SIP) для обмена мгновенными сообщениями