Прокси-сервер определяет адреса для дальнейшей передачи запроса. Перечень адресов (target set) для запроса будет либо назначен в содержимом запроса, либо получен при обращении к серверу определения местоположения.

Если Request-URI в запросе содержит параметр «maddr», Request-URI должен быть помещен в перечень, как единственный адрес, и прокси-сервер должен перейти к выполнению функции пересылки запроса. Если домен в Request-URI является доменом, за который данный прокси-сервер не несет ответственности, выполняются аналогичные действия. Существует множество условий, при которых прокси-сервер может получить запрос для пользователя, находящегося в домене, который обслуживается другим прокси-сервером. Прокси-сервер с функциями брандмауэра, поддерживающий исходящие вызовы (равно как и прокси-сервер HTTP, поддерживающий исходящие запросы), - один из примеров, когда это может произойти.

Если перечень адресов не был назначен, это подразумевает, что данный элемент ответственен за домен, указанный в Request-URI, и элемент может использовать любой механизм для того, чтобы определить, куда переслать запрос. Любой из этих механизмов базируется на обращении к серверу определения местоположения. Механизм может предусматривать получение информации от сервера определения местоположения, просмотр базы данных, обращение к серверу присутствия (presence server), использование других протоколов, или просто выполнение алгоритмической подстановки Request-URI. При обращении к серверу определения местоположения Request-URI должен быть сперва приведен к каноническому виду для дальнейшего поиска в базе данных. Результат действия механизмов используется для формирования перечня адресов (target set). Если Request-URI не обеспечивает достаточной информации для того, чтобы определить перечень адресов, прокси-сервер передает ответ с кодом 485 (Ambiguous). Ответ должен содержать заголовок, содержащий URI новых адресов для следующих попыток. Например, запрос INVITE, адресованный на sip: This e-mail address is being protected from spambots, you need JavaScript enabled to view it , может быть неясным прокси-серверу, поскольку в базе данных услуги определения местоположения присутствует несколько адресов с именем пользователя Vladimir.

При формировании перечня адресов может использоваться информация о запросе, или содержащаяся в запросе, или сведения о текущем окружении прокси-сервера. Например, различные перечни адресов могут быть созданы в зависимости от содержимого или присутствия заголовков и тел сообщения, от времени поступления запроса, от интерфейса, на который пришел запрос, от ошибки предыдущего запроса и даже от текущего уровня загруженности прокси-сервера. Если перечисленные причины каким-либо образом обуславливают наличие определенных адресов, то эти адреса добавляются в перечень. URI могут быть помещены в перечень единожды.

Прокси-сервер не должен помещать в перечень дополнительные URI, если Request-URI оригинального запроса указывает ресурс, который обслуживается другим прокси-сервером. Прокси-сервер может изменить Request-URI запроса в процессе пересылки только тогда, когда он обслуживает домен, указанный в Request-URI. В противном случае прокси-сервер не будет добавлять в перечень контактные адреса из ответов класса Зхх или ответов с кодом 416, как это описано ниже.

Если Request-URI оригинального запроса указывает ресурс, за который данный элемент ответственен, прокси-сервер может продолжать добавлять адреса в перечень в процессе пересылки запроса. Для определения новых адресов, он может использовать любую информацию, полученную при обработке. Например, прокси-сервер может добавлять в перечень адресов контактные адреса, полученные в ответе перенаправления класса Зхх. Если прокси-сервер во время создания перечня адресов (к примеру, если он обращается к SIP-серверу регистрации) использует динамический источник информации, он должен следить за изменениями з источнике на протяжении всего времени обработки запроса. Поэтому, как только У пользователя появится новый контактный адрес, он сразу должен быть включенв перечень адресов.

Если поле Request-URI указывает ресурс на прокси-сервере, которого не существует, он должен передать ответ с кодом 404 (Not Found). Если после проведения вышеперечисленных операций перечень адресов остается пуст, прокси-сервер должен передать ответ с кодом ошибки 480 (Temporarily Unavailable).