SIP -- Session Initiation Protocol D. Willis
Working Group dynamicsoft Inc.
Internet-Draft April 12, 2002
Expires: October 11, 2002
SIP Extension for Registering Non-Adjacent Contacts
draft-willis-sip-path-03
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 11, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The 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
Willis Expires October 11, 2002 [Page 1]
Internet-Draft Path Extension Header for SIP April 2002
provides such a mechanism.
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
3. Path Header Definition and Syntax . . . . . . . . . . . . . . 4
4. Usage of Path Header . . . . . . . . . . . . . . . . . . . . . 5
4.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . . 5
4.2 Procedures at Intermediate Proxies . . . . . . . . . . . . . . 5
4.3 Procedures at the Registrar . . . . . . . . . . . . . . . . . 5
4.4 Procedures at the Home Proxy . . . . . . . . . . . . . . . . . 5
4.5 Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9
Non-Normative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
Willis Expires October 11, 2002 [Page 2]
Internet-Draft Path Extension Header for SIP April 2002
1. Background
3GPP established a requirement for discovering intermediate proxies
during SIP registration and published this requirement in [3GPPReq]
Scenario:
UA----P1-----P2-----P3------REGISTRAR
UA 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.
2. Applicability Statement
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:
1. One or more of the intermediate proxies MUST be visited by
messages between REGISTRAR and UA.
2. 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
Willis Expires October 11, 2002 [Page 3]
Internet-Draft Path Extension Header for SIP April 2002
proxy route between the UA and its registrar.
3. The network topology is such that the intermediate proxies which
must be visited are NOT implied by SIP routing tables, DNS, or
similar mechanisms.
3. Path Header Definition and Syntax
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 [2]. The
following additions to this table are needed for Path.
Addition of Path to SIP Table 2:
Header field where proxy ACK BYE CAN INV OPT REG PRA
_______________________________________________________________
Path R amr - - - - - o -
Path 2xx amr - - - - - o -
Willis Expires October 11, 2002 [Page 4]
Internet-Draft Path Extension Header for SIP April 2002
4. Usage of Path Header
4.1 Procedures at the UA
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.
4.2 Procedures at Intermediate Proxies
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.
4.3 Procedures at the Registrar
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 [1]). The
registrar copies the Path elements list as one or more Path headers
into into the successful (200 OK) REGISTER response message.
4.4 Procedures at the Home Proxy
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,
Willis Expires October 11, 2002 [Page 5]
Internet-Draft Path Extension Header for SIP April 2002
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.
4.5 Examples of Usage
As an example, we use the scenario from the Background section:
UA----P1-----P2----P3-----REGISTRAR
UA 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.
Message sequence for REGISTER with Path:
F1 Register UA -> P1
REGISTER sip:REGISTRAR SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA@REGISTRAR <UA1@REGISTRAR>
From: UA@REGISTRAR <UA@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
. . .
F2 Register P1 -> P2
REGISTER sip:REGISTRAR SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
To: UA@REGISTRAR <UA@REGISTRAR>
From: UA@REGISTAR <UA@REGISTAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Willis Expires October 11, 2002 [Page 6]
Internet-Draft Path Extension Header for SIP April 2002
Contact: <sip:UA@192.0.2.4>
Path: <sip:P1;lr>
. . .
F3 Register P2 -> P3
REGISTER sip:REGISTRAR SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
To: UA@REGISTRAR <UA@REGISTRAR>
From: UA@REGISTRAR <UA1@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Path: <sip:P1;lr>
. . .
F4 Register P3 -> REGISTRAR
REGISTER sip:REGISTRAR SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
Via: SIP/2.0/UDP P3:5060;branch=p3wer654363
To: UA@REGISTRAR <UA@REGISTRAR>
From: UA@REGISTRAR <UA@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Path: <sip:P3;lr>
Path: <sip:P1;lr>
. . .
F5 REGISTRAR executes Register
REGISTRAR Stores:
For UA@REGISTRAR
Contact = <sip:UA@192.0.2.4>
Path=<sip:P3;lr>,<sip:P1;lr>
F6 Register Response REGISTRAR -> P3
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
Via: SIP/2.0/UDP P3:5060;branch=p3wer654363
To: UA@REGISTRAR <sip:UA@P2>
From: UA@REGISTRAR <sip:UA@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
Willis Expires October 11, 2002 [Page 7]
Internet-Draft Path Extension Header for SIP April 2002
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Path: <sip:P1;lr>,<sip:P3;lr>
. . .
F7 Register Response P3 -> P2
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
Via: SIP/2.0/UDP P2:5060;branch=iokioukju908
To: UA@REGISTRAR <sip:UA@REGISTRAR>
From: UA@REGISTRAR <sip:UA@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Path: <sip:P3;lr>,<sip:P1;lr>
. . .
F8 Register Response P2 -> P1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04
To: UA@REGISTRAR <sip:UA@REGISTRAR>
From: UA@REGISTRAR <sip:UA@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Path: <sip:P3;lr>,<sip:P1;lr>
. . .
F9 Register Response P1 -> UA
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA@REGISTRAR <sip:UA@REGISTRAR>
From: UA@REGISTRAR <sip:UA@REGISTRAR>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA@192.0.2.4>
Path: <sip:P3;lr>,<sip:P1;lr>
. . .
5. Security Considerations
There are few security considerations for this draft beyond those in
SIP [2]. From a security perspective, the Path extension and its
usage are identical to the Record-Route header of basic SIP. Note
Willis Expires October 11, 2002 [Page 8]
Internet-Draft Path Extension Header for SIP April 2002
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.
6. IANA Considerations
This document defines the SIP extension header name "Path", which
IANA will add to the registry of SIP header names defined in [2]
7. Acknowledgements
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.
Normative References
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[2] Rosenberg, J., "SIP: Session Initiation Protocol draft-ietf-
sip-rfc2543bis-09.txt", March 2002.
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
Non-Normative References
[5] Garcia-Martin, MA., "3GPP requirements On SIP, draft-garcia-
sipping-3GPPRequirements.txt", March 2002.
Willis Expires October 11, 2002 [Page 9]
Internet-Draft Path Extension Header for SIP April 2002
Author's Address
Dean Willis
dynamicsoft Inc.
5100 Tennyson Parkway
Suite 1200
Plano, TX 75028
US
Phone: +1 972 473 5455
EMail: dwillis@dynamicsoft.com
URI: http://www.dynamicsoft.com/
Willis Expires October 11, 2002 [Page 10]
Internet-Draft Path Extension Header for SIP April 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Willis Expires October 11, 2002 [Page 11]
