idnits 2.17.1 draft-alexiou-sipping-allocate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 180: '... of three minutes is RECOMMENDED.)...' RFC 2119 keyword, line 186: '... in the Contact header field SHOULD be...' RFC 2119 keyword, line 195: '...ocation servers, MAY use this informat...' RFC 2119 keyword, line 197: '...llocate requestors SHOULD include this...' RFC 2119 keyword, line 207: '... server MUST be able to fork or sequ...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-sip-rfc2543-bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 3015 (ref. '3') (Obsoleted by RFC 3525) ** Obsolete normative reference: RFC 2916 (ref. '4') (Obsoleted by RFC 3761) == Outdated reference: A later version (-08) exists of draft-antti-rfc2806bis-02 -- Possible downref: Normative reference to a draft: ref. '8' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group T. Alexiou 2 Internet Draft J. Lennox 3 Document: K. Murakami 4 Lucent 5 Technologies 7 Expires: August 2002 February 2002 9 The SIP ALLOCATE Method 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or become obsolete by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 The distribution of this memo is unlimited. 33 Abstract 35 This document defines ALLOCATE, a new method extending the SIP 36 protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media 37 Gateway Controller to create a dynamic and short-lived binding 38 between a PSTN telephone number and a set of SIP URIs. 40 Table of Contents 42 Status of this Memo................................................1 43 Abstract...........................................................1 44 Table of Contents..................................................1 45 1 Introduction.....................................................2 46 2 Example Use......................................................2 47 3 ALLOCATE Method..................................................3 48 3.1 Constructing the Request.......................................3 49 3.2 Processing the Request.........................................4 50 3.3 Call setup.....................................................5 51 4 Security Considerations..........................................5 52 February 2002 54 5 IANA Considerations..............................................6 55 6 Message Examples.................................................6 56 7 References.......................................................6 57 8 Authors' Addresses...............................................7 58 9 Acknowledgements.................................................7 59 10 IPR Statement...................................................7 60 11 Full Copyright Statement........................................7 62 1 Introduction 64 This document defines ALLOCATE, a new method extending the SIP [2] 65 protocol. ALLOCATE is a request to a SIP/PSTN gateway or Media 66 Gateway Controller (MGC) [3] to create a dynamic and short-lived 67 binding between a PSTN telephone number and a set of SIP URIs. This 68 telephone number, which we call a Temporary SIP Gateway Number 69 (TSGN), is similar in purpose to a routing number in wireless 70 networks. Once the gateway is contacted through PSTN signaling (such 71 as an IAM ISUP message) with this TSGN number after the binding is 72 created, the gateway issues INVITE requests to the addresses 73 specified in the ALLOCATE request to complete the call. 75 Existing techniques for mapping a telephone number to a set of SIP 76 URLs, such as Enum [4] or a REGISTER request sent to a telephone 77 number, assume that the telephone number space is under the control 78 of the entity performing the assignments; TRIP [6] was mainly meant 79 for routing calls from SIP networks to PSTN. This model, however, 80 deals with the opposite direction: many ALLOCATE requestors may 81 obtain temporary gateway numbers from a single gateway, dynamically 82 on a per user/call basis. The pool of temporary numbers must 83 therefore be under the control of the gateway, not the requestor, so 84 a new technique is needed. 86 IETF protocols for temporary leases of resources out of a pool, such 87 as DHCP [5] or MADCAP [7], do currently exist. However, these 88 protocols are primarily designed for very specific problem domains, 89 such as use on a local-area network or for allocating multicast 90 addresses with only loose coupling, and none of them are terribly 91 well suited for the wide-area use that this usage scenario requires. 92 No existing protocols are directly suitable to exactly this purpose. 93 As the scenario simply has request and response semantics, any of 94 the multitudinous existing Internet request/response protocols could 95 potentially provide the transport for this scenario; there is not an 96 extremely strong argument for any of them. However, since the 97 devices to be used must already speak SIP, and since SIP's syntax 98 and semantics are designed to represent telephony-style resources, 99 SIP seems the most appropriate protocol for this purpose. 101 2 Example Use 103 The ALLOCATE method, combined with cellular network technologies, 104 allows the selection of a media gateway dynamically upon delivering 105 a call from a circuit switched network to a SIP terminal. This 106 February 2002 108 contrasts with the current prevailing approach of statically 109 determining a media gateway by the directory number, regardless of 110 the location of the end terminal. 112 In cellular networks, a dynamically assigned routing number is 113 employed to deliver a call to the roaming subscriber via circuit- 114 switched networks. ALLOCATE makes it possible to obtain such routing 115 number from any desirable SIP gateway. With this routing number, a 116 call can be relayed through the PSTN networks to the gateway, which 117 then attempts to deliver the call to the provided contact addresses. 119 A specific example of this is shown in Figure 1. The ISUP network 120 queries the mobility manager with a routing information request. 121 The mobility manager then asks a gateway to allocate a TSGN for a 122 particular user's contact addresses. The gateway returns the TSGN in 123 the 200 OK message, and the mobility manager sends the TSGN back to 124 the ISUP network. Then the ISUP network issues an IAM addressed with 125 the TSGN, which the PSTN routes to the gateway. When the gateway 126 receives the IAM, it initiates SIP INVITE requests to the addresses 127 which were specified in the ALLOCATE request. 129 The SIP request and response messages for this example's ALLOCATE 130 transaction are shown in Section 6. 132 |---------| 133 | ISUP | 5. IAM (TSGN) 134 | Network | -------------------------- 135 |---------| | 136 ^ | | 137 4. | | | 138 Rsp | | 1. Routing Info | 139 (TSGN)| | Request | 140 | | | 141 | | | 142 | \/ \/ 143 |---------| 2. ALLOCATE 6. INVITE alice@office 144 | Mobility|---------------------->|------|------------------------> 145 | Manager |<--------------------- | GW |------------------------> 146 |---------| 3. 200 OK |------| 6'. INVITE alice@lab 147 Contact: 149 Figure 1: Example Call Flow 151 3 ALLOCATE Method 153 The ALLOCATE method is structured much like the REGISTER method. 154 However the semantics of the Contact, To, and From headers are 155 different as described in the following section. There is also one 156 additional header, Allocate-For. There are no new response codes, 157 bodies, or special processing requirements for proxies. 159 3.1 Constructing the Request 160 February 2002 162 A client issuing an ALLOCATE constructs its headers as detailed 163 below: 165 To: The To header field contains a SIP URL representing the initial 166 gateway to which the request was sent. As with REGISTER, this 167 will generally have only a 'host' component and no 'user' 168 component. 170 From: The From header field contains a SIP URL representing the 171 requestor. If the destination gateway is using SIP-layer 172 authentication to authenticate the requestor, this field is 173 used as the key to determine the authentication credentials to 174 be used (as with REGISTER). 176 Contact: At least one Contact address, to be bound to a TSGN by the 177 server, must be present. The client can use the "expires" 178 header field parameter (or an Expires header) to indicate how 179 long it wishes the binding to be valid. (An expiration value 180 of three minutes is RECOMMENDED.) 182 Note: three minutes is an initial estimate of an 183 appropriate expiration timer; the optimal value for 184 this timer is for further study. 186 The addresses specified in the Contact header field SHOULD be 187 SIP or SIPS URIs, unless the requestor has out-of-band 188 knowledge that the gateway supports routing calls to other URI 189 schemes. 191 Allocate-For: This optional header indicates an E.164 address of the 192 entity on whose behalf the allocation is being performed, 193 through which the PSTN call will be routed. The syntax of this 194 header is the same as that of Contact. Gateways, or gateway 195 location servers, MAY use this information to choose an 196 appropriate gateway, in order to minimize, e.g. the length of 197 the PSTN call leg. Allocate requestors SHOULD include this 198 information if it is available. 200 Other SIP header fields and the SIP Request-URI are constructed in 201 the standard manner specified by the SIP specification. ALLOCATE 202 requests contain no content bodies. 204 3.2 Processing the Request 206 If the received request contains multiple Contact addresses, the 207 server MUST be able to fork or sequentially search for the user 208 based on the q preference value; otherwise it MUST reject the 209 request with a 488 Not Acceptable Here response code. 211 If the server decides to accept the request, it sends the client a 212 200 OK response. The response MUST include one Contact header with 213 February 2002 215 exactly one Contact header field containing the TSGN, expressed as a 216 "tel" URI [8]. The TSGN SHOULD be in global (E.164) format, and 217 SHOULD NOT contain an isdn-subaddress or other components which 218 would prevent it from being globally reachable. 220 The server MUST indicate how long the binding is valid with an 221 "expires" Contact header field parameter. The server MAY lower the 222 expiration time from the value specified in the request, but MUST 223 NOT increase it. 225 If the expiration period in the request is shorter than is supported 226 by the server, the server rejects the request with the status 423 227 Interval Too Brief, and includes a Min-Expires header in the 228 response indicating the shortest expiration period supported. 230 If subsequent ALLOCATE requests (in new transactions) arrive for the 231 same set of Contact addresses, they are processed independently, and 232 should obtain different TSGNs. 234 3.3 Call setup 236 When a PSTN call placed to the TSGN arrives at the gateway, the 237 gateway initiates SIP INVITE requests to the SIP addresses specified 238 in the ALLOCATE message's Contact header field. Once the INVITE 239 transactions have been initiated, the binding between the TSGN and 240 the set of SIP addresses is removed. 242 The binding is alternatively removed when the "expires" timer 243 specified by the server has elapsed. Gateways SHOULD avoid re-using 244 TSGNs for some period of time after a binding has expired, to avoid 245 accidental collision between old and new bindings. 247 4 Security Considerations 249 The security requirements and considerations in the SIP 250 specification apply to the ALLOCATE method. Trust models or security 251 associations between clients and servers are beyond the scope of 252 this document. The authors wish that the definition of this 253 extension be orthogonal to the current or future security models for 254 SIP. 256 For example, Denial of Service attack against the server by 257 unauthenticated users, to exhaust the available TSGNs, is among the 258 obvious attacks. Minimally, the digest authentication mechanism used 259 for SIP registrations can apply to the ALLOCATE method for 260 authentication between domains. 262 Gateways SHOULD avoid exposing the TSGN in the INVITE methods they 263 generate after receiving the PSTN call setup. This will help 264 somewhat to avoid session hijacking by callers calling TSGN numbers 265 for sessions they have not been assigned. In the absence of 266 authentication in the PSTN, however, this problem will still remain; 267 February 2002 269 gateways which have administrative relationships with all PSTN 270 entities authorized to transit through them SHOULD verify at least 271 the PSTN source of the call. 273 5 IANA Considerations 275 This document defines a new SIP method name (ALLOCATE), and a new 276 header field (Allocate-For). 278 6 Message Examples 280 In the following example, the gateway gw58.ca.pstn-gws.example 281 binds, for 180 seconds, the TSGN +13235554258 to the Contact 282 addresses in the request. 284 ALLOCATE sip:gw58.ca.pstn-gws.example SIP/2.0 285 Via: SIP/2.0/UDP nj.mobility-manager.example:5060 286 From: 287 To: 288 Call-ID: 1234567890@nwelem47.nj.mobility-manager.example 289 CSeq: 1 ALLOCATE 290 Max-Forwards: 70 291 Contact: "Alice at work" ; expires=180 292 Contact: "Alice in the lab" ; expires=180 293 Allocate-For: 294 Content-Length: 0 296 SIP/2.0 200 OK 297 Via: SIP/2.0/UDP nj.mobility-manager.example:5060 298 From: 299 To: 300 Call-ID: 1234567890@nwelem47.nj.mobility-manager.example 301 CSeq: 1 ALLOCATE 302 Contact: ; expires=180 303 Content-Length: 0 305 7 References 307 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 308 9, RFC 2026, October 1999. 309 [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session Initiation 310 Protocol", draft-ietf-sip-rfc2543-bis-08, February 2002. Work in 311 progress. 312 [3] F. Cuervo et al, "Megaco Protocol Version 1.0", RFC 3015, 313 November 2000. 314 [4] P. Falstrom, "E.164 number and DNS", RFC 2916, September 2000. 315 [5] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 316 1997. 317 [6] J. Rosenberg, H. Salama, M. Squire, "Telephony Routing over IP 318 (TRIP)", RFC 3219, January 2002. 319 [7] S. Hanna, B. Patel, and M. Shah, "Multicast Address Dynamic 320 Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. 322 February 2002 324 [8] H. Schulzrinne and A. Vaha-Sipila, "URIs for Telephone Calls", 325 draft-antti-rfc2806bis-02.txt, February 2002. Work in progress. 327 8 Authors' Addresses 329 Triantafyllos Alexiou 330 101 Crawfords Corner Rd 331 Room: 4J-513A 332 Holmdel, NJ 07733 333 Tel: +1 732 332-5559 334 Email: akis@lucent.com 336 Jonathan Lennox 337 101 Crawfords Corner Rd 338 Room: 4F-516 339 Holmdel, NJ 07733 340 Tel: +1 732 332-6063 341 Email: lennox@lucent.com 343 Kazutaka Murakami 344 101 Crawfords Corner Rd 345 Room: 4G-512 346 Holmdel, NJ 07733 347 Tel: +1 732 949-6028 348 Email: kmurakami@lucent.com 350 9 Acknowledgements 352 We thank Henning Schulzrinne, Tom La Porta, and Oliver Haase for 353 their comments on this proposal. 355 10 IPR Statement 357 Lucent Technologies may have intellectual property rights on the 358 example scenario described in section 2. The ALLOCATE method itself 359 is unencumbered to the best of our knowledge. 361 11 Full Copyright Statement 363 Copyright (c) The Internet Society (2002). All Rights Reserved. 365 This document and translations of it may be copied and furnished to 366 others, and derivative works that comment on or otherwise explain it 367 or assist in its implementation may be prepared, copied, published 368 distributed, in whole or in part, without restriction of any 369 kind, provided that the above copyright notice and this paragraph 370 are included on all such copies and derivative works. However, this 371 document itself may not be modified in any way, such as by removing 372 the copyright notice or references to the Internet Society or other 373 Internet organizations, except as needed for the purpose of 374 developing Internet standards in which case the procedures for 375 defined in the Internet Standards process must be followed, or as 376 February 2002 378 required to translate it into languages other than English. 380 The limited permissions granted above are perpetual and will not be 381 revoked by the Internet Society or its successors or assigns. 383 This document and the information contained herein is provided on an 384 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 385 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 386 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 387 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 388 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.