idnits 2.17.1 draft-vanelburg-martini-friends-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 28, 2010) is 5105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5486' is mentioned on line 214, but not defined == Unused Reference: 'RFC3455' is defined on line 378, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3455 (Obsoleted by RFC 7315) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARTINI Working Group J. van Elburg 3 Internet-Draft Detecon International Gmbh 4 Intended status: Informational B. Chatras 5 Expires: October 30, 2010 France Telecom Orange 6 M. Dolly 7 AT&T Labs, Inc. 8 T. Dwight 9 Verizon 10 J. van Geel 11 Belgacom 12 C. Holmberg 13 Ericsson 14 K. Drage 15 P. Mourot 16 Alcatel-Lucent 17 April 28, 2010 19 Session Initiation Protocol (SIP): single registration for Multiple 20 Address of Record (AoR) reachabiliTy InformatioN, with FedeRated Intra 21 ENterprise Domain name Setup 22 draft-vanelburg-martini-friends-00 24 Abstract 26 The Martini Working Group is defining a mechanism for SIP IP-PBX type 27 devices to REGISTER and obtain SIP service for E.164-based Address of 28 Records. In doing so it has selected a solution that is not 29 compatible with the solution that was specified in ETSI TISPAN and 30 3GPP for subscription based business trunking. The latter solution 31 not only covers E.164 numbers but also handles non-E.164 numbers and 32 alphanumeric AOR's. 34 This document defines a extension of the martini mechanism that 35 allows it to be used also with ETSI TISPAN and 3GPP standard 36 subscription based business trunking arrangements. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 30, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 3.1. AOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 3.2. Alphanumeric SIP URI . . . . . . . . . . . . . . . . . . . 5 89 3.3. Implicit Registration . . . . . . . . . . . . . . . . . . 6 90 3.4. Reachability Information . . . . . . . . . . . . . . . . . 6 91 3.5. SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 92 3.6. BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 3.7. domain federation . . . . . . . . . . . . . . . . . . . . 6 94 4. Overview of the FRIENDS solution . . . . . . . . . . . . . . . 6 95 4.1. The issue in short . . . . . . . . . . . . . . . . . . . . 6 96 4.2. Registration signalling . . . . . . . . . . . . . . . . . 7 97 4.3. SSP Processing of Inbound Requests targeted at an 98 implicitly registered AOR assigned to a bulk contact . . . 8 99 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 100 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 101 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 103 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 104 8.2. Informative references . . . . . . . . . . . . . . . . . . 9 105 Appendix A. Revision Information . . . . . . . . . . . . . . . . 9 106 A.1. version 00, MARTINI . . . . . . . . . . . . . . . . . . . 10 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 109 1. Introduction 111 In many deployed SIP Service Provider (SSP) architectures, it is 112 common to use REGISTER requests to provide the reachability 113 information for IP-PBXs, instead of DNS-based resolution and routing. 114 An IETF-defined mechanism for doing so is being worked on in the 115 Martini Working Group, in [draft-gin]. 117 The actual end users that are served by the IP-PBX will most likely 118 register themselves with the IP-PBX, if that IP-PBX is connecting end 119 users using the SIP protocol. This means that end users register 120 with the IP-PBX so the IP-PBX knows where to reach them, additionally 121 the IP-PBX will have registered with the SSP using a bulkcontact 122 which allows the SSP to know where to reach end users that are 123 assigned to that IP-PBX in the SSP systems. 125 Taking one step back and considering the normal SIP arrangement 126 without any IP-PBX, in this case the usual setup in which SIP is used 127 is that any user's AOR would be handled by a proxy that is 128 responsible for handling requests for the domain indicated by the 129 hostport portion of the AOR. Note that this does not imply 130 exclusivity of this proxy instance as there may be a farm of 131 cooperating proxies all handling requests for that same domain. The 132 users registered individual reachability information with the proxy 133 instance assigned during registration, which would then route 134 incoming requests accordingly. 136 Fast forwarding again to the case where the IP-PBX provides 137 reachability information to the SSP's proxy using a REGISTER request. 138 The problem that martini is tasked to resolve is that current 139 solutions like the one standardised by ETSI/3GPP or the ones 140 specified by the SIP Forum lack an explicit indication during 141 registration, this is reflected in the name of the work group 142 "Multiple AoR reachabiliTy InformatioN Indication", a description can 143 be found in [draft-ietf-martini-reqs]. 145 The current proposed Martini mechanism described in 146 [draft-ietf-martini-gin] only supports E.164-based AoR's, however in 147 actual deployments private-extension or "local" numbers are used for 148 hosted and carrier-provided intra-Enterprise calling services, and 149 domain-scoped alphanumeric URIs may become more popular in the near 150 future. Neither of these forms of AoRs are supported by the current 151 Martini mechanism. 153 Furthermore the current martini routing mechanism provides a solution 154 that is not compatible with the solution that is standardised in ETSI 155 TISPAN and 3GPP for subscription based business trunking. That 156 solution not only supports E.164 numbers but also handles non-E.164 157 numbers and alphanumeric AOR's. 159 The current martini mechanism described in [draft-ietf-martini-gin] 160 is said to put less requirements on the SIP IP-PBX in terms of 161 configuration and might therefore put less requirements on simple IP- 162 PBX regarding configuration and be more appropriate in limited 163 deployments where there is no need for addressing users beyond 164 traditional E.164 numbers. That might well be, but it also is only 165 representing a small fraction of the market as it ignores the only 166 service provider standard available today. 168 This document therefore proposes a way forward whereby two modes of 169 operation can be signalled independently, in a manner consistent with 170 (RFC3261 [RFC3261]). 172 ETSI TISPAN defines Next Generation Networks (NGN) which uses the 173 3rd-Generqation Partnership Project (3GPP) IMS (IP Multimedia 174 Subsystem) which in turn uses SIP (RFC3261 [RFC3261]) as its main 175 signalling protocol. (For more information on the IMS, a detailed 176 description can be found in 3GPP TS 23.228 [3GPP.23.228] and 3GPP TS 177 24.229 [3GPP.24.229].) 179 2. Conventions 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in BCP 14, RFC 2119 184 [RFC2119]. 186 3. Definitions 188 3.1. AOR 190 address-of-record, as defined by RFC 3261: a URI by which the user is 191 canonically known (e.g., on their business cards, in the From header 192 field of their requests, in the To header field of REGISTER requests, 193 etc.). 195 3.2. Alphanumeric SIP URI 197 a SIP AoR which does not identify a global E.164 number or local- 198 number. 200 3.3. Implicit Registration 202 implicitly providing the reachability information for something other 203 than the AoR explicitly indicated in the Register transaction. 205 3.4. Reachability Information 207 a set of URI's identifying the host and path of Proxies to reach that 208 host; like any URI, these URI's may identify the specific connection 209 transport, IP Address, and port information, or they may only 210 identify FQDN's. 212 3.5. SSP 214 SIP Service Provider, as defined by [RFC5486]. 216 3.6. BC 218 bulk contact, a contact address that is used as a reachability 219 address for multiple AOR. 221 3.7. domain federation 223 Domain federation constitutes an architecture whereby SSP and the 224 enterprise owning a PBX connected to the SSP's network, together 225 manage a specific domain. 227 4. Overview of the FRIENDS solution 229 4.1. The issue in short 231 The current martini solution based on the GIN draft solves only a 232 subspace of the total SIP trunking problemspace. It does so by 233 staying carefully within the boundaries of what can be made to work 234 with simple SIP proxies, taking for granted that the solution is 235 suboptimal when more complicated deployments need to be served 236 involving private numberplans, alphanumeric naming schemes etc. 238 It chooses a solution where Request-URI is rewritten with the PBX- 239 contact for routing as is also done normally on the last hop to the 240 UAS, this means that such Request-URI rewriting is also imposed on 241 the intermediary hop between the SSP and the SIP IP-PBX. It has been 242 recognised in earlier discussions that this is in fact an error in 243 SIP to use Request-URI rewriting for request routing. In fact 244 RFC3261 already introduced a mechanism to overcome this on 245 intermediary hops for which it provides the Route header field. The 246 Route header field is part of the core routing mechanism of SIP 247 RFC3261 compliant proxies. 249 Other standards have been developed (especially ETSI TISPAN TS 182 250 025 and related work in 3GPP 24229) to serve such more complicated 251 scenarios, the solution is build on placing the PBX-contact in the 252 Route header field and leaving the Request-URI unchanged. There 253 exist on the market place already a number of IP-PBX that expect the 254 AOR in the Request-URI and its own contact address in the Route 255 header field. 257 Both mechanisms have their area of applicability and are superior in 258 their respective application niches. 260 Building on these facts the conclusion must be that it would be 261 beneficial to combine both mechanisms and allow both routing variants 262 to be supported. 264 4.2. Registration signalling 266 This document extends the martini mechanism by distinguishing basic 267 and federated bulk contact routing. 269 A PBX can announce that it supports basic bulk contact routing, by 270 registering with bulk contact parameter set to the value "basic" in 271 the registered contact. 273 A PBX can announce that it supports federated bulk contact routing, 274 by registering with bulk contact parameter set to the value 275 "federated" in the registered contact. 277 A PBX can announce that it supports both basic and federated bulk 278 contact routing, by including two occurrences of the bulk contact 279 parameter in the register request. 281 A PBX that supports basic bulk contact routing, supports and 282 understands Request-URI's resulting from the current GIN model. This 283 is good for simple PBX's or undemanding non-IMS deployments and it 284 works great with numbers. 286 A PBX that supports federated bulk contact routing can handle cases 287 where the enterprise domain to which the PBX belongs is federated 288 with the SSP. And hence it is OK to be treated as a next hop proxy 289 and receive the PBX-contact on the Route header field and a Request- 290 URI where the hostpart portion contains the federated domain name. 291 The latter allows delivery of the AOR in the Request-URI to the IP- 292 PBX. 294 Upon receipt of a register request the SSP determines whether bulk 295 contact routing applies and which variant to use based on the 296 presence of the bulk contact parameter in the registration. 298 4.3. SSP Processing of Inbound Requests targeted at an implicitly 299 registered AOR assigned to a bulk contact 301 When a request enters the SSP that belongs to an implicitly 302 registered AOR assigned to a bulk contact the SSP's proxy checks 303 whether the bulk contact registered for basic or federated bulk 304 contact routing. 306 If the bulk contact parameter indicated support for basic bulk 307 contact routing or if the bulk contact was absent but the provisioned 308 bulk contact indicator indicated support for basic bulk contact 309 routing the SSP proxy proceeds with behaviour as specified in 310 [draft-ietf-martini-gin-01]. 312 If the bulk contact parameter indicated support for federated bulk 313 contact routing or if the bulk contact parameter was absent but the 314 provisioned bulk contact indicator indicated support for federated 315 bulk contact routing, then the SSP proxy will proceed by placing the 316 registered PBX-contact at the end of the Route header field and leave 317 the Request-URI unchanged. 319 The above behaviour makes sure that federated routing is only used in 320 cases where it is certain that the SSP configured its system 321 knowingly to perform that behaviour for a certain customer. He will 322 make sure that both sides are configured properly. This addresses 323 the issues that people raised with solutions based on placing the 324 contact on the Route header field in terms of problems with domain 325 ownership. 327 5. Security considerations 329 tbd 331 6. IANA considerations 333 tbd 335 7. Acknowledgments 337 Thanks to Adam Roach and Hadriel Kaplan for (unknowingly) providing 338 text which we used for inspiration [draft-shaken], [draft-gin], 339 [draft-olive]. Thanks to Martien Huysmans for providing text for the 340 definition of the federated concept. 342 8. References 344 8.1. Normative references 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 350 A., Peterson, J., Sparks, R., Handley, M., and E. 351 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 352 June 2002. 354 8.2. Informative references 356 [ETSI.181.019] 357 ETSI, "Telecommunication and Internet converged Services 358 and Protocols for Advanced Networking (TISPAN); Business 359 Communication Requirements", ETSI TS 181 019 V2, 360 July 2007. 362 [ETSI.182.025] 363 ETSI, "Telecommunications and Internet converged Services 364 and Protocols for Advanced Networking (TISPAN);Business 365 trunking;Architecture and functional description", ETSI 366 TS 182 025 V2, Sept 2008. 368 [3GPP.23.228] 369 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP 370 TS 23.228 V8. 372 [3GPP.24.229] 373 3GPP, "Internet Protocol (IP) multimedia call control 374 protocol based on Session Initiation Protocol (SIP) and 375 Session Description Protocol (SDP); Stage 3", 3GPP 376 TS 24.229 V8. 378 [RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private 379 Header (P-Header) Extensions to the Session Initiation 380 Protocol (SIP) for the 3rd-Generation Partnership Project 381 (3GPP)", RFC 3455, January 2003. 383 Appendix A. Revision Information 384 A.1. version 00, MARTINI 385 1. 2010-04-27, Initial version 387 Authors' Addresses 389 Hans Erik van Elburg 390 Detecon International Gmbh 391 Oberkasselerstrasse 2 392 Bonn 53227 393 Germany 395 Email: ietf.hanserik@gmail.com 397 Bruno Chatras 398 France Telecom Orange 399 38-40 rue du General Leclerc 400 Issy Les Moulineaux 92794 401 France 403 Email: bruno.chatras@orange-ftgroup.com 405 Martin Dolly 406 AT&T Labs, Inc. 407 200 Laurel Ave. 408 Middletown, NJ 409 USA 411 Email: md3135@att.com 413 Timothy Dwight 414 Verizon 415 2400 North Glenville Drive 416 Richardson, Texas 417 USA 419 Email: timothy.dwight@verizon.com 420 Jan van Geel 421 Belgacom 422 Koning Albert II laan 423 Brussels 1030 424 Belgium 426 Email: jan.van.geel@belgacom.eb 428 Christer Holmberg 429 Ericsson 430 Hirsalantie 11 431 Jorvas 02420 432 Finland 434 Email: christer.holmberg@ericsson.com 436 Keith Drage 437 Alcatel-Lucent 438 The Quadrant, Stonehill Green, Westlea 439 Swindon SN5 7DJ 440 UK 442 Email: drage@alcatel-lucent.com 444 Patrick Mourot 445 Alcatel-Lucent 446 1 rue du Dr. A. Schweitzer 447 Illkirch 67400 448 France 450 Email: patrick.mourot@alcatel-lucent.com