UAS без сохранения состояний (stateless) - это UAS, который не запоминает состояния текущих транзакций. Он нормально обрабатывает запросы, но, в отличие от UAS с сохранением состояний (stateful), не сохраняет состояния транзакций после передачи ответов. Если stateless UAS получает повторно переданный запрос, он повторно формирует ответ и повторно его отсылает так же, как это происходило при получении первого запроса. UAS может быть stateless , только если обработка идентичных запросов одного типа приводит к генерации одинаковых ответов. Stateless UAS не использует уровень транзакций: он принимает запрос прямо от транспортного уровня SI P и передает ответ тоже непосредственно транспортному уровню. Основная роль stateless UAS состоит в поддержке не аутен-тифицированных запросов, которые требуют передачи ответа с запросом аутентификации. Если бы эти запросы поддерживались с сохранением состояния, то возможные потоки злонамеренных запросов, не содержащих отклика аутентификации, сопровождались бы созданием большого числа транзакций, что, в свою очередь, могло бы замедлить или остановить обработку вызовов в UAS.

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

Поле From ответа должно совпадать с аналогичным полем запроса, равно как и поля Call-ID, Cseq и Via ответа должны совпадать с полями Call-ID, Cseq и Via запроса. Помимо этого, значения поля Via должны совпадать со значениями поля Via в запросе и должны сохранять порядок следования. Если запрос содержал «tag» в поле То, то поле То в ответе должно совпадать с тем, что было в запросе. В случае если поле То в запросе не содержит «tag», URI в поле То ответа должен совпадать с URI в поле То запроса; дополнительно, UAS должен добавить «tag» в поле То ответа (за исключением ответа с кодом 100 (Trying), в котором «tag» может уже присутствовать). Тот же «tag» должен быть использован для всех ответов на этот запрос, предварительных и окончательных (исключая ответ с кодом 100 (Trying)).

Основное правило, вне зависимости от типа запроса, состоит в том, что серверы UA должны передавать предварительные ответы только на запросы INVITE. При этом они должны как можно быстрее создавать окончательные ответы на все запросы, кроме INVITE. При формировании ответа с кодом 100 (Trying) в него из запроса должен быть в точности скопирован заголовок Timestamp (указывает время, когда UAC передал сообщение UAS). Это выполняется для оценки клиентом времени RTT. Если происходит задержка при генерировании ответа, UAS должен добавить значение задержки к значению, содержащемуся в поле заголовка Timestamp в ответе. Это значение должно содержать разницу между временем получения запроса и временем передачи ответа, выраженную в секундах.

Когда UAS создает ответ на запрос, он следует общим процедурам, описанным ниже. Могут потребоваться также дополнительные действия, которые зависят от кода ответа. После завершения всех процедур, связанных с созданием ответа, UAS передает ответ серверной транзакции, от которой был получен запрос.

При формировании ответа UAS не должен использовать расширения, если поддержка этих расширений клиентом не была указана в заголовке Supported запроса. Если требуемые расширения не поддерживаются, сервер должен опираться только на основные SIP-расширения и другие расширения, поддерживаемые клиентом, В редких случаях, когда сервер не может обработать запрос без требуемого расширения, он может отправить ответ с кодом 421 (Extension Required).

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

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

После того как UAS решает, что запрос предназначен для него, он приступает к анализу заголовка Require (в случае его наличия).

Поле заголовка Require используется UAC, чтобы сообщить UAS о SIP-расширениях, которые тот должен поддерживать для правильной обработки запроса. Если UAS не понимает какого-либо идентификатора расширения option-tag, указанного в поле Require, он должен передать ответ с кодом 420 (Bad Extension). UAS должен добавить в ответ заголовок Unsupported со списком непонятных опций, указанных в поле Require запроса. Заметим, что заголовки Require и Proxy-Require не должны использоваться в запросе CANCEL, а также в запросе АСК, подтверждающем получение ответа, отличного от класса 2хх. Эти заголовки должны игнорироваться, даже если они имеются в таких запросах.

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

Если запрос не содержит параметра «tag» в поле заголовка То, ядро UAS (UAS core) должно проверить запрос на предмет происходящих транзакций. Если «tag» заголовка From, заголовки Call-ID и CSeq точно совпадают с аналогичными полями, связанными с происходящей транзакцией, но запрос не соответствует этой транзакции, ядро UAS должно составить ответ с кодом 482 (Loop Detected) и передать его серверной транзакции. Одинаковые запросы могут придти на сервер более одного раза, следуя разными путями, вероятнее всего, из-за размножения запросов прокси-сервером. Ядро UAS обрабатывает первый такой запрос и отправляет ответ с кодом 482 (Loop Detected) на остальные такие же запросы.

В поле заголовка То вызывающий пользователь указывает адрес получателя запроса. При выработке решения о приеме запроса, заголовок То которого идентифицирует другой UAS, данный UAS может поступать произвольным образом. Однако рекомендуется, чтобы UAS принимал запросы, даже если они содержат неизвестную схему URI (например, схему «tel») в поле То, или если поле То не содержит адреса ни текущего, ни одного из существующих пользователей этого UAS. Если UAS, все же, решает отклонить запрос, он должен создать ответ с кодом 403 (Forbidden) и отправить его серверной транзакции (понятие серверной транзакции дается в разделе 4.4) для передачи.

Поле Request-URI идентифицирует UAS, который должен обработать запрос. Если в Request-URI используется схема адресации, не поддерживаемая сервером, запрос должен быть отклонен, и должен быть отправлен ответ с кодом 416 (Unsupported URI Scheme). Если Request-URI не идентифицирует адрес, для которого UAS готов принять запрос, сообщение отбрасывается, и передается ответ с кодом 404 (Not Found). Обычно UA, который использует сообщение REGISTER, чтобы связать списочный адрес пользователя (address-of-record) с определенным контактным адресом, должен опознавать запросы, Request-URI которых совпадает с его контактным адресом. Другие возможные источники для значения полученного Request-URI - заголовки Contact запросов и ответов, отправленных UA для установления или обновления параметров диалога.