SIP -- Session Initiation Protocol D. Willis Working Group dynamicsoft Inc. Internet-Draft March 20, 2002 Expires: September 18, 2002 Private SIP Extension for Service Route Discovery in Some Networks draft-willis-sip-scvrtdisco-00 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 This document proposes a private SIP extension header used in conjunction with responses to REGISTER messages to provide a mechanism by which the registrar may inform the UA of a service route that the UA may use to request outbound services from the registrar's domain. Willis Expires September 18, 2002 [Page 1] Internet-Draft Private SIP Ext for Service Route March 2002 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Discussion of Mechanism . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . 5 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . 5 5.2 Procedures at the Proxy . . . . . . . . . . . . . . . . . . 5 5.3 Procedures at the Registrar . . . . . . . . . . . . . . . . 5 5.4 Examples of Usage . . . . . . . . . . . . . . . . . . . . . 6 5.4.1 Example of Mechanism in REGISTER Transaction . . . . . . . . 6 5.4.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 Willis Expires September 18, 2002 [Page 2] Internet-Draft Private SIP Ext for Service Route March 2002 1. Background 3GPP established a requirement for discovering home proxies during SIP registration and published this requirement in [3GPPReq]. Unlike many other network environments, the 3GPP network dynamically assigns a home service proxy to each address-of-record. This assignment may occur in conjunction with a REGISTER operation, or out-of-band as needed to support call services when the address-of-record has no registrations. This home service proxy may provide both inbound (UA terminated) and outbound services (UA originated). The home proxy network routes inbound messages having a request-URI targetting the address-of-record associated with the UA to the assigned home service proxy by using some sort of look-up-mechanism outside the scope of this document. This mechanism deals with inbound (UA terminated) messages. Outbound (UA originated) messages raise another issue. Specifically, "How does the UA know which service proxy to use and how to get there?" Several mechanisms have been proposed in list discussions, including: 1. Configuration data in the UA. This raises questions of UA configuration management and updating, especially if proxy assignment is very dynamic as in load-balancing scenarios. 2. Use of some other protocol, such as HTTP, to get configuration data from a configuration server in the home network. While functional, this solution requires additional protocol engines, firewall complexity, operations overhead, and asignificant additional "over the air" traffic. 3. Use of lookup tables in the home network, as is done for inbound messages. This has a relatively high overhead in terms of database operations. 4. Returning a 302 response indicating the service proxy as a new contact, causing the upstream node processing the 302 (obstensibly the UA) to retransmit the message toward the service proxy. While this shares the database operation of the previous alternative, it does explicitly alloow for cacheing the 302 response thereby potentially reducing the frequency and number of database operations. 5. Performing an operation equivalent to record-routing a REGISTER message between the UA and the associated registrar, then storing that route in the UA and reusing it as a service route on future messages originating from the UA. While efficient, this constrains the service route for proxy operations to be congruent with the route taken by the REGISTER message. 6. Returning service route information as the value of a header in the REGISTER response. While similar to the previous Willis Expires September 18, 2002 [Page 3] Internet-Draft Private SIP Ext for Service Route March 2002 alternative, this approach grants the ability for the regisrtar to selectively apply knowledge about the topology of the home network in constructing the service route. Scenario UA1----P1-----| |--R-------| | | | P2---| DBMS | | | UA2-----------| |--HSP-----| In this scenario, we have a "home network" containing routing proxy P2, registrar R, home service proxy HSP, and database DBMS used by both R and HSP. P2 represents the "edge" of the home network from a SIP perspective, and might be called an "edge proxy". UA1 is an external UA behind proxy P1. UA1 discovers P1 via DHCP. UA2 is another UA on the internet, and does not use a default outbound proxy. We do not show DNS elements in this diagram, but will assume their reasonable availability in the discussion. The mission is for UA1 to discover HSP so that outbound messages from UA1 may be routed (at the discretion of UA1) through HSP, thereby receiving outbound services from HSP. 2. Discussion of Mechanism The proposed mechanism uses a private header "P-ServiceRoute" in the REGISTER response to indicate a service route that the UA may wish to use if requesting services from the proxy network associated with the registrar generating the response. Simply put, the registrar generates a service route for the registering UA and returns it in the response to each successful REGISTER request. This service route has the form of a Route header that the registering UA may use to send messages through the service proxy selected by the registrar. The UA would use this route by inserting it as a preloaded Route header in messages originated by the UA intended for routing through the service proxy. The mechanism by which the registrar constructs the header value is specific to the local implementation and outside the scope of this document. Willis Expires September 18, 2002 [Page 4] Internet-Draft Private SIP Ext for Service Route March 2002 3. Applicability Statement The P-ServiceRoute mechanism is applicable when: 1. The UA registers with a REGISTRAR in a given domain. 2. The domain dynamically assigns a service proxy for the UA. 3. The registrar(s) in the domain has/have sufficient knowledge of the network topology, policy, and situation such that a reasonable service route can be constructed. 4. Other mechanisms for proposing a service route to the UA are not available or are innapropriate for use within the administrative domain. 4. Syntax The syntax for the P-ServiceRoute header is: p-ServiceRoute = "P-ServiceRoute" HCOLON 1#( name-addr *( SEMI rr- param )) rr-param = generic-param 5. Usage 5.1 Procedures at the UA The UA performs a register as usual. The register response may contain a "P-ServiceRoute" header. If so, the UA MAY store the value of the P-ServiceRoute header in an association with the address-of- record for which the REGISTER message had registered a contact. If the UA supports multiple address of records, it may be able to store multiple service routes, one per address-of-record. The UA MAY choose to exercise a service route for future messages associated with a given address-of-record for which a service route is known. If so, it appends the given service route to any local required Route headers, and uses the result as a pre-loaded Route header in outgoing messages. 5.2 Procedures at the Proxy The P-ServiceRoute header is treated like any other unknown header by intermediate proxies. They simply forward it on towards the destination. 5.3 Procedures at the Registrar When a registrar receives a successful REGISTER message, it MAY choose to return a P-ServiceRoute header in the 200 OK response. The Willis Expires September 18, 2002 [Page 5] Internet-Draft Private SIP Ext for Service Route March 2002 determinations of whether to include this header in the and what value to insert are a matter of local policy and outside the scope of this document. Having inserted a P-ServiceRoute header, the registrar returns the 200 OK reponse to the UA in accordance with standard procedures. 5.4 Examples of Usage We present example in the context of the scenario presented in the Background section earlier in this document. The network diagram is replicated below: Scenario UA1----P1-----| |--R-------| | | | P2---| DBMS | | | UA2-----------| |--HSP-----| 5.4.1 Example of Mechanism in REGISTER Transaction This example shows the message sequence for UA1 registering to HOMEDOMAIN using registrar R. R returns a P-ServiceRoute indicating that UA1 may use home servcie proxy HSP to receive outbound services from HOMEDOMAIN. Message sequence for REGISTER returning P-ServiceRoute: F1 Register UA1 -> P1 REGISTER sip:HOMEDOMAIN SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA@HOMEDOMAIN From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: . . . F2 Register P1 -> P2 REGISTER sip:HOMEDOMAIN SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 Willis Expires September 18, 2002 [Page 6] Internet-Draft Private SIP Ext for Service Route March 2002 Via: SIP/2.0/UDP P1:5060;branch=34ghi7ab04 To: UA@HOMEDOMAIN From: UA@REGISTAR ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: . . . F3 Register P2 -> R REGISTER sip:HOMEDOMAIN 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@HOMEDOMAIN From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Path: Path: . . . F4 R executes Register R Stores: For UA1@P2 Contact = F5 R calculates Service Route Statically configured to reference HSP as a Service Route P-ServiceRoute= F6 Register Response r -> 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@HOMEDOMAIN From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: P-ServiceRoute= . . . F7 Register Response P2 -> P1 Willis Expires September 18, 2002 [Page 7] Internet-Draft Private SIP Ext for Service Route March 2002 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@HOMEDOMAIN From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: P-ServiceRoute= . . . F8 Register Response P1 -> UA SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA@HOMEDOMAIN From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: P-ServiceRoute= . . . F9 UA stores service route for HOMEDOMAIN 5.4.2 Example of Mechanism in INVITE Transaction This example shows the message sequence for an INVITE transaction originating from UA1 eventually ariving at UA2 using outbound servcies from HOMEDOAMIN,, where UA1 has previously registered with HOMEDOMAIN and been informed of a service route through HSP. The service being provided by HOMEDOMAIN is a "speed dial" service, where the user's private speed dial code "Joe" is expanded to "sip:Joe@UA2" by the action of HSP. Message sequence for INVITE using P-ServiceRoute: F1 INVITE UA1 -> P1 INVITE sip:joe SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: Route: Willis Expires September 18, 2002 [Page 8] Internet-Draft Private SIP Ext for Service Route March 2002 . . . (note: P1 is selected using the "outbound proxy" rule in UA1) F2 INVITE P1 -> P2 INVITE sip:joe 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: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: Record-Route Route: . . . (note: P2 is slected using a DNS lookup on the domain of HSP) F3 INVITE P2 -> HSP INVITE sip:joe 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: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Contact: Record-Route Record-Route Route: . . . (note: HSP is slected using a DNS lookup for HSP within HOMEDOMAIN) F4 HSP executes service looks up name "sip:joe" in UA1's profile, returns "sip:joe@UA2" This will be request-URI of next-hop INVITE F5 INVITE HSP->P2 INVITE sip:joe@UA2 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/USP HSP:5060;branch=HSP10120323 To: Joe From: UA@HOMEDOMAIN ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 18 INVITE Willis Expires September 18, 2002 [Page 9] Internet-Draft Private SIP Ext for Service Route March 2002 Contact: Record-Route Record-Route Record-Route . . . (note: P2 selected by outbound proxy rule on HSP) INVITE propagates toward UA2 as usual. 6. Security Considerations It is possible for proxies between the UA and the registrar during the REGISTER transaction to modify the value of P-ServiceRoute returned by the registrar, or to insert a P-ServiceRoute even when one was not returned by the registrar. It is also possible for proxies on the INVITE path to execute many different attacks. It is therefore desirable to apply transitive mutual authentication using sips: or other available mechanisms in order to prevent such attacks. 7. IANA Considerations This document defines the SIP extension header "P-ServiceRoute" which should be included in the registry of SIP headers defined in SIP [2]. As required by the SIP change process draft-tsvarea-sipchange [4] the SIP extension header name "ServiceRoute" should also be registered in association with this extension. 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. [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange", March 2002. Willis Expires September 18, 2002 [Page 10] Internet-Draft Private SIP Ext for Service Route 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 11] Internet-Draft Private SIP Ext for Service Route 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 12]