SIP Working Group Dean Willis Internet-Draft dynamicsoft Inc. February 2002 expires June 2002 Path Extension Header for Establishing Service Route with SIP REGISTER 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 From: UA1 ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: . . . 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 From: UA1 ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: . . . F3 P2 executes Register P2 Stores: For UA1@P2 Contact = Path= 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 From: UA1 ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: . . . 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 From: UA1 ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: . . . F5 UA2 Stores Path UA1 Stores: Path= Future non-REGISTER messages from UA1 will include a preloaded Route header, as in: Route: 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]