Addressing and Routing of Requests in SIP

The problems surrounding "request URI rewriting" are common and are likely to become more intense. In the PSTN, there are a small number of fairly well-controlled ways that calls can be forwarded, routed, and redirected. SIP is more flexible, allowing nearly arbitrary address manipulation by all SIP agents. Quite a number of different rewriting operations are present in the small-to-medium organization PBX system that the author's company produces, and we can expect that as people become more familiar with the possibilities, rewriting will become as routinely complex as e-mail forwarding is now. For example, a recent message to the IETF SIP mailing list contained the following Received headers:

; Thu, 10 Jan 2008 10:10:05 -0500 Received: from mail.g.comcast.net [216.148.227.80] by localhost with POP3 (fetchmail-6.2.0) for worley@localhost (single-drop); Thu, 10 Jan 2008 10:10:05 -0500 (EST) Received: from imta21.emeryville.ca.mail.comcast.net ([76.96.30.31]) by sccrmxc16.comcast.net (sccrmxc16) with ESMTP id <20080110150359s1600jigc6e>; Thu, 10 Jan 2008 15:03:59 +0000 Received: from megatron.ietf.org ([156.154.16.145]) by IMTA21.emeryville.ca.mail.comcast.net with comcast id bT3y1Y00d37nXEc0M00000; Thu, 10 Jan 2008 15:03:59 +0000 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCywW-0008B8-3E; Thu, 10 Jan 2008 10:03:40 -0500 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCywV-0008B1-40 for sip-confirm+ok@megatron.ietf.org; Thu, 10 Jan 2008 10:03:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCywU-0008As-QR for sip@ietf.org; Thu, 10 Jan 2008 10:03:38 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCywT-0000Gu-Vl for sip@ietf.org; Thu, 10 Jan 2008 10:03:38 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2008 10:03:38 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m0AF3bXs026778; Thu, 10 Jan 2008 10:03:37 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m0AF3apm000195; Thu, 10 Jan 2008 15:03:37 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:03:31 -0500 Received: from [161.44.174.128] ([161.44.174.128]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:03:31 -0500 ]]> That is 13 routing decisions that were considered important enough by the SMTP agents to log the decision.

Jonathan's "UA Loose Routing I-D provides a number of use cases or problems to be solved. Many of these cases are fundamentally the same, so we here divide them into groups.

In a number of situations, the UA that receives a request requires more information about how the request was addressed to itself than is provided by the request-URI. (Or more than can be easily represented in the request-URI by present techniques.)

A number of situations are forms of subaddressing, where an "authority" issues an AOR to a user or user agent, which in turn wants to create a series of "subaddresses". The subaddresses are required to all route to the user agent, but the user agent desires to be able to determine which subaddress was used in the original request. (We assume that the authority prescribes the method by which the subaddresses are constructed from the AOR, but that the authority has no knowledge of which specific subaddresses have been constructed prior to their appearance in a request to be routed.)

To quote from : A key requirement of systems supporting emergency calling is that the SIP INVITE request for an emergency call be 'marked' in some way that makes it clear that it is an emergency call, so that it can receive priority treatment [7]. However, such a marking needs to be done in a way that it cannot be abused by attackers seeking to get special treatment for non- emergency calls. The solution for this is that the marking needs to be the target address of the request itself, which would unambiguously identify an emergency services call taker as the target.

For a considerable time, many parties have proposed that the operations which currently just rewrite the request-URI (which we generically call "rewrites") be divided into two classes. One class, "routing", is conceived as not altering the the fundamental identity of the target of the request, but only adding information as to how to reach the target. The prototypical example is when a request to an AOR is routed to the AOR's contact address. The other class, "redirection", is conceived as changing the identity of the specified target. A typical example is "call forwarding", where all requests to a particular AOR are directed to another AOR. Through the history of a request from its UAC to its UAS, it bears a number of different request-URIs, the "sequence of rewrites". The above distinction privileges a subset of these rewrites, the request-URIs inserted by "redirections", as being of particular significance (which they are).

The proposal of is essentially that a request should bear as its request-URI the last redirection URI in its history, on the assertion that URI contains the most useful information about the addressing of the request. Rewrites after the last redirection (which are necessarily routings) would be carried in Route headers. This mechanism requires no changes to the procedures of RFC 3261 as long as any SIP agents which would see the request after these Route headers are removed understand this new mechanism. (The SIP agents in question are the ultimate UAS for the request, and any intermediarey proxies which should perform routing or redirection.)

Security issues have not been considered.

First version.