Embedded Routes in Redirect Responses
When the Oracle® Enterprise Session Border Controller recurses as the result of a redirect (3xx) response, the server might need to specify one or more intermediate hops. These hops are reflected in the Contact header for the 3xx response using embedded route headers and look like this:
Contact: <sip:touser@server.example.com?Route=%3Cproxy.example.com%Blr%3E>
The Contact header shows that the request should be sent to server.example.com using proxy.example.com.
You can configure your Oracle® Enterprise Session Border Controller to specify that embedded headers in 3xx Contact headers are to be included in new requests such that they are tied to a session agent representing the new target (server.example.com). This behavior requires you to set the request-uri-headers parameter.
However, you can also use the use-redirect-route in global SIP configuration’s options parameter so that the embedded Route header is used as the next hop to receive the new request.
When you configure this new option, the Oracle® Enterprise Session Border Controller constructs a new request using the redirect Contact, and the SIP URI from the Contact becomes the Request-URI. Then, the system inserts the embedded routes as Route headers in the, using the same order in which they appeared in the redirect Contact. Afterward, the Oracle® Enterprise Session Border Controller determines the next hop in the same way it does with any other request. If the first route is a loose route (i.e., it has the lr URI parameter), then the Oracle® Enterprise Session Border Controller sends a request to host indicated in the first route. Otherwise, strict routing applies, and the Oracle® Enterprise Session Border Controller sends the request to the host indicated in the Request-URI.
