|
Written by Hemanshu Patel
|
|
Thursday, 08 November 2007 |
|
Page 11 of 16
8. Record-Route
If the selected response contains a Record-Route header field
value originally provided by this proxy, the proxy MAY choose
to rewrite the value before forwarding the response. This
allows the proxy to provide different URIs for itself to the
next upstream and downstream elements. A proxy may choose to
use this mechanism for any reason. For instance, it is useful
for multi-homed hosts.
If the proxy received the request over TLS, and sent it out
over a non-TLS connection, the proxy MUST rewrite the URI in
the Record-Route header field to be a SIPS URI. If the proxy
received the request over a non-TLS connection, and sent it out
over TLS, the proxy MUST rewrite the URI in the Record-Route
header field to be a SIP URI.
The new URI provided by the proxy MUST satisfy the same
constraints on URIs placed in Record-Route header fields in
requests (see Step 4 of Section 16.6) with the following
modifications:
The URI SHOULD NOT contain the transport parameter unless the
proxy has knowledge that the next upstream (as opposed to
downstream) element that will be in the path of subsequent
requests supports that transport.
When a proxy does decide to modify the Record-Route header
field in the response, one of the operations it performs is
locating the Record-Route value that it had inserted. If the
request spiraled, and the proxy inserted a Record-Route value
in each iteration of the spiral, locating the correct value in
the response (which must be the proper iteration in the reverse
direction) is tricky. The rules above recommend that a proxy
wishing to rewrite Record-Route header field values insert
sufficiently distinct URIs into the Record-Route header field
so that the right one may be selected for rewriting. A
RECOMMENDED mechanism to achieve this is for the proxy to
append a unique identifier for the proxy instance to the user
portion of the URI.
When the response arrives, the proxy modifies the first
Record-Route whose identifier matches the proxy instance. The
modification results in a URI without this piece of data
appended to the user portion of the URI. Upon the next
iteration, the same algorithm (find the topmost Record-Route
header field value with the parameter) will correctly extract
the next Record-Route header field value inserted by that
proxy.
Not every response to a request to which a proxy adds a
Record-Route header field value will contain a Record-Route
header field. If the response does contain a Record-Route
header field, it will contain the value the proxy added.
9. Forward response
After performing the processing described in steps "Aggregate
Authorization Header Field Values" through "Record-Route", the
proxy MAY perform any feature specific manipulations on the
selected response. The proxy MUST NOT add to, modify, or
remove the message body. Unless otherwise specified, the proxy
MUST NOT remove any header field values other than the Via
header field value discussed in Section 16.7 Item 3. In
particular, the proxy MUST NOT remove any "received" parameter
it may have added to the next Via header field value while
processing the request associated with this response. The
proxy MUST pass the response to the server transaction
associated with the response context. This will result in the
response being sent to the location now indicated in the
topmost Via header field value. If the server transaction is
no longer available to handle the transmission, the element
MUST forward the response statelessly by sending it to the
server transport. The server transaction might indicate
failure to send the response or signal a timeout in its state
machine. These errors would be logged for diagnostic purposes
as appropriate, but the protocol requires no remedial action
from the proxy.
The proxy MUST maintain the response context until all of its
associated transactions have been terminated, even after
forwarding a final response.
10. Generate CANCELs
If the forwarded response was a final response, the proxy MUST
generate a CANCEL request for all pending client transactions
associated with this response context. A proxy SHOULD also
generate a CANCEL request for all pending client transactions
associated with this response context when it receives a 6xx
response. A pending client transaction is one that has
received a provisional response, but no final response (it is
in the proceeding state) and has not had an associated CANCEL
generated for it. Generating CANCEL requests is described in
Section 9.1.
The requirement to CANCEL pending client transactions upon
forwarding a final response does not guarantee that an endpoint
will not receive multiple 200 (OK) responses to an INVITE. 200
(OK) responses on more than one branch may be generated before
the CANCEL requests can be sent and processed. Further, it is
reasonable to expect that a future extension may override this
requirement to issue CANCEL requests.
|
|
Last Updated ( Thursday, 08 November 2007 )
|
