SIPPING Working Group T. Alexiou Internet Draft J. Lennox Document: <draft-alexiou-sipping-allocate-00.txt> K. Murakami Lucent Technologies Expires: August 2002 February 2002 The SIP ALLOCATE Method Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 become obsolete 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. The distribution of this memo is unlimited. Abstract This document defines ALLOCATE, a new method extending the SIP protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media Gateway Controller to create a dynamic and short-lived binding between a PSTN telephone number and a set of SIP URIs. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................1 1 Introduction.....................................................2 2 Example Use......................................................2 3 ALLOCATE Method..................................................3 3.1 Constructing the Request.......................................3 3.2 Processing the Request.........................................4 3.3 Call setup.....................................................5 4 Security Considerations..........................................5 T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 1 <draft-alexiou-sipping-allocate-00.txt> February 2002 5 IANA Considerations..............................................6 6 Message Examples.................................................6 7 References.......................................................6 8 Authors' Addresses...............................................7 9 Acknowledgements.................................................7 10 IPR Statement...................................................7 11 Full Copyright Statement........................................7 1 Introduction This document defines ALLOCATE, a new method extending the SIP [2] protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media Gateway Controller (MGC) [3] to create a dynamic and short-lived binding between a PSTN telephone number and a set of SIP URIs. This telephone number, which we call a Temporary SIP Gateway Number (TSGN), is similar in purpose to a routing number in wireless networks. Once the gateway is contacted through PSTN signaling (such as an IAM ISUP message) with this TSGN number after the binding is created, the gateway issues INVITE requests to the addresses specified in the ALLOCATE request to complete the call. Existing techniques for mapping a telephone number to a set of SIP URLs, such as Enum [4] or a REGISTER request sent to a telephone number, assume that the telephone number space is under the control of the entity performing the assignments; TRIP [6] was mainly meant for routing calls from SIP networks to PSTN. This model, however, deals with the opposite direction: many ALLOCATE requestors may obtain temporary gateway numbers from a single gateway, dynamically on a per user/call basis. The pool of temporary numbers must therefore be under the control of the gateway, not the requestor, so a new technique is needed. IETF protocols for temporary leases of resources out of a pool, such as DHCP [5] or MADCAP [7], do currently exist. However, these protocols are primarily designed for very specific problem domains, such as use on a local-area network or for allocating multicast addresses with only loose coupling, and none of them are terribly well suited for the wide-area use that this usage scenario requires. No existing protocols are directly suitable to exactly this purpose. As the scenario simply has request and response semantics, any of the multitudinous existing Internet request/response protocols could potentially provide the transport for this scenario; there is not an extremely strong argument for any of them. However, since the devices to be used must already speak SIP, and since SIP's syntax and semantics are designed to represent telephony-style resources, SIP seems the most appropriate protocol for this purpose. 2 Example Use The ALLOCATE method, combined with cellular network technologies, allows the selection of a media gateway dynamically upon delivering a call from a circuit switched network to a SIP terminal. This T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 2 <draft-alexiou-sipping-allocate-00.txt> February 2002 contrasts with the current prevailing approach of statically determining a media gateway by the directory number, regardless of the location of the end terminal. In cellular networks, a dynamically assigned routing number is employed to deliver a call to the roaming subscriber via circuit- switched networks. ALLOCATE makes it possible to obtain such routing number from any desirable SIP gateway. With this routing number, a call can be relayed through the PSTN networks to the gateway, which then attempts to deliver the call to the provided contact addresses. A specific example of this is shown in Figure 1. The ISUP network queries the mobility manager with a routing information request. The mobility manager then asks a gateway to allocate a TSGN for a particular user's contact addresses. The gateway returns the TSGN in the 200 OK message, and the mobility manager sends the TSGN back to the ISUP network. Then the ISUP network issues an IAM addressed with the TSGN, which the PSTN routes to the gateway. When the gateway receives the IAM, it initiates SIP INVITE requests to the addresses which were specified in the ALLOCATE request. The SIP request and response messages for this example's ALLOCATE transaction are shown in Section 6. |---------| | ISUP | 5. IAM (TSGN) | Network | -------------------------- |---------| | ^ | | 4. | | | Rsp | | 1. Routing Info | (TSGN)| | Request | | | | | | | | \/ \/ |---------| 2. ALLOCATE 6. INVITE alice@office | Mobility|---------------------->|------|------------------------> | Manager |<--------------------- | GW |------------------------> |---------| 3. 200 OK |------| 6'. INVITE alice@lab Contact: <tel:TSGN> Figure 1: Example Call Flow 3 ALLOCATE Method The ALLOCATE method is structured much like the REGISTER method. However the semantics of the Contact, To, and From headers are different as described in the following section. There is also one additional header, Allocate-For. There are no new response codes, bodies, or special processing requirements for proxies. 3.1 Constructing the Request T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 3 <draft-alexiou-sipping-allocate-00.txt> February 2002 A client issuing an ALLOCATE constructs its headers as detailed below: To: The To header field contains a SIP URL representing the initial gateway to which the request was sent. As with REGISTER, this will generally have only a 'host' component and no 'user' component. From: The From header field contains a SIP URL representing the requestor. If the destination gateway is using SIP-layer authentication to authenticate the requestor, this field is used as the key to determine the authentication credentials to be used (as with REGISTER). Contact: At least one Contact address, to be bound to a TSGN by the server, must be present. The client can use the "expires" header field parameter (or an Expires header) to indicate how long it wishes the binding to be valid. (An expiration value of three minutes is RECOMMENDED.) Note: three minutes is an initial estimate of an appropriate expiration timer; the optimal value for this timer is for further study. The addresses specified in the Contact header field SHOULD be SIP or SIPS URIs, unless the requestor has out-of-band knowledge that the gateway supports routing calls to other URI schemes. Allocate-For: This optional header indicates an E.164 address of the entity on whose behalf the allocation is being performed, through which the PSTN call will be routed. The syntax of this header is the same as that of Contact. Gateways, or gateway location servers, MAY use this information to choose an appropriate gateway, in order to minimize, e.g. the length of the PSTN call leg. Allocate requestors SHOULD include this information if it is available. Other SIP header fields and the SIP Request-URI are constructed in the standard manner specified by the SIP specification. ALLOCATE requests contain no content bodies. 3.2 Processing the Request If the received request contains multiple Contact addresses, the server MUST be able to fork or sequentially search for the user based on the q preference value; otherwise it MUST reject the request with a 488 Not Acceptable Here response code. If the server decides to accept the request, it sends the client a 200 OK response. The response MUST include one Contact header with T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 4 <draft-alexiou-sipping-allocate-00.txt> February 2002 exactly one Contact header field containing the TSGN, expressed as a "tel" URI [8]. The TSGN SHOULD be in global (E.164) format, and SHOULD NOT contain an isdn-subaddress or other components which would prevent it from being globally reachable. The server MUST indicate how long the binding is valid with an "expires" Contact header field parameter. The server MAY lower the expiration time from the value specified in the request, but MUST NOT increase it. If the expiration period in the request is shorter than is supported by the server, the server rejects the request with the status 423 Interval Too Brief, and includes a Min-Expires header in the response indicating the shortest expiration period supported. If subsequent ALLOCATE requests (in new transactions) arrive for the same set of Contact addresses, they are processed independently, and should obtain different TSGNs. 3.3 Call setup When a PSTN call placed to the TSGN arrives at the gateway, the gateway initiates SIP INVITE requests to the SIP addresses specified in the ALLOCATE message's Contact header field. Once the INVITE transactions have been initiated, the binding between the TSGN and the set of SIP addresses is removed. The binding is alternatively removed when the "expires" timer specified by the server has elapsed. Gateways SHOULD avoid re-using TSGNs for some period of time after a binding has expired, to avoid accidental collision between old and new bindings. 4 Security Considerations The security requirements and considerations in the SIP specification apply to the ALLOCATE method. Trust models or security associations between clients and servers are beyond the scope of this document. The authors wish that the definition of this extension be orthogonal to the current or future security models for SIP. For example, Denial of Service attack against the server by unauthenticated users, to exhaust the available TSGNs, is among the obvious attacks. Minimally, the digest authentication mechanism used for SIP registrations can apply to the ALLOCATE method for authentication between domains. Gateways SHOULD avoid exposing the TSGN in the INVITE methods they generate after receiving the PSTN call setup. This will help somewhat to avoid session hijacking by callers calling TSGN numbers for sessions they have not been assigned. In the absence of authentication in the PSTN, however, this problem will still remain; T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 5 <draft-alexiou-sipping-allocate-00.txt> February 2002 gateways which have administrative relationships with all PSTN entities authorized to transit through them SHOULD verify at least the PSTN source of the call. 5 IANA Considerations This document defines a new SIP method name (ALLOCATE), and a new header field (Allocate-For). 6 Message Examples In the following example, the gateway gw58.ca.pstn-gws.example binds, for 180 seconds, the TSGN +13235554258 to the Contact addresses in the request. ALLOCATE sip:gw58.ca.pstn-gws.example SIP/2.0 Via: SIP/2.0/UDP nj.mobility-manager.example:5060 From: <sip:nwelem47.nj.mobility-manager.example> To: <sip:gw58.ca.pstn-gws.example> Call-ID: 1234567890@nwelem47.nj.mobility-manager.example CSeq: 1 ALLOCATE Max-Forwards: 70 Contact: "Alice at work" <sip:alice@office.work.com>; expires=180 Contact: "Alice in the lab" <sip:alice@lab.work.com>; expires=180 Allocate-For: <tel:+18475550000> Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP nj.mobility-manager.example:5060 From: <sip:nwelem47.nj.mobility-manager.example> To: <sip:gw58.ca.pstn-gws.example> Call-ID: 1234567890@nwelem47.nj.mobility-manager.example CSeq: 1 ALLOCATE Contact: <tel:+13235554258>; expires=180 Content-Length: 0 7 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1999. [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543-bis-08, February 2002. Work in progress. [3] F. Cuervo et al, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [4] P. Falstrom, "E.164 number and DNS", RFC 2916, September 2000. [5] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [6] J. Rosenberg, H. Salama, M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. [7] S. Hanna, B. Patel, and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 6 <draft-alexiou-sipping-allocate-00.txt> February 2002 [8] H. Schulzrinne and A. Vaha-Sipila, "URIs for Telephone Calls", draft-antti-rfc2806bis-02.txt, February 2002. Work in progress. 8 Authors' Addresses Triantafyllos Alexiou 101 Crawfords Corner Rd Room: 4J-513A Holmdel, NJ 07733 Tel: +1 732 332-5559 Email: akis@lucent.com Jonathan Lennox 101 Crawfords Corner Rd Room: 4F-516 Holmdel, NJ 07733 Tel: +1 732 332-6063 Email: lennox@lucent.com Kazutaka Murakami 101 Crawfords Corner Rd Room: 4G-512 Holmdel, NJ 07733 Tel: +1 732 949-6028 Email: kmurakami@lucent.com 9 Acknowledgements We thank Henning Schulzrinne, Tom La Porta, and Oliver Haase for their comments on this proposal. 10 IPR Statement Lucent Technologies may have intellectual property rights on the example scenario described in section 2. The ALLOCATE method itself is unencumbered to the best of our knowledge. 11 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 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 defined in the Internet Standards process must be followed, or as T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 7 <draft-alexiou-sipping-allocate-00.txt> February 2002 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. T. Alexiou, J. Lennox, K. Murakami Expires August 2002 Page 8