Заключительная обработка маршрутной информации |
|
Прокси-сервер может вести внутреннюю политику, которая предусматривает, чтобы запрос прошел через группу прокси-серверов перед тем, как быть доставленным к месту назначения. Прокси-сервер должен гарантировать, что все эти серверы придерживаются стандартных процедур обработки заголовка Route, предусматривающих разделение места назначения запроса (содержащееся в Request-URI) и списка прокси-серверов на пути к месту назначения (содержащийся в заголовке Route). Это может быть достоверно известно, только еслипрокси-серверы находятся водном административном домене. Список прокси-серверов представлен перечнем URI, каждый из которых содержит параметр «Ir». Перечень URI должен быть помещен в заголовок Route копии над существующими значениями (в случае их присутствия). Если заголовок Route отсутствует, он должен быть добавлен с содержащимся в нем перечнем URI. Если прокси-сервер ведет внутреннюю политику, которая предписывает, чтобы запрос прошел через один определенный прокси-сервер, альтернативным вариантом помещения значения в заголовок Route является обход логики пересылки путем лишь передачи запроса на адрес, порт и по транспортному протоколу определенному прокси-серверу. Если запрос уже содержит заголовок Route, этот альтернативный вариант может быть использован, только если известно, что следующий прокси-сервер придерживается стандартных процедур обработки заголовка Route, как описано выше. Однако механизм введения значений в заголовок Route предпочтительнее данного подхода из-за своей надежности, гибкости, универсальности и последовательности действия. Более того, если поле Request-URI содержит SIPS URI, при взаимодействии с этим прокси-сервером должен быть использован протокол TLS. Если копия содержит заголовок Route, прокси-сервер должен проанализировать URI в его первом значении. Если он не содержит параметр «Ir», прокси-сервер модифицирует копию следующим образом:
|
