SIP Extension for Registering Non-Adjacent Contacts
dynamicsoft Inc.
5100 Tennyson ParkwaySuite 1200PlanoTX75028US+1 972 473 5455dwillis@dynamicsoft.comhttp://www.dynamicsoft.com/
Transport
SIP -- Session Initiation Protocol Working GroupSIPPathREGISTERContactThe REGISTER function is used in a SIP system primarily to
associate a temporary contact address with an
address-of-record. This contact is generally in the form of a
URI, such as Contact: <sip:alice@pc33.atlanta.com> and is
generally dynamic and associated with the IP address or hostname
of the SIP UA. The problem is that network topology may be that
there are one or more SIP proxies between the UA and the
registrar, such that any message from the user's home network to
the registered UA must traverse these proxies. The REGISTER
method does not give us a mechanism to discover and record this
sequence of proxies in the registrar for future use. This
document defines an extension header, "Path" which provides such
a mechanism.3GPP established a requirement for discovering intermediate
proxies during SIP registration and published this requirement in
[3GPPReq].
Scenario:UA----P1-----P2-----P3------REGISTRARUA wishes to register with REGISTRAR. However, due to network
topology, UA must use P1 as an "outbound proxy", and all messages
between UA1 and REGISTRAR must also traverse P1, P2, and P3 before
reaching REGISTRAR. Likewise, all messages between REGISTRAR UA
must also traverse P1, P2, and P3 before reaching UA.UA has a standing relationship with REGISTRAR, which it
considers its "Home"". How UA establishes this relationship is
outside the scope of this document. UA discovers P1 as a result of
a DHCP assignment or similar operation, also outside the scope of
this document. REGISTRAR has a similar "default outbound proxy"
relationship with P3.Eventually, REGISTRAR or a service proxy closely related to it
will receive a message for UA. It needs to know which proxies must
be transited by that message in order to get back to UA. In some
cases, this information may be deducible from SIP routing
configuration tables or from DNS entries. In other cases, such as
that raised by 3GPP, the information is not readily available
outside of the SIP REGISTER transaction.The proposed Path extension header allows accumulating and
transmitting the list of proxies between UA and REGISTRAR.
Intermediate nodes such as P1 may statefully retain Path
information if needed by operational policy. This mechanism is in
many ways similar to the operation of Record-Route in
dialog-initiating messages.The Path mechanism is applicable whenever there are intermediate
proxies between a SIP UA and a SIP Registrar used by that UA where the
following conditions are true:One or more of the intermediate proxies MUST be visited by
messages between REGISTRAR and UA.The same set of intervening proxies MUST be visited by
messages between a home service proxy and UA. That is, the proxy
route between the UA and its home service proxy is identical to
the proxy route between the UA and its registrar.The network topology is such that the intermediate proxies which
must be visited are NOT implied by SIP routing tables, DNS, or
similar mechanisms.The Path header is a SIP extension header with syntax very
similar to the Record-Route header. It is used in conjunction with
SIP REGISTER messages and with 200 OK messages in response to
REGISTER (a REGISTER response).A Path header may be inserted into a REGISTER by any SIP node
traversed by that message. Like the Route header, sequential Path
headers are evaluated in the sequence in which they are present in
the message, and Path header values may be combined into compound
Path elements in a single Path header. The registrar reflects the
accumulated Path back into the REGISTER response, and intermediate
nodes propagate this back toward the originating UA. The
originating UA is therefore informed of the inclusion of nodes on
its registered Path, and MAY use that information in other
capacities outside the scope of this document.The primary difference between Path and Record-Route is that
Path applies to REGISTER and 200 OK responses to REGISTER. Record-Route
doesn't, and can't be defined in REGISTER for reasons of backward
compatibility.The syntax for Path can be given as:Path = "Path" HCOLON path-value *( COMMA path-value )path-value = name-addr *( SEMI rr-param )The allowable usage of headers is described in Table 2 of . The following additions to this table are
needed for Path. The UA executes its register operation as usual. The response
may contain a Path header. The general operation of the UA is to
ignore the Path header in the response. It MAY choose to display the
contents of the Path header to the user or take other action outside
the scope of this document.It has been suggested that the UA MAY choose to store the
contents of the Path header for future use as a preloaded Route for
use when the UA wishes to send a SIP message that, for reasons of
acquiring services in the home network, need to transit the service
proxies in the home network. Such usage is explicitly outside the
scope of this document.When a proxy processing a REGISTER request wishes to be on the
path for future transmissions toward the UA originating that
REGISTER request, the proxy inserts a URI for that proxy as the
topmost element in the Path header (or inserts a new topmost Path
header) before proxying that request. It is also possible for a
proxy with specific knowledge of network topology to add a Path
element referencing another node, thereby allowing construction of a
Path which is discongruent with the route taken by the REGISTER
request. Such a construction is implementation specific and outside
the scope of this document.If a Path header exists in a successful REGISTER request, the
registrar constructs an ordered list of route elements from the
nodes listed in the Path elements, preserving the order as indicated
in the Path header(s). The registrar then stores this route set in
association with that contact and the addres-of-record indicated in
the Register request (the "binding" as defined in RFC 2543). The registrar copies the Path
elements list as one or more Path headers into into the successful
(200 OK) REGISTER response message.In the common SIP model, there is a home service proxy associated
with the registrar for a user. Each incoming message targeted to the
public address-of-record for the user is routed to this proxy, which
consults the registrar's database in order to determine the contact
to which the message should be retargeted. The home service proxy,
in its basic mode of operation, rewrites the request-URI from the
incoming message with the value of the registered contact and
retransmits the message.With the addition of Path, the home service proxy also copies the
route set associated with the specific contact in the registrar
database into the Route header(s) of the outgoing message as a
preloaded route. This causes the outgoing message to transit the set
of proxies that indicated that they were to be used in future
messages to that contact by including themselves in the Path header
on the REGISTER message.As an example, we use the scenario from the Background section:UA----P1-----P2----P3-----REGISTRARUA sends a REGISTER message to REGISTRAR. This message transits
its default outbound proxy P1, an intermediate proxy P2, and the
firewall proxy for the home domain, P3, before reaching
REGISTRAR. Due to network topology and operational policy, P1 and
and P3 need to be transited by messages from REGISTRAR or other nodes
in the home network targeted to UA. P2 does not. P1 and P3 have been
configured to include themselves in Path headers on REGISTER
messages that they process.There are few security considerations for this draft beyond those
in SIP . From a security
perspective, the Path extension and its usage are identical to the
Record-Route header of basic SIP. Note that the transparency of the
user expectations are preserved by returning the final Path to the
originating UA -- that is, the UA is informed which additional
proxies have been inserted into the path for the registration
associated with that response.This document defines the SIP extension header name "Path", which
IANA will add to the registry of SIP header names defined in Min Huang and Stinson Mathai, who put together the original
proposal in 3GPP for this mechanism, and worked out most of the 3GPP
procedures in 24.229.Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin who
argued with everybody a lot about the idea as well as helped refine
the requirements.Juha Heinanen, who argued steadfastly against standardizing the
function of discovering the home service proxy with this technique
in this document.SIP: Session Initiation Protocol
draft-ietf-sip-rfc2543bis-09.txtdynamicsoft Inc.3GPP requirements On SIP,
draft-garcia-sipping-3GPPRequirements.txt