Действия клиента |
|
Запросы CANCEL передаются для отмены запросов INVITE. Поскольку на прочие запросы ответы приходят незамедлительно, передача CANCEL для He-INVITE-запросов всегда будет приводить к явлению, когда с равной вероятностью первым могут быть доставлен и окончательный ответ - клиенту, и запрос CANCEL - серверу. Для формирования запроса CANCEL применяются следующие процедуры. Поля Request-URI, Call-ID, To, числовая часть поля CSeq и From в запросе CANCEL должны быть идентичны полям в отменяемом запросе, включая параметры «tag». CANCEL, формируемый клиентом, должен иметь только одно значение заголовка Via, соответствующее верхнему значению Via отменяемого запроса. Использование тех же значений для этих полей позволяет установить соответствие CANCEL отменяемому запросу. Однако поле типа запроса в заголовке CSeq должно иметь значение CANCEL. Это приводит к тому, что сообщение будет идентифицировано и обработано как отдельная транзакция. Запрос CANCEL не должен содержать заголовков Require и Proxy-RequireЕсли отменяемый запрос содержит заголовок Route, CANCEL тоже должен содержать значения этого заголовка. Это нужно для того, чтобы stateless прокси-серверы могли правильно маршрутизировать запросы CANCEL. После формирования запроса CANCEL клиент должен проверить, не получил ли он ответа (предварительного или окончательного) на отменяемый запрос. Если предварительного ответа не было получено, запрос CANCEL не должен передаваться; точнее, клиент должен дождаться прихода предварительного ответа, прежде чем передать запрос CANCEL. Если на оригинальный запрос пришел окончательный ответ, нет смысла передавать CANCEL, так как он не оказывает влияния на запросы, на которые уже создан окончательный ответ. Когда клиент решает передать запрос CANCEL, он создает для него клиентскую транзакцию и передает ей запрос вместе с адресом назначения, номером порта и типом транспортного протокола. Адрес назначения, порт и тип транспортного протокола для CANCEL должны быть идентичными тем, которые использовались при передаче оригинального запроса. Если бы было разрешено передать CANCEL до получения ответа на предыдущий запрос, сервер мог бы получить CANCEL раньше оригинального запроса. Заметим, что и транзакция, соответствующая оригинальному запросу, и CANCEL-транзакция будут завершены независимо. Однако UAC, отменяющий запрос, не может быть уверен в получении ответа с кодом 487 (Request Terminated) на оригинальный запрос, так как UAS, функционирующий в соответствии с более ранней версией спецификации, может не создать такого ответа. В связи с этим, если за интервал времени 64 Т1 секунд не пришло окончательного ответа на оригинальный запрос, клиент расценивает оригинальную транзакцию отмененной и разрушает клиентскую транзакцию оригинального запроса. |
