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 3GPP established a requirement for discovering service routes during SIP registration and published this requirement in [3GPPReq]. Service routes are used as pre-loaded route headers for future messages, which when processed according to SIP routing rules provide for transiting a specific set of SIP nodes. The PATH extension provides a mechanism to discover service routes for future messages directed from a given SIP contact, and another service route for future messages directed toward that contact. 3. Background 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 the registrar applies inbound services for that user agent. draft-willis-sip-path-00 [Page 1] Internet-Draft Path Extension Header for SIP February 2002 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 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 syntax for Path can be given as: Path = "Path" HCOLON path-value *(COMMA path-value) path-value = name-addr *( SEMI rr-param ) 5. Usage of Path Header 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 draft-willis-sip-path-00 [Page 2] Internet-Draft Path Extension Header for SIP February 2002 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 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: . . . draft-willis-sip-path-00 [Page 3] Internet-Draft Path Extension Header for SIP February 2002 F4 Registrar Response P1 -> UA1 SIP/2.0 200 OK 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: Path: . . . F5 UA2 Stores Path UA1 Stores: Path= Future non-REGISTER messages from UA1 will include a preloaded Route header, as in: Route: 7. 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. 8. IANA Considerations There are no IANA considerations raised by this document. 9. References [RFC 2543] " SIP: Session Initiation Protocol.", M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, RFC 2543, March 1999 [3GPPReq] "3GPP requirements On SIP", Garcia, M., draft-garcia- sipping-3GPPRequirements.txt, Novemebr 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 draft-willis-sip-path-00 [Page 4] Internet-Draft Path Extension Header for SIP February 2002 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-00 [Page 5]