При приеме ответа перенаправления (например, ответа с кодом 301), клиенты должны использовать адрес (адреса) из поля Contact при составлении одного или нескольких новых запросов, основанных на перенаправленном запросе. Клиент начинает работу с начального списка адресов вызываемого пользователя (target set), включающего в себя только один URI - Request-URI оригинального запроса.

Если отправитель желает сформировать новые запросы, получив на предшествующий запрос перенаправляющий ответ класса Зхх, он помещает новые адреса в target set. UAC может выбрать, какие из URI, расположенных в поле Contact, поместить в target set. Клиент, обрабатывающий ответы класса Зхх, не должен добавлять один и тот же URI в target set более одного раза. Если оригинальный запрос содержит SIPS URI в Request-URI, клиент может перенаправить запрос на не-SIPS URI, но должен информировать пользователя о перенаправлении запроса на небезопасный URI.

По мере того как target set растет, UAC может генерировать новые запросы, используя адреса, выбранные из target set в любом порядке. Простейшим механизмом для этого является упорядочение в соответствии со значением параметра «q» каждого значения заголовка Contact. Параметр «q» определяет приоритеты среди адресов, содержащихся в заголовке Contact, путем варьирования их значения в пределах от 0 до 1. Запросы могут генерироваться последовательно или параллельно. Один подход состоит в обработке групп в порядке уменьшения значения параметра «q» последовательно и обработке адресов в каждой группе с определенным значением параметра «q» параллельно. Другой подход предусматривает последовательную обработку в порядке уменьшения значения параметра «q», произвольно выбирая адреса с одинаковым значением q. Если при обращении на контактный адрес из списка приходит ответ об ошибке, SIP-элемент переходит к следующему адресу в списке. Когда список заканчивается, запрос отбрасывается. Ошибки определяются по кодам ответов (коды со значением более 399). Об ошибках, произошедших при передаче по сети (ошибках транспортного уровня), пользователю транзакций (TU) сообщает клиентская транзакция. Некоторые коды ответов показывают, что запрос может быть передан снова; такие ответы не должны расцениваться как ошибки. Когда приходит ответ об ошибке при обращении на определенный контактный адрес, клиент должен попытаться передать запрос на следующий контактный адрес. Это повлечет за собой создание новой клиентской транзакции.

Для того чтобы создать запрос на основании контактного адреса, полученного в ответе класса Зхх, UAC должен полностью скопировать URI из списка адресов target set в Request-URI, за исключением параметров «method-param» и «header». Параметры «header» используются для создания значений полей заголовков новых запросов, заменяя значения, связанные с перенаправленным запросом.

В некоторых случаях в контактном адресе (адресе, содержащемся в заголовке Contact) указываются другие заголовки. Значения этих заголовков могут быть добавлены к значениям заголовков в оригинальном перенаправленном запросе. Как правило, если поле заголовка может принимать разделенный запятыми список значений параметров, то новое значение поля заголовка может быть добавлено к любым существующим значениям оригинального перенаправленного запроса. Если же поле заголовка не поддерживает множественность значений, то значение в оригинальном перенаправленном запросе может быть заменено значением из контактного адреса. Например, если контактный адрес возвращен со следующим значением:

sip: This e-mail address is being protected from spambots, you need JavaScript enabled to view it ?Subject=organization&Call-Info=http://www.bamlex.com,

то любое поле заголовка Subject в оригинальном перенаправленном запросе заменяется, но HTTP URL просто добавляется к существующим значениям поля заголовка Call-Info.

Рекомендуется, чтобы UAC использовал поля заголовков То, From и Call-ID, применявшиеся в перенаправленном запросе, но UAC, например, может обновить значение поля заголовка Call-ID для новых запросов. В результате, сформированный новый запрос отправляется с использованием новой клиентской транзакции и, следовательно, он будет иметь новое значение параметра «branch» в верхнем поле Via. В остальном, запросы, отправленные при получении ответа перенаправления, будут иметь те же поля заголовков и тела сообщения, что и оригинальный запрос. В некоторых случаях значения поля заголовка Contact могут запоминаться клиентом временно или постоянно в зависимости от кода ответа и присутствия информации о истечении времени действия.