|
Written by Hemanshu Patel
|
|
Thursday, 08 November 2007 |
|
Page 7 of 16
The URI a proxy places into a Record-Route header field is only
valid for the lifetime of any dialog created by the transaction
in which it occurs. A dialog-stateful proxy, for example, MAY
refuse to accept future requests with that value in the
Request-URI after the dialog has terminated. Non-dialog-
stateful proxies, of course, have no concept of when the dialog
has terminated, but they MAY encode enough information in the
value to compare it against the dialog identifier of future
requests and MAY reject requests not matching that information.
Endpoints MUST NOT use a URI obtained from a Record-Route
header field outside the dialog in which it was provided. See
Section 12 for more information on an endpoint's use of
Record-Route header fields.
Record-routing may be required by certain services where the
proxy needs to observe all messages in a dialog. However, it
slows down processing and impairs scalability and thus proxies
should only record-route if required for a particular service.
The Record-Route process is designed to work for any SIP
request that initiates a dialog. INVITE is the only such
request in this specification, but extensions to the protocol
MAY define others.
5. Add Additional Header Fields
The proxy MAY add any other appropriate header fields to the
copy at this point.
6. Postprocess routing information
A proxy MAY have a local policy that mandates that a request
visit a specific set of proxies before being delivered to the
destination. A proxy MUST ensure that all such proxies are
loose routers. Generally, this can only be known with
certainty if the proxies are within the same administrative
domain. This set of proxies is represented by a set of URIs
(each of which contains the lr parameter). This set MUST be
pushed into the Route header field of the copy ahead of any
existing values, if present. If the Route header field is
absent, it MUST be added, containing that list of URIs.
If the proxy has a local policy that mandates that the request
visit one specific proxy, an alternative to pushing a Route
value into the Route header field is to bypass the forwarding
logic of item 10 below, and instead just send the request to
the address, port, and transport for that specific proxy. If
the request has a Route header field, this alternative MUST NOT
be used unless it is known that next hop proxy is a loose
router. Otherwise, this approach MAY be used, but the Route
insertion mechanism above is preferred for its robustness,
flexibility, generality and consistency of operation.
Furthermore, if the Request-URI contains a SIPS URI, TLS MUST
be used to communicate with that proxy.
If the copy contains a Route header field, the proxy MUST
inspect the URI in its first value. If that URI does not
contain an lr parameter, the proxy MUST modify the copy as
follows:
- The proxy MUST place the Request-URI into the Route header
field as the last value.
- The proxy MUST then place the first Route header field value
into the Request-URI and remove that value from the Route
header field.
Appending the Request-URI to the Route header field is part of
a mechanism used to pass the information in that Request-URI
through strict-routing elements. "Popping" the first Route
header field value into the Request-URI formats the message the
way a strict-routing element expects to receive it (with its
own URI in the Request-URI and the next location to visit in
the first Route header field value).
7. Determine Next-Hop Address, Port, and Transport
The proxy MAY have a local policy to send the request to a
specific IP address, port, and transport, independent of the
values of the Route and Request-URI. Such a policy MUST NOT be
used if the proxy is not certain that the IP address, port, and
transport correspond to a server that is a loose router.
However, this mechanism for sending the request through a
specific next hop is NOT RECOMMENDED; instead a Route header
field should be used for that purpose as described above.
In the absence of such an overriding mechanism, the proxy
applies the procedures listed in [4] as follows to determine
where to send the request. If the proxy has reformatted the
request to send to a strict-routing element as described in
step 6 above, the proxy MUST apply those procedures to the
Request-URI of the request. Otherwise, the proxy MUST apply
the procedures to the first value in the Route header field, if
present, else the Request-URI. The procedures will produce an
ordered set of (address, port, transport) tuples.
Independently of which URI is being used as input to the
procedures of [4], if the Request-URI specifies a SIPS
resource, the proxy MUST follow the procedures of [4] as if the
input URI were a SIPS URI.
As described in [4], the proxy MUST attempt to deliver the
message to the first tuple in that set, and proceed through the
set in order until the delivery attempt succeeds.
For each tuple attempted, the proxy MUST format the message as
appropriate for the tuple and send the request using a new
client transaction as detailed in steps 8 through 10.
Since each attempt uses a new client transaction, it represents
a new branch. Thus, the branch parameter provided with the Via
header field inserted in step 8 MUST be different for each
attempt.
If the client transaction reports failure to send the request
or a timeout from its state machine, the proxy continues to the
next address in that ordered set. If the ordered set is
exhausted, the request cannot be forwarded to this element in
the target set. The proxy does not need to place anything in
the response context, but otherwise acts as if this element of
the target set returned a 408 (Request Timeout) final response.
|
|
Last Updated ( Thursday, 08 November 2007 )
|
|
| |
|
|
