Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
updated by
- rfc-5630 — The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
Extracted elements (25)
Dual-homed proxies are advised to record two route values (one per interface) rather than following the RFC 3261 single-value record-routing procedure, because the standard procedure causes the route vector seen at the UAS to differ from the inverse of the route vector seen at the UAC, which complicates use of the recorded route vector in constructing service routes.
Intermediate proxies are explicitly prohibited from adding themselves to the Service-Route in REGISTER responses for two reasons: transparency (the registrar would not know about such additions) and end-to-end security (if the registrar uses S/MIME to protect the response, such additions would appear to the UA as man-in-the-middle alterations).
This document chose to return service route information as a header field value in the REGISTER response (option 6 of 6 considered) rather than UA configuration, HTTP-based configuration, lookup tables, 302 redirects, or record-routing during REGISTER. The header field approach grants the registrar the ability to selectively apply knowledge about home network topology in constructing the service route, which record-routing during REGISTER does not allow.
A UA that has lost its stored Service-Route value may perform a Fetching Bindings REGISTER (no Contact header) to recover it; alternatively, the UA may simply re-REGISTER.
Service-Route is treated like any other unknown header field by intermediate proxies: they forward it toward the destination. Proxies should not assume they will be traversed by future requests in a dialog simply because they appear in the Service-Route header field.
The Service-Route mechanism is only applicable when: (1) the UA registers with a registrar, (2) the registrar has knowledge of a service proxy for the UA, (3) the registrar has sufficient knowledge of the topology to construct a reasonable service route, and (4) the service route is the same for all contacts of a single AOR — it does not provide contact-specific service routes.
A REGISTER operation performing a Fetching Bindings (no Contact header field present) SHOULD return the same value of Service-Route as returned in the corresponding previous REGISTER response for the address-of-record in question.
Dual-homed proxies inserting Record-Route or Path header field values SHOULD record not one but two route values when processing the request: the first indicating the receiving interface, and the second indicating the sending interface. No modification of the recorded route is needed when processing the response.
If the UA refreshes the registration, the stored Service-Route is updated from the latest 200-class response; if there is no Service-Route in the response, the UA clears any previously stored service route for that address-of-record. If re-registration is refused or the registration expires and the UA chooses not to re-register, the UA SHOULD discard any stored service route.
Intermediate proxies SHOULD NOT alter the value of Service-Route in REGISTER responses. If they do alter it, the UA MUST NOT be required to accept the alteration.
Registrars returning a Service-Route MUST implement end-to-end protection using S/MIME and SHOULD use S/MIME to protect all such responses. UAs receiving Service-Route SHOULD authenticate attached S/MIME bodies if present.
Service-Route elements inserted by the registrar MUST conform to the syntax of a Route element as defined in RFC 3261, and such route elements MUST include the loose-routing indicator parameter ";lr".
Service-Route header field values MUST conform to the syntax of a Route element as defined in RFC 3261, and such values MUST include the loose-routing indicator parameter ";lr" for full compliance.
Systems using Service-Route SHOULD provide hop-by-hop message integrity and mutual authentication. UAs SHOULD request this support by using a "sips:" URI.
The combination of the service route set with any locally configured route MUST provide valid routing in the local environment; in general, the service route set is appended to any locally configured route needed to egress the access proxy chain.
The UA MUST preserve the order of Service-Route header field values when using them as a preloaded Route header in outgoing requests, in case there is more than one Service-Route header field or header field value.
The registrar MAY return more than one Service-Route header field or element in the 200-class response to handle network topologies requiring traversal of multiple proxies (e.g., a firewall proxy before the home service proxy). The order is top-down, meaning the topmost entry is visited first.
The Service-Route header field generally contains references to elements strictly within the administrative domain of the registrar and home service proxy. When a UA roams into a visited network, the registrar's Service-Route contains only home network elements, as the registrar cannot be assumed to have knowledge of the visited network topology.
The Service-Route header field is a SIP extension header returned by a registrar in responses to REGISTER requests. It carries a route vector (preloaded route) that a UA may use to direct future outbound requests through a specific sequence of service proxies associated with the registrar's domain.
The Service-Route header field is only valid in 200-class responses to REGISTER requests (table entry: where=2xx, methods: REG=optional). It has no compact form.
The Service-Route mechanism applies only to UA-originated (outbound) requests, not to requests terminated by that UA. The routing established affects only requests the UA originates, enabling outbound service via a home service proxy.
The UA stores the Service-Route in association with the address-of-record for which the REGISTER was performed. If the UA supports multiple addresses-of-record, it may store multiple service routes, one per address-of-record.
This document registers the "Service-Route" SIP extension header field in the IANA registry of SIP header fields defined in RFC 3261. RFC Number: RFC 3608; Header Field Name: Service-Route; Compact Form: none.
Proxies between the UA and the registrar during a REGISTER transaction may modify or insert a Service-Route header field. The consequence is that future requests from the UA using the service route may be diverted to or through an unintended node. Transitive mutual authentication using "sips:" or S/MIME bodies should be applied to prevent such attacks.
Service-Route is encoded as: `Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)` where `sr-value = name-addr *( SEMI rr-param )`. Values must conform to Route element syntax and must include the loose-routing indicator parameter ";lr".