SIP Working Group Dean Willis
Internet-Draft dynamicsoft Inc.
February 2002
expires June 2002
Path Extension Header for Establishing Service Route with SIP REGISTER
<draft-willis-sip-path-01.txt>
1. Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC 2026.
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
Copyright (C) The Internet Society (2002). All Rights Reserved.
2. Abstract
This draft provides a mechanism to be used in the REGISTER method,
that allows SIP nodes that 1) wish to be included on the service
route in future transactions, and 2) are situated on the signaling
path between the UA and the registrar, to communicate with other
nodes such that they can form part of a preloaded route list for
future transactions.
3. Background
3GPP established a requirement for discovering service routes during
SIP registration and published this requirement in [3GPPReq].
The concept of a service route generally applies whenever a SIP proxy
not immediately adjacent to a user agent applies outbound services
for that user agent, or whenever a proxy between the user agent and
draft-willis-sip-path-01 [Page 1]
Internet-Draft Path Extension Header for SIP February 2002
the registrar applies inbound services for that user agent.
The basic requirement from 3GPP is to provide a mechanism to discover
and communicate a service route during registration.
Scenario:
UA1----P1-----P2----UA2
UA1 uses proxy P2 for "home services", so all messages from UA1 must
traverse P2. However, due to network topology, UA1 must use P1 as an
"outbound proxy", and all messages between UA1 and P2 must also
traverse P1 before traversing P2. UA1 has a standing relationship
with P2, which it consider's it's Home proxy". UA1 discovers P1 as a
result of a DHCP assignment. UA1 wishes to register with P2, using P1
as a default outbound proxy. P2 will wish to direct future dialog
initiations to UA1, perhaps from UA2, through P1 toward P2.
UA1 needs to know its service route (P1, P2) for future dialog
initiations using P2. P2 needs to know the service route (P1, UA1)
for future dialog initiations toward UA1.
The proposed Path extension header allows accumulating and
transmitting the service route for direction UA1->P2 toward P2, and
accumulating and transmitting the service route for direction P2->UA1
toward UA1. 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.
4. 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 inserted into a REGISTER or REGISTER Response 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 primary differences between Path and Record-Route are:
1) Path applies to REGISTER and responses to REGISTER. Record-Route
doesn't.
draft-willis-sip-path-01 [Page 2]
Internet-Draft Path Extension Header for SIP February 2002
2) Path is directional and starts at the node originating the Path
header and is "learned" by the node receiving the Path header.
Record-Route is "learned" by the node that originates it.
3) The Path header is a unidirectional operation. That is, the Path
in a response to REGISTER is completely independent of the Path in
the original Regsiter. Record-Route is bidirectional, and the route
learned on the initial message is rflected back from the terminal
node in the response.
4) There may only be a Path applied in one direction. A proxy might
add a Path on REGISTER, but not on the response to that REGISTER, or
vice-versa.
The syntax for Path can be given as:
Path = "Path" HCOLON path-value *(COMMA path-value)
path-value = name-addr *( SEMI rr-param )
Note: an alternate suggestion for syntax is:
Path = "Path" HCOLON 1#
( name-addr *( SEMI rr-param ))
rr-param = generic-param
5. Usage of Path Header
5.1 Procedures at the UA
When a UA receives a response to REGISTER containing the Path header,
the UA removes its SIP URL from the list of Path headers,
reverse the order of the list and save the resulting list of Path
headers. This list SHOULD be stored during the entire registration
period of the associated public user identity. If this registration is
a reregistration, any stateful proxy which has stored the Path SHOULD
replace the stored Path with the new path.
A UA SHOULD use any route list created by the Path mechanism during a
registration procedure as the pre-loaded route in the Route header of the
first request in a dialog, or in any request that does not form part of a
dialog.
5.2 Procedures at the Proxy
A proxy processing a REGISTER that wishes to be on the path for future
transactions or dialogs related to the UA originating that REGISTER
request inserts a URI for that proxy as the topmost entry in the Path
draft-willis-sip-path-01 [Page 3]
Internet-Draft Path Extension Header for SIP February 2002
header before proxying that request. It is also possible for a proxy
with specific knowledge of network topology to add a Path header
referencing another node, thereby allowing construction of a Path
which is discongruent with the route taken by the REGISTER or REGISTER
Response.
5.3 Procedures at the Registrar
If a Path header exists in a sucessful REGISTER request, the registrar
constructs a list of preloaded Route headers from the list of
entries in the Path header. The order in the lists is preserved. The
registrar binds to each contact information the Path
header entries that were received in the same REGISTER message as
that contact information. The registrar shall also return the path
list as a Path header in a 200 OK response to the REGISTER request.
An inbound proxy which uses the location server to determine the
Contact address of the user MUST also use this list of preloaded Route
headers in the transaction request.
The registrar can also act as a proxy as described above (in which
case it inserts a resolvable identifier identifying itself in the Path
header) before storing the list of preloaded Route headers.
5.4 Examples of Usage
Any node generating or receving a REGISTER message or REGISTER Response
that wishes to be included in the service route for future messages
flowing in the direction of the received message may add their identity
as a path-value at the end of any Path header in that message, or may add
a Path header with their identity as a path-value as the final Path header
in that message.
As an example, we use the scenario from Section 3:
UA1----P1-----P2----UA2
UA1 needs to know its service route (P1, P2) for future dialog
initiations using P2. P2 needs to know the service route (P1, UA1) for
future dialog initiations toward UA1. P2 is the registrar and
"home service proxy" for UA1.
So, P1 and will add itself to the Path on REGISTER. P2 stores this
request Path in association with the contact provded by UA1. P2 and P1
will add themselves to the Path on the 200 OK in response to the
REGISTER, and UA1 will store the supplied Path as a default outbound
Route for future messages. Note that if the relationship between UA1
and P1 is fixed and P1 is registration-stateful, P1 could store the
draft-willis-sip-path-01 [Page 4]
Internet-Draft Path Extension Header for SIP February 2002
response Path on the behalf of UA1 and insert it into future messages
from UA1.
F1 Register UA1 -> P1
REGISTER sip:UA1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: UA1 <UA1@P2>
From: UA1 <UA1@P2>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
. . .
F2 Register P1 -> P2
REGISTER sip:UA1 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: UA1 <UA1@P2>
From: UA1 <UA1@P2>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Path: <sip:P1>
. . .
F3 P2 executes Register
P2 Stores:
For UA1@P2
Contact = <sip:UA1@192.0.2.4>
Path=<sip:P1>
F4 Registrar 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: UA1 <sip:UA1@P2>
From: UA1 <sip:UA1@P2>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Path: <sip:P2>
. . .
F4 Registrar Response P1 -> UA1
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
draft-willis-sip-path-01 [Page 5]
Internet-Draft Path Extension Header for SIP February 2002
To: UA1 <sip:UA1@P2>
From: UA1 <sip:UA1@P2>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:UA1@192.0.2.4>
Path: <sip:P2><sip:P1>
. . .
F5 UA2 Stores Path
UA1 Stores:
Path=<sip:P1><sip:P2>
Future non-REGISTER messages from UA1 will include a
preloaded Route header, as in:
Route:<sip:p1><sip:P2>
6. Security Considerations
There are no security considerations for this draft beyond those in
SIP BIS (draft-sip-rfc2543bis-07.txt). From a security perspective,
the Path extension and its usage are exactly similar to the
Record-Route header of basic SIP.
7. IANA Considerations
There are no IANA considerations raised by this document.
8. Acknowledgements
Min Huang and Stinson Mathai, who put together the original proposal
in 3GPP for this mechanism, and worked most of the 3GPP procedures
in 24.229.
Keith Drage, Bill Marshall, and Migual Angel Garcia-Martin who argued with
everybody a lot about the idea as well as helped refine the requirements.
9. References
9.1 Normative References
draft-willis-sip-path-01 [Page 6]
Internet-Draft Path Extension Header for SIP February 2002
[RFC 2543] " SIP: Session Initiation Protocol.", M. Handley, H.
Schulzrinne, E. Schooler, J. Rosenberg, RFC 2543, March 1999
[bis] "SIP: Session Initiation Protocol." J. Rosenberg et. al.,
draft-ietf-sip-rfc2543bis-07.txt, February 2002
9.2 Non-Normative References
[3GPPReq] "3GPP requirements On SIP", Garcia, M.,
draft-garcia-sipping-3GPPRequirements.txt, November 2001
10. Author's Addresses
Dean Willis
Email: dean.willis@softarmor.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
draft-willis-sip-path-01 [Page 8]
