Формирование запроса АСК |
|
Далее рассматривается конструкция запросов АСК, передаваемых в ходе клиентской транзакции. Ядро UAC, генерирующее АСК на ответ класса 2хх, должно следовать описанным в главе 2 правилам, определенным для запроса данного типа. Запрос АСК, формируемый клиентской транзакцией, должен содержать значения заголовков Call-ID, From и поля Request-URI, идентичные тем, что были переданы в составе оригинального запроса - запроса, для которого создавалась данная клиентская транзакция (в данном случае - для запроса INVITE). Значение заголовка То копируется из аналогичного заголовка подтверждаемого ответа и, следовательно, всегда будет отличаться от оригинального запроса дополнительным параметром «tag». В АСК должен присутствовать единственный заголовок Via, равный верхнему заголовку Via в оригинальном запросе. Поле заголовка CSeq содержит тот же порядковый номер, что и оригинальный запрос, но поле типа запроса имеет значение АСК. В случае, если запрос INVITE, на который получен требующий подтверждения ответ, содержал поля заголовка Route, они также должны быть и в запросе АСК. Это гарантирует, что АСК будет правильно маршрутизироваться при прохождении через прокси-серверы без сохранения состояний (stateless). Как и другие запросы, АСК может содержать тело сообщения. Однако существуют трудности, связанные с тем, что запрос АСК не может быть отклонен в случае, если тело сообщение не понято. Поэтому не рекомендуется помещать тело сообщения в запрос АСК, который подтверждает ответ, отличный от класса 2хх, но если это происходит, типы тела должны соответствовать типам, указанным в запросе INVITE, при условии, что ответ был не с кодом 415. В случае, если на оригинальный запрос пришел ответ с кодом 415, тело в сообщении АСК должно придерживаться типов, перечисленных в заголовке Accept ответа. Пример: |
