idnits 2.17.1 draft-haluska-sipping-directory-assistance-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (August 15, 2011) is 4638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5244' is mentioned on line 3163, but not defined ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) == Outdated reference: A later version (-09) exists of draft-yu-tel-dai-07 == Outdated reference: A later version (-15) exists of draft-york-sipping-p-charge-info-07 -- Duplicate reference: RFC5079, mentioned in 'RFC5009', was also mentioned in 'RFC5079'. Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Haluska 2 Internet Draft Telcordia 3 Intended status: Informational R. Ahern 4 Expires: February 2012 AT&T Customer Information Services 5 Marty Cruze 6 CenturyLink 7 C. Blackwell 8 Verizon 9 August 15, 2011 11 Considerations for Information Services and Operator Services Using 12 SIP 13 draft-haluska-sipping-directory-assistance-11.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. This document may not be 22 modified, and derivative works of it may not be created, and it may 23 not be published except as an Internet-Draft. 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. This document may not be 27 modified, and derivative works of it may not be created, except to 28 publish it as an RFC and to translate it into languages other than 29 English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on February 15, 2009. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. 60 Abstract 62 Information Services are services whereby information is provided in 63 response to user requests, and may include involvement of a human or 64 automated agent. A popular existing Information Service is Directory 65 Assistance (DA). Moving ahead, Information Services providers 66 envision exciting multimedia services that support simultaneous 67 voice and data interactions with full operator backup at any time 68 during the call. Information Services providers are planning to 69 migrate to SIP based platforms, which will enable such advanced 70 services, while continuing to support traditional DA services. 72 Operator Services are traditional PSTN services which often involve 73 providing human or automated assistance to a caller, and often 74 require the specialized capabilities traditionally provided by an 75 operator services switch. Market and/or regulatory factors in some 76 jurisdictions dictate that some subset of Operator Services continue 77 to be provided going forward. 79 This document aims to identify how Operator and Information Services 80 can be implemented using existing or currently proposed SIP 81 mechanisms, to identity existing protocol gaps, and to provide a set 82 of Best Current Practices to facilitate interoperability. For 83 Operator Services, the intention is to describe how current operator 84 services can continue to be provided to PSTN based subscribers via a 85 SIP based operator services architecture. It also looks at how 86 current operator services might be provided to SIP based subscribers 87 via such an architecture, but does not consider the larger question 88 of the need for or usefulness or suitability of each of these 89 services for SIP based subscribers. 91 This document addresses the needs of current Operator and 92 Information Services providers; as such, the intended audience 93 includes vendors of equipment and services to such providers. 95 Table of Contents 97 1. Introduction...................................................4 98 2. Protocol Gaps..................................................7 99 3. Terminology....................................................7 100 4. High Level Requirements.......................................10 101 4.1. Potential Future Requirements............................13 102 5. Information Services..........................................13 103 6. Operator Services.............................................17 104 6.1. Inter Provider Capabilities..............................19 105 6.2. Inter OISP Capabilities..................................20 106 6.3. Intra OISP Capabilities..................................20 107 6.4. Capabilities Required for Specific Services..............21 108 7. OISP Internal Architecture....................................22 109 8. General Approach..............................................24 110 9. Signaling Mechanisms..........................................26 111 9.1. PSTN Protocol Interworking...............................26 112 9.2. Conveying Application Specific Information...............27 113 9.3. Calling Party's Identity.................................28 114 9.4. Provider Identification..................................30 115 9.4.1. Home Provider.......................................30 116 9.4.2. Intermediate Provider...............................31 117 9.5. Originating Line Information/ANI II Value................33 118 9.6. Trunk Group Identifier...................................34 119 9.7. Identification of PSTN Originated Calls..................36 120 9.8. Dialed Digits............................................36 121 9.9. Retargeting to Identify the Desired Service..............37 122 9.10. Charge Number...........................................38 123 9.11. Access Prefix...........................................38 124 9.12. Signaling of Carrier Information........................39 125 9.13. Transit Network Selection...............................41 126 9.14. Carrier Identification..................................42 127 9.15. Carrier Selection Information...........................43 128 9.16. Passing Whisper.........................................43 129 9.17. Calling Equipment Capabilities and Characteristics......47 130 9.18. Media Server Returning Data to the Application Server...48 131 9.19. Control of Cut Through Direction for PSTN Interworking..49 132 9.20. With Holding of Final Responses.........................50 133 10. Example Call Flow - Directory Assistance.....................50 134 10.1. Basic Flow..............................................50 135 10.2. OISP Drops Out at Call Completion Setup.................59 136 10.3. OISP Drops Out After Call Completion Call is Answered...61 137 10.4. OISP Drops Out After Interaction with Called Party......63 138 10.5. OISP Remains in Path....................................65 139 10.6. Return of Call to OISP..................................67 140 10.7. PSTN Origination........................................68 141 10.8. PSTN Termination........................................71 142 10.9. Call Completion By Releasing Call Back to PSTN..........73 143 11. Operator Services Example Call Flows.........................76 144 11.1. Network Controlled Coin Calls...........................76 145 11.2. Busy Line Verification and Interrupt....................83 146 11.2.1. PSTN Target........................................84 147 11.2.2. SIP Target.........................................86 148 11.3. Inward Calls............................................89 149 11.4. Intercept...............................................90 150 11.4.1. Intercept Request Via SIP..........................90 151 11.4.2. Intercept Request Via PSTN.........................93 152 11.5. Operator Assisted Collect Call..........................95 153 11.6. Operator Assisted Third Party Billing..................102 154 11.7. Offerless INVITE.......................................106 155 12. Summary and Conclusions.....................................108 156 13. Security Considerations.....................................109 157 14. IANA Considerations.........................................109 158 15. Acknowledgements............................................109 159 16. References..................................................110 160 16.1. Normative References...................................110 161 16.2. Informative References.................................110 162 Author's Addresses..............................................114 164 1. Introduction 166 Information Services are services whereby information is provided in 167 response to user requests. This may include involvement of a human 168 or automated agent. Information Services may include call completion 169 to a requested telephone number and other extensions provided on 170 behalf of the owner of the information, such as assistance with 171 purchases. The users normally access the Information Services by 172 dialing an appropriate dialing sequence and verbally requesting an 173 operator or automated system for the information. Examples of such 174 dialing sequences for directory assistance currently include "411" 175 or "1-NPA-555-1212" in North America, or "118xxx" in many European 176 countries. Dialing sequences for operator services in North America 177 often include "0" either by itself or as a prefix. In Europe the 178 dialing sequence varies by country, but may include "00", or "100" 179 plus additional digits depending on the service being requested. The 180 users may also request information through other access methods, 181 such as chat (IM), email, Web (HTTP) or SMS initiated requests. The 182 Information may be delivered to the user via any mode, such as 183 verbal announcements, chat (IM), email, Web (HTTP), MMS, or SMS. 185 A popular existing Information Service is Directory Assistance (DA). 186 DA is a well known service in today's PSTN, and is generally 187 identified with "411" or "NPA-555-1212" type services in North 188 America. Today's DA services provide a user with telephone number 189 associated with a name and locality provided by the user, can 190 complete the call for the user, and can send SMS with the listing to 191 the user's wireless phone. Other Information Services provide the 192 user with a wide range of information, such as movie listings and 193 the weather. 195 Moving ahead, Information Services providers envision exciting 196 multimedia services that support simultaneous voice and data 197 interactions with full operator backup at any time during the call. 198 For instance, a directions Information Service may announce and 199 display directions to the requested listing, with the option for the 200 caller to request transfer to an operator with the latest call 201 context information. 203 Operator Services are traditional PSTN services which often involve 204 providing human or automated assistance to a caller, and often 205 require the specialized capabilities traditionally provided by an 206 operator services switch. Market and/or regulatory factors in some 207 jurisdictions dictate that some subset of Operator Services continue 208 to be provided going forward. Some examples of such services include 209 collect calls, third party billed calls, and busy line verification. 211 Operator and Information Services providers are planning to migrate 212 to SIP based platforms, which will enable such advanced services, 213 while continuing to support traditional DA services. 215 Implementing Operator and Information Services with SIP will require 216 the exchange of certain information, and possibly the use of 217 specialized capabilities which are not normally required for other 218 types of calls. This document aims to identify such information, and 219 stimulate discussion about how this information could be exchanged. 220 Existing mechanisms will be used where appropriate, and currently 221 existing proposals will be favored over new extensions. 223 Some of the services discussed in this document are based on 224 Operator Services offered in North America. Also, many of the 225 signaling issues described are based on North American PSTN 226 signaling. However, the ideas in this document are not intended to 227 be exclusive to North America, and are intended to be useful in 228 other environments as well. 230 For Operator Services, the intention is to describe how current 231 operator services can continue to be provided to PSTN based 232 subscribers via a SIP based operator services architecture. It also 233 looks at how current operator services might be provided to SIP 234 based subscribers via such an architecture, but does not consider 235 the larger question of the need for or usefulness or suitability of 236 each of these services in such an environment. Specifically, many of 237 the constraints and assumptions regarding access to wireline 238 services via a copper loop, under which services such as Busy Line 239 Verification, Interrupt, and services where the operator controls 240 the "line" make sense, do not have natural parallels in a SIP based 241 environment. Some of these services are treated here for 242 completeness. 244 A basic architecture utilizing an application server as the primary 245 controller, performing third party call control to route incoming 246 calls among media servers, operator workstations, etc. is described. 247 Interface to the PSTN is described using PSTN gateways which 248 interwork between ISUP or MF signaling and SIP. 250 Operator services in the North American PSTN often utilize MF 251 trunks. As there is currently no specific specification for MF/SIP 252 interworking, we assume that the PSTN gateway performs an internal 253 MF to ISUP translation. 255 The use of existing SIP mechanisms is described where possible. Some 256 of the main mechanisms described include third party call control, 257 the REFER method with several extensions (e.g. Replaces), the Join 258 header, Netann, and some of the ongoing work in the MEDIACTRL 259 working group. 261 It is assumed that appropriate business relationships are in place 262 between involved providers, and that the providers involved have 263 trust relationships as described in [RFC3325]. In other words, this 264 document does not assume general operation on the open internet, but 265 rather between sets of providers with appropriate business and trust 266 relationships. Individual providers may decide to provide handling 267 for other requests, but this is beyond the scope of this document. 269 2. Protocol Gaps 271 As indicated above, one of the purposes of this document is to identify 272 gaps in existing protocols, with respect to implementing Directory 273 Assistance and Operator Services in SIP. Several gaps have been 274 identified, and these are listed in this section of the document for 275 convenience to the reader. These include: 277 o Charge Number 279 o Coin Deposit Tones 281 o Carrier Information: ISUP TNS, CIP, and CSI parameters, and 282 "cic", "dai" tel URI parameters 284 3. Terminology 286 This section defines terms that will be used to discuss Information 287 and Operator Services. 289 "0-" ("zero minus") Dialing - Invocation of Operator Services by 290 dialing "0" with no further digits. 292 "0+" ("Zero Plus") Dialing - Invocation of Operator Services by 293 dialing "0" followed by a phone number. 295 Application Server (AS) - An Application Server is a server 296 providing value added services. It controls SIP sessions on behalf 297 of the services supported by the service provider's network. 299 Back End Automation - Back End Automation refers to automation of 300 the function that provides listing information to the caller. This 301 includes playing a verbal announcement with the listing information, 302 and may also include prompting the user for additional service 303 requests (e.g., call completion service). 305 Branding - Branding is a service where customized announcements are 306 provided to the caller to identify the service provider. For 307 example, if the service is provided to a Home Provider's subscribers 308 by a third party provider, branded service might include a message 309 thanking them for using that Home Provider. Thus the user experience 310 is that the service is provided by their Home Provider rather than 311 some third party. Branding can be influenced by a number of factors, 312 including but not limited to the identity of the caller's Home 313 Provider, or of other providers involved in the call. 315 Call Completion - Call Completion is a service where a call is 316 initiated by the provider on behalf of the user. For example, in the 317 DA service, once the DA provider has identified the requested 318 listing, it may offer to complete the call for the caller, usually 319 for some additional fee. This relieves the user from having to 320 remember the number and then dial it. 322 DA Provider - The DA provider is the provider of DA services to end 323 users. Since DA services are a subset of IS services, a DA provider 324 is also an IS provider, and the definition of IS provider holds true 325 for DA provider, except that the scope of services is limited to DA 326 services. 328 Front End Automation - Front End Automation refers to automation of 329 the initial customer contact, whereby a branded announcement may be 330 played, a prompt is played to the user, and the user's spoken 331 request is recorded. Speech recognition and querying for the listing 332 information are performed as part of front end automation. 334 Home Provider - The service provider who is responsible for 335 providing voice services to the calling customer. This is the 336 service provider that has the business relationship with the calling 337 customer. The identity of the home provider influences call 338 processing treatment, such as branding and operator queue selection. 340 Home Subscriber Server (HSS) - The Home Subscriber Server is an IMS 341 network element similar to a Home Location Register. It is a 342 database containing information about the subscriber, user 343 equipment, filter criteria for call processing triggers, etc. 345 Information Services (IS) Provider - The IS provider is the provider 346 of Information Services to end users. The Information Services 347 provider provides retail services directly to end users, and 348 provides wholesale services to other service providers. 350 Intermediate Provider - In the context of this document, an 351 Intermediate Provider is a provider which has agreements with home 352 providers to handle OIS requests, and with OISPs which actually 353 provide the requested services. Note that some home providers will 354 have direct relationships with OISPs, rather than using an 355 Intermediate Provider. Intermediate Providers are the targets of SIP 356 requests from home providers since they are involved when a home 357 provider does not have a direct relationship with an OISP. 358 Intermediate Providers perform retargeting of received SIP requests 359 toward the OISP. Intermediate providers make service level 360 decisions, such as receiving requests for a service (such as DA 361 calls) from other networks, deciding which provider will actually 362 provide the service, and forwarding the request to that provider, 363 retargeting the Request-URI as necessary. 365 Layer 3 connectivity - This refers to IP connectivity, for example 366 as provided by an Internet Service Provider or Managed IP service 367 provider. If one entity has Layer 3 connectivity to another entity, 368 then it can route packets to that entity. This does not imply 369 anything about any physical path between the entities. Nor does it 370 imply any application layer connectivity between the entities. 372 Media Server - A Media Server is a general-purpose platform for 373 executing real-time media processing tasks. Examples of typical 374 functions performed by media servers include playing announcements, 375 collecting speech and/or DTMF digits, and performing conferencing 376 functions. 378 Operator and Information Services Provider (OISP) - In this 379 document, this term refers to an Information Services Provider, 380 Directory Assistance Provider, or Operator Services Provider, 381 depending on the context. This term is used for brevity. We are also 382 defining this to be an adjective, thus "OISP services" is a 383 convenient, intuitive way to say "Operator and Information 384 Services". 386 Operator Services - Traditional PSTN services which often involve 387 providing human or automated assistance to a caller, and often 388 require the specialized capabilities traditionally provided by an 389 operator services switch. Some examples of such services include 390 collect calls, third party billed calls, and busy line verification. 392 Retail OIS service - A retail OIS service is one which is provided 393 to a user by the user's Home Provider. 395 SIP Layer connectivity - When two SIP service providers interconnect 396 for the purpose of exchanging SIP sessions or calls, they are said 397 to have SIP layer connectivity to one another. 399 Time Division Multiplexed (TDM) Local Exchange Carriers (LECs) - 400 ATDM LEC provides local exchange service to end users utilizing TDM- 401 based switching systems. 403 Transit Provider - In the context of this document, a transit 404 provider simply "moves calls", and has no concept of OIS services. 405 It may perform SIP rerouting of the request, but does not perform 406 SIP retargeting. Such a provider is used when a provider cannot 407 directly route calls to another provider. For example, an 408 Intermediate Provider might use a Transit Provider if for some 409 reason (e.g. error condition) it cannot route a call directly to an 410 OISP. This is in contrast to an Intermediate Provider (see 411 definition earlier in this section). 413 Whisper - During front end automation, the OIS-MS will record and 414 may time compress the caller's perhaps meandering speech into what 415 is known as the "Whisper". This is intended to be played into a 416 human operator's ear, should the call be referred to an operator, to 417 avoid the operator from having to prompt the caller again. The 418 whisper is obtained during the front end automation, and saved as an 419 audio file. 421 Wholesale OIS service -A Wholesale OIS Service is one which is 422 provided to a user by a Service Provider other than the user's Home 423 Provider. 425 Zero Minus ("0-") Dialing - Invocation of Operator Services by 426 dialing "0" with no further digits. 428 Zero Plus ("0+") Dialing - Invocation of Operator Services by 429 dialing "0" followed by a phone number. 431 4. High Level Requirements 433 In addition to all-IP scenarios, it must be possible to support 434 interworking with existing PSTN and wireless based providers, via 435 both SS7 and MF interconnections. 437 It must be possible to support collection of usage information. This 438 includes both online and offline usage information. It must be 439 possible to perform usage collection for all actions associated with 440 a particular call, and further to be able to correlate actions 441 across multiple provider elements and across providers. 443 It must be possible to support multiple Operator and Information 444 Services Providers (OISPs) per originating provider. The choice as 445 to which OISP to be used could be on a per subscriber basis, or on 446 other criteria. 448 It must be possible to support multiple OISP providers per call. For 449 example, one provider might be used for front end automation, and 450 another used for operator assistance. 452 It must be possible to provide an automated announcement to the 453 user, and prompt the user for the type of query and query 454 information. 456 It must be possible to pass a "whisper" to the operator workstation. 458 It must be possible to connect the user to a human operator. 460 It must be possible to provide an automated announcement of the 461 requested information. 463 It must be possible to prompt the user for call completion. 465 It must be possible to perform call completion. 467 It must be possible to support the case where OIS services are 468 provided by the caller's Home Provider. This scenario is known in 469 the OIS industry as the Retail scenario. In this case, the caller's 470 Home Provider is also an OISP, and provides OIS service to its own 471 subscribers. This is illustrated in the following figure: 473 +--------+ +--------------------+ 474 | Caller |----| Home +------+ | 475 | | | Provider | OISP | | 476 | | | +------+ | 477 +--------+ +--------------------+ 479 Figure 1 Services Provider by Home Provider 481 It must be possible to support the case where OIS services are 482 provided by a direct third party provider. In this scenario, the 483 OISP is a third party service provider, and there is direct SIP 484 layer connectivity as well as business relationships between the 485 calling user's provider and the OISP. This is illustrated in the 486 following figure: 488 +--------+ +----------+ +------+ 489 | Caller |----| Home |---| OISP | 490 | | | Provider | | | 491 +--------+ +----------+ +------| 493 Figure 2 Services Provider by a Direct Third Party Provider 495 It must be possible to support the case where services are provided 496 by an indirect third party provider. In this scenario, the OISP is a 497 third party provider, but the caller's Home Provider does not have 498 direct SIP connectivity to the OISP. Further, it's possible that it 499 has no business relationship with the OISP. The caller's provider 500 routes the call to a provider with whom it does have a relationship, 501 referred to in this document as an "intermediate provider", and this 502 intermediate provider in turn routes either to the OISP, with which 503 it has a relationship, or there could be multiple intermediate 504 providers. This is illustrated in the following figure: 506 +--------+ +--------+ +---------+ +------+ 507 | Caller | |Home | | Inter- | | OISP | 508 | |----|Provider|---| mediate |---| | 509 | | | | | Provider| | | 510 | | | (A) | | (B) | | (C) | 511 +--------+ +--------+ +---------+ +------+ 513 Figure 3 Services Provided by an Indirect Third Party Provider 515 It must be possible to support the case where transit providers are 516 included between any other providers involved in the call. The 517 transit provider only "moves calls" between other providers, and is 518 involved in no other way with OIS services. I.e., it simply forwards 519 the call towards the destination, without making any service level 520 decisions, in contrast to an Intermediate provider as described 521 previously. This is illustrated in the following figure: 523 +--------+ +--------+ +--------+ +---------+ +------+ 524 | Caller | |Home | |Transit | | Inter- | | OISP | 525 | |----|Provider|---|Provider|---| mediate |---| | 526 | | | | | | | Provider| | | 527 | | | (A) | | (B) | | (C) | | (D) | 528 +--------+ +--------+ +--------+ +---------+ +------+ 530 Figure 4 Involvement of a Transit Provider 532 It must be possible to support both Information Services as well as 533 Operator Services. Examples of Operator services include Operator 534 Intercept, Busy Line Verification, Call Restrictions, etc. 536 4.1. Potential Future Requirements 538 The following are potential future requirements. 540 Operation via the general internet, not specific to any particular 541 SDO's architecture, and not depending on any protocol extensions 542 specific to those architectures, should be supported. 544 It must be possible to support non voice initiated Information 545 Services requests. Possible examples include chat (IM), email, Web 546 (HTTP) or SMS initiated requests. In the case that the subscriber 547 makes a purchase via some online auction service, that subscriber 548 can via IM or email request the assistance of an operator. 550 It must be possible to provide an application interface to other 551 types of systems. An example could be a web based API, so that once 552 some online search engine has located some business listing, the 553 services of the Information Services provider could be invoked by 554 the user from the web page. 556 It must be possible to support IPTV interactive services. As 557 multiple services such as IM and telephony are integrated with IPTV, 558 it must be possible to initiate Information Services requests in 559 this context as well. 561 5. Information Services 563 Information Services (IS) are services whereby information is 564 provided in response to user requests. This may include involvement 565 of a human or automated agent. Usually, the user accesses the 566 Information Service by placing a voice call to the automated 567 Information Service and verbally requests the information, such as 568 phone number, movie listings, weather, etc. Frequently, a live 569 operator is attached to recognize the user's verbal request. 570 Sometimes, the user can utilize other access methods, such as SMS, 571 IM, or HTTP-initiated requests. These additional methods are not 572 currently covered in this document. 574 Information Services are often provided on a wholesale basis to Home 575 Providers, and include features such as branded announcements. 577 Directory Assistance (DA) is a specific type of Information Service 578 whereby end users request a telephone number for an entity. 580 Purchase services and Concierge services facilitate the Information 581 Services operator providing assistance to the caller after the 582 listing has been announced and perhaps call completion performed. 583 The call is routed to an Information Services operator who interacts 584 with the customer, offering to help make a purchase. Concierge 585 service is similar; the Information Services operator offers to make 586 e.g. restaurant reservations for the caller. 588 The following represents a list of representative steps taken during 589 the course of a typical DA request and identifies a set of required 590 high level capabilities. 592 1. Initial recognition of an OIS call. At some point, the call needs 593 to be identified as an OIS call, and appropriate routing or other 594 logic must be invoked in order to fulfill the request. This could be 595 based on any number of criteria, including but not limited to 596 analysis of the "address information" - e.g. the digits or Request- 597 URI emitted by the caller's UA. This could occur at any number of 598 places - e.g. in the caller's UA, in a proxy in the home provider, 599 or in some downstream element. 601 2. Identification of the requested service. There are many possible 602 OIS services, and the number of these is only expected to increase 603 as providers respond to customer needs. At some point during call 604 processing it is necessary to identify exactly which service is 605 desired. For example "directory assistance with call completion" is 606 a service where after the listing information is provided to the 607 caller, the option is provided for the call to be placed 608 automatically, so the customer need not hang up, remember the 609 digits, and dial the number. Another example is "directory 610 assistance only", where call completion is not offered. There are 611 multiple factors which could affect the service which is to be 612 offered, and the logic deciding this could be located anywhere along 613 the path to the OIS provider. Some of the information required to 614 make such decisions could include: 616 o The digits dialed by the caller. 618 o The Request-URI emitted by the caller's UA. 620 o The identity of the calling party, for instance the calling 621 party number. 623 o The charge number associated with the caller's account. 625 o The identity of the calling party's home provider. 627 o The identity of the provider which directly hands off the call 628 to the OISP. 630 o The identity of other provider which the request might 631 traverse 633 o The Originating Station Type, in case the call was originated 634 in the PSTN. 636 o Trunk group information, in case the call was originated in 637 the PSTN. 639 o Capabilities and characteristics of the caller's user 640 equipment. 642 3. Routing of the OIS call. The call must be routed towards an 643 entity which can provide the requested service. Each entity or 644 network handling the call routes it based on the logic located in 645 that provider, and the information currently available. For 646 instance, the home provider may know very little about OIS services, 647 having farmed that service out to another provider. Consequently it 648 might simply route all such calls towards the OIS provider, which 649 decides which service is to be offered. 651 4. Authentication. When one provider passes a call to another 652 provider, there is a need for the providers involved to be sure of 653 each other's identity. This might be through explicit security 654 mechanisms such as mutual TLS or security gateways using IPSec 655 tunnel mode, it might be through reliance on a closed set of trusted 656 interconnected providers, or some other policy set by the providers 657 involved. 659 5. Receipt of the OIS call. The OIS provider needs to be able to 660 receive such calls. 662 6. Querying upstream providers for information. The OISP, or an 663 intermediate provider may require information from an upstream 664 provider. For instance, the capabilities and characteristics of the 665 caller's equipment may be needed in order to influence call 666 processing. 668 7. Selection of automated voice platform. When it has been 669 determined that the call must be routed to an automated voice 670 platform, there are a number of factors to be taken into account to 671 determine an appropriate, available platform for the call. It must 672 be possible to determine an appropriate, available automated voice 673 platform to which the call should be routed. 675 8. Connection of caller to automated voice platform. The OISP must 676 be able to connect the caller to an appropriate automated voice 677 platform. 679 9. Provision of branded announcements. The OISP must be capable of 680 providing custom announcements to the caller based on a number of 681 criteria. For example, it might greet the caller, thanking them for 682 using their Home Provider's service. Though the service is actually 683 provided by the OISP, business arrangements would dictate such 684 branded announcements. 686 10. Query the caller. The OISP must be capable of playing a voice 687 request to the customer asking them for the listing. For example 688 "Name and city, please." 690 11. Recording a spoken request. The OISP must be capable of 691 recording the caller's spoken request. This both for speech 692 recognition, and also for playing back the "whisper" to a human 693 operator should one be required, to prevent having to ask the 694 customer to repeat the request. 696 12. Speech recognition. The OISP must be able to pass the caller's 697 spoken request to speech recognition system, suitable for querying a 698 listing database. 700 13. Listing database query. The OISP must be capable of querying one 701 or more listings databases using the request. 703 14. Decide to use human operator if listing query fails. If the 704 listing query fails, or the speech recognition fails, the OISP must 705 be able to decide to send the call to a human operator. 707 15. Selection of appropriate operator. When it has been determined 708 that the call must be routed to a human operator, there are a number 709 of factors to be taken into account to determine the appropriate 710 operator for the call. It must be possible to determine an 711 available, appropriate human operator to which the call should be 712 routed. 714 16. Routing of call to operator workstation. Once the appropriate 715 operator has been identified, the call must be routed to that 716 operator's workstation. 718 17. Whisper. Once the operator answers the call, the previously 719 recorded request should be played to the operator as a "whisper", 720 prior to connecting the caller to the operator. 722 18. Connection of caller to operator. Once the operator has heard 723 the whisper, the caller can be connected to the human operator. The 724 operator queries the caller for the request, and initiates a query 725 to the listing database. 727 19. Playing listing information. Once the listing information is 728 returned from the database, the caller must be connected to a media 729 resource which speaks the listing information to the caller. 731 20. Prompting for call completion. If the identified service 732 includes call completion, the caller should be prompted for this 733 service, for example by pressing some DTMF key. In such a case, the 734 AS would instruct the MS to prompt the user, and collect any DTMF 735 stimulus from the user. The MS would do so, and would report back to 736 the AS whether the DTMF stimulus was received. 738 21. Call completion. If the caller requests call completion, the 739 call should be automatically initiated for the caller. 741 6. Operator Services 743 Operator Services are traditional PSTN services which often involve 744 providing human or automated assistance to a caller, and often 745 require the specialized capabilities traditionally provided by an 746 operator services switch. Market and/or regulatory factors in some 747 jurisdictions dictate that some subset of Operator Services continue 748 to be provided going forward. 750 This document assumes an architecture with SIP based OISPs, SIP 751 based home providers, and SIP based end users. Since it is necessary 752 to maintain backward compatibility with traditional TDM based 753 providers and end users, these are also considered. It may not be 754 necessary, desirable, or technically feasible to support every 755 existing Operator Service using SIP, or to support both SIP and TDM 756 based end users for all Operator Services. This is the subject of 757 ongoing investigation, and the current iteration of this document 758 assumes that both SIP and TDM based home providers and end users are 759 in scope for these services, unless specifically indicated to the 760 contrary. A future revision may update this assumption based on the 761 findings of the investigation. 763 With respect to Operator Services, this iteration of this document 764 intends to provide an introduction to and descriptions of some of 765 these services, as well as provide some high level requirements. It 766 is intended that the subsequent iteration will build upon this, 767 providing more detailed requirements, suggested SIP mechanisms, and 768 more call flows. 770 Operator Services are typically provided by the requesting party's 771 OISP. In some cases, such as Busy Line Verification, the target or 772 called party's OISP may be involved as well. 774 Next, several traditional Operator Services will be described. As 775 indicated above, the current iteration of this document is silent 776 regarding which of these may or may not be candidates for 777 implementation with SIP, or towards SIP end users. Note that unless 778 specifically indicated, most of these services are traditionally 779 provided by the caller's OISP. 781 Operator Assistance. This allows the caller to perform either "zero 782 minus" or "zero plus" dialing to be connected to a human or 783 automated system for assistance with the call. 785 Collect calls. This allows the caller to request that the called 786 party accept the charges for the call. Typically an OISP utilizes a 787 human operator or automated system to provide this service. 789 Rate Quotes. This allows the caller to request a quote for the cost 790 or rate for specific calls. 792 Third party billed calls. This allows the caller to request that a 793 third party (different than the calling or called party) be 794 contacted and requested to accept charges for the call (although in 795 some limited cases, contacting the third party is not necessary). 797 Busy Line Verification and Interrupt. This allows a caller to have 798 the OISP determine whether a target line is in use, and if so, to 799 "barge in" to the conversation and request whether the target party 800 is willing to accept a call from the caller. This service is 801 initially handled by the caller's OISP, which then contacts the 802 target party's OISP, which is able to perform the verification and 803 interrupt on the target party. 805 Coin Calls. Operator services systems must be able to control TDM- 806 based network controlled coin stations (payphones). This includes 807 monitoring of coin deposit tones (to verify payment) sent from the 808 coin station, as well as sending supervision (control) signals to 809 the coin station. Network controlled coin stations are connected to 810 TDM based end offices via specialized phone lines which support the 811 required signaling. These end offices, in turn, connect to TDM based 812 OISPs using specialized trunks capable of conveying the coin 813 signaling. The OISP monitors and controls the coin station via these 814 trunks. "Smart" coin stations perform coin detection locally and do 815 not require network control, and are not discussed here. This 816 service is provided by the OISP associated with the coin station. 818 Emergency Calls. Sometimes a caller dials "0" instead of the 819 standard emergency dialstring, resulting in placement of an 820 emergency call to the OISP. The OISP must properly route such a call 821 toward the PSAP. This service is provided by the caller's OISP. 823 Calling Card Billing Service. This enables a calling party to bill a 824 call to a calling card number. 826 Commercial Credit Card Billing Service. This enables a calling party 827 to bill a call to a commercial credit card. 829 Directory Assistance (DA). In some contexts, DA is considered as an 830 Operator Service. Within the context of this document, we consider 831 DA as an Information Service, which is related to but distinct from 832 Operator Services. 834 The following sections describe an initial set of basic high level 835 capabilities required for supporting Operator Services. The 836 capabilities for Information Services generally apply for Operator 837 Services as well. This work is currently under study, and a complete 838 set of required capabilities is expected to be identified in the 839 near future. Similarly to the required capabilities for Information 840 Services, the use of existing SIP mechanisms will be investigated 841 for providing these capabilities. 843 6.1. Inter Provider Capabilities 845 Ability to accept requests from other providers. This is the ability 846 to accept incoming OIS requests from other providers, including home 847 providers, intermediate providers, and transit providers. 849 Ability to terminate calls to other providers. This applies to call 850 completion services, as well as other services such as third party 851 billing. 853 6.2. Inter OISP Capabilities 855 These are capabilities between OISPs. 857 Inward connection. This is a call from one OISP to another, e.g. so 858 that the originating OISP may request services from the terminating 859 OISP. One example of this is Busy Line Verification, where the 860 caller calls their own OISP, and this OISP places an "inward" call 861 to the target party's OISP, which would have the capability to 862 perform the verification of the target party. 864 Transfer between OISPs. In this case, one OISP transfers the call to 865 another OISP, to be handled by that OISP, so that the first OISP is 866 no longer in the signaling path. 868 Moving connection from one OISP to another. An example of this case 869 is where one OISP farms out a specific service to another OISP. The 870 first OISP performs initial handling of the call, to determine the 871 desired service. The call is sent to a different OISP with which the 872 first has a relationship. The first OISP remains in the signaling 873 path, and when the provided service is complete, the first OISP 874 determines what if any additional processing may be necessary. This 875 is similar to a third party call control type arrangement. 877 6.3. Intra OISP Capabilities 879 Note that some of the following capabilities may be required for 880 inter OISP scenarios as well; this is the subject of ongoing 881 analysis and is not covered in the current iteration of this 882 document. 884 Placing a caller on hold, possibly with announcements. This is used 885 in many services, including Information Services. 887 Exchanging information between Application Server and Operator 888 Workstations/Automated Platforms. This capability is required 889 whenever an operator workstation or automated platform is used. 890 Because an Operator Workstation interacts with a human user, it is 891 expected that additional information, beyond that which an automated 892 system would exchange with an application server, will be required. 893 Further, several modes of application server control are currently 894 under investigation. The first is where the workstation or automated 895 platform is more or less autonomous, and is capable of initiating 896 calls and directly impacting call processing. The other is more of a 897 master-slave relationship, where the AS is in complete control. The 898 master-slave model requires that more information be exchanged with 899 the AS than does the autonomous model. Other models may be possible. 901 Queuing and call distribution. Resources including human operators 902 and automated platforms need to be tracked and managed, and the 903 appropriate resource of the appropriate type needs to be selected on 904 a per invocation basis. What is needed is that for a particular 905 call, that a set of criteria be provided and the best match resource 906 be selected. This is the job of the ACD server. Some means is needed 907 to communicate the selection criteria for human operators and 908 automated platforms to the ACD server. 910 Operator Registration and Location. Human operators may not be 911 interchangeable, and have specific attributes such as skillsets 912 which can be used to identify the best human operator to service a 913 particular call. Operators log in at workstations at the beginning 914 of a shift, and log out during breaks and at the end of a shift. It 915 is important to associate each available operator with the 916 workstation at which they are logged in, so that requests can be 917 sent to the appropriate human operator. This is needed because the 918 selection process described above identifies a particular human 919 operator; it is then necessary to identify the workstation at which 920 that operator can be reached. 922 Bridging and removal of operator or automated system. Many operator 923 services require that either a human operator or automated system be 924 "bridged" onto a call, and to be removed at some point. 926 6.4. Capabilities Required for Specific Services 928 Connection Hold and Ringback. This capability involves having the 929 OISP "hold" the connection, such that the originating caller remains 930 connected, even if they attempt to hang up. This is mainly used in 931 relation to emergency services. Ringback is the ability for the OISP 932 to call back the calling party after they have hung up. This too is 933 often used in conjunction with emergency calls. Note that these are 934 only discussed in this document in the context of controlling a PSTN 935 based endpoint, as this capability does not carry over directly to 936 SIP based endpoints. 938 Coin Station Control. This is the ability of the OISP to determine 939 the coinage deposited into a TDM based network controlled coin 940 station (as opposed to an "intelligent" coin station which performs 941 such functions locally). This involves interpretation of the coin 942 control signals sent via specialized trunks from the end office to 943 which the TDM based coin station is connected via a specialized 944 phone line. Additionally, the need to signal toward the coin station 945 needs to be supported as well, for example to instruct the station 946 to return coins to the caller. This capability is intended to 947 interact with the specialized coin trunk. 949 Network Service Recall. After a call resulting from Operator 950 Services is completed, the caller may signal the desire to return 951 back to the OISP, without placing another call. In the traditional 952 PSTN, this is typically accomplished by the user signaling a hook 953 flash or other distinctive stimulus. 955 Verification and Interrupt. This is used in the Busy Line 956 Verification and Interrupt service, and allows the OISP to determine 957 if the target number is in use, to listen to a scrambled 958 representation of the conversation, and to interrupt the target 959 party's conversation to ask if they would accept a call from the 960 caller. 962 Transfer of emergency services call to selective router. Sometimes a 963 caller places an emergency call using a dial string which invokes 964 operator assistance (such as "0" in North America), rather than an 965 emergency call dial string. In such cases, the OISP must be able to 966 pass the emergency call to the appropriate PSAP. Handling of these 967 types of calls is outside the scope of this document. Standards for 968 emergency calling with SIP are still in development. 970 7. OISP Internal Architecture 972 This section describes an initial view of the elements internal to 973 the OISP architecture. 975 The following types of elements may be present within the OISP 976 infrastructure: 978 Automatic Call Distributor (ACD) server - The ACD provides queuing 979 and call distribution functions for human operators. Specifically, 980 it is the component that tracks the availability of the human 981 operators and selects an available operator utilizing complex 982 algorithms based on operator skills, type of call, type of request, 983 calling party information, etc. Similar functionality is required 984 with respect to automated platforms. The ACD server is modeled as an 985 Application Server. Two different models of ACD include a "query" 986 model, where the ACD accepts a request and returns a response (such 987 as a SIP redirection response) identifying the selected resource, 988 and an "inline" model, where the ACD server accepts a request and 989 inserts itself into the signaling path, making its selection and 990 sending requests to that resource. There is currently work in the 991 MEDIACTL working group regarding Media Resource Brokers (MRBs) which 992 may be relevant to this. 994 The ACD server may also contain functionality for tracking and 995 maintaining statistics about resource utilization; this is sometimes 996 referred to as force management. 998 Customer Profile Database - The Customer Profile Database is a per 999 subscriber database maintained by an OISP about its customers. Some 1000 of this information might be statically provisioned, other 1001 information such as customer preferences or session information 1002 might be populated dynamically as a result of customer interactions. 1004 Messaging Gateways - Messaging Gateways provide access and data via 1005 E-mail, SMS, MMS, WAP. 1007 Operator and Information Services Application Server (OIS-AS) - The 1008 OIS-AS contains AS functions specifically for directory assistance 1009 and information services as well as other Operator Services. This 1010 may coordinate multiple call legs, connecting the caller in sequence 1011 to one or more OIS-MS and/or operator workstations according to the 1012 logic contained within. The OIS-AS may need to communicate with 1013 elements of other providers, for instance to query information about 1014 the capabilities and characteristics of the caller's equipment, or 1015 to access another provider's operator resources. 1017 Operator and Information Services Media Server (OIS-MS) - The OIS-MS 1018 provides the media resources for playing announcements, performing 1019 voice recognition, performing listing database queries, generating 1020 whisper from the user's verbal request, etc. 1022 Operator Workstations - Operator Workstations provide an interface 1023 to the human operator. They may receive the customer's recorded 1024 request (e.g. name and city of requested listing), information from 1025 listing or other databases, and also terminate a multimedia session 1026 with the customer. Operator workstations are specialized SIP 1027 endpoints, and may be modeled in various ways, such as UAs or media 1028 servers. 1030 PSTN Gateways - OISPs need to interface with the PSTN. Thus, 1031 gateways are needed to interface between the OISP and both signaling 1032 and bearer. The bearer is handled by trunk gateways, which interface 1033 RTP streams on the OISP side to TDM trunks on the PSTN side. The 1034 signaling may be handled by signaling gateways which interface SS7 1035 on the PSTN side and SIP on the OISP side. Currently in North 1036 America, inband signaling on MF trunks is common for interfacing to 1037 OISPs, and trunk gateways need to be able to interpret and report as 1038 well as generate the appropriate MF signaling. 1040 Service Databases - Service Databases store service specific 1041 information (e.g. listing information such as name, address, and 1042 phone number, etc.) These may be located in the OISP's network 1043 and/or in other networks, and more than one may be used. 1045 SIP Proxy - One or more SIP proxies may be present in the OISP 1046 network, to facilitate SIP communications with other providers as 1047 well as to perform call processing functions between OISP 1048 components. 1050 The following figure shows a simplified view of an OISP internal 1051 architecture. The lines show logical connectivity; elements 1052 communicate via the proxy. A single OIS-AS is shown, along with up 1053 to "k" OIS-MS and up to "m" Operator Work Stations, and an ACD 1054 server. Communications between elements are assumed to traverse a 1055 proxy, which has been omitted from the figure for brevity. 1057 +--------+ +---------+ +---------+ 1058 | OIS-AS |-+-| OIS-MS1 |...| OIS-MSk | 1059 +--+-----+ | +---------+ +---------+ 1060 | 1061 | | +---------+ +---------+ 1062 | +-| OWS1 |...| OWSk | 1063 +--+--+ | +---------+ +---------+ 1064 | ACD | | 1065 +-----+ | +--+---+ 1066 +-|PSTNGW| 1067 +------+ 1069 Figure 5 Simplified view of OISP Internal Architecture 1071 8. General Approach 1073 This section describes one possible way to implement DA using SIP. 1074 Other ways may be possible. 1076 The general approach involves having the OIS-AS host most of the 1077 processing logic, and to control the call in general. The OIS-AS 1078 implements a third party call control (3PCC) functionality, as 1079 described in [RFC3725]. It terminates the signaling dialog from the 1080 caller, and originates dialogs towards other components as 1081 necessary. There may be multiple sequential sessions set up during 1082 the course of a DA call. 1084 For example, the OIS-AS would initiate a new dialog towards a MS for 1085 front-end automation. When it gets the 200 OK from the MS with SDP, 1086 it passes that SDP back toward the caller. When the front end 1087 automation has completed, the OIS-MS sends a BYE containing message 1088 bodies conveying the success of the operation (i.e., was it able to 1089 obtain the listing) as well as any data related to the operation. In 1090 case of success, the body might carry the listing information, or a 1091 URI pointing to it. In case of failure, it might carry a URI 1092 pointing to the whisper file. 1094 In case of failure, the OIS-AS would determine that the call needs 1095 to be routed to a human operator. The OIS-AS first needs to identify 1096 a suitable operator to handle this request. The ACD server has this 1097 responsibility, and could be implemented as a redirect server facing 1098 the OIS-AS, redirecting towards the best suited available operator. 1099 Facing the operator workstations, the ACD server could be 1100 implemented as a presence server, maintaining availability of each 1101 operator, as well as the associated information for each (e.g. 1102 languages, skill level, cost, etc). 1104 The OIS-AS would then send an INVITE toward the identified operator 1105 workstation. This INVITE includes the caller's SDP as well as a URI 1106 pointing to the whisper file. The workstation could play the whisper 1107 to the operator as the call is answered. The operator workstation's 1108 SDP would be passed back to the caller via a re-INVITE or UPDATE 1109 request. 1111 If the operator is successful in locating the desired listing, the 1112 workstation would send a BYE containing message bodies with an 1113 indication of success, and either the listing information of a 1114 pointer to the same. 1116 The OIS-AS would then initiate a call leg towards an OIS-MS for back 1117 end automation. The INVITE would include the same body with the 1118 listing information that was sent by the operator workstation. The 1119 OIS-MS returns its SDP, which the OIS-AS would propagate back over 1120 the originating leg via a re-INVITE or UPDATE request. The back end 1121 automation process includes audibly playing out the listing 1122 information, and possibly offering call completion service. The OIS- 1123 MS sends a BYE with a message body indicating whether call 1124 completion is desired. 1126 If call completion is desired, the OIS-AS sends a REFER back over 1127 the originating call leg to the caller, and clears the call. 1129 These examples describe simple voice scenarios. Other media types 1130 may be possible. For example, it may be desirable to send the 1131 listing information via text message to the caller's terminal, or to 1132 show a video clip. Such features require knowledge of the calling 1133 terminal's capabilities and characteristics. The mechanism described 1134 in [RFC3840] Indicating User Agent Capabilities in the Session 1135 Initiation Protocol (SIP) can be used for this. The capabilities 1136 might have been signaled in the initial INVITE request. Otherwise, 1137 the OIS-AS can query for capabilities using an OPTIONS request. 1138 Additionally, some non SIP mechanism might be used, such as querying 1139 a database (e.g. IMS HSS) in the caller's network. 1141 References to a whisper file can be passed using the mechanism 1142 described in [RFC4483]. 1144 Other information signaled via message bodies includes the success 1145 or failure status of operations (such as identifying the requested 1146 listing), or other data (such as the listing information). 1148 Context information may be maintained on a per call basis. It could 1149 include such information as the caller's preferred language, etc. A 1150 URI pointing to the context information could be passed between 1151 elements in the OISP infrastructure. 1153 Note that the IETF MEDIACTRL working group is currently developing 1154 mechanisms for control of SIP based MSs by ASs; this work may be 1155 applicable for OIS as well. 1157 9. Signaling Mechanisms 1159 This section discusses the signaling mechanisms required to provide 1160 OIS services. 1162 9.1. PSTN Protocol Interworking 1164 Operator Services will need to interoperate with the existing PSTN. 1165 This includes both receiving incoming call requests from the PSTN as 1166 well as initiating calls towards the PSTN. There are several issues 1167 which are specific to PSTN interworking. 1169 Current Operator Services systems use both SS7 ISUP and MF 1170 signaling. PSTN gateways interwork between the PSTN signaling and 1171 SIP signaling, and between the PSTN's circuit switched bearer 1172 channels and RTP. [RFC3398] defines ISUP-SIP interworking 1173 procedures. ATIS, which is responsible for defining North American 1174 specific telecommunications standards, provides North American 1175 procedures in [T1679]. There is currently no standard for MF-SIP 1176 interworking; rather, ATIS standards assume a gateway model whereby 1177 MF signaling is logically mapped to ISUP, then ISUP-SIP interworking 1178 procedures are applied. 1180 ISUP interworking involves two mechanisms; parameter mapping and 1181 encapsulation. Some concepts exist natively in both PSTN and SIP 1182 signaling, and thus both PSTN signaling and SIP define protocol 1183 mechanisms for conveying such information. Mapping between these is 1184 specified in interworking standards such as [RFC3398] and [T1679]. 1186 Other ISUP parameters have no direct equivalent in SIP, but are 1187 needed in SIP headers so that proxies and other SIP entities can 1188 route calls; extensions have defined SIP headers and parameters for 1189 this purpose. In order to convey those parameters which have no 1190 mapping to SIP headers, encapsulation of ISUP messages is used, 1191 whereby the ISUP message content is encoded in a MIME body which is 1192 carried in SIP messages. [T1679] specifies that the entire ISUP 1193 message be encapsulated in a MIME body of type "application/ISUP", 1194 as registered with IANA and defined in [RFC3204]. [NSS] defines a 1195 MIME type "application/NSS"; this standard specifies that the only 1196 parameters which do not have mappings to SIP be included in the NSS 1197 body, along with identification of the ISUP version and ISUP message 1198 type, rather than encapsulating the entire ISUP message. [T1679] is 1199 the ATIS standard for North American networks. 1201 Thus, PSTN gateways send SIP messages containing SIP headers and 1202 parameters mapped from ISUP parameters where specified, and carrying 1203 an "application/ISUP" MIME body containing an entire encapsulated 1204 ISUP messages. 1206 It should be noted that when MF PSTN signaling is used, the use of 1207 encapsulated ISUP involves logically mapping the MF signaling to the 1208 corresponding ISUP information elements, generation of the 1209 corresponding ISUP message, and MIME encapsulation of this generated 1210 ISUP message in the corresponding SIP message. 1212 9.2. Conveying Application Specific Information 1214 Some information carried by PSTN signaling, such as the ISUP Called 1215 Party Number is required for routing calls. Other information, such 1216 as Charge Number, is for use by applications such as operator 1217 services, and is not needed for routing the call. 1219 With SIP, information needed for routing requests, or which 1220 otherwise needs to be available to proxies, should be present in 1221 message headers. Note that proxies may add headers and modify header 1222 content. 1224 Message bodies can be carried in SIP requests and responses. Such 1225 bodies are generated by and consumed by endpoints, and are expected 1226 to be passed transparently by proxies. Additional headers such as 1227 Content-type and Content-disposition describe the MIME type of the 1228 message body as well as how the receiving endpoint is to handle 1229 unsupported MIME types. Messages can contain more than one body, as 1230 described in [RFC2045]. 1232 Moreover, much of the information delivered to an operator services 1233 system is expected to be provided by trusted equipment in the 1234 caller's home provider, rather than by the caller's user equipment. 1236 Architectures such as IMS include application servers which have the 1237 ability to act as Back to Back User Agents (B2BUAs). Whereas proxies 1238 cannot insert message bodies, B2BUAs can in fact do so, because they 1239 act as SIP endpoints. 1241 Not all information passed in PSTN signaling can be conveyed 1242 natively in SIP, but operator services systems expect this 1243 information. One option for doing this is to have an application 1244 server in the caller's home provider, acting as a B2BUA, populate a 1245 MIME body in the INVITE sent to the operator services provider, for 1246 consumption by an OIS AS. There is at the time of this writing no 1247 agreement on a MIME type to use for this purpose. 1249 Some ISUP information for which SIP mappings are not currently 1250 defined is also expected to be relevant for calls initiated using 1251 SIP. Charge Number is business related information, and is expected 1252 to apply regardless of whether a caller is using a SIP or PSTN 1253 device. The same is true for Originating Line Information. Again, 1254 the use of a MIME body is potential option. Mechanisms for some of 1255 this information in SIP header fields and parameters are described 1256 in several Internet-Drafts at the time of this writing, and are 1257 described in this document where applicable. 1259 9.3. Calling Party's Identity 1261 In many cases, downstream providers may need to know the calling 1262 party's identity. This might be needed to influence call processing, 1263 or for usage collection purposes. Also, the calling party's identity 1264 in the form of a SIP URI might be needed so that the identity of the 1265 home provider can be determined. 1267 The calling party's equipment populates the From header in SIP 1268 messages. This is not trusted. There are several methods for 1269 providing "network-asserted identities", which under the appropriate 1270 conditions can be trusted. 1272 The SIP Identity mechanism defined in [RFC4474] provides a 1273 standardized, architecture agnostic SIP mechanism for 1274 cryptographically assuring the user's identity. However, this 1275 mechanism has seen little deployment. 1277 The P-Asserted-Identity header [RFC3325] is a private extension to 1278 SIP that enables a network of trusted SIP servers to assert the 1279 identity of authenticated users. This is the prevalent mechanism 1280 currently used in service provider environments. 1282 Note that some networks may allow their users to hide their 1283 identity. In the current North American PSTN, for such cases the 1284 caller id information is often transported through the network, 1285 marked with a privacy indication such that it will not be presented 1286 to the called party. In SIP, the Privacy header field defined in 1287 [RFC3323] is used. 1289 Bilateral agreements between VOIP providers determine whether 1290 providers are within the same "trust domain" as defined in 1291 [RFC3324], and what information, including network-asserted 1292 identities, may be exchanged between providers. Depending on such 1293 agreements, it is possible that the caller identity information is 1294 obscured or completely absent. As indicated in [RFC3325], "Masking 1295 identity information at the originating user agent will prevent 1296 certain services, e.g., call trace, from working in the Public 1297 Switched Telephone Network (PSTN) or being performed at 1298 intermediaries not privy to the authenticated identity of the user." 1300 When an OIS provider is not privy based on bilateral agreement to 1301 network asserted identity information from the calling network when 1302 the caller has requested privacy, it may be unable to implement any 1303 call processing logic based on such information. 1305 If the OISP desires to reject anonymous calls, [RFC5079] defines a 1306 new SIP response code 433 (Anonymity Disallowed) for this purpose. 1308 The following shows an example of an INVITE message contain a P- 1309 Asserted-Identity header. 1311 INVITE sip:da@provider-c.example SIP/2.0 1312 Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060 1313 ;branch=y9hG4bK74bf9 1314 Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060 1315 ;branch=x9hG4bK74bf9 1316 Via: SIP/2.0/UDP client.provider-a.example.com:5060 1317 ;branch=z9hG4bK74bf9 1318 From: ;tag=1234567 1319 To: sip:411@provider-a.example.com 1320 Contact: 1321 P-Asserted-Identity: "732758123" 1323 Content-Type: application/sdp 1324 Content-Length: ... 1325 [SDP not shown] 1327 9.4. Provider Identification 1329 As discussed, in some deployment scenarios, the OISP makes use of 1330 the identities of other providers involved in the call. This section 1331 discusses how those identities can be conveyed using SIP. 1333 9.4.1. Home Provider 1335 In many cases, the OISP needs to identify the caller's Home 1336 Provider. This may be needed for branding purposes as well as to 1337 potentially influence treatment in other ways. 1339 The basic mechanism for determining the home provider is to derive 1340 it from the right hand side (RHS) of the network asserted identity. 1342 In SIP, identities are expressed as URIs. These can be SIP (or SIPS) 1343 URIs, or "tel" URIs. 1345 [RFC3261] defines the SIP URI, which is used for identifying SIP 1346 resources. The RHS can be expressed as a DNS domain name or as an 1347 IPv4 or IPv6 address. The hostname format is most suitable for 1348 providing an identity to reach the calling party. For instance the 1349 mechanisms defined in [RFC3263] for locating SIP servers depends on 1350 the use of domain names for the various types of DNS lookups such as 1351 NAPTR, SRV, and A. 1353 If a provider decides to provide network asserted identities 1354 expressed as SIP URIs using IP addresses instead of hostnames, it 1355 forfeits the use of such standardized mechanisms for reaching its 1356 users. It also becomes difficult to derive the home provider 1357 identity from the network asserted identity. 1359 [RFC3966] defines the "tel" URI, which is used for describing 1360 resources identified by phone numbers. The "tel" URI format does not 1361 include a domain. Thus, if the network asserted identity includes 1362 only a "tel" URI, no direct information about the home provider is 1363 provided. 1365 The SIP Identity mechanism is intended for use with SIP URIs. The 1366 PAI mechanism can use either a SIP URI, a "tel" URI, or both. 1368 This document depends on the home provider providing a network 1369 asserted identity containing a hostname. This includes the SIP 1370 identity where the SIP URI contains a hostname, or a PAI header 1371 containing at least a SIP URI with a hostname. 1373 Very simply, the RHS of the hostname in the SIP URI is extracted and 1374 used as the basis to influence call processing. In cases where the 1375 caller's identity is not available, as discussed in the "Calling 1376 Party's Identity" section, then the home provider's identity is 1377 consequently also not available, and call processing logic based on 1378 such information (such as branding) cannot take place. 1380 9.4.2. Intermediate Provider 1382 In some cases, the OISP may need to know the identity of an 1383 intermediate provider which the call has traversed. Recall that for 1384 our purposes, we define "intermediate provider" as having a business 1385 relationship with both the home provider (to handle OIS requests) 1386 and with an OISP (which will actually provide the requested 1387 service.) This may be needed to influence treatment. 1389 The use of the SIP History-Info mechanism defined in [RFC4244], can 1390 be used for this. As the call moves from one provider to the next 1391 and is retargeted, corresponding entries are added to the SIP 1392 History-Info header. If the domain name format is used for the 1393 retargeted entities, then the History-Info header now includes a 1394 list of traversed SIP domains or providers, which can be consulted 1395 by the OISP. 1397 According to [RFC4244], entries should be added to the History-Info 1398 header whenever the Request-URI is modified. Cases may exist where 1399 the call is sent to another provider but the URI is not modified. In 1400 such cases, the provider is not captured by the History-Info header. 1402 The following figure illustrates the use of the History-Info header 1403 for this purpose. 1405 Caller Provider-A Provider-B Provider-C 1406 | | | | 1407 | | | | 1408 | | | | 1409 |(1) INVITE sip:411@provider-a.example.com | 1410 | 1411 |------------->| | | 1412 | | | | 1413 | | | | 1414 | |(2) INVITE sip:da@prov-b.example.com 1415 | |------------->| | 1416 | | | | 1417 | | | | 1418 | | |(3) INVITE sip:da@prov- 1419 c.example.com 1420 | | |------------->| 1421 | | | | 1422 | | | | 1424 Figure 6 Use of History-Info header to identity traversed providers 1426 1. The user dials "411", and the resulting INVITE to its home proxy 1427 is for "sip: 411@provider-a.example.com". No History-Info header is 1428 included yet. 1430 INVITE sip:411@provider-a.example.com SIP/2.0 1431 (other message content omitted) 1433 2. The home proxy retargets this to "sip:da@prov-b.example.com", and 1434 adds a History-Info header which includes the targeted-from URI: 1436 INVITE sip:DA@prov-b.example.com SIP/2.0 1437 History-Info: sip:411@provider-a.example.com; index=1 1438 (other message content omitted) 1440 3. Proxy-B retargets this to "SIP: da@prov-c.example.com", and 1441 appends another entry to the History-Info header: 1443 INVITE sip:DA@prov-c.example.com SIP/2.0 1444 History-Info: sip:411@provider-a.example.com; index=1, 1445 ; index=1.1 1446 (other message content omitted) 1448 When this request arrives a Proxy-C in Provider C (OISP), it conveys 1449 the following: 1451 o The Request-URI (SIP: da@prov-c.example.com) indicates this as 1452 a DA call 1454 o The History-Info header conveys the history of the request: 1456 o It started as a SIP URI for "sip:411@provider-a.example.com" 1458 o It was then targeted to provider B 1460 o It is now targeted to provider C 1462 Please note that if a transit provider were encountered, the transit 1463 provider would simply route the request toward Provider C, and would 1464 not perform retargeting. It would not modify the Request-URI nor the 1465 SIP History-Info header contents. 1467 9.5. Originating Line Information/ANI II Value 1469 In the current PSTN in North America, OIS providers have the ability 1470 to tailor treatment based on the type of originating station. For 1471 instance, calls from prison phones are restricted from accessing DA 1472 services. Example values include POTS, coin, hospital, 1473 prison/inmate, cellular, etc. In the PSTN in North America, this 1474 information is signaled for SS7 calls using the Originating Line 1475 Information (OLI) information element, and in MF calls using the ANI 1476 II digits. To support interworking with the PSTN, it must be 1477 possible to convey the Originating Line Information value. The 1478 ability to convey this information natively with SIP is currently 1479 lacking. 1481 It is also desirable to characterize certain types of originating 1482 SIP based callers using these same values, e.g. prison, police, etc. 1484 [TS24229] defines the "oli" parameter for conveying Originating Line 1485 Information in SIP using a tel URI parameter, is aimed at 1486 telecommunications service provider applications, and has been 1487 adopted by 3GPP, making it the preferred approach. This document 1488 defines the parameter to convey the 2-digit numeric OLI value. This 1489 is in contrast to the "cpc" parameter defined in [draft-mahy-iptel- 1490 cpc], which specified a limited subset of string based values. This 1491 mechanism would be applicable for both PSTN interworking and also 1492 for SIP originated calls. 1494 The "isup-oli" parameter is sometimes used to convey OLI information 1495 for PSTN interworking, but it is not defined in any standards 1496 document. 1498 For PSTN interworking, the current version of [T1679] does not 1499 specify a SIP mapping for the OLI parameter. Thus, that document 1500 specifies that it be carried in an encapsulated ISUP message in a 1501 MIME body. This mechanism would be applicable to PSTN interworking 1502 but not for SIP originated calls. 1504 9.6. Trunk Group Identifier 1506 The incoming trunk group number provides information which could be 1507 used to influence call processing, thus this information is needed. 1508 Trunks are point to point circuits and as such, their remote 1509 termination point is unambiguously known. As such, knowledge of the 1510 incoming trunk group conveys the identity of the provider offering 1511 the call. 1513 For PSTN interworking, the incoming trunk group identifier is a key 1514 piece of information and must be known. Thus, at a PSTN to IP 1515 interworking point, the trunk group information must be kept and 1516 signaled forward. This holds for OISP's accepting incoming calls 1517 from the PSTN as well as upstream providers accepting calls from the 1518 PSTN. 1520 [RFC4904], "Representing trunk groups in tel/sip Uniform Resource 1521 Identifiers (URIs)" defines a way to signal incoming and/or outgoing 1522 trunk group information as a parameter in SIP URIs and tel URIs. 1524 To represent incoming trunk groups, the trunk group parameter is 1525 included in the Contact header of the SIP message. The "trunk- 1526 context" parameter should also be included, to ensure that the trunk 1527 group is unambiguously identified, since trunk group numbers are not 1528 globally unique. 1530 At the time of this writing, [T1679], which specifies PSTN 1531 interworking for North American networks, does not include this 1532 mechanism, possibly because it predates [RFC4904]. However, gateways 1533 should include this information for operator services. 1535 The following example shows an INVITE containing a trunk group 1536 identification in the Contact header: 1538 INVITE sip:da@provider-c.example.com SIP/2.0 1539 Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060 1540 ;branch=y9hG4bK74bf9 1541 Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060 1542 ;branch=x9hG4bK74bf9 1543 Via: SIP/2.0/UDP client.provider-a.example.com:5060 1544 ;branch=z9hG4bK74bf9 1545 From: ;tag=1234567 1546 To: sip:411@provider-a.example.com 1547 Contact: 1549 P-Asserted-Identity: "7327581234" 1551 Content-Type: application/sdp 1552 Content-Length: ... 1554 This example identifies trunk group 101, with the trunk-context 1555 identifying gateway-a.provider-b.com. Together these unambiguously 1556 identify the incoming trunk group. Both of these parameters are tel URI 1557 parameters and thus appear on the left hand side of the "@" sign. The 1558 domain of the SIP URI formed from this tel URI is provider- 1559 b.example.com, and the "user=phone" parameter is a SIP URI parameter. 1561 9.7. Identification of PSTN Originated Calls 1563 Since calls arriving via PSTN trunks may require different 1564 processing from those received from SIP endpoints, it must be 1565 possible to distinguish between these types of calls. For PSTN 1566 originated calls, the Contact header identifies the gateway, and 1567 also the presence of the "tgrp" parameter in that header 1568 indicatesthat the call was received via a PSTN trunk. Obviously the 1569 presence of an encapsulated ISUP message also identifies the call as 1570 such. 1572 In some cases, the identity of the home PSTN provider of the caller 1573 may be known (e.g., the call arrived via a dedicated trunk group 1574 from a PSTN end office). In such cases, the gateway may populate the 1575 host portion of the SIP URI in a P-Asserted-Identity header field 1576 with a value of local significance within the OISP identifying that 1577 PSTN home provider. Conveyance of such information beyond the OISP 1578 is outside the scope of this document. 1580 Note that some implementations may make use of the trunk group 1581 parameters in a non standard or proprietary manner, including them 1582 when the call did not originate from the PSTN. Thus, the mere 1583 presence of these parameters does not guarantee that the call 1584 originated in the PSTN. Rather, the value of the trunk-context 1585 parameter must also be taken into account, and the OISP must 1586 recognize this as identifying a PSTN trunk group. 1588 9.8. Dialed Digits 1590 Currently in the North American PSTN, the OIS provider may take into 1591 account the digits dialed by the user. In that scenario the dialed 1592 digits are frequently forwarded to the OIS provider. 1594 Using SIP, the dialed digits would typically be sent by the user's 1595 equipment in the form of a SIP URI in the Request-URI of a SIP 1596 INVITE. In this case, the Request-URI would be in a form such as 1597 "sip:411@provider-a.example.com". 1599 The use of tel URIs instead of SIP URIs in the Request-URI is also 1600 theoretically possible. In this case, the URI might be formatted as 1601 "tel:411;phone-context=+1",where in this case the "+1" identifies 1602 the country code "1" for North America, or "tel:411;phone- 1603 context=+1-732", identifying a more specific context. However, the 1604 use of tel URIs in the Request-URI is not common in current service 1605 provider deployments. 1607 It is possible that retargeting could take place, in which case the 1608 dialed digits would be lost. 1610 The SIP History-Info mechanism defined in [RFC4244] provides a 1611 mechanism for solving exactly this type of problem. It defines a new 1612 optional SIP header, History-Info, to provide a standard mechanism 1613 for capturing the request history information. Whenever a node which 1614 supports this mechanism modifies the Request-URI of a request, it 1615 captures this in the History-Info header. 1617 The following example shows an INVITE containing a History-Info 1618 header, which conveys the original dialed digits, after having been 1619 retargeted. 1621 INVITE sip:DA@prov-b.example.com SIP/2.0 1622 (other message content omitted) 1623 History-Info: sip:411@provider-a.example.com; index=1, 1624 ; index=1.1 1626 Please see the section titled "Arbitrary Involved Provider" for an 1627 example of a flow where the History-Info mechanism delivers the 1628 dialed digits to the OISP when retargeting has occurred. 1630 9.9. Retargeting to Identify the Desired Service 1632 It is necessary to identify the service being requested. Such 1633 services might include directory assistance with or without call 1634 completion. The logic to determine this might reside in one or more 1635 points in the network. Additionally, the identification of the 1636 service might be refined as the request traverses potentially 1637 multiple networks, depending on the availability of additional 1638 information. 1640 It is proposed here to retarget the Request-URI of the SIP request 1641 to specify the desired service. While the initial Request-URI might 1642 specify "SIP:411@provider-a.example.com", a downstream element might 1643 invoke service logic and determine that this call should be sent to 1644 OISP C's network for directory assistance with call completion, and 1645 change the Request-URI to "SIP:da-with-call-completion@oisp- 1646 c.example.com". 1648 A similar approach is taken for identifying resources in [RFC4240]. 1650 [CSI], a work in progress, discusses explicit service identifiers 1651 for using in IMS [IMS] based networks. 1653 9.10. Charge Number 1655 In the current PSTN in North America, a Charge Number is signaled 1656 with call originations. The Charge Number identifies the customer or 1657 account with which the caller is associated. In many cases it is the 1658 same as the Calling Party Number, while in others it is different - 1659 e.g. the main number for a business which has many individual 1660 calling numbers. This might be needed for usage collection, but it 1661 also could influence call processing, especially when a particular 1662 type of service applies for any caller associated with a particular 1663 charge number. 1665 There is currently no IETF standardized mechanism to convey the 1666 Charge Number in SIP. The need to convey equivalent information for 1667 SIP based callers is also under investigation. 1669 [PCI] proposes a "P-Charge-Info" SIP header for carrying charge 1670 information for a call. It is intended to facilitate carrying 1671 information equivalent to OLI for SIP originated calls. It is also 1672 intended to support PSTN interworking by carrying the ISUP Charge 1673 Number value. 1675 For PSTN interworking, [T1679] does not specify a SIP mapping for 1676 the Charge Number parameter. Thus, it is carried in an encapsulated 1677 ISUP message in a MIME body. The P-Charge-Info header, if 1678 standardized, would be useful in this role. 1680 For SIP originated calls, there is no currently standardized way to 1681 carry this information. The P-Charge-Info header, if standardized, 1682 would be useful in this role. 1684 9.11. Access Prefix 1686 In the current PSTN in North America, operator services calls are 1687 often originated by dialing a prefix such as "0". In ISUP signaling, 1688 the "0" is not carried in the Called Party Number parameter. Rather, 1689 it is stripped, and the ISUP Operator Services Information (OSI) 1690 parameter carries an indication of the original access prefix. 1692 For SIP originations, there are several options. First, the dialed 1693 digits, including any prefix, can be included in the Request-URI. 1694 Alternatively, an AS in the caller's home provider can retarget the 1695 request based on the digits, such that new Request-URI identifies 1696 the requested service. The original dialed digits can be carried in 1697 the retargeted-from Request-URI in a History-Info header. For 1698 example, a Request-URI containing a zero plus 10 digits might be 1699 retargeted at an AS to sip:operator-assistance@provider- 1700 b.example.com. Though not currently standardized, these options can 1701 also be used for PSTN interworking. I.e., the GW could choose to 1702 prepend a prefix to the digits in the Request-URI based on the 1703 received Operator Services Information parameter. Additionally, the 1704 GW could support building a Request-URI which specifies the 1705 requested service, based on analysis of the incoming ISUP signaling. 1707 For PSTN originations, the Request-URI can be formed as described 1708 above for SIP originations. Additionally, this information is also 1709 conveyed via the Operator Services Information parameter in the 1710 encapsulated ISUP. 1712 9.12. Signaling of Carrier Information 1714 In North America, the handling of PSTN calls utilizing Interexchange 1715 Carrier (IXC) networks are subject to specific regulatory 1716 requirements, resulting in specific signaling requirements which may 1717 differ from those in other regions. Reflecting this is the 1718 definition of ANSI ISUP parameters not defined in the ITU-T as well 1719 as specific usage for certain ISUP parameters. Interworking between 1720 ISUP and SIP signaling for such scenarios is documented in several 1721 specifications, but there are issues with these specifications. This 1722 section identifies the ISUP parameters involved in IXC signaling in 1723 North America, and provides an overview of some of the issues with 1724 current interworking specifications. Subsequent sections will 1725 specifically address each parameter. The relevant ANSI ISUP 1726 parameters include the Transit Network Selection (TNS) parameter, 1727 the Carrier Identification Parameter (CIP), and the Carrier 1728 Selection Information (CSI) parameter. 1730 The ISUP Transit Network Selection (TNS) parameter is used to route 1731 calls to a specific carrier. In North American networks, it is used 1732 on several different interfaces to request that a call be routed to 1733 a particular carrier. TNS is also used in ITU-T ISUP. 1735 Specialized switches called Access Tandems (ATs) provide IXC 1736 networks with access to Local Exchange Carrier (LEC) switches. When 1737 a LEC switch originates an IXC call through an AT, it uses the TNS 1738 to inform the AT of the IXC to which the call is to be routed. 1740 Based on business arrangements, IXCs may also provide access to 1741 other IXCs. Thus a LEC switch may need to route a call using IXC B, 1742 but might have connectivity to only IXC A. The LEC switch could, 1743 depending on arrangements, send the call to IXC A, with the TNS 1744 parameter specifying IXC B. This requests IXC A to hand the call to 1745 IXC B. 1747 Also in North America, carrier selection procedures allow a caller 1748 to presubscribe to a particular IXC, and further to casually dial on 1749 a per call basis yet a different IXC to be used. Based on business 1750 arrangements, the carrier which will actually carry the call may be 1751 different from the presubscribed or dialed carrier. In ANSI ISUP, 1752 the Carrier Identification Parameter (CIP) is used to convey the 1753 dialed or presubscribed carrier, and accordingly the value of the 1754 CIP parameter may differ from that of any included TNS parameter. 1755 The definition of a separate parameter for this in ANSI ISUP 1756 underscores the need to separately identify the dialed or 1757 presubscribed carrier from the carrier which actually routes the 1758 call. 1760 Both [RFC3398] and [T1679] discuss interworking between the "cic" 1761 tel URI parameter and the ISUP TNS and/or CIP parameters. This 1762 document points out that there are issues with both these 1763 specifications, but does not attempt to resolve those issues here. 1765 [RFC3398] provides guidance on mapping between the "cic" tel URI 1766 parameter and the corresponding ISUP parameter. It essentially 1767 states that "cic" maps to TNS except for North American networks, 1768 where ANSI ISUP is used, where it maps to CIP, also allowing for 1769 application of local policy. 1771 Some information not discussed in [RFC3398] includes the fact that 1772 for North American networks it is not an either/or choice between 1773 inclusion of TNS and CIP, that both ISUP parameters may be present, 1774 that their values may differ, the nature of the relationship between 1775 these parameters, or what to do in the ISUP to SIP direction when 1776 both TNS and CIP are present. Also, for a given "cic" parameter 1777 received by the gateway, and depending on the outgoing PSTN 1778 interface type, a TNS value may also need to be determined and 1779 populated in the outgoing IAM, in addition to the CIP parameter. 1781 [T1679] specifies a mapping between the ISUP TNS parameter and the 1782 "cic" parameter in the Request-URI for North American networks. In 1783 doing so, it precludes the use of the "cic" parameter to convey the 1784 identity of the dialed or presubscribed carrier for PSTN 1785 interworking scenarios, as is suggested in [RFC4694], [DAI], and 1786 [RFC3398] for North American networks. Also, when the "cic" 1787 parameter is used to convey TNS for PSTN interworking scenarios, 1788 then if the "cic" parameter were also to be used to convey the 1789 dialed or presubscribed carrier for SIP originated calls, there is a 1790 potential for ambiguity regarding the meaning of a received "cic" 1791 parameter. 1793 The Carrier Selection Information (CSI) ISUP parameter indicates how 1794 the IXC identified in the CIP parameter was selected. For example, 1795 it may be the caller's presubscribed carrier, or may have been 1796 casually dialed, etc. The "dai" tel URI parameter described in [DAI] 1797 is intended to convey this information in SIP. 1799 The signaling of carrier selection information for non interworked, 1800 all-SIP calls in North American networks is for further study. 1802 9.13. Transit Network Selection 1804 As indicated above, the TNS identifies the IXC to which a call is to 1805 be routed. Note that it does not identify the network in which the 1806 call will actually terminate. The TNS is used in cases where it is 1807 necessary to specify the specific IXC through which the call should 1808 be routed. One example is when a call is handed off via an AT which 1809 provides access to multiple IXCs, in this case it is necessary to 1810 identify the desired IXC to the AT. Another example is when business 1811 arrangements dictate that the call be handed off to one IXC, which 1812 hands the call off to yet another specified IXC. For example, a call 1813 may be handed to IXC A with the TNS identifying IXC B; in this case 1814 the TNS instructs IXC A to hand off the call to Carrier B. 1816 The domain of a SIP URI in the Request-URI of a SIP INVITE can be 1817 seen to fill a role analogous to that of the TNS. If one provider 1818 needs to route a call to a specific provider, it would populate the 1819 domain in the Request-URI with the domain of that specific provider. 1820 When the call reaches that specific provider, it is typically 1821 (though not always) sent to a different provider to terminate the 1822 call. The analog to the example in the previous paragraph would be 1823 for a SIP provider to hand an INVITE to SIP Provider A with the 1824 domain in the Request-URI identifying SIP Provider B. As in the 1825 previous example, the signaling would reflect business arrangements. 1827 One potential mechanism for interworking for North America between 1828 the ISUP TNS and SIP is to map between TNS and a SIP domain 1829 representing the provider identified in the TNS. Mappings between 1830 TNS values and corresponding SIP domains would need to be pre- 1831 established and maintained at gateways implementing this mechanism. 1832 When such a gateway receives an ISUP IAM containing a TNS parameter, 1833 it would populate the domain of the Request-URI of the corresponding 1834 SIP INVITE with the appropriate domain mapped from the received TNS 1835 value. Conversely, when a gateway implementing this mechanism 1836 receives a SIP INVITE, the domain of the SIP URI would be consulted 1837 by the gateway and potentially mapped to any included TNS value. 1838 Note that the inclusion of a TNS value is dependent upon local 1839 policy, which may be determined from several factors including the 1840 provisioned characteristics of the trunk group via which the call is 1841 routed. 1843 Note that this mechanism precludes the use of tel URIs in the 1844 Request-URI for calls involving IXCs; such URIs, including their 1845 parameters, would need to be converted to SIP URIs as described in 1846 [RFC3966]. 1848 For SIP originated calls, the domain of the Request-URI is already 1849 used to identify the provider to which the request should be routed, 1850 thus there is no need to for additional SIP signaling to express 1851 such information. 1853 9.14. Carrier Identification 1855 In the current PSTN in North America, callers can specify the IXC 1856 they want to use for a particular long distance call. Otherwise, 1857 their presubscribed IXC is used. In either case the carrier 1858 identification code (CIC) of the chosen carrier is signaled. In ANSI 1859 ISUP this is signaled in the Carrier Information Parameter (CIP). 1860 Per [RFC3398], for interworking from ANSI ISUP to SIP, the CIP is 1861 mapped to the "cic" tel URI parameter, and vice versa. Note that in 1862 North America, the CIP, which identifies the selected carrier, may 1863 have a different value than the TNS, and is not used for routing 1864 purposes. 1866 For SIP originated calls, the "cic" parameter can also be used to 1867 identify the selected carrier, as described in [RFC4694]. Note 1868 however that [RFC4694] describes a usage of "cic" where it is used 1869 for routing, which is more consistent with ITU-T ISUP than with ANSI 1870 ISUP, where it is not used for routing. As a result, some of the 1871 procedures in that document would require modification to be 1872 applicable to North American deployments. 1874 9.15. Carrier Selection Information 1876 The ISUP Carrier Selection Information (CSI) parameter describes how 1877 the selected IXC was chosen; e.g. presubscribed, dialed, etc. One 1878 example of the utility of this information comes from Operator 1879 services calls that include call completion, whereby a call is 1880 initiated on behalf of the caller. In order to know which IXC to 1881 use, and how that IXC was chosen, the operator services provider 1882 needs to receive the CIP and Carrier Selection Information. In ANSI 1883 ISUP this describes the carrier identified in the CIP; while in ITU- 1884 T ISUP it describes the carrier identified in the TNS. Thus in both 1885 cases it describes the selection of the carrier identified in the 1886 "cic" tel URI parameter of the Request-URI. 1888 When interworking from ISUP to SIP, this information is included in 1889 the encapsulated ISUP. The "dai" parameter proposed in [DAI] can 1890 also be used to be carry this information. The "dai" parameter can 1891 also be used for SIP originated calls. Thus, the dai information 1892 would be associated with the carrier identified in the ANSI CIP or 1893 the ITU-T TNS. That is, in the ANSI model, it is associated with the 1894 carrier information that is delivered to the interested 1895 application(s) rather than the information that is used for routing. 1897 9.16. Passing Whisper 1899 During front end automation, the OIS-MS will record and may time 1900 compress the caller's perhaps meandering speech into what is known 1901 as the "whisper". This is intended to be played into a human 1902 operator's ear, should the call be referred to an operator, to avoid 1903 the operator from having to prompt the caller again. The whisper is 1904 obtained during the front end automation, and saved to an audio 1905 file. 1907 If the call needs to be transferred to a human operator, the whisper 1908 will need to be played to the operator at the same time or slightly 1909 prior to connecting the caller to the operator. Thus, the operator 1910 workstation needs to be able to access the whisper file. 1912 When the OIS-MS performs front end automation, it generates the 1913 whisper and saves it as an audio file. The location, storage type, 1914 and format are out of the scope of this document. What is needed is 1915 a way for the OIS-MS to convey the whisper information to the OIS- 1916 AS, so it could potentially be used for later processing, such as 1917 passing to a human operator. 1919 Due to size constraints, it may not be feasible or desirable to pass 1920 the actual audio file containing the whisper. This document will 1921 discuss the most general case of passing a pointer, in the form of a 1922 URI, to the audio content. What follows is a description of one 1923 possible way to implement this. The work of the recently formed IETF 1924 MEDIACTRL working group may provide alternatives. 1926 Since the whisper is an output of the front end automation process, 1927 it makes sense to return this upon completion of that process. The 1928 most reasonable time to do this is when the OIS-MS sends the BYE. 1930 Any SIP request, including BYE, can contain a message body. 1931 [RFC4483] defines an extension to the URL MIME External-Body Access- 1932 Type to satisfy the content indirection requirements for SIP. These 1933 extensions are aimed at allowing any MIME part in a SIP message to 1934 be referred to indirectly via a URI. 1936 This is illustrated in the following figure. Note that the proxy has 1937 been omitted for clarity, as have some messages not crucial to 1938 illustrating the use of this mechanism. All SIP signaling traverses 1939 the proxy. 1941 AS MS Operator 1942 | | | 1943 | | | 1944 | | | 1945 |(1) INVITE | | 1946 |------------->| | 1947 | | | 1948 |(2) 200 OK | | 1949 |<-------------| | 1950 |(3) ACK | | 1951 |------------->| | 1952 | | | 1953 |MS prompts user, collects whisper 1954 | | | 1955 | | | 1956 |(4) BYE, body w. status, whisper URI 1957 |<-------------| | 1958 | | | 1959 |(5) 200 OK | | 1960 |------------->| | 1961 | | | 1962 |(6) INVITE w. whisper URI | 1963 |---------------------------->| 1964 | | | 1965 |(7) 200 OK SDP| | 1966 |<----------------------------| 1967 |(8) ACK | | 1968 |---------------------------->| 1969 | | | 1970 | | | 1972 Figure 7 Call flow illustrating passing of whisper 1974 1. INVITE AS->MS 1975 INVITE sip:da@ms-1.oisp-c.example.com SIP/2.0 1976 [remainder of message omitted] 1978 2. 200 OK MS->AS 1979 SIP/2.0 200 OK 1980 [remainder of message omitted] 1981 4. BYE MS->AS 1982 BYE sip:as-1@as-1.oisp-c.example.com SIP/2.0 1983 [non relevant portions of message omitted] 1984 Content-Type: message/external-body; access-type="URL"; 1985 URL="http://ms1.oisp-c.example.com/whisper/20070206092700- 1986 0001.wav" 1987 expiration="Tues, 06 Feb 2007 09:30:00 GMT"; 1988 1989 Content-Type: audio/x-wav 1990 Content-Disposition: render 1991 1993 5. 200 OK AS->MS 1994 SIP/2.0 200 OK 1995 [remainder of message omitted] 1997 6. INVITE AS->Operator Workstation 1998 INVITE sip:operator@operator-123.oisp-c.example.com SIP/2.0 1999 [non relevant portions of message omitted] 2000 Content-Type: message/external-body; access-type="URL"; 2001 URL="http://ms1.oisp-c.example.com/whisper/20070206092700- 2002 0001.wav" 2003 expiration="Tues, 06 Feb 2007 09:30:00 GMT"; 2004 2005 Content-Type: audio/x-wav 2006 Content-Disposition: render 2007 2009 7. 200 OK Operator->AS 2010 SIP/2.0 200 OK 2011 [remainder of message omitted] 2013 Note that this same mechanism also supports the case where front end 2014 automation is performed by one provider, and another provider 2015 provides the operator assistance. In this type of scenario, 2016 provisions need to made such that the second provider can access the 2017 resources referenced by the URI. 2019 9.17. Calling Equipment Capabilities and Characteristics 2021 It may be necessary for the OIS provider to learn the capabilities 2022 and characteristics of the caller's equipment. This would be useful 2023 when the OIS provider wishes to provide content to the caller other 2024 than that which was used on the call to the OISP. For example, the 2025 OIS provider might wish to send listing information via text 2026 message, or play a video clip about a particular venue about which 2027 he has requested information. 2029 [RFC3840] Indicating User Agent Capabilities in the Session 2030 Initiation Protocol (SIP), defines mechanisms by which a UA can 2031 convey its capabilities and characteristics to other user agents and 2032 to the registrar for its domain. This information is conveyed as 2033 parameters of the Contact header field. 2035 This information might be included in the incoming INVITE to the 2036 OISP, if the caller's UA supports this mechanism and is configured 2037 to do so. Otherwise, the OISP could query the caller's UA by sending 2038 a SIP OPTIONS request, and the UA, if it supports this mechanism, 2039 would include its capability feature tags in the response to the 2040 OISP. 2042 The following is an example of an INVITE containing capability 2043 feature tags, as it arrives at the OISP. In this case, the UA 2044 supports audio, video, and text. Other included tags provide 2045 additional information. 2047 INVITE sip:da@provider-c.example.com SIP/2.0 2048 Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060 2049 ;branch=y9hG4bK74bf9 2050 Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060 2051 ;branch=x9hG4bK74bf9 2052 Via: SIP/2.0/UDP client.provider-a.example.com:5060 2053 ;branch=z9hG4bK74bf9 2054 From: ;tag=1234567 2055 To: sip:411@provider-a.example.com 2056 Contact: ;audio;video;text 2057 ;actor="principle";automata;mobility="fixed" 2058 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" 2059 P-Asserted-Identity: "7327581234" 2061 P-Asserted-Identity: tel:+7327581234 2062 Content-Type: application/sdp 2063 Content-Length: ... 2064 [SDP not shown] 2066 If the OISP wishes to query the UA, it can send an OPTIONS request 2067 to the UA, and the UA, if it supports this mechanism, would include 2068 the feature capability tags in the Contact header, as show above, in 2069 the 200 OK response. 2071 9.18. Media Server Returning Data to the Application Server 2073 The OIS-AS needs to know the outcome of the operations performed by 2074 the OIS-MS, e.g. success/failure of front end automation, etc. Some 2075 mechanism is needed to convey this information. This could be 2076 conveyed using non SIP mechanisms. 2078 Any SIP message, including BYE, can carry message bodies. The 2079 simplest way for a OIS-MS to return data to an OIS-AS is to 2080 encapsulate the data in a MIME body. This requires agreement between 2081 both sides on the format and semantics of these bodies. 2083 Another approach is to use the content indirection mechanism to 2084 point to the data, however this may be rather cumbersome if only a 2085 small amount of data is to be returned. 2087 Some OIS service may make use of VoiceXML, whereby the OIS-AS 2088 invokes VoiceXML scripts on the OIS-MS, and the OIS-MS returns 2089 data to the OIS-AS. [RFC5552] describes a SIP interface to 2090 VoiceXML media services, which is commonly employed between 2091 application servers and media servers offering VoiceXML processing 2092 capabilities. This may be found useful for OIS services. 2094 The topic of application server control of media services is 2095 currently under study, and is the subject of the IETF MEDIACTRL 2096 working group's efforts. 2098 This information can also be conveyed using non SIP mechanisms. 2099 Describing such mechanisms is out of the scope of this document. 2101 9.19. Control of Cut Through Direction for PSTN Interworking 2103 For PSTN interworking scenarios, it may be desirable to explicitly 2104 control the "duplex" of the PSTN circuit; whether it be a two way 2105 connection or one way in the forward direction. The rules about SDP 2106 offer/answer indicate that as soon as an entity sends an SDP offer, 2107 it should be prepared to receive media for that session. 2109 However, in practice some deployments may require that a 18x 2110 response containing SDP be sent in the backward direction before 2111 "blocking gates" are opened to allow media in the reverse direction. 2113 SDP provides a "mode" attribute with values such as "a=sendonly", 2114 "a=recvonly", "a=sendrecv" for explicit control of the 2115 directionality. This mode attribute can be included in the SDP sent 2116 toward the PSTN GW in order to signal what duplex and directionality 2117 is desired. If it's desired to have a talk path only in the backward 2118 direction, such that audio is sent toward the caller but not in the 2119 opposite direction, then SDP with "a=sendonly" can be sent to the 2120 GW. When it's desired to have both-way cut through, an updated SDP 2121 can be sent with "a=sendrecv". This should affect not only the 2122 duplex of the voice path but also the related PSTN signaling sent by 2123 the GW towards the PSTN switch. For example, with ISUP, the GW 2124 should send an ACM with the User Network Interaction bit set in the 2125 Optional Backward Call Indication. Existing standards on PSTN 2126 interworking do not address this aspect of gateway behaviour. 2128 Further, some service provider networks may implement media 2129 authorization policies that require the use of the P-Early-Media SIP 2130 header field as defined in [RFC5009]. In such networks, or when 2131 interoperating with such networks, the response sent toward the PSTN 2132 GW as described above should also include the P-Early-Media header 2133 field with the "em-param" value set to "sendrecv". 2135 9.20. With Holding of Final Responses 2137 Currently in the PSTN, for operator services, signaling of Answer, 2138 whether this be an ISUP ANM or MF Answer Supervision, is often with 2139 held, leaving the call in an alerting state while the caller 2140 interacts with the operator services system. The motivation for this 2141 is that in the PSTN, billing normally starts when answer is 2142 signaled. For some calls answer may never be signaled; in others it 2143 may be signaled for instance when a call completion call is 2144 answered. 2146 The equivalent of answer indication in SIP is the 200 OK final 2147 response. It is not an intrinsic property of SIP based systems that 2148 billing must start upon 200 OK. In cases where it's desired to 2149 emulate the PSTN behaviour, the 200 OK can be with held. When this 2150 is done, normal SIP procedures need to be followed to prevent the 2151 session from timing out. For example, the UAS can periodically 2152 retransmit non-100 provisional responses as described in Section 2153 13.3.1.1 of [RFC3261]. 2155 10. Example Call Flow - Directory Assistance 2157 10.1. Basic Flow 2159 The following call flow provides examples of how a DA service could 2160 be implemented using the mechanisms described in this document. It 2161 is intended to illustrate the intended use of the proposed signaling 2162 mechanism. Some messages not crucial to this may be omitted for 2163 clarity. 2165 Caller Proxy A Proxy B Proxy C OIS-AS OIS-MS1 2166 | | | | | | 2167 | | | | | | 2168 | | | | | | 2169 |(1) INVITE sip:411@prov-a.net| | | 2170 |-------->| | | | | 2171 | | | | | | 2172 | |(2) INVITE sip:da@prov-b.net | | 2173 | |-------->| | | | 2174 | | | | | | 2175 | | |(3) INVITE sip:da@prov-c.net | 2176 | | |-------->| | | 2177 | | | | | | 2178 | | | |(4) INVITE sip:da-cc@prov-c.net 2179 | | | |-------->| | 2180 | | | | | | 2181 | | | | |(5) INVITE prompt & 2182 collect 2183 | | | | |-------->| 2184 | | | | | | 2185 | | | | |(6) 200 OK w.SDP 2186 | | | | |<--------| 2187 | | | |(7) 200 OK w.SDP | 2188 | | | |<--------| | 2189 | | |(8) 200 OK w.sdp | | 2190 | | |<--------| | | 2191 | |(9) 200 OK w.sdp | | | 2192 | |<--------| | | | 2193 |(10) 200 OK w.sdp | | | | 2194 |<--------| | | | | 2195 |(11) Ack | | | | | 2196 |-------->| | | | | 2197 | |(12) Ack | | | | 2198 | |-------->| | | | 2199 | | |(13) Ack | | | 2200 | | |-------->| | | 2201 | | | |(14) Ack | | 2202 | | | |-------->| | 2203 | | | | |(15) Ack | 2204 | | | | |-------->| 2205 | | | | | | 2207 Figure 8 DA Call flow, part 1 2209 For brevity, only relevant SIP headers will be shown. The following 2210 test refers to Figure 8. 2212 The user, homed in provider A, initiates a request for an OIS 2213 service, for instance by dialing "411". The user's UA sends a SIP 2214 INVITE. It might contain a "tel" URI. 2216 1. INVITE UE -> Home Proxy 2218 INVITE sip: 411@provider-a.example.com SIP/2.0 2219 Via: SIP/2.0/UDP client.provider-a.example.com:5060 2220 ;branch=z9hG4bK74bf9 2221 From: ;tag=1234567 2222 To: sip:411@provider-a.example.com 2223 Contact: 2224 Content-Type: application/sdp 2225 Content-Length: ... 2227 The home provider knows nothing of OISP services, for instance it 2228 might be a rather small scale provider. It is essentially set up to 2229 forward all calls of this type to Provider B. It translates the 2230 Request-URI to a SIP URI and sends the call on to provider B. 2231 Because of this retargeting, it adds a History-Info header to 2232 capture the dialed digits. 2234 The caller's identity is verified in a manner consistent with this 2235 provider's policies, and the proxy adds two P-Asserted-Identity 2236 headers: one with a SIP URI, and another with a "tel" URI. 2238 2. INVITE proxy-a -> proxy-b 2240 INVITE sip:411@provider-b.example.com SIP/2.0 2241 Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060 2242 ;branch=x9hG4bK74bf9 2243 Via: SIP/2.0/UDP client.provider-a.example.com:5060 2244 ;branch=z9hG4bK74bf9 2245 From: ;tag=1234567 2246 To: sip:411@provider-a.example.com 2247 Contact: 2248 P-Asserted-Identity: "7327581234" 2250 P-Asserted-Identity: tel:+7327581234 2251 History-Info: sip:411@provider-a.example.com; index=1 2252 Content-Type: application/sdp 2253 Content-Length: ... 2255 Proxy-b in provider-b's network receives the request. This is a 2256 larger network, and it has business relationships with several OIS 2257 providers, as well as with several providers which serve 2258 subscribers. This provider has logic which requires it to query the 2259 Home Provider's network to find some information related to the 2260 caller. This is not likely to be a SIP related function, and is thus 2261 out of scope for this document. The logic executes, taking the 2262 result of this query into account. It is determined that the call is 2263 for directory assistance, and that the call should be routed to 2264 provider C for handling. 2266 So, proxy-b retargets the Request-URI to reflect this, and routes 2267 the call to provider C (the OISP). It adds another entry to the 2268 History-Info header to capture this retargeting. 2270 3. INVITE proxy-b -> proxy-c 2272 INVITE sip:da@provider-c.example.com SIP/2.0 2273 Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060 2274 ;branch=y9hG4bK74bf9 2275 Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060 2276 ;branch=x9hG4bK74bf9 2277 Via: SIP/2.0/UDP client.provider-a.example.com:5060 2278 ;branch=z9hG4bK74bf9 2279 From: ;tag=1234567 2280 To: sip:411@provider-a.example.com 2281 Contact: 2282 P-Asserted-Identity: "732758123" 2284 P-Asserted-Identity: tel:+7327581234 2285 History-Info: sip:411@provider-a.example.com; index=1, 2286 ; index=1.1 2287 Content-Type: application/sdp 2288 Content-Length: ... 2290 Proxy-c in provider C's network receives the request. The source of 2291 the request is authenticated via mechanisms not described here. It 2292 needs to know how to bill this call, and thus needs to know which 2293 provider it came from. It looks at the topmost Via header, and sees 2294 that the call came from provider B. 2296 It examines the History-Info header, and is able to identify the 2297 dialed digits. It can also determine from the SIP URI which domains 2298 have been traversed, as long as each has retargeted and appended an 2299 entry in the header. 2301 The proxy determines that the call needs to go the OIS-AS for 2302 handling, so it retargets if necessary and forwards the INVITE. 2304 The OIS-AS performs 3PCC. It determines that the call needs a 2305 branded announcement based on the identity of the home provider, 2306 which it derives from the P-Asserted-Identity header. It initiates a 2307 new call leg toward OIS-MS1 for front end automation. Per [RFC4240], 2308 the "dialog" portion of the Request-URI indicates the "prompt & 2309 collect" service. The URI identifies the VoiceXML script to be 2310 executed. The SDP is the caller's SDP. 2312 5. INVITE OIS-AS -> MS1 2314 INVITE sip:dialog@ois-as.prov-c.example.com; \ 2315 voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml \ 2316 SIP/2.0 2317 Via: SIP/2.0/UDP ois-as.prov-c.example.com:5060 2318 ;branch=z9hG4bK74bf9 2319 From: ;tag=1234567 2320 To: sip:dialog@ois-as.prov-c.example.com; \ 2321 voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml 2322 Contact: 2323 Content-Type: application/sdp 2324 Content-Length: ... 2326 The OIS-MS responds with a 200 OK, with its own SDP. The OIS-AS now 2327 sends a 200 OK response back toward the caller, with the MS's SDP. 2328 Note that the OIS-AS could first have sent non final response back 2329 toward the user. 2331 Caller OIS-AS OIS-MS1 ACD OWS 2332 | | | | | 2333 |(16) RTP session | | | 2334 |...................| | | 2335 | | | | | 2336 | |(17) INFO w.URI, body | 2337 | |<--------| | | 2338 | | | | | 2339 | |(18) INVITE | | 2340 | |------------------>| | 2341 | | | | | 2342 | |(19) 182 Queued | | 2343 | |<------------------| | 2344 | | | | | 2345 | |(20) 3xx Redirection | 2346 | |<------------------| | 2347 | | | | | 2348 | |(21) INVITE | | 2349 | |---------------------------->| 2350 | | | | | 2351 | |(22) 200 OK | | 2352 | |<----------------------------| 2353 | |(23) ACK | | | 2354 | |---------------------------->| 2355 | | | | | 2356 | |(24) BYE | | | 2357 | |-------->| | | 2358 | |(25) 200 OK | | 2359 | |<--------| | | 2360 | | | | | 2361 |(26) re INVITE | | | 2362 |<--------| | | | 2363 | | | | | 2364 |(27) 200 OK | | | 2365 |-------->| | | | 2366 |(28) ACK | | | | 2367 |<--------| | | | 2368 | | | | | 2369 |(29) RTP session | | | 2370 |.......................................| 2371 | | | | | 2372 | |(30) BYE | | | 2373 | |<----------------------------| 2374 | |(31) 200 OK | | 2375 | |---------------------------->| 2376 Figure 9 DA Call flow, part 2 2378 The following text refers to Figure 9. 2380 The user is now connected (16) to the MS, which plays a branded 2381 announcement, and prompts for the listing information. When the user 2382 speaks his request, the MS processes the audio to obtain a "whisper" 2383 file, or condensed version of the request. In this example, the MS 2384 is unable to successfully perform the query, so it sends an 2385 indication of this to the AS. In this example, the indication is 2386 sent using an as yet unspecified protocol message carried in a 2387 message body in a SIP INFO message, which also carries a URI which 2388 points to the whisper file. Other mechanisms, including non SIP 2389 mechanisms, could also be used to this end (this is the subject of 2390 further study). The AS allows the caller to remain connected to the 2391 MS while it sets up a call to an operator workstation (OWS), 2392 allowing for the possibility to play custom announcements to the 2393 caller. 2395 The OIS-AS decides based on the failure indication that it needs to 2396 route the call to a human operator. It sends an INVITE (18) to the 2397 ACD server. This INVITE carries information about the required 2398 characteristics, such as language and skill set, of the operator 2399 which should be selected for this call. The means by which this 2400 information is carried has yet to be defined. One possible way an 2401 ACD could be implemented is as a presence server, such that it keeps 2402 track of the availability of all the operators. The Media Resource 2403 Broker being discussed in the IETF MEDIACTRL working group also 2404 represents an approach to ACD. 2406 If the call needs to be queued due to lack of an immediately 2407 available resource, the ACD may send a 812 Queued response (19). In 2408 this example, the ACD server is implemented as a redirect server - 2409 it sends a 3XX response (20) which identifies the operator the OIS- 2410 AS should contact. Alternately, the ACD server could have proxied 2411 the request to the operator. 2413 The OIS-AS now sends an INVITE (21) containing the URI to the 2414 whisper, as well as the caller's SDP, to the indicated operator 2415 workstation. The operator workstation sends a 200 OK (22) with its 2416 SDP, which the OIS-AS sends toward the caller in a re-INVITE (26). 2417 Only when the workstation has sent a final response to the INVITE, 2418 the AS sends a BYE (24) to the MS. 2420 The caller is now connected to the operator (29), and the operator 2421 helps the caller with the listing. The operator workstation launches 2422 a query, and a response is received. The operator signals a BYE (30) 2423 toward the OIS-AS, which may contain the listing information in a 2424 message body, a pointer (URI) to the listing information, or it may 2425 pass this information to the OIS-AS using some other, non SIP 2426 mechanism. 2428 Caller OIS-AS OIS-MS2 2429 | | | 2430 | | | 2431 | | | 2432 | |(32) INVITE 2433 | |-------->| 2434 | | | 2435 | |(33) 200 OK 2436 | |<--------| 2437 | |(34) ACK | 2438 | |-------->| 2439 | | | 2440 |(35) re INVITE | 2441 |<--------| | 2442 | | | 2443 |(36) 200 OK | 2444 |-------->| | 2445 |(37) ACK | | 2446 |<--------| | 2447 | | | 2448 |(38) RTP session | 2449 |...................| 2450 | | | 2451 | |(39) BYE w.URI, body 2452 | |<--------| 2453 | | | 2454 | |(40) 200 OK 2455 | |-------->| 2456 | | | 2457 |(41) REFER | 2458 |<--------| | 2459 | | | 2460 | | | 2462 Figure 10 DA Call flow, part 3 2464 The following text refers to Figure 10. 2466 The OIS-AS sends an INVITE (32) to another OIS-MS, MS2, for back end 2467 automation. (Note that though MS2 is shown as a separate element, 2468 the functionality it provides may or may not require a separate 2469 element.) When it receives MS2's SDP in the 200 OK (33), it sends a 2470 re-INVITE (35) toward the user to update the SDP. At this point an 2471 audio session is in place between the caller and the back end 2472 automation MS (38). The MS plays the listing information, and offers 2473 call completion service. The caller accepts, so OIS-MS2 sends a BYE 2474 (39) with a message body containing the result of the call 2475 completion offer. Since call completion was requested, the OIS-AS 2476 sends a REFER (41) to the caller, to cause it to place a call to the 2477 listed party. The OIS-AS may or may not care about subsequent 2478 NOTIFYs from the caller, and drops out of the call. 2480 10.2. OISP Drops Out at Call Completion Setup 2482 The OISP may want to support different call flow options with 2483 respect to call completion. Reasons for this may include the desire 2484 to free up resources quickly, provide additional functionality, etc. 2485 When the OISP wants to provide the listing information and free 2486 resources as soon as possible, a simple flow based on REFER can be 2487 used, as illustrated below. 2489 In this flow, the caller is already connected to an OISP resource 2490 such as an MS, and requests call completion. In (2), the OISP sends 2491 a REFER to initiate the call completion call. The caller's UA 2492 indicates acceptance of the REFER by sending a 202 Accepted (3). It 2493 then sends a NOTIFY indicating that it is attempting to contact the 2494 indicated resource, by sending an INVITE (10). When the AS receives 2495 this notification, it understands that the caller is attempting the 2496 call completion call, so it drops the call by sending BYE in (6)and 2497 (8). The various notifications sent by the caller to the OISP can be 2498 used to monitor progress of the call, or may simply be ignored from 2499 an application standpoints (from a protocol standpoint they must be 2500 acknowledged). 2502 Caller AS MS Called Party 2503 | | | | 2504 | | | | 2505 |(1) Caller connected to e.g., MS | 2506 |.............................| | 2507 | | | | 2508 |(2) REFER (Called) | | 2509 |<-------------| | | 2510 |(3) 202 Accepted | | 2511 |------------->| | | 2512 | | | | 2513 |(4) NOTIFY (Trying) | | 2514 |------------->| | | 2515 |(5) 200 OK | | | 2516 |<-------------| | | 2517 | | | | 2518 | |(6) BYE | | 2519 | |------------->| | 2520 | |(7) 200 OK | | 2521 | |<-------------| | 2522 | | | | 2523 |(8) BYE | | | 2524 |<-------------| | | 2525 |(9) 200 OK | | | 2526 |------------->| | | 2527 | | | | 2528 |(10) INVITE | | | 2529 |------------------------------------------->| 2530 | | | | 2531 |(11) 200 OK | | | 2532 |<-------------------------------------------| 2533 |(12) Ack | | | 2534 |------------------------------------------->| 2535 | | | | 2536 |(13) NOTIFY (200 OK) | | 2537 |------------->| | | 2538 |(14) 200 OK | | | 2539 |<-------------| | | 2540 | | | | 2541 Figure 11 OISP Drops Out at Call Completion Setup 2543 10.3. OISP Drops Out After Call Completion Call is Answered 2545 The OISP may need to remain in the signaling path until the call 2546 completion call is answered. One way to implement this is to use the 2547 REFER method with the Replaces header, as described in [RFC3891]. In 2548 this case, once the call completion call is answered (5), the OISP's 2549 AS sends a REFER (6) toward the caller with a Replaces header 2550 identifying the current dialog between the AS and called party, and 2551 Referred-by header identifying the AS. This causes an INVITE (10) to 2552 be sent toward the called party, also with Replaces and Referred-by 2553 headers. As described in [RFC3891], this causes a new session to be 2554 set up with the called party, replacing the existing sessions. As 2555 part of this, the original session is torn down (16). Thus, the 2556 OISP's resources are removed from the call. 2558 Caller AS MS Called Party 2559 | | | | 2560 | | | | 2561 | | | | 2562 |(1) Caller listening to announcements, etc | 2563 |.............................| | 2564 | | | | 2565 | |(2) INVITE | | 2566 | |---------------------------->| 2567 | | | | 2568 | |(3) 183 Ringing | 2569 | |<----------------------------| 2570 | | | | 2571 | |(4) 200 OK | | 2572 | |<----------------------------| 2573 | | | | 2574 | |(5) ACK | | 2575 | |---------------------------->| 2576 | | | | 2577 |[Called party has answered] | | 2578 | | | | 2579 |(6) REFER (Called Party, Replaces:AS, Referred-by:AS) 2580 |<-------------| | | 2581 | | | | 2582 |(7) 202 Accepted | | 2583 |------------->| | | 2584 | | | | 2585 |(8) NOTIFY (100 Trying) | | 2586 |------------->| | | 2587 | | | | 2588 |(9) 200 OK | | | 2589 |<-------------| | | 2590 | | | | 2591 |(10) INVITE (Replaces:AS, Referred-by:AS) | 2592 |------------------------------------------->| 2593 | | | | 2594 |(11) 200 OK | | | 2595 |<-------------------------------------------| 2596 | | | | 2597 |(12) ACK | | | 2598 |------------------------------------------->| 2599 | | | | 2600 |[Called Party replaces existing dialog from Step 2 with new one] 2601 | | | | 2602 | | | | 2603 |(13) RTP [Called and Calling Party are now connected ] 2604 |............................................| 2605 | | | | 2606 | | | | 2607 |[ Remainder of steps cleanup dialogs between Caller-AS and AS- 2608 Called ] 2609 | | | | 2610 |(14) NOTIFY (200 OK) | | 2611 |------------->| | | 2612 | | | | 2613 |(15) 200 OK | | | 2614 |<-------------| | | 2615 | | | | 2616 | |(16) BYE (as a result of receiving Replaces) 2617 | |<----------------------------| 2618 | | | | 2619 | |(17) 200 OK | | 2620 | |---------------------------->| 2621 | | | | 2622 |(18) BYE | | | 2623 |<-------------| | | 2624 | | | | 2625 |(19) 200 OK | | | 2626 |------------->| | | 2627 | | | | 2628 Figure 12 OISP Drops After Call Completion is Answered 2630 10.4. OISP Drops Out After Interaction with Called Party 2632 In this scenario, the OISP needs to interact with the called party, 2633 then desired to remove its resources from the call. Collect calls 2634 are one example where this might be used. This also uses REFER with 2635 Replaces. The OISP places a call to the called party, and 2636 interactions between OISP resources (automated or human) occur. The 2637 OISP then sends a REFER with Replaces and Referred-by to the calling 2638 party, which then sends an INVITE as described for the previous 2639 scenario. 2641 In this scenario, the OISP has one media session (1) with the caller 2642 and another (2) with the called party. After interactions have been 2643 completed, the OISP initiates the transfer by sending a REFER (3) 2644 with Replaces and Referred-by headers. This causes the caller's UA 2645 to send a corresponding INVITE (7) containing those headers. As with 2646 the previous scenario, this causes initiation of a new session 2647 replacing the existing session, as well as teardown (10) of the 2648 existing session. 2650 Caller AS MS Called 2651 | | | | 2652 | | | | 2653 | | | | 2654 |[ Calling party has some RTP session with MS ] | 2655 | | | | 2656 | | | | 2657 |(1) RTP | | | 2658 |.......................................| | 2659 | | | | 2660 |[ Called party has different RTP session with MS ] | 2661 | | | | 2662 | | | | 2663 | | |(2) RTP | 2664 | | |...................| 2665 | | | | 2666 |[ AS initiates transfer with REFER ] | | 2667 | | | | 2668 | | | | 2669 |(3) REFER (to called, Replaces:AS, Referred-by:AS) | 2670 |<------------------| | | 2671 | | | | 2672 | | | | 2673 |(4) 202 Accepted | | | 2674 |------------------>| | | 2675 | | | | 2676 |(5) NOTIFY (trying)| | | 2677 |------------------>| | | 2678 | | | | 2679 |(6) 200 OK | | | 2680 |<------------------| | | 2681 | | | | 2682 |[ Replaces header causes Called to replace old call with new ] 2683 | | | | 2684 | | | | 2685 |(7) INVITE (Replaces:AS, Referred-by:AS) | 2686 |---------------------------------------------------------->| 2687 | | | | 2688 | | | | 2689 |(8) 200 OK (SDP-called) | | 2690 |<----------------------------------------------------------| 2691 | | | | 2692 |(9) ACK | | | 2693 |---------------------------------------------------------->| 2694 | | | | 2695 |[ Calling and Called are now talking directly ] | 2696 | | | | 2697 | | | | 2698 | | | | 2699 |[As a result of Replaces operation, called ends session with MS] 2700 | | | | 2701 | |(10) BYE (as a result of processing Replaces) 2702 | |<--------------------------------------| 2703 | | | | 2704 | |(11) 200 OK | | 2705 | |-------------------------------------->| 2706 | | | | 2707 |[AS ends session with Calling] | | 2708 | | | | 2709 |(12) BYE | | | 2710 |<------------------| | | 2711 |(13) 200 OK | | | 2712 |------------------>| | | 2713 | | | | 2714 |(14) NOTIFY (200 OK) | | 2715 |------------------>| | | 2716 |(15) 200 OK | | | 2717 |<------------------| | | 2718 | | | | 2719 Figure 13 OISP Drops Out After Interaction With Called Party 2721 10.5. OISP Remains in Path 2723 In some cases, the OISP desires to maintain its elements in the 2724 signaling path and possibly in the media path as well for the 2725 duration of the call completion call. One possible reason for doing 2726 this is so that the caller can request to be returned to the OISP 2727 for additional services after the call has completed. 2729 The figure below begins with the caller already connected to OISP 2730 resources. The AS initiates call completion in steps 2 through 5 by 2731 sending an INVITE toward the called party. The AS then sends a re- 2732 INVITE toward the caller to update the SDP, and step 9 shows the 2733 media session established between the caller and the called party, 2734 and in step 10 clears the previous session with the MS. When the 2735 called party hangs up in step 12, the AS responds. In step 14, the 2736 AS has the opportunity to redirect the caller to a MS or other 2737 resource to offer additional services, but in this case simply 2738 clears the dialog with the caller. 2740 Caller AS MS Called Party 2741 | | | | 2742 | | | | 2743 | | | | 2744 |(1) Caller has media session with MS | 2745 |.............................| | 2746 | | | | 2747 |AS initiates call completion | | 2748 | | | | 2749 | | | | 2750 | |(2) INVITE | | 2751 | |---------------------------->| 2752 | | | | 2753 | |(3) 180 Ringing | 2754 | |<----------------------------| 2755 | | | | 2756 | |(4) 200 OK | | 2757 | |<----------------------------| 2758 | | | | 2759 | |(5) ACK | | 2760 | |---------------------------->| 2761 | | | | 2762 |Called party has answered | | 2763 | | | | 2764 | | | | 2765 |(6) re-INVITE | | | 2766 |<-------------| | | 2767 | | | | 2768 |(7) 200 OK | | | 2769 |------------->| | | 2770 | | | | 2771 |(8) ACK | | | 2772 |<-------------| | | 2773 | | | | 2774 |(9) Media Session | | 2775 |............................................| 2776 | | | | 2777 | |(10) BYE | | 2778 | |------------->| | 2779 | | | | 2780 | |(11) 200 OK | | 2781 | |<-------------| | 2782 | | | | 2783 |Called party hangs up | | 2784 | | | | 2785 | | | | 2786 | |(12) BYE | | 2787 | |<----------------------------| 2788 | | | | 2789 | |(13) 200 OK | | 2790 | |---------------------------->| 2791 | | | | 2792 |AS clears call back to Caller| | 2793 | | | | 2794 | | | | 2795 |(14) BYE | | | 2796 |<-------------| | | 2797 | | | | 2798 |(15) 200 OK | | | 2799 |------------->| | | 2800 | | | | 2801 | | | | 2802 Figure 14 OISP Remains in Signaling Path 2804 10.6. Return of Call to OISP 2806 In some cases, it is desirable that the caller be able to request, 2807 typically via keypad stimulus such as the octothorpe or pound sign, 2808 to be returned to the OISP operator (human or automated). One way 2809 this can be accomplished is for the OISP to use KPML [RFC4730] to 2810 subscribe to the desired keypress. The flow presented here assumes 2811 that the calling UA, or an intermediary acting on its behalf, 2812 supports this event package, and is able to detect the desired 2813 keypress. Examples of such intermediaries include back to back user 2814 agents (B2BUAs) and Session Border Controllers (SBCs). Another 2815 option is for the OISP to insert some element such as a MS into the 2816 media stream, which is capable of detecting and notifying the 2817 desired keypress. 2819 In (1) the caller has already been connected to called party via the 2820 AS. In (2), the AS subscribes to KPML events from the caller's UA. 2821 Note that in some environments, this could be intercepted and acted 2822 upon by intermediaries such as B2BUAs or SBCs. As long as this does 2823 not interfere with notification, this is transparent to the OISP. 2824 When the caller presses the specified keypress to request return to 2825 the OISP, a NOTIFY (6) is sent to the AS. At this time, the OISP can 2826 perform whatever actions are necessary, such as perhaps sending a 2827 re-INVITE or UPDATE to move the media session to an OISP resource. 2829 Caller AS MS Called Party 2830 | | | | 2831 |(1) Caller connected to called via 3PCC | 2832 |............................................| 2833 | | | | 2834 |(2) SUBSCRIBE (KPML body specifying "#") | 2835 |<-------------| | | 2836 |(3) 200 OK | | | 2837 |------------->| | | 2838 | | | | 2839 |(4) NOTIFY (result of subscription) | 2840 |------------->| | | 2841 |(5) 200 OK | | | 2842 |<-------------| | | 2843 | | | | 2844 |[ Some time passes ] | | 2845 | | | | 2846 |[ Caller wants back to OISP, hits "#" ] | 2847 | | | | 2848 | | | | 2849 |(6) NOTIFY (KPML body specifying "#") | 2850 |------------->| | | 2851 |(7) 200 OK | | | 2852 |<-------------| | | 2853 Figure 15 Return of Call to OISP 2855 10.7. PSTN Origination 2857 The following example shows a call from a PSTN caller. In this case, 2858 the incoming IAM is translated at the PSTN gateway to a SIP INIVTE. 2859 Though not specifically shown, the INVITE contains the IAM 2860 encapsulated in a MIME body, and any ISUP parameters are mapped to 2861 SIP headers and/or parameters as described in [T1679]; additionally 2862 the mechanisms described in this document are also applied, such as 2863 encoding of the trunk group information in the Contact header per 2864 [RFC4904]. 2866 Note that the 183 Session Progress in step (6) contains the SDP of 2867 the media server. As described in Section 9.19 "Control of Cut 2868 Through Direction for PSTN Interworking", this may be required in 2869 some deployments before media in the reverse direction is allowed by 2870 blocking gates. 2872 EO GW AS MS1 MS2 Called Party 2873 | | | | | | 2874 | | | | | | 2875 | | | | | | 2876 |Incoming ISUP Call | | | | 2877 | | | | | | 2878 |(1) IAM | | | | | 2879 |---------->| | | | | 2880 | |(2) INVITE (GW SDP) | | | 2881 | |---------->| | | | 2882 | | |(3) INVITE (GW SDP) | | 2883 | | |---------->| | | 2884 | | |(4) 200 OK (MS1 SDP) | | 2885 | | |<----------| | | 2886 | | |(5) ACK | | | 2887 | | |---------->| | | 2888 | |(6) 183 Session Progress (MS1 SDP) | | 2889 | |<----------| | | | 2890 |(7) ACM | | | | | 2891 |<----------| | | | | 2892 | |(8) PRACK | | | | 2893 | |---------->| | | | 2894 | |(9) 200 OK | | | | 2895 | |<----------| | | | 2896 | |(10) RTP Session | | | 2897 | |.......................| | | 2898 |E.g. Front End Announcements | | | 2899 | | | | | | 2900 | | |(11) BYE | | | 2901 | | |<----------| | | 2902 | | |(12) 200 OK| | | 2903 | | |---------->| | | 2904 | | | | | | 2905 | | |(13) INVITE (GW SDP) | | 2906 | | |---------------------->| | 2907 | | |(14) 200 OK (MS2 SDP) | | 2908 | | |<----------------------| | 2909 | | |(15) ACK | | | 2910 | | |---------------------->| | 2911 | |(16) UPDATE (MS2 SDP) | | | 2912 | |<----------| | | | 2913 | |(17) 200 OK| | | | 2914 | |---------->| | | | 2915 | |(18) RTP Session | | | 2916 | |...................................| | 2917 | | |(19) INVITE| | | 2918 | | |---------------------------------->| 2919 | | |(20) 183 Session Progress | 2920 | | |<----------------------------------| 2921 | | |(21) PRACK | | | 2922 | | |---------------------------------->| 2923 | | |(22) 200 OK| | | 2924 | | |<----------------------------------| 2925 | |(23) UPDATE (Called SDP) | | 2926 | |<----------| | | | 2927 | |(24) 200 OK| | | | 2928 | |---------->| | | | 2929 | | |(25) BYE | | | 2930 | | |<----------------------| | 2931 | | |(26) 200 OK| | | 2932 | | |---------------------->| | 2933 | |(27) RTP Session | | | 2934 | |...............................................| 2935 | | |(28) 200 OK| | | 2936 | | |<----------------------------------| 2937 | | |(29) Ack | | | 2938 | | |---------------------------------->| 2939 | |(30) 200 OK| | | | 2940 | |<----------| | | | 2941 | |(31) ACK | | | | 2942 | |---------->| | | | 2943 |(32) ANM | | | | | 2944 |<----------| | | | | 2945 | | | | | | 2946 Figure 16 PSTN Origination 2948 10.8. PSTN Termination 2950 The following example shows a call which results in call completion 2951 to a destination on the PSTN. In Step 17 the AS sends an INVITE 2952 toward the PSTN gateway which results in an IAM being sent which 2953 initiates the PSTN call leg. 2955 Calling Party AS MS1 MS2 GW EO 2956 | | | | | | 2957 | | | | | | 2958 | | | | | | 2959 |Incoming SIP call | | | | 2960 | | | | | | 2961 |(1) INVITE (Caller SDP)| | | | 2962 |---------->| | | | | 2963 | |(2) INVITE (Caller SDP)| | | 2964 | |---------->| | | | 2965 | |(3) 200 OK (MS1 SDP) | | | 2966 | |<----------| | | | 2967 | |(4) ACK | | | | 2968 | |---------->| | | | 2969 |(5) 183 Session Progress (MS1 SDP) | | | 2970 |<----------| | | | | 2971 |(6) PRACK | | | | | 2972 |---------->| | | | | 2973 |(7) 200 OK | | | | | 2974 |<----------| | | | | 2975 |(8) RTP Session | | | | 2976 |.......................| | | | 2977 |E.g. Front End Announcements | | | 2978 | | | | | | 2979 | |(9) BYE | | | | 2980 | |<----------| | | | 2981 | |(10) 200 OK| | | | 2982 | |---------->| | | | 2983 | | | | | | 2984 | |(11) INVITE (Caller SDP) | | 2985 | |---------------------->| | | 2986 | |(12) 200 OK (MS2 SDP) | | | 2987 | |<----------------------| | | 2988 | |(13) ACK | | | | 2989 | |---------------------->| | | 2990 |(14) UPDATE (MS2 SDP) | | | | 2991 |<----------| | | | | 2992 |(15) 200 OK| | | | | 2993 |---------->| | | | | 2994 |(16) RTP Session | | | | 2995 |...................................| | | 2996 | |(17) INVITE| | | | 2997 | |---------------------------------->| | 2998 | | | | |(18) IAM | 2999 | | | | |---------->| 3000 | | | | |(19) ACM | 3001 | | | | |<----------| 3002 | |(20) 183 Session Progress | | 3003 | |<----------------------------------| | 3004 | |(21) PRACK | | | | 3005 | |---------------------------------->| | 3006 | |(22) 200 OK| | | | 3007 | |<----------------------------------| | 3008 |(23) UPDATE (GW SDP) | | | | 3009 |<----------| | | | | 3010 |(24) 200 OK| | | | | 3011 |---------->| | | | | 3012 | | | | |(25) ANM | 3013 | | | | |<----------| 3014 | |(26) 200 OK| | | | 3015 | |<----------------------------------| | 3016 | |(27) Ack | | | | 3017 | |---------------------------------->| | 3018 |(28) 200 OK(GW SDP) | | | | 3019 |<----------| | | | | 3020 |(29) ACK | | | | | 3021 |---------->| | | | | 3022 |(30) RTP Session | | | | 3023 |...............................................| | 3024 | | | | |(31) REL | 3025 | | | | |<----------| 3026 | | | | |(32) RLC | 3027 | | | | |---------->| 3028 | |(33) BYE | | | | 3029 | |<----------------------------------| | 3030 | |(34) 200 OK| | | | 3031 | |---------------------------------->| | 3032 |(35) BYE | | | | | 3033 |<----------| | | | | 3034 |(36) 200 OK| | | | | 3035 |---------->| | | | | 3036 | | | | | | 3037 Figure 17 PSTN Termination 3039 10.9. Call Completion By Releasing Call Back to PSTN 3041 This example shows how when a call is received from the PSTN, call 3042 completion can be achieved by releasing the call back to the PSTN to 3043 have a PSTN switch initiate the call completion call. This allows 3044 call completion to occur in the PSTN, and completely drops the call 3045 from the OISP. The PSTN feature which supports this is called 3046 Release To Pivot; other implementations may also exist. The 3047 gateway's connection to the PSTN needs to be specifically 3048 provisioned to support this feature. There is currently no standard 3049 describing the invocation of this feature using SIP; nor does this 3050 document intend to do this. Rather, it intends to illustrate one way 3051 in which it might be done. This flow appears as the equivalent of a 3052 blind transfer with the PSTN gateway as the originator; the key 3053 thing is that the PSTN gateway needs to understand this as a request 3054 for Release to Pivot or equivalent PSTN feature. 3056 EO GW AS MS1 EO-2 3057 | | | | | 3058 | | | | | 3059 | | | | | 3060 |Incoming ISUP Call | | | 3061 | | | | | 3062 |(1) IAM | | | | 3063 |------------->| | | | 3064 | |(2) INVITE (GW SDP) | | 3065 | |------------->| | | 3066 | | |(3) INVITE (GW SDP) | 3067 | | |------------->| | 3068 | | |(4) 200 OK (MS1 SDP) | 3069 | | |<-------------| | 3070 | | |(5) ACK | | 3071 | | |------------->| | 3072 | |(6) 183 Session Progress (MS1 SDP) | 3073 | |<-------------| | | 3074 |(7) ACM | | | | 3075 |<-------------| | | | 3076 | |(8) PRACK | | | 3077 | |------------->| | | 3078 | |(9) 200 OK | | | 3079 | |<-------------| | | 3080 | |(10) RTP Session | | 3081 | |.............................| | 3082 |E.g. Front End Announcements | | | 3083 | | | | | 3084 | | |(11) BYE | | 3085 | | |<-------------| | 3086 | | |(12) 200 OK | | 3087 | | |------------->| | 3088 | |(13) REFER (call completion number) | 3089 | |<-------------| | | 3090 | |(14) 202 Accepted | | 3091 | |------------->| | | 3092 | |(15) NOTIFY(trying) | | 3093 | |------------->| | | 3094 | |(16) 200 OK | | | 3095 | |<-------------| | | 3096 |(17) REL | | | | 3097 |<-------------| | | | 3098 |(18) RLC | | | | 3099 |------------->| | | | 3100 | |(19) NOTIFY(200 OK) | | 3101 | |------------->| | | 3102 | |(20) 200 OK | | | 3103 | |<-------------| | | 3104 |(21) IAM, etc.| | | | 3105 |---------------------------------------------------------->| 3106 | | | | | 3107 | | | | | 3108 Figure 18 Call Completion By Releasing Call Back to PSTN 3110 11. Operator Services Example Call Flows 3112 The following call flows provide examples of how specific operator 3113 services could be implemented using the mechanisms described in this 3114 document. The purpose is to illustrate one way to implement these 3115 services using the proposed signaling mechanisms. 3117 11.1. Network Controlled Coin Calls 3119 This flow depicts a SIP based OISP handling calls from a network 3120 controlled coin station. The OISP needs to determine the coinage 3121 deposited by the station. Note that "smart" coin stations do not 3122 require interaction with the OISP. This discussion only addresses 3123 control of TDM based network controlled coin stations. 3125 The configuration is as follows. Network controlled coin stations 3126 are connected to TDM based end offices (EOs) using special access 3127 lines, the characteristics of which are not important to this 3128 discussion. The EO exchanges signaling with the station over this 3129 access line, but does not perform the coin control. Operator 3130 Services switches historically provide the control for these types 3131 of calls, and the EO connects to the Operator Switch via special 3132 coin control trunks. The EO translates between coin access and coin 3133 trunk signaling. 3135 The signaling includes coin station control and coin deposit 3136 indications. The OISP sends coin station control signaling to the 3137 coin station to instruct it to collect coins, return coins, etc. The 3138 coin deposit signaling is sent by the coin station toward the OISP, 3139 and indicates the coinage inserted by the user. 3141 Coin station control signaling includes signals such as coin 3142 collect, coin return, operator ringback, etc. The way in which these 3143 signals are conveyed depends on the type of coin trunk being used. 3144 For SS7 ISUP coin trunks, these are conveyed using the Service 3145 Activation (SAP) ISUP parameter. For MF trunks using multiwink coin 3146 signaling, these signals are conveyed using a series MF hook state 3147 transition events known as "winks". For MF trunks using Expanded 3148 Inband Signaling (EIS), these signals are conveyed as tone bursts in 3149 conjunction with a wink. The relevant MF signaling is described in 3150 [GR506]. 3152 When the AS communicates with the GW using encapsulated ISUP, such 3153 as for SS7 ISUP trunks and cases where the gateway internally 3154 converts between MF and encapsulated ISUP, then the AS can convey 3155 coin control signaling to the GW using encapsulated ISUP that 3156 includes the appropriate Service Activation Parameter (SAP) value. 3157 This encapsulated ISUP is carried within the SIP signaling sent to 3158 the GW. 3160 For multiwink signaling, the AS could connect the GW to an MS and 3161 instruct the MS to play the appropriate signals using an existing 3162 mechanism such as netann, VXML, etc. As mentioned above, the 3163 multiwink signals are MF hook transition events. [RFC5244] defines a 3164 mechanism for signaling the ABCD states used to represent MF hook 3165 states within an RTP stream. The MS would generate the appropriate 3166 "telephone-event" RTP payload format packets defined in RFC 5244 in 3167 response to requests from the AS. In order to be able to render 3168 these events on the TDM side, the GW would need to implement 3169 reception of RFC 5244 packets. 3171 For EIS signaling, an MS could be used as above, generating the 3172 appropriate tones and hook transitions in response to requests from 3173 the AS. The hook transition events as above could be accomplished 3174 using RFC 5244. The audio tones could be transmitted using an audio 3175 codec such as G.711. Alternatively, RFC 4733 "tone" RTP payload 3176 format packets as described in Section 4 of that document could be 3177 used. Finally, new RFC 4733 codepoints have been registered with 3178 IANA for these tones, so the can be conveyed using the "telephone- 3179 event" RTP payload format. 3181 Coin deposit signaling is sent as tone bursts on the trunk from the 3182 coin station towards the OISP, regardless of whether ISUP or MF 3183 signaling is used on the trunk. The tones could be detected by the 3184 GW, or they could be detected by a MS that has been connected by the 3185 AS. In either case, some mechanism is needed in order for the AS to 3186 request detection and for the MS to report detection of these tones. 3187 KPML [RFC4730] and VXML both natively support the reporting of DTMF 3188 tones, but there is currently no standardized way to represent the 3189 tone bursts representing the deposit of coins. The possibility 3190 arises to represent the coin deposit tones in KPML or VXML by 3191 mapping them to some set of service provider specified DTMF digits. 3193 The following examples illustrates the use of encapsulated ISUP to 3194 convey the coin control signaling, and detection of coin deposit 3195 signals at the GW, with the GW reporting coin deposits using KPML. 3196 As identified above, other alternatives are possible. 3198 In the following flow, the EO is the end office service the coin 3199 station, the PSTN GW is the GW terminating the voice trunks and 3200 signaling from the EO, the AS is the OIS AS, the MS is a media 3201 server in the OIS provider, and the called party is self 3202 explanatory. 3204 In step 1, the coin station (not shown) has signaled a call request 3205 to the EO, which in turn selects a coin trunk toward the OISP PSTN 3206 GW, and initiates the corresponding signaling. In steps 2 through 4, 3207 the PSTN GW sends an INVITE to the AS, which accepts the call. 3209 In steps 5 through 7, the AS sends a SIP INFO message containing 3210 encapsulated ISUP, which contains an ISUP SAP parameter with the 3211 Feature Code Indicator (FCI) indicating "Network Service Attached", 3212 which is an instruction to the coin station that an Operator 3213 Services System has been connected. The GW sends the corresponding 3214 PSTN signaling back toward the coin station. 3216 In steps 8 through 10, the AS using the same procedures sends 3217 encapsulated ISUP with a SAP parameter with the FCI indicating "Coin 3218 Collect" which instructs the coin station to collect and report on 3219 coin deposits. 3221 The coin deposits will be signaled as tones over the trunk, so the 3222 AS in steps 11 through 14 subscribes to these events at the GW. This 3223 example assumes an extension to KPML to support these tones, but the 3224 mechanism is the same even if a new event package were defined. 3226 In 15, the user deposits coins into the station, and these events 3227 are signaled by the EO to the GW. In step 16, the GW sends SIP 3228 NOTIFY messages to the AS for each such event. 3230 When the AS determines that adequate payment has been collected, it 3231 routes the call, as depicted in steps 18 through 24. 3233 In this example, the caller exceeds his credit, and hangs up the 3234 phone. This is represented by steps 25 through 27. 3236 Using similar signaling, the OISP sends an Operator Hold and 3237 Ringback request toward the station, to "keep the line open" and to 3238 ring the station so that the user can be prompted to pay the 3239 exceeded credit. This is represented in steps 28 through 36. In this 3240 case, the honest user inserts the required coins, and this is 3241 signaled to the OISP in steps 39 through 41. From steps 42 on, the 3242 line is "released". 3244 EO GW AS MS Called Party 3245 | | | | | 3246 | | | | | 3247 | | | | | 3248 |(1) Call Request Indication | | 3249 |-------->| | | | 3250 | | | | | 3251 | |(2) INVITE | | 3252 | |-------->| | | 3253 | | | | | 3254 | |(3) 200 OK | | 3255 | |<--------| | | 3256 | | | | | 3257 | |(4) ACK | | | 3258 | |-------->| | | 3259 | | | | | 3260 | |(5) INFO (ISUP),SAP FCI=Network Service Attach) 3261 | |<--------| | | 3262 | | | | | 3263 | |(6) 200 OK | | 3264 | |-------->| | | 3265 | | | | | 3266 |(7) corresponding MF or ISUP signaling | 3267 |<--------| | | | 3268 | | | | | 3269 | |(8) INFO (ISUP,SAP FCI=Coin Collect) 3270 | |<--------| | | 3271 | | | | | 3272 | |(9) 200 OK | | 3273 | |-------->| | | 3274 | | | | | 3275 |(10) corresponding MF or ISUP signaling| 3276 |<--------| | | | 3277 | | | | | 3278 |(11) SUBSCRIBE (KPML body specifying coin deposit tones) 3279 |<------------------| | | 3280 | | | | | 3281 |(12) 200 OK | | | 3282 |------------------>| | | 3283 | | | | | 3284 |(13) NOTIFY (result of subscription) | 3285 |------------------>| | | 3286 | | | | | 3287 |(14) 200 OK | | | 3288 |<------------------| | | 3289 | | | | | 3290 |[ User inserts coins ] | | 3291 | | | | | 3292 | | | | | 3293 |(15) Coin deposit signals | | 3294 |-------->| | | | 3295 | | | | | 3296 | |(16) NOTIFY (KPML body specifying coin deposit 3297 tones) 3298 | |-------->| | | 3299 | | | | | 3300 | |(17) 200 OK | | 3301 | |<--------| | | 3302 | | | | | 3303 |[ AS determines adequate coinage, routes call ] 3304 | | | | | 3305 | | | | | 3306 | | |(18) INVITE | 3307 | | |------------------>| 3308 | | | | | 3309 | | |(19) 180 Ringing | 3310 | | |<------------------| 3311 | | | | | 3312 | | |(20) 200 OK | 3313 | | |<------------------| 3314 | | | | | 3315 | | |(21) ACK | | 3316 | | |------------------>| 3317 | | | | | 3318 | |(22) re-INVITE (Called SDP) | 3319 | |<--------| | | 3320 | | | | | 3321 | |(23) 200 OK | | 3322 | |-------->| | | 3323 | | | | | 3324 | |(24) RTP | | | 3325 | |.............................| 3326 | | | | | 3327 |[ Conversation, exceeds credit ] | 3328 | | | | | 3329 | | | | | 3330 |[ Caller hangs up, tries to run ] | 3331 | | | | | 3332 | | | | | 3333 |(25) Disconnect Request | | 3334 |-------->| | | | 3335 | | | | | 3336 | |(26) INFO (ISUP,SAP FCI=Disconnect Request) 3337 | |-------->| | | 3338 | | | | | 3339 | |(27) 200 OK | | 3340 | |<--------| | | 3341 | | | | | 3342 |[ AS requests Connection Hold and Ringback ] 3343 | | | | | 3344 | | | | | 3345 | |(28) INFO (ISUP,SAP FCI=Hold Request) 3346 | |<--------| | | 3347 | | | | | 3348 | |(29) 200 OK | | 3349 | |-------->| | | 3350 | | | | | 3351 |(30) corresponding MF or ISUP signaling| 3352 |<--------| | | | 3353 | | | | | 3354 |(31) Hold Acknowledge | | 3355 |-------->| | | | 3356 | | | | | 3357 | |(32) INFO (ISUP,SAP FCI=Hold Acknowledge) 3358 | |-------->| | | 3359 | | | | | 3360 | |(33) 200 OK | | 3361 | |<--------| | | 3362 | | | | | 3363 | |(34) INFO (ISUP,SAP FCI=Ringback Request) 3364 | |<--------| | | 3365 | | | | | 3366 | |(35) 200 OK | | 3367 | |-------->| | | 3368 | | | | | 3369 |(36) corresponding MF or ISUP signaling| 3370 |<--------| | | | 3371 | | | | | 3372 |[ User inserts coins ] | | 3373 | | | | | 3374 | | | | | 3375 |(37) NOTIFY (KPML body specifying coin deposit tones) 3376 |------------------>| | | 3377 | | | | | 3378 |(38) 200 OK | | | 3379 |<------------------| | | 3380 | | | | | 3381 |[ Billing satisfied ] | | 3382 | | | | | 3383 | | | | | 3384 | |(39) INFO (ISUP,SAP FCI=Hold Release Request) 3385 | |<--------| | | 3386 | | | | | 3387 | |(40) 200 OK | | 3388 | |-------->| | | 3389 | | | | | 3390 |(41) corresponding MF or ISUP signaling| 3391 |<--------| | | | 3392 | | | | | 3393 |[ User hangs up ] | | | 3394 | | | | | 3395 | | | | | 3396 |(42) Disconnect Request | | 3397 |-------->| | | | 3398 | | | | | 3399 | |(43) INFO (ISUP,SAP FCI=Disconnect Request) 3400 | |-------->| | | 3401 | | | | | 3402 | |(44) 200 OK | | 3403 | |<--------| | | 3404 | | | | | 3405 | |(45) BYE | | | 3406 | |<--------| | | 3407 | | | | | 3408 | |(46) 200 OK | | 3409 | |-------->| | | 3410 | | | | | 3411 |(47) corresponding MF or ISUP signaling| 3412 |<--------| | | | 3413 | | | | | 3414 | | |(48) BYE | | 3415 | | |------------------>| 3416 | | | | | 3417 | | |(49) 200 OK | 3418 | | |<------------------| 3419 | | | | | 3420 | | | | | 3421 | | | | | 3422 Figure 19 Network Controlled Coin Call 3424 11.2. Busy Line Verification and Interrupt 3426 An existing PTSN service is Busy Line Verification and Interrupt. In 3427 the Busy Line Verification (BLV) Service, a customer obtains 3428 operator assistance to determine if a called line is in use. In 3429 Operator Interrupt Service, the operator provides a BLV Service and, 3430 if requested by the caller, interrupts a conversation in progress 3431 and relays a message. If the interrupted party is willing to hang 3432 up, the call can be reoriginated by the caller to the called party. 3433 At the caller's request, the connection between the caller and the 3434 called party can be reinitiated and handled by the operator as a 3435 Call Completion Service. 3437 11.2.1. PSTN Target 3439 Currently, BLV/I is handled by the Operator Services System placing 3440 calls via special BLV/I trunk toward the target. Use of this type of 3441 trunk results in the Operator Services System being able to monitor 3442 a scrambled version of the target's conversation, and being able to 3443 barge in to speak to the target. In this document, the focus of 3444 BLV/I toward a PSTN target is on having the OIS components such as 3445 OWS and AS be able to communicate with the EO via BLV/I trunks. For 3446 IP targets, SIP capabilities are used. 3448 The following figure depicts a BLV/I call to a PSTN target. In steps 3449 (1) through (8) the caller is routed to an AS which performs 3PCC to 3450 connect this caller to an operator workstation. 3452 The operator determines the user's request, and initiates (9) a call 3453 toward the target via a BLV/I trunk. Ensuring that the call is 3454 routed via the correct type of trunk can be handled the same using 3455 SIP as in the PSTN; that is, by prepending specified routing digits 3456 to the target number. The operator is bridged by the EO onto the 3457 target's line, during which time no voice is sent toward the caller. 3458 A one way connection can be explicitly signaled, or the operator 3459 workstation can simply not send RTP at this time. The operator 3460 workstation or GW implements a scrambler so that only the presence 3461 or absence of speech can be determined, and the operator then 3462 reports to the caller on the status. If there is speech, then the 3463 operator reports that the line is busy, and may offer to interrupt 3464 the caller. 3466 If this is desired, the operator removes the scrambler, and 3467 indicates to the target of the caller's desire to call them, and 3468 drops off. The operator informs the caller of the result, and drops 3469 the caller, who may then re attempt the call. The option where the 3470 OISP offers the call as a call completion service is not shown here, 3471 but this poses no unique requirements with respect to call 3472 completion. 3474 Caller AS WS GW 3475 |[ Caller dials 0+ or 0- ] | 3476 |(1) INVITE | | 3477 |-------->| | | 3478 |(2) 180 Ringing | | 3479 |<--------| | | 3480 | |(3) INVITE | 3481 | |-------->| | 3482 | |(4) 200 OK | 3483 | |<--------| | 3484 | |(5) ACK | | 3485 | |-------->| | 3486 |(6) 200 OK | | 3487 |<--------| | | 3488 |(7) ACK | | | 3489 |-------->| | | 3490 |(8) RTP | | | 3491 |...................| | 3492 |[ Caller is now connected to operator ] 3493 | | |(9) INVITE 3494 | | |-------->| 3495 | | |(10) 200 OK 3496 | | |<--------| 3497 | | |(11) ACK | 3498 | | |-------->| 3499 | | |(12) RTP | 3500 | | |.........| 3501 |[ Operator is now connected to BLV trunk ] 3502 | | |(13) BYE | 3503 | | |-------->| 3504 | | |(14) 200 OK 3505 | | |<--------| 3506 |[ Operator drops caller ] 3507 |(15) BYE | | | 3508 |<------------------| | 3509 |(16) 200 OK | | 3510 |------------------>| | 3511 |[ Caller may or may not place call, OISP uninvolved ] 3513 Figure 20 BLV/I to PSTN Target 3515 11.2.2. SIP Target 3517 The following depicts a BLV/I call to a SIP target. Note that this 3518 is included mainly for completeness. The characteristics of POTS 3519 based subscribers support such a service, but many of those 3520 characteristics may not be applicable to SIP based endpoints. POTS 3521 access can carry only a single call at a time; as a packet switched 3522 technology SIP does not share this inherent restriction. There is 3523 typically a strong association between a physical POTS line and the 3524 address (phone number) used to reach it, while a SIP address of 3525 record is a logical address which can be registered with various 3526 endpoints, even simultaneously. Also, attempts towards such a set of 3527 devices can be tried in sequence or in parallel; thus the same 3528 concept of "busy" does not carry directly from POTS access to SIP. 3529 The ambiguity of "busy" may also have impacts on the "interrupt" 3530 aspect of this service. 3532 The approach detailed here is based on that described in the 3533 PacketCable Residential SIP Telephony Feature Specification, [RST]. 3534 The main aspects of this approach include using the Event dialog 3535 package [RFC4235] to determine whether the device has an active 3536 call, and using the Join header in order to bridge onto the current 3537 conversation for monitoring and interrupting the user. Additional 3538 aspects include the operator workstation performing the scrambling 3539 function, and the use of a preconfigured network asserted 3540 workstation identity from which the user device must accept and 3541 process the BLV/I related requests. 3543 Steps 1 through 8 represent an incoming call to the OISP being 3544 connected to an operator workstation. The operator interacts with 3545 the caller and determines the BLV/I request. 3547 In steps 9 through 12, the operator workstation subscribes to the 3548 Dialog event package at the target party's UA, and receives a NOTIFY 3549 identifying any active dialogs. 3551 In 13 through 16, the workstation sends an INVITE with a Join header 3552 [RFC3911] to bridge onto the active call. The INVITE includes a P- 3553 Asserted-Identity value corresponding to the value prearranged 3554 between the OISP and the target's home provider. The user devices 3555 are configured to accept SUBSCRIBEs for Dialog event package and 3556 INVITEs with the Join header when the P-Asserted-Identity contains 3557 this value. Thus, the user device accepts the Join header. 3558 Initially, the workstation acts in a receive only mode, and further, 3559 implements an audio scrambler such that speech is distinguishable as 3560 such, but is non intelligible. Thus the operator can determine 3561 whether the person at the target device is in active conversation. 3563 During this time, the workstation does not exchange media with the 3564 caller, who may be put on hold (not show here). 3566 The operator can then report the status to the caller, and offer the 3567 Interrupt service. If accepted, the scrambling function is removed 3568 from the voice path between operator and target, and the operator 3569 "barges in" on the conversation, informs the target party of the 3570 caller's request, and asks whether the target would like to accept 3571 the call. The operator can then drop the session with the target and 3572 inform the caller about the target's response. There is of course no 3573 guarantee of the target's or caller's subsequent actions. 3575 Caller AS WS Target 3576 |[ Caller dials 0+ or 0- ] | 3577 |(1) INVITE | | 3578 |-------->| | | 3579 |(2) 180 Ringing | | 3580 |<--------| | | 3581 |[ Simplified flow for brevity - straight to WS ] 3582 | |(3) INVITE | 3583 | |-------->| | 3584 | |(4) 200 OK | 3585 | |<--------| | 3586 | |(5) ACK | | 3587 | |-------->| | 3588 |(6) 200 OK | | 3589 |<--------| | | 3590 |(7) ACK | | | 3591 |-------->| | | 3592 |(8) RTP | | | 3593 |...................| | 3594 |[ Caller is now connected to operator ] 3595 | | |(9) SUBSCRIBE (Dialog) 3596 | | |-------->| 3597 | | |(10) 200 OK 3598 | | |<--------| 3599 | | |(11) NOTIFY (Dialog state) 3600 | | |<--------| 3601 | | |(12) 200 OK 3602 | | |-------->| 3603 | | |(13) INVITE (Join, dialog id) 3604 | | |-------->| 3605 | | |(14) 200 OK 3606 | | |<--------| 3607 | | |(15) ACK | 3608 | | |-------->| 3609 | | |(16) RTP | 3610 | | |.........| 3611 | | |(17) BYE | 3612 | | |-------->| 3613 | | |(18) 200 OK 3614 | | |<--------| 3615 |[ Operator informs caller of target's disposition ] 3616 |(19) BYE | | | 3617 |<------------------| | 3618 |(20) 200 OK | | 3619 |------------------>| | 3620 Figure 21 BLV/I to SIP Target 3622 11.3. Inward Calls 3624 Typically, operator services are provided by the OISP serving a 3625 user's originating provider. In some cases, another OISP must be 3626 involved. One example is BLV/I, where an OISP can only invoke BLV/I 3627 for targets served by providers that the OISP serves. In the case of 3628 a caller desiring to invoke BLV/I to a target served by a different 3629 provider, the caller's request would be routed to the same OISP as 3630 usual. That OISP would identify the OISP serving the target, and 3631 initiate an "inward" call to an operator in that OISP, and request 3632 that operator to perform the BLV/I. For this feature, the initiating 3633 OISP acts as the caller to the OISP serving the target. Currently, 3634 Inward calls are originated by operators at operator workstations, 3635 and terminated to operators at operator workstations. 3637 Inward calls need to be distinguishable from calls from subscribers 3638 that are routed to operators. Further, inward calls should be 3639 accepted only from other OISPs, never from subscribers, and only 3640 from those OISPs with appropriate business relationships. 3642 The request should be screened based on the identity of originator. 3643 Since the From header can easily be spoofed, a network-asserted 3644 identity should be used for this. Within trust domains that use the 3645 P-Asserted-Identity [RFC3325] header as a network asserted identity, 3646 this header should be used for this purpose. Alternatively, the SIP 3647 Identity mechanism [RFC4474] can be used in domains where this is 3648 used for network asserted identity. Rather than maintain lists of 3649 every possible URI for which Inward requests are allowed, the 3650 decision could be based on the domain in the SIP URI. Requests from 3651 domains corresponding only to OISPs which are authorized to make 3652 Inward requests would be accepted. 3654 In the current North American PSTN, the digits dialed by the 3655 operator placing Inward call can be used to identify the type of 3656 service being requested, so that the destination OISP can properly 3657 handle the request. These digits are known as Operator Special 3658 Dialed Code (OSDC) digits. Thus, the Request-URI should include the 3659 OSDC digits, and the AS should populate the Request-URI as a SIP URI 3660 which includes the SIP domain of the destination OISP as well as the 3661 OSDC code. 3663 For Inward calls to PSTN based OISPs, the call should be placed via 3664 a PSTN gateway, and should appear to the destination OISP the same 3665 as any other Inward call. 3667 11.4. Intercept 3669 Intercept service provides the capability for a customer to be 3670 informed that a working number is no longer in service or why a 3671 working number is no longer in service. Basically, it provides 3672 announcements to the caller, which may be fixed or dynamic. 3673 Currently in the North American PSTN, Intercept may be handled by 3674 individual end offices, or may be sent to Operator Services Systems, 3675 which have specialized resources for handling such requests. When a 3676 call reaches a PSTN switch for a number which requires Intercept 3677 treatment, that switch, known as the "intercepted switch", initiates 3678 an Intercept request for that "intercepted number". The request to 3679 an OISP specifies the intercepted number, and an "intercept type", 3680 which provides an indication of the general reason for intercept. 3681 Often, the OISP needs to consult an "intercept database" to 3682 determine specific processing for a particular intercepted number. 3684 Currently, with MF, dedicated Intercept trunk groups are typically 3685 used, so the call is implicitly identified as such. The ANI digits 3686 identify the intercepted number, and the II digits identify the 3687 intercept type. For ISUP, dedicated trunk groups may or may not be 3688 used, but the SAP parameter identifies the intercept type, and the 3689 Called Party Number parameter identifies the intercepted number. In 3690 both cases, the key information conveyed include identification of 3691 the request as intercept, intercept type, and intercepted number. 3693 11.4.1. Intercept Request Via SIP 3695 Intercept requests to a SIP based OISP need to convey the same 3696 information currently conveyed. Such requests can be treated as a 3697 call forwarded to an Intercept service. Thus, the Request-URI should 3698 identify the request as Intercept, as well as conveying the 3699 intercept type. The currently defined values for intercept type 3700 include regular, blank, and trouble. Prepending these with 3701 "intercept-" in the left hand side of the Request-URI unambiguously 3702 identifies the request as intercept and conveys the intercept type. 3703 Treating this as a redirection, the SIP History-Info header can be 3704 used to convey the intercepted number. An example of such an INVITE 3705 (relevant fields only) follows: 3707 INVITE sip:intercept-trouble@oisp-c.example.com SIP/2.0 3708 From: ;tag=1234567 3709 To: 3710 History-Info: ; index=1 3711 Content-Type: application/sdp 3712 Content-Length: ... 3714 Upon receiving such a request, the AS would typically perform any 3715 required processing, including database lookups, and generate a 3716 request to a MS to play the specified announcement. The conventions 3717 described in [RFC4240] can be used for this. 3719 An example high level message flow follows: 3721 Intercepted domain AS MS 3722 | | | 3723 | | | 3724 | | | 3725 [ Receives a call requiring Intercept service ] 3726 | | | 3727 | | | 3728 |(1) INVITE ( r-URI->intercept type, Hist- 3729 Info=intercepted number ) 3730 |------------->| | 3731 | | | 3732 | |(2) INVITE (r-URI->RFC 4240 annc) 3733 | |------------->| 3734 | | | 3735 | |(3) 200 OK | 3736 | |<-------------| 3737 | | | 3738 | |(4) ACK | 3739 | |------------->| 3740 | | | 3741 |(5) 183 Session Progress | 3742 |<-------------| | 3743 | | | 3744 |(6) RTP (announcements) | 3745 |.............................| 3746 | | | 3747 |Caller hangs up | 3748 | | | 3749 | | | 3750 |(7) BYE | | 3751 |------------->| | 3752 | | | 3753 |(8) 200 OK | | 3754 |<-------------| | 3755 | | | 3756 | |(9) BYE | 3757 | |------------->| 3758 | | | 3759 | |(10) 200 OK | 3760 | |<-------------| 3761 | | | 3762 | | | 3763 Figure 22 Intercept Request Via SIP 3765 11.4.2. Intercept Request Via PSTN 3767 When intercept requests are received from PSTN interfaces, the PSTN 3768 gateway needs to translate the incoming signaling to SIP. The 3769 preferred approach is to have the PSTN gateway construct an INVITE 3770 request of the form described above for requests received via SIP. 3771 This method requires additional functionality on the part of the 3772 gateway, but the AS only needs to recognize one type of INVITE 3773 request for Intercept. 3775 Alternatively, the gateway could construct an INVITE containing 3776 encapsulated ISUP, in which the Called Party Number and SAP fields 3777 are most significant. Also, the Request-URI should contain the 3778 Called Party Number. With this method, the PSTN gateway treats the 3779 INVITE the same as other INVITEs, but requires the AS to recognize 3780 this as an Intercept request by examining the encapsulated ISUP body 3781 contents. 3783 Intercepted 3784 Switch PSTN GW AS MS 3785 | | | | 3786 | | | | 3787 | | | | 3788 |[ Receives a call requiring Intercept service ] 3789 | | | | 3790 | | | | 3791 |(1) IAM ( CdPN digits=intcptd number, CdPN NOA=op req, 3792 SAP=intcpt type ) 3793 |------------->| | | 3794 | | | | 3795 | |(2) INVITE (see above) 3796 | |------------->| | 3797 | | | | 3798 | | |(3) INVITE (r-URI->RFC 4240 annc) 3799 | | |------------->| 3800 | | | | 3801 | | |(4) 200 OK | 3802 | | |<-------------| 3803 | | | | 3804 | | |(5) ACK | 3805 | | |------------->| 3806 | | | | 3807 | |(6) 183 Session Progress | 3808 | |<-------------| | 3809 | | | | 3810 |(7) ACM | | | 3811 |<-------------| | | 3812 | | | | 3813 | |(8) RTP (announcements) | 3814 | |.............................| 3815 | | | | 3816 |(9) TDM (announcements) | | 3817 |..............| | | 3818 | | | | 3819 |Caller hangs up | | 3820 | | | | 3821 | | | | 3822 |(10) REL | | | 3823 |------------->| | | 3824 | | | | 3825 | |(11) BYE | | 3826 | |------------->| | 3827 | | | | 3828 | |(12) 200 OK | | 3829 | |<-------------| | 3830 | | | | 3831 |(13) RLC | | | 3832 |<-------------| | | 3833 | | | | 3834 | | |(14) BYE | 3835 | | |------------->| 3836 | | | | 3837 | | |(15) 200 OK | 3838 | | |<-------------| 3839 | | | | 3840 Figure 23 Intercept Request Via PSTN 3842 11.5. Operator Assisted Collect Call 3844 The following call flow provides examples of how a specific operator 3845 service, Operator Assisted Collect Call, could be implemented using 3846 the mechanisms described in this document. The purpose is to 3847 illustrate one way to implement this service using the proposed 3848 signaling mechanisms. In practice, this particular service could be 3849 implemented in an automated fashion without human intervention. 3851 Caller Proxy AS WS Called MS ACD 3852 | | | | | | | 3853 | | | | | | | 3854 | | | | | | | 3855 |[ Caller dials 0+ or 0- ] | | | | 3856 | | | | | | | 3857 | | | | | | | 3858 |(1) INVITE | | | | | 3859 |------------------>| | | | | 3860 | | | | | | | 3861 |(2) 100 Trying | | | | | 3862 |<------------------| | | | | 3863 | | | | | | | 3864 |[ AS determines operator is needed, performs 3PCC ] | 3865 | | | | | | | 3866 | | | | | | | 3867 | | |(3) INVITE | | | 3868 | | |-------------------------------------->| 3869 | | | | | | | 3870 | | |(4) 3xx redirect to WS where selected 3871 operator registered 3872 | | |<--------------------------------------| 3873 | | | | | | | 3874 | | |(5) INVITE | | | 3875 | | |-------->| | | | 3876 | | | | | | | 3877 | | |(6) 200 OK | | | 3878 | | |<--------| | | | 3879 | | | | | | | 3880 | | |(7) ACK | | | | 3881 | | |-------->| | | | 3882 | | | | | | | 3883 |(8) 200 OK | | | | | 3884 |<------------------| | | | | 3885 | | | | | | | 3886 |(9) ACK | | | | | | 3887 |------------------>| | | | | 3888 | | | | | | | 3889 |[ Caller is now connected to operator ]| | | 3890 | | | | | | | 3891 | | | | | | | 3892 |(10) RTP | | | | | | 3893 |.............................| | | | 3894 | | | | | | | 3895 |[ Operator determines calling's request and places on hold]| 3896 | | | | | | | 3897 | | | | | | | 3898 | | |(11) re-INVITE (HOLD) | | 3899 | | |<--------| | | | 3900 | | | | | | | 3901 | | |(12) 200 OK | | | 3902 | | |-------->| | | | 3903 | | | | | | | 3904 | | |(13) ACK | | | | 3905 | | |<--------| | | | 3906 | | | | | | | 3907 |[ AS logic determines announcements should be played instead ] 3908 | | | | | | | 3909 | | | | | | | 3910 | | |(14) INVITE (play announcements) | 3911 | | |---------------------------->| | 3912 | | | | | | | 3913 | | |(15) 200 OK (SDP-MS) | | 3914 | | |<----------------------------| | 3915 | | | | | | | 3916 | | |(16) ACK | | | | 3917 | | |---------------------------->| | 3918 | | | | | | | 3919 |(17) reINVITE (SDP-MS) | | | | 3920 |<------------------| | | | | 3921 | | | | | | | 3922 |(18) 200 OK (SDP-calling) | | | | 3923 |------------------>| | | | | 3924 | | | | | | | 3925 |(19) ACK | | | | | | 3926 |<------------------| | | | | 3927 | | | | | | | 3928 |(20) RTP (MS plays announcements to calling) | | 3929 |.................................................| | 3930 | | | | | | | 3931 |[ Operator calls called party ] | | | 3932 | | | | | | | 3933 | | | | | | | 3934 | | | |(21) INVITE | | 3935 | | | |-------->| | | 3936 | | | | | | | 3937 | | | |(22) 200 OK | | 3938 | | | |<--------| | | 3939 | | | | | | | 3940 | | | |(23) ACK | | | 3941 | | | |-------->| | | 3942 | | | | | | | 3943 | | | |(24) RTP | | | 3944 | | | |.........| | | 3945 | | | | | | | 3946 |[ Called agrees to accept charges ] | | | 3947 | | | | | | | 3948 | | | | | | | 3949 |[ Operator takes Calling off hold ] | | | 3950 | | | | | | | 3951 | | | | | | | 3952 | | |(25) re-INVITE (un-HOLD) | | 3953 | | |<--------| | | | 3954 | | | | | | | 3955 |[ AS logic directs Calling from MS back to WS ] | | 3956 | | | | | | | 3957 | | | | | | | 3958 |(26) re-INVITE (SDP-ws) | | | | 3959 |<------------------| | | | | 3960 | | | | | | | 3961 |(27) 200 OK | | | | | 3962 |------------------>| | | | | 3963 | | | | | | | 3964 | | |(28) 200 OK | | | 3965 | | |-------->| | | | 3966 | | | | | | | 3967 | | |(29) ACK | | | | 3968 | | |<--------| | | | 3969 | | | | | | | 3970 |(30) ACK | | | | | | 3971 |<------------------| | | | | 3972 | | | | | | | 3973 |(31) RTP | | | | | | 3974 |.............................| | | | 3975 | | | | | | | 3976 |[ AS releases MS ] | | | | | 3977 | | | | | | | 3978 | | | | | | | 3979 | | |(32) BYE | | | | 3980 | | |---------------------------->| | 3981 | | | | | | | 3982 | | |(33) 200 OK | | | 3983 | | |<----------------------------| | 3984 | | | | | | | 3985 |[ Calling and Called both have RTP session with WS ] | 3986 | | | | | | | 3987 | | | | | | | 3988 |[ WS bridges conversations together internally ] | | 3989 | | | | | | | 3990 | | | | | | | 3991 |[ After brief interlude WS transfers Calling directly to Called 3992 ] 3993 | | | | | | | 3994 | | | | | | | 3995 |[ then drops out ] | | | | | 3996 | | | | | | | 3997 | | | | | | | 3998 | | |(34) REFER (to called) | | 3999 | | |<--------| | | | 4000 | | | | | | | 4001 | | |(35) 202 Accepted | | | 4002 | | |-------->| | | | 4003 | | | | | | | 4004 | | |(36) NOTIFY (trying) | | 4005 | | |-------->| | | | 4006 | | | | | | | 4007 | | |(37) 200 OK | | | 4008 | | |<--------| | | | 4009 | | | | | | | 4010 |[ Replaces header causes Called to replace old call with new ] 4011 | | | | | | | 4012 | | | | | | | 4013 | | |(38) INVITE (replaces: WS ) | | 4014 | | |------------------>| | | 4015 | | | | | | | 4016 | | |(39) 200 OK (SDP-called) | | 4017 | | |<------------------| | | 4018 | | | | | | | 4019 | | |(40) ACK | | | | 4020 | | |------------------>| | | 4021 | | | | | | | 4022 | | | |(41) BYE | | | 4023 | | | |<--------| | | 4024 | | | | | | | 4025 | | | |(42) 200 OK | | 4026 | | | |-------->| | | 4027 | | | | | | | 4028 |[ The following interactions synch up SDP - optimization 4029 possible ] 4030 | | | | | | | 4031 | | | | | | | 4032 |(43) re-INVITE (SDP-called) | | | | 4033 |<------------------| | | | | 4034 | | | | | | | 4035 |(44) 200 OK (SDP-calling) | | | | 4036 |------------------>| | | | | 4037 | | | | | | | 4038 |(45) ACK | | | | | | 4039 |<------------------| | | | | 4040 | | | | | | | 4041 | | |(46) re-INVITE (SDP-calling) | | 4042 | | |------------------>| | | 4043 | | | | | | | 4044 | | |(47) 200 OK | | | 4045 | | |<------------------| | | 4046 | | | | | | | 4047 | | |(48) ACK | | | | 4048 | | |------------------>| | | 4049 | | | | | | | 4050 |(49) RTP | | | | | | 4051 |.......................................| | | 4052 | | | | | | | 4053 |[ Calling and Called are now talking directly ] | | 4054 | | | | | | | 4055 | | | | | | | 4056 | | |(50) NOTIFY (Call completed) | | 4057 | | |-------->| | | | 4058 | | | | | | | 4059 | | |(51) 200 OK | | | 4060 | | |<--------| | | | 4061 | | | | | | | 4062 |[ Operator now drops out ] | | | | 4063 | | | | | | | 4064 | | | | | | | 4065 | | | |(52) BYE | | | 4066 | | | |-------->| | | 4067 | | | | | | | 4068 | | | |(53) 200 OK | | 4069 | | | |<--------| | | 4070 | | | | | | | 4071 |[ AS remains in signaling path until call ends ] | | 4072 | | | | | | | 4073 | | | | | | | 4074 |(54) BYE | | | | | | 4075 |------------------>| | | | | 4076 | | | | | | | 4077 | | |(55) BYE | | | | 4078 | | |------------------>| | | 4079 | | | | | | | 4080 | | |(56) 200 OK | | | 4081 | | |<------------------| | | 4082 | | | | | | | 4083 |(57) 200 OK | | | | | 4084 |<------------------| | | | | 4085 | | | | | | | 4086 | | | | | | | 4087 | | | | | | | 4089 Figure 24 Operator Assisted Collect Call 4091 The caller initiates the call by dialing 0+ or 0-. 4093 The call is routed to the AS. The AS examines the calling party 4094 number and calling party's home provider, which are derived from the 4095 P-Asserted-Identity header. The charge number is also needed, in 4096 case the caller's service is determined by agreements with another 4097 party, such as the caller's employer. The employer may have a large 4098 number of calling identities representing its employees, which are 4099 covered under its agreement with the OISP. Rather than provision 4100 every possible calling number/identity with the OISP (and this may 4101 be constantly changing), the ability to pass a charge number would 4102 allow the OISP to determine whether this charge number has any 4103 associated treatment on a per charge number basis. 4105 In any case, in our example, the AS examines the request and 4106 determines that the call is for an operator assisted collect call. 4107 Typically a MS could be initially connected to prompt the user for 4108 the type of call. This step is omitted in this example. 4110 The AS performs third party call control (3PCC). It sends a 18x 4111 response towards the caller. It needs to initiate a call leg to an 4112 operator workstation. It populates the selection criteria in an 4113 INVITE message (the exact mechanism for this is under study) which 4114 it sends to the ACD server in (3). The ACD server identifies the 4115 best match available operator and returns the contact information 4116 for the workstation where that operator is currently registered in a 4117 3xx redirection response. 4119 In (5) the AS sets up a call to the workstation identified by the 4120 ACD server, and using 3PCC connects the caller to the WS, resulting 4121 in an RTP session in (10). 4123 The operator determines the caller's requested number, and sends an 4124 INVITE toward the AS to put the caller on hold. The logic in the AS 4125 determines that instead the caller should be connected to custom 4126 announcements, and in (14) through (20) creates a session between 4127 the caller and a MS. 4129 Meanwhile, in (21) the WS places a call to the called party, and 4130 asks whether the called party would accept the charges for a collect 4131 call. In this example, the called party agrees to the request. 4133 In (25), the operator takes the caller off hold (recall that it 4134 believes it has placed the caller on hold). The AS, in (26) through 4135 (33), performs 3PCC, and removes the caller from the MS which is 4136 playing custom announcements, and reconnects the caller back to the 4137 WS. The WS uses its own internal bridging functionality to 4138 conference the operator, calling, and called parties. 4140 After a brief interlude, the operator initiates a transfer of the 4141 calling and called parties directly together using a REFER in (34) 4142 through (37). The AS, performing 3PCC, utilizes the SIP Replaces 4143 mechanism beginning in (38) to complete the transfer. When the 4144 transfer is complete, the operator drops out completely. Note that 4145 the AS, performing 3PCC, remains in the signaling path until the 4146 call is torn down in (54) through (57). 4148 11.6. Operator Assisted Third Party Billing 4150 The Operator Assisted Third Party Billing service allows a caller to 4151 request billing of a call to a third party. In such a service, the 4152 caller calls the operator, who places a call to the billed party to 4153 obtain authorization for billing. If authorized, the OISP places the 4154 call to the called party, and bills it to the billed party. This 4155 document focuses on the call flow and SIP signaling, and does not 4156 discuss the billing mechanisms. 4158 In 1 through 8 below, the caller is connected to the operator. In 9 4159 through 14, the operator places the caller on hold, and in 15 4160 through 18 the operator calls the billed party to ask for 4161 authorization. In 21, the operator un-holds the caller and informs 4162 of the authorization. In 18 the operator initiates a call to the 4163 called party via the AS by sending a REFER to the AS. 4165 Caller CSCF AS WS Billed Called 4166 | | | | | | 4167 | | | | | | 4168 | | | | | | 4169 |[ Caller dials 0+ or 0- ] | | | 4170 | | | | | | 4171 | | | | | | 4172 |(1) INVITE | | | | 4173 |------------------>| | | | 4174 |(2) 100 Trying | | | | 4175 |<------------------| | | | 4176 | | | | | | 4177 |[ AS determines operator is needed, performs 3PCC ] 4178 | | | | | | 4179 | | | | | | 4180 | | |(3) INVITE | | 4181 | | |-------->| | | 4182 | | |(4) 200 OK | | 4183 | | |<--------| | | 4184 | | |(5) ACK | | | 4185 | | |-------->| | | 4186 | | | | | | 4187 |(6) 200 OK | | | | 4188 |<------------------| | | | 4189 |(7) ACK | | | | | 4190 |------------------>| | | | 4191 | | | | | | 4192 |[ Caller is now connected to operator ]| | 4193 | | | | | | 4194 | | | | | | 4195 |(8) RTP | | | | | 4196 |.............................| | | 4197 | | | | | | 4198 |[ Operator determines caller's request and places on hold] 4199 | | | | | | 4200 | | | | | | 4201 | | |(9) re-INVITE (HOLD) | 4202 | | |<--------| | | 4203 | | |(10) 200 OK | | 4204 | | |-------->| | | 4205 | | |(11) ACK | | | 4206 | | |<--------| | | 4207 | | | | | | 4208 |[ AS could optionally send caller to advertisements vs hold ] 4209 | | | | | | 4210 | | | | | | 4211 |(12) re-INVITE (HOLD) | | | 4212 |<------------------| | | | 4213 |(13) 200 OK | | | | 4214 |------------------>| | | | 4215 |(14) ACK | | | | | 4216 |<------------------| | | | 4217 | | | | | | 4218 |[ Operator calls billed party ] | | 4219 | | | | | | 4220 | | | | | | 4221 | | | |(15) INVITE | 4222 | | | |-------->| | 4223 | | | |(16) 200 OK | 4224 | | | |<--------| | 4225 | | | |(17) ACK | | 4226 | | | |-------->| | 4227 | | | | | | 4228 | | | |(18) RTP | | 4229 | | | |.........| | 4230 | | | | | | 4231 |[ Charges OK, operator disconnects billed party ]| 4232 | | | | | | 4233 | | | | | | 4234 | | | | | | 4235 | | | |(19) BYE | | 4236 | | | |-------->| | 4237 | | | |(20) 200 OK | 4238 | | | |<--------| | 4239 | | | | | | 4240 |[ Operator informs AS of result, un-HOLDs caller ] 4241 | | | | | | 4242 | | | | | | 4243 | | |(21) re-INVITE(result, un-HOLD) 4244 | | |<--------| | | 4245 | | | | | | 4246 |(22) re-INVITE(un-HOLD) | | | 4247 |<------------------| | | | 4248 |(23) 200 OK | | | | 4249 |------------------>| | | | 4250 |(24) ACK | | | | | 4251 |<------------------| | | | 4252 | | | | | | 4253 | | |(25) 200 OK | | 4254 | | |-------->| | | 4255 | | |(26) ACK | | | 4256 | | |<--------| | | 4257 | | | | | | 4258 |(27) RTP | | | | | 4259 |.............................| | | 4260 | | | | | | 4261 |[ Operator informs caller, transfers AS to initiate call ] 4262 | | | | | | 4263 | | | | | | 4264 | | |(28) REFER | | 4265 | | |<--------| | | 4266 | | |(29) 202 Accepted | | 4267 | | |-------->| | | 4268 | | | | | | 4269 | | |(30) NOTIFY (trying) | 4270 | | |-------->| | | 4271 | | |(31) 200 OK | | 4272 | | |<--------| | | 4273 | | | | | | 4274 |[ AS places call to called party, notifies WS on success ] 4275 | | | | | | 4276 | | | | | | 4277 | | |(32) INVITE | | 4278 | | |---------------------------->| 4279 | | |(33) 180 | | | 4280 | | |<----------------------------| 4281 | | |(34) 200 OK | | 4282 | | |<----------------------------| 4283 | | |(35) ACK | | | 4284 | | |---------------------------->| 4285 | | | | | | 4286 |(36) re-INVITE | | | | 4287 |<------------------| | | | 4288 |(37) 200 OK | | | | 4289 |------------------>| | | | 4290 |(38) ACK | | | | | 4291 |<------------------| | | | 4292 | | | | | | 4293 | | |(39) NOTIFY (Call completed) | 4294 | | |-------->| | | 4295 | | |(40) 200 OK | | 4296 | | |<--------| | | 4297 | | | | | | 4298 |[ Operator drops] | | | | 4299 | | | | | | 4300 | | | | | | 4301 | | |(41) BYE | | | 4302 | | |<--------| | | 4303 | | |(42) 200 OK | | 4304 | | |-------->| | | 4305 | | | | | | 4307 Figure 25 Operator Assisted Third Party Billed Call 4309 11.7. Offerless INVITE 4311 In some cases, notably including calls originating from enterprise 4312 systems, it may occur that the incoming SIP INVITE message does not 4313 contain an SDP offer. Such "offerless INVITEs" are the source of 4314 much discussion and are often characterized as troublesome. The 4315 intention of this section is to identify the possibility of 4316 receiving such an INVITE. An example flow illustrating one way of 4317 addressing this is shown; however any particular solution may need 4318 to take into account factors such as equipment capabilities, 4319 operator policies, etc. 4321 The most significant impact of this on a typical call is that when 4322 the application server receives such an INVITE and needs to perform 4323 third party call control, it does not have an SDP offer to send to 4324 the destination. In the example flow below, the media server 4325 receives such an INVITE from the application server, and it will not 4326 be able to formulate an SDP answer as usual, nor will it know which 4327 codec to use, nor will it know where to send the RTP stream. It will 4328 thus be delayed from sending media toward the caller until the SDP 4329 offer/answer exchange has completed. 4331 Instead of sending an SDP answer, the media server needs to 4332 formulate an SDP offer of its own and include this in the next SIP 4333 message send toward the user. It will require some basis for 4334 selecting the appropriate media type (e.g., audio) and codec set. 4335 This should be configurable via operator policy. One possibility is 4336 to include all codecs supported by the media server in the SDP 4337 offer. If the caller finds one of the codecs acceptable it will make 4338 it selection and include in its SDP answer. 4340 The flow below shows the media server returning a 183 Session 4341 Progress message with its SDP offer, and the caller including the 4342 SDP answer in the PRACK message sent in response to the 183. This is 4343 only one example; other flows are possible. For example the 183 4344 could be omitted, and the media server could simply send a 200 OK 4345 message with the SDP offer. In that case the caller would include 4346 the SDP answer in the ACK message. 4348 For normative information on the SDP offer/answer procedures, please 4349 refer to [RFC3264]. 4351 Caller OIS-AS OIS-MS1 4352 | | | 4353 | | | 4354 |(1) INVITE (no SDP offer) | 4355 |----------------------->| | 4356 | |(2) INVITE (no SDP offer) 4357 | |----------------------->| 4358 | | | 4359 | |(3) 183 Session Progress (SDP offer) 4360 | |<-----------------------| 4361 | | | 4362 |(4) 183 Session Progress (SDP offer) | 4363 |<-----------------------| | 4364 | | | 4365 |(5) PRACK (with SDP answer) | 4366 |----------------------->| | 4367 | |(6) PRACK (with SDP answer) 4368 | |----------------------->| 4369 | | | 4370 | |(7) 200 OK for PRACK | 4371 | |<-----------------------| 4372 |(8) 200 OK for PRACK | | 4373 |<-----------------------| | 4374 | |(9) 200 OK for INVITE | 4375 | |<-----------------------| 4376 |(10) 200 OK for INVITE | | 4377 |<-----------------------| | 4378 | | | 4379 |(11) Ack | | 4380 |----------------------->| | 4381 | |(12) Ack | 4382 | |----------------------->| 4383 |(13) RTP Session | | 4384 |.................................................| 4385 | | | 4387 Figure 26 Offerless INVITE 4389 12. Summary and Conclusions 4391 The intent of this document is to explain how Directory Assistance and 4392 Operator Services work, and explore how they could be implemented with 4393 SIP. This includes both SIP originated requests as well as interworking 4394 with requests from the PSTN. 4396 A basic architecture utilizing an application server as the primary 4397 controller, performing third party call control to route incoming calls 4398 among media servers, operator workstations, etc. is described. 4399 Interface to the PSTN is described using PSTN gateways which interwork 4400 between ISUP or MF signaling and SIP. 4402 Operator services in the North American PSTN often utilize MF trunks. 4403 As there is currently no specific specification for MF/SIP 4404 interworking, we assume that the PSTN gateway performs an internal MF 4405 to ISUP translation. 4407 The use of existing SIP mechanisms is described where possible. Some of 4408 the main mechanisms described include third party call control, the 4409 REFER method with several extensions (e.g. Replaces), the Join header, 4410 Netann, and some of the ongoing work in the MEDIACTRL working group. 4412 Several protocol gaps and issues were identified. These include: 4414 Charge Number 4416 Coin Deposit Tones 4418 Carrier Information: ISUP TNS, CIP, and CSI parameters, and "cic", 4419 "dai" tel URI parameters/ 4421 For conveyance of coin deposit tones, the document suggests that 4422 extensions to KPML are one potential option, and shows how KPML could 4423 be used to this end. Definition of an operator services SIP event 4424 package is mentioned as another alternative. 4426 The desired next steps include soliciting feedback from the IETF 4427 community on the choices and intended usages of the proposed 4428 mechanisms. 4430 13. Security Considerations 4432 This document describes the use of existing and currently proposed 4433 protocol mechanisms. Detailed security analysis of services provided 4434 using these mechanisms should be performed, and needs to take into 4435 account the security implications of the individual mechanisms, which 4436 are documented in the defining documents for each mechanism. Security 4437 analysis of service provider use of these mechanisms also needs to take 4438 into account the interactions between individual mechanisms, as well as 4439 the overall context, including interactions with other providers, with 4440 which the provider may have differing levels of trust, in which these 4441 services are deployed. 4443 Note that signaling for Operator and Information Services may convey 4444 information of a private nature, and may also convey information about 4445 deposit of coins by customers into coin phones. Thus, appropriate 4446 measures should be taken to ensure the confidentiality, integrity, and 4447 data origin authenticity of such signaling. 4449 14. IANA Considerations 4451 This document identifies how existing and currently proposed protocol 4452 mechanisms can be used, and does not request any action on the part of 4453 IANA. 4455 15. Acknowledgements 4457 The authors would like to thank Martin Dolly, Gary Munson, Spencer 4458 Dawkins, and Cullen Jennings for their review, comments, and advice 4459 with this document. 4461 16. References 4463 16.1. Normative References 4465 [RFC3261] Rosenberg, et al, J., "SIP: Session Initiation Protocol", 4466 RFC 3261, June 2002. 4468 [RFC4474] Peterson, Jennings, "Enhancements for Authenticated 4469 Identity Management in the Session Initiation Protocol 4470 (SIP)", RFC 4474, August 2006. 4472 [RFC3325] Jennings, et al, "Private Extensions to the Session 4473 Initiation Protocol (SIP) for Asserted Identity within 4474 Trusted Networks", RFC 3325, November 2002. 4476 16.2. Informative References 4478 [CSI] Loreto, Terril, "Input 3rd-Generation Partnership Project 4479 (3GPP) Communications Service Identifiers Requirements on 4480 the Session Initiation Protocol (SIP)", draft-loreto- 4481 sipping-3gpp-ics-requirements-00.txt, June 2006. (work in 4482 progress) 4484 [RFC3324] Watson, "Short Term Requirements for Network Asserted 4485 Identity", RFC 3324, November 2004. 4487 [RFC3263] Rosenberg, Schulzrinne, "Session Initiation Protocol 4488 (SIP): Locating SIP Servers", RFC 3263, June 2002. 4490 [RFC4240] Burger, et al, "Basic Network Media Services with SIP", 4491 RFC 4240, December 2005. 4493 [RFC3725] Rosenberg, et al, "Best Current Practices for Third 4494 Party Call Control (3pcc) in the Session Initiation 4495 Protocol (SIP)", RFC 3725, April 2004. 4497 [IMS] 3GPP TS 23.228 V7.4.0 (2006-06) - 3rd Generation Partnership 4498 Project; Technical Specification Group Services and System 4499 Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 4500 7) 4502 [NSS] American National Standards Institute, Inc., "ANSI Extensions 4503 to the Narrowband Signaling Syntax (NSS) - Syntax 4504 Definition", ATIS-1000008.2006, January 2006. 4506 [RFC4904] Gurbani, et al, "Representing Trunk Groups in tel/sip 4507 Uniform Resource Identifiers (URIs)", RFC 4904, June 2007. 4509 [RFC4730] Burger, Dolly, "A Session Initiation Protocol (SIP) Event 4510 Package for Key Press Stimulus (KPML)", RFC 4730, November 4511 2006. 4513 [RST] PacketCable, " Residential SIP Telephony Feature 4514 Specification", PKT-SP-RSTF-I01-060927, September 2006. 4516 [RFC4235] Rosenberg, et al, "An INVITE-Initiated Dialog Event 4517 Package for the Session Initiation Protocol (SIP)", RFC 4518 4235, November 2005. 4520 [RFC3911] Mahy, et al, "The Session Initiation Protocol (SIP) "Join" 4521 Header", RFC 3911, October 2004. 4523 [RFC3398] Camarillo, et al, "Integrated Services Digital Network 4524 (ISDN) User Part (ISUP) to Session Initiation Protocol 4525 (SIP) Mapping", RFC 3398, December 2002. 4527 [RFC3840] Rosenberg, et al, "Indicating User Agent Capabilities in 4528 the Session Initiation Protocol (SIP)", RFC 3840, August 4529 2004. 4531 [RFC4483] Burger, et al, "A Mechanism for Content Indirection in 4532 Session Initiation Protocol (SIP) Messages", RFC 4483, May 4533 2006. 4535 [RFC2045] Freed, et al, "Multipurpose Internet Mail Extensions 4536 (MIME) Part One: Format of Internet Message Bodies", RFC 4537 2045, November 1996. 4539 [RFC3204] Zimmerer, et al, "MIME media types for ISUP and QSIG 4540 Objects", RFC 3204, November 2001. 4542 [RFC3325] Jennings, et al, "Private Extensions to the Session 4543 Initiation Protocol (SIP) for Asserted Identity within 4544 Trusted Networks", RFC 3325, November 2002. 4546 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 4547 3966, December 2004. 4549 [RFC4244] Barnes, et al, "An Extension to the Session Initiation 4550 Protocol (SIP) for Request History Information", RFC 4244, 4551 November 2005. 4553 [RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI", 4554 RFC 4694, October 2006. 4556 [RFC5552] Burke, D. and Scott, M., "SIP Interface to VoiceXML Media 4557 Services", RFC 5552, May 2009. 4559 [DAI] Yu, et al, "DAI Parameter for the tel URI", draft-yu-tel-dai- 4560 07, July 2009. (work in progress) 4562 [T1679] Alliance for Telecommunications Industry Solutions (ATIS) 4563 Committee T1, "American National Standard for 4564 Telecommunications - Interworking between Session 4565 Initiation Protocol (SIP) and Bearer Independent Call 4566 Control or ISDN User Part", ATIS T1.679-2004, June 2004. 4568 [PCI] York, et al, "P-Charge-Info: A Private Header (P-Header) 4569 Extension to the Session Initiation Protocol (SIP)", 4570 draft-york-sipping-p-charge-info-07, August 2009. (work in 4571 progress) 4573 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 4574 Initiation Protocol (SIP)", RFC 3323, November 2002. 4576 [draft-mahy-iptel-cpc] Mahy, R., "The Calling Party's Category tel 4577 URI Parameter (SIP)", draft-mahy-iptel-cpc-06.txt, March 4578 2007. 4580 [RFC3891] Mahy, R. et al., "The Session Initiation Protocol (SIP) 4581 "Replaces" Header", RFC 3891, September 2004. 4583 [RFC5079] Rosenberg, J., "Rejecting Anonymous Requests in the 4584 Session Initiation Protocol (SIP)", RFC 5079, December 4585 2007. 4587 [TS24229] xxx. 4589 [RFC5009] Ejzak, R., "Private Header (P-Header) Extension to the 4590 Session Initiation Protocol (SIP) for Authorization of 4591 Early Media", RFC 5079, September 2007. 4593 [GR506] GR-506-CORE, "LSSGR: Signaling for Analog Interfaces". 4594 Telcordia Technologies, Issue 2, December 2006. 4596 [RFC3264] Rosenberg, J., et al. "An Offer/Answer Model with the 4597 Session Description Protocol (SDP)", RFC 3264, June 2002. 4599 Author's Addresses 4601 John Haluska 4602 Telcordia Technologies, Inc. 4603 331 Newman Springs Road 4604 Room 2Z-323 4605 Red Bank, NJ 07701-5699 4606 USA 4608 Phone: +1 732 758 5735 4609 Email: jhaluska@telcordia.com 4611 Renee Berkowitz 4612 Telcordia Technologies, Inc. 4613 One Telcordia Drive 4614 Piscataway, NJ 08854-4157 4615 USA 4617 Phone: +1 732 699 4784 4618 Email: rberkowi@telcordia.com 4620 Paul Roder 4621 Telcordia Technologies, Inc. 4622 One Telcordia Drive 4623 Room RRC-4A619 4624 Piscataway, NJ 08854-4157 4625 USA 4627 Phone: +1 732 699 6191 4628 Email: proder2@telcordia.com 4630 Wesley Downum 4631 Telcordia Technologies, Inc. 4632 One Telcordia Drive 4633 Piscataway, NJ 08854-4157 4634 USA 4636 Phone: +1 732 699 6201 4637 Email: wdownum@telcordia.com 4639 Richard Ahern 4640 AT&T Customer Information Services 4641 1876 Data Drive 4642 Room 314 4643 Hoover, AL 35244 4644 USA 4646 Email: Richard.Ahern@bellsouth.com 4648 Paul Lum Lung 4650 Marty Cruze 4651 CenturyLink 4652 Email: marty.cruze@centurylink 4654 Nicholas S. Costantino 4655 Soleo Communications, Inc. 4656 300 Willowbrook Drive 4657 Fairport, NY 14450 4659 Email: ncostantino@soleocommunications.com 4661 Chris Blackwell 4663 D. E. Scott 4664 VoltDelta 4665 2401 N. Glassell St. 4666 Orange, CA 92865-2705 4668 Email: dscott@voltdelta.com