Наиболее простой сценарий имеет место, когда вызываемый пользователь не может или не желает принять дополнительный вызов на свой терминал. При этом вызывающему пользователю передается ответ с кодом 486 (Busy Here). Если UAS знает о том, что никакой другой терминал не в состоянии принять этот вызов, передается ответ с кодом 600 (Busy Everywhere). Так как маловероятно, что UAS может располагать такими широкими сведениями, ответе кодом 600 обычно не используется. Ответ передается серверной INVITE-транзакции, которая занимается его повторной передачей.

UAS, отклоняющий информацию offer, которая содержится в запросе INVITE, должен передать ответе кодом 488 (Not Acceptable Here). Такой ответ должен включать в себя заголовок Warning с содержимым, объясняющим причину отказа.

Если UAS не в состоянии ответить на приглашение немедленно, он может предоставить UAC некоторую информацию о текущей стадии обработки запроса (например, оповестить о том, что в данный момент пользователю передается вызывной сигнал). Это выполняется путем передачи предварительных ответов с кодами от 101 по 199. Передача таких предварительных ответов приводит к установлению диалогов, находящихся на «ранней стадии». UAS может передать неограниченное число предварительных ответов. Каждый из них должен иметь одно и тоже значение идентификатора диалога (dialog ID).

Если UAS нуждается в отсрочке передачи ответа на запрос INVITE, он должен запросить «увеличение времени обработки» для того, чтобы предотвратить аннулирование транзакции прокси-серверами. Прокси-сервер может разрушить транзакцию, когда интервал между ответами достигает трех минут. Чтобы не допустить этого, UAS должен передавать предварительные ответы (за исключением ответа с кодом 100) каждую минуту с учетом того, что некоторые из них могут быть утеряны (т.к. по умолчанию предварительные ответы передаются ненадежно). INVITE-транзакция может продолжать свое существование на время действия отсрочки в случаях, когда пользователь поставлен на ожидание или при межсетевом взаимодействии с системами ТфОП, которые поддерживают соединения в предот-ветном состоянии (например, интерактивные системы речевого ответа IVR).

Ядро UAS получает запросы INVITE от уровня транзакций. Вначале выполняются общие процедуры обработки для UAS (как для запросов INVITE вне диалога, так и для запросов INVITE в режиме диалога). Допуская, что эти процедуры обработки выполняются без создания ответа, ядро UAC выполняет дополнительные шаги обработки:

продолжить...

Как только UAC передает запрос INVITE клиентской транзакции, он переходит в режим ожидания ответов на запрос. Если клиентская INVITE-транзакция вместо передачи ответа сообщает об истечении времени ожидания окончательного ответа, пользователь транзакции (TU) действует, как в случае получения ответа с кодом 408 (Request Timeout).

продолжить...

Формирование первоначального запроса INVITE происходит вне диалога с использованием соответствующих стандартных процедур. Дополнительная обработка требуется лишь в особых случаях.

Как правило, INVITE содержит заголовок Allow. Он указывает, какие типы запросов могут быть использованы вызывающей стороной в процессе диалога. Скорее всего, в запросе будет также присутствовать заголовок Supported. Он перечисляет все расширения, поддерживаемые клиентом агента пользователя. Возможно присутствие заголовка Accept, который указывает поддерживаемые данным УАтипы тел сообщения из предложенных в принятом ответе или запросе в ходе диалога. Заголовок Accept особенно важен для индикации поддержки различных форматов описания сеансов. UAC можеттакже добавить заголовок Expires, чтобы ограничить время действия приглашения к установлению соединения. Если время, указанное в Expires, истечет до получения окончательного ответа на INVITE, UAC передает сообщение CANCEL. Кроме этого, UAC может посчитать нужным добавить заголовки Subject, Organization и User-Agent; все они содержат информацию, относящуюся к запросу INVITE. UAC может добавить в запрос INVITE тело сообщения. Существуют отдельные правила для тел, содержащих описание сеанса связи, - их заголовок Content-Disposition имеет значение session. Протокол SIP использует модель типа «запрос/ответ» (offer/answer), где один UA посылает предложение - запрос с описанием сеанса. Запрос предлагает желаемые средства общения (аудио, видео), их параметры (такие как типы кодека) и адреса для получения медиа-информации от отвечающей стороны.

продолжить...

Когда клиент агента пользователя желает установить сеанс связи (аудио или видео), он формирует запрос INVITE. INVITE - запрос сервера установить сеанс связи. Он пересылается прокси-серверами и, в конечном счете, приходит на один или несколько UAS, которые потенциально могут принять предложение клиента.

Эти UAS, как правило, требуют от пользователя подтверждения приема вызова. По прошествии некоторого времени UAS может принять предложение путем передачи ответа 2хх (ОК); после этого сеанс связи считается установленным. Если предложение не принято, передаются ответы с кодами Зхх, 4хх, 5хх или бхх, в зависимости от причины отказа. Перед передачей окончательного ответа UAS может передавать предварительные ответы (1хх) для того, чтобы уведомлять UAC о состоянии процесса обработки вызова на стороне вызываемого пользователя.

продолжить...

Сообщение CANCEL запрашивает TU на стороне сервера отмену незавершенной транзакции. Чтобы определить транзакцию, которую требуется отменить, TU принимает запрос CANCEL, а затем применяет процедуры сопоставления транзакций, описанные в § 4.4.8. Отменена может быть только единственная транзакция.

Обработка запроса CANCEL сервером зависит от типа сервера. Stateless прокси-сервер его перешлет, stateful прокси-сервер может ответить на него и самостоятельно создать несколько запросов CANCEL, a UAS ответит на него.

продолжить...

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

Для формирования запроса CANCEL применяются следующие процедуры. Поля Request-URI, Call-ID, To, числовая часть поля CSeq и From в запросе CANCEL должны быть идентичны полям в отменяемом запросе, включая параметры «tag». CANCEL, формируемый клиентом, должен иметь только одно значение заголовка Via, соответствующее верхнему значению Via отменяемого запроса. Использование тех же значений для этих полей позволяет установить соответствие CANCEL отменяемому запросу. Однако поле типа запроса в заголовке CSeq должно иметь значение CANCEL. Это приводит к тому, что сообщение будет идентифицировано и обработано как отдельная транзакция.

продолжить...

Запрос CANCEL, как следует из его названия, используется для отмены предшествующего запроса, переданного клиентом. Точнее, он требует от UAS прекратить обработку запроса и создать ответ на него с определенным кодом. Запрос CANCEL не оказывает воздействия на запрос, на который UAS уже передал окончательный ответ. Поэтому отмена запросов представляет наибольшую важность для запросов, формирование ответов на которые требует больших затрат серверного времени. По этой причине CANCEL лучше всего подходит для запросов INVITE, которые требуют длительного времени для генерации ответа. В этом случае UAS, который получает CANCEL для INVITE, но еще не передал окончательного ответа, прекращает передавать пользователю сигнал вызова и посылает ответ на INVITE с определенным кодом ошибки (487).

Запросы CANCEL могут быть сформированы и переданы и прокси-серверами, и клиентами агента пользователя. Раздел 4.4 описывает, при каких условиях UAC отменит запрос INVITE, в разделе 5.2 дано описание использования запроса CANCEL прокси-сервером.