SIP -- Session Initiation Protocol D. Willis Working Group dynamicsoft Inc. Internet-Draft March 20, 2002 Expires: September 18, 2002 SIP Extension for Registering Non-Adjacent Contacts draft-willis-sip-path-02 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 September 18, 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 itself 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 September 18, 2002 [Page 1] Internet-Draft Path Extension Header for SIP March 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 . . . . . . . . . . . . . . . . . . . . . 4 4.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Willis Expires September 18, 2002 [Page 2] Internet-Draft Path Extension Header for SIP March 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 transacation. 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 proxy route between the UA and its rregistrar. Willis Expires September 18, 2002 [Page 3] Internet-Draft Path Extension Header for SIP March 2002 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 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 responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatinility. 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 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. Willis Expires September 18, 2002 [Page 4] Internet-Draft Path Extension Header for SIP March 2002 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 bottomost entry in the Path header (or inserts a new bottommost Path 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 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 sucessful REGISTER request, the registrar constructs an ordered list of route elements from the nodes listed in the Path header(s), preserving the order as indicated in the Path headers. The registrar then stores this route set in association with that contact and the adddres-of-record indicated in the Register request (the "binding" as defined in RFC 2543 [1]). The registrar copies the Path header list into the 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 retargetted. The home service proxy, 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 (inverted) the route set associated with the specific contact in the registrar database into the Route header of the outgoing message as a preloaded route. This causes the outoing message to transit the set of proxies that indicated that they were to be used in future messages to that contact by including themseleves in the Path header Willis Expires September 18, 2002 [Page 5] Internet-Draft Path Extension Header for SIP March 2002 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 From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: . . . 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 From: UA@REGISTAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: . . . 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 Willis Expires September 18, 2002 [Page 6] Internet-Draft Path Extension Header for SIP March 2002 From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: . . . 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 From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: Path: . . . F5 REGISTRAR executes Register REGISTRAR Stores: For UA@REGISTRAR Contact = Path=, 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 From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: , . . . 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 Willis Expires September 18, 2002 [Page 7] Internet-Draft Path Extension Header for SIP March 2002 To: UA@REGISTRAR From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: , . . . 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 From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: , . . . 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 From: UA@REGISTRAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: , . . . 5. Security Considerations There are few 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 identical to the Record-Route header of basic SIP. Note 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 RFC 2543 Willis Expires September 18, 2002 [Page 8] Internet-Draft Path Extension Header for SIP March 2002 [1] 7. 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 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. References [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol, RFC2543", April 1999. [2] Rosenberg, J., "SIP: Session Initiation Protocol draft-ietf- sip-rfc2543bis-09.txt", March 2002. [3] Garcia-Martin, MA., "3GPP requirements On SIP, draft-garcia- sipping-3GPPRequirements.txt", March 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 September 18, 2002 [Page 9] Internet-Draft Path Extension Header for SIP March 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 September 18, 2002 [Page 10]