The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes(the tel URL, for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. (RFC3261 P36)
Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Frequently, the user will not enter a complete URI, but rather a string of digits or letters(for example, "bob"). It is at the descretion of the UA to choose how to interpret this input. Using the string to form the user part of a SIP URI implies that the UA wishes ther name to be resolved in the domain to the right-hand side(RHS) of the at-sign in the SIP URI(for instance, sip:bog@example.com). The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like "speed dial" that require interpretation of the user part in the home domain. (RFC3261 P36)
The To header field specifies the logical recipient of the request. The optional "display-name" is meant to be rendered by a human-user interface. The "tag" parameter serves as a gerneral mechanism for dialog identification.
Request-URI
Request-URI
(RFC3261 P35)The initial Request-URI of the message SHOULD be set to the value of the URI in the To field.One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is:
(RFC3261 P57)the Request-URI names the domain of the location service for which the registration is meant (for example, "sip:chicago.com"). The "userinfo" and "@" components of the SIP URI MUST NOT be present.
(RFC3261 P35) In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, the are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field is:
(RFC3261 P74)The UAC uses the remote target and route set to build the Request-URI and Route header field of the request.
(RFC3261 P74)If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the reuqest.
(RFC3261 P74)If the route set is not empty, and the first URI in the route set contains the lr parameter, the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters.
(RFC3261 P74)If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into Route header field as the last value.
The To field is never used for routing - Request-URI is used for this purpose.
Record-Route/Route
Record-Route
The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy.
Route
The Route header field is used to force routing for a request through the listed set of proxies.
SIP Routing
The proxy is used for routing messages within a SIP network. The following items only work for stateful proxy.
Loose Routing
The lr parameter indicates that loose routing is being used. When loose routing is being used, the request-URI remains constant(instead of changing for each hop). The TO and FROM headers never change either, regardless of the routing method used. The two headers are never used for routing in the SIP network.
The VIA header is appended by each proxy as the message is routed through the network. The purpose of the VIA header is loop detection. If a proxy finds its own address in the VIA header, it then knows that this message has already been processed, and the message is looping around the network. Stric routing uses additional headers for recording a route(record-route).
Routing responsibility for the message is left to each proxy along the route. Any single router is only responsible, however, for its leg of the path, and not end-to-end routing.
Strict Routing
Strict routing relies on a route list for each subscriber. The route list is created during registration. As the REGISTER message is routed through the network, each proxy will append the message with its own address using the RECORD-ROUTE header. The headers are added to the message in order so that the path can be established.
The route recorded when registering a location is stored at the registar and becomes a part of the subsciber's registration record. This route list is then shared with any stateful proxy. The route is shared though the use of ROUTE headers in the messages. The ROUTE messages are added to each request either by the UAC or by a stateful proxy.
For example, some stateful proxies/UAS might save the RECORD-ROUTE headers as a route list for the subscriber for the duration of the session. When the UAC has received all of the responses for a request, it then converts the RECORD-ROUTE headers into a ROUTE header(or headers) for subsequent requests. For example, the ACK would use ROUTE header.
When routing a SIP request, the request-URI will identify the next hop in the network, employing the route list established for a particular subscriber. It should be noted that the TO and FROM headers are never used for routing purposes. In fact, the network ignores these headers completely. The are only for the consumption by applications and use displays(such as calling name dispalys).
