idnits 2.17.1 draft-gurbani-iptel-sip-to-in-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 98 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2.1 Overview of IN calls' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 853 looks like a reference -- Missing reference section? '2' on line 855 looks like a reference -- Missing reference section? '3' on line 858 looks like a reference -- Missing reference section? '4' on line 861 looks like a reference -- Missing reference section? '5' on line 864 looks like a reference -- Missing reference section? '6' on line 867 looks like a reference -- Missing reference section? '7' on line 869 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Vijay K. Gurbani 3 August 2001 Lucent Technologies, Inc. 4 Expires: February 2002 Vidhi Rastogi 5 Wipro Technologies 7 Accessing IN services from SIP networks 9 11 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 ABSTRACT 33 In Internet telephony, the call control functions of a traditional 34 circuit switch are replaced by a IP-based call controller that must 35 provide features normally provided by the traditional switch, 36 including operating as a SSP for IN features. A traditional switch 37 is armed with an IN call model that provides it a means to reach out 38 and make service decisions based on intelligence stored elsewhere. 39 Internet call controllers, by contrast, do not have an IN call model. 40 Furthermore, since there are many Internet call models with varying 41 number of states than the IN call model, there has to be a mapping 42 from the IN call model states to the equivalent states of the 43 Internet call model if existing services are to be accessed 44 transparently. To leverage the existing IN services from the 45 Internet domain, this draft proposes a mapping from the states of the 46 IN call model to the states of SIP, an Internet call signaling 47 protocol. 49 Accessing IN services from SIP networks 51 1. Introduction 53 In Internet telephony, the call control functions of a traditional 54 circuit switch are replaced by a device referred to, in different 55 contexts, as a call agent, a SIP server, a H.323 Gatekeeper, a 56 feature server, or a soft- switch. This device (which we will refer 57 to as an Internet call agent, or simply a call agent) is an IP entity 58 that coordinates the calls. A call agent executes a finite number of 59 state transitions as it processes the call; these state transitions 60 constitute its call model. To be precise, the term "call model" when 61 applied to an Internet call agent is a misnomer; a better term would 62 be a "protocol state machine." Unlike a traditional switch armed 63 with an IN call model, the protocol state machine on a call agent 64 does not contain IN specific triggers and states. Also, the number 65 of call-related states of an Internet call agent are much less than 66 those of the IN call model. Currently, there are at least two major 67 Internet call signaling protocols in use - H.323 and SIP - both with 68 varying number of states than the IN call model. 70 In order to access IN services transparently using Internet 71 telephony, the Internet protocol state machine must be mapped to the 72 IN call model. This has the added benefit of accessing existing IN 73 services using the same detection points (DPs) from the same well 74 known point in call (PIC). From the viewpoint of other IN elements 75 like the service control point (SCP), the fact that the request 76 originated from a call agent versus a call processing function on a 77 traditional switch is immaterial. Thus, it is important that the 78 call agent be able to provide features normally provided by the 79 traditional switch, including operating as a SSP for IN features. 80 The call agent should also maintain call state and trigger queries to 81 IN-based services, just as traditional switches do. 83 The IN call model consists of two halves: the Originating call model 84 and the Terminating call model. If the called and calling party 85 share the same switch, the originating call model is assigned to the 86 calling party and the terminating call model is assigned to the 87 called party. If the call has to go through multiple switches to get 88 to the destination, each of the intervening switch will run the two 89 halves of the call model, with the destination switch's terminating 90 call model providing services to the called party. While this model 91 has worked well for traditional circuit-based switching, it may not 92 be desirable to implement it in an analogous manner on an Internet 93 call model. A later section will discuss this issue in more detail. 95 The most expeditious manner for providing existing IN services in the 96 Internet telephony domain would be to use the deployed IN 98 Accessing IN services from SIP networks 100 infrastructure as much as possible and leverage existing services. 101 The logical point in the Internet telephony domain to tap into for 102 accessing existing IN services is the call agent. However, the call 103 agent, as we have discovered above, does not run an IN call model. 104 Instead, the various Internet call agents run their respective native 105 protocol state machines for call signaling - either Q.931 in H.323 or 106 a SIP stack in SIP. The trick, then, is to overlay this state 107 machine with an IN layer such that call acceptance and routing is 108 performed by the native state machine and services are accessed 109 through the IN layer using an IN call model. This draft proposes 110 using SIP as the native state machine and accessing IN services by 111 mapping SIP states to the IN call model states. Doing this enables 112 Internet access to well known telephony services such as number 113 translation, call screening, call routing and distribution services, 114 which mostly occur before call setup is complete. 116 The rest of the paper is organized as follows: Section 2 briefly 117 discusses the IN and SIP call models. Section 3 discusses some 118 issues that necessarily arise from mapping call models. Section 4 119 outlines some possible SIP/IN architectures. Section 5 establishes a 120 mapping between the IN call model and SIP. Section 6 discusses a few 121 call flows; section 7 includes a report on the implementation status 122 of this I-D, and section 8 touches on some security considerations. 124 2. Call models 126 2.1 Overview of IN calls 128 In a traditional switch environment, when the SSP recognizes a call 129 that requires IN treatment, it temporarily suspends the call 130 processing and sends a query to the SCP. The SCP analyzes the 131 information it received from the SSP and makes a decision on how to 132 continue processing the call. The decision is sent to the SSP, which 133 now continues with further call processing. It is important to 134 realize that IN treatment for a call is not limited to simple 135 request-reply transactions. Including simple querying, the following 136 are the major functions that are part of ITU-T CS-1 and CS-2 [1]: 138 2.1.1 Querying 140 The SSP sends a query to the SCP over SS7 in form of a INAP query 141 message. The SCP analyzes the information in the INAP query and 142 sends back a INAP response to the SSP which contains instructions on 143 how to further handle this call. 145 2.1.2 Caller interaction 147 Accessing IN services from SIP networks 149 Instead of normal query-response, the SSP and SCP may enter an 150 extended interaction. After receiving a query message from the SSP, 151 the SCP may send back to the SSP a INAP conversation with permission 152 message. This prompts the SSP to collect additional information from 153 the caller, possibly by involving other IN devices like the 154 Intelligent Peripheral or a Service Node. The caller may send back 155 to the SSP dial-pulse digits or DTMF signals. Whatever the format of 156 the response, the SSP returns this information back to the SCP in a 157 INAP conversation package message. 159 2.1.3 Trigger activation/deactivation 161 Most DPs in a switch are armed by the SMF offline. However, it is 162 possible for the SCP to inform a switch to arm a DP for the duration 163 of a call. DPs armed in the former manner are said to be statically 164 armed and those armed in the latter manner are said to be dynamically 165 armed. Dynamically armed DPs remain in effect for the duration of 166 that particular call [2]. 168 2.1.4 Response processing 170 The SSP, upon receiving a INAP response message from the SCP, must 171 take the appropriate actions such as routing the call, redirecting 172 the call, disconnecting the call, playing announcements to the 173 caller, and so on. The SCP may further control the SSP by requesting 174 that it be notified when the call ends, or requesting it to monitor 175 certain facilities. 177 2.2 IN call model 179 The IN generic basic call state model (BCSM), independent of any 180 capability sets, is divided into two halves - an originating call 181 model (O_BCSM) and a terminating call model (T_BCSM) [3]. There are 182 a total of 19 PICs and 35 DPs between both the halves (11 PICs and 21 183 DPs for O_BCSM; 8 PICs and 14 DPs for T_BCSM) [2]. The SSPs, SCPs 184 and other IN elements track a call's progress in terms of the basic 185 call model. The basic call model provides a common context for 186 communication about a call. 188 O_BCSM has 11 PICs. These are: 190 O_NULL: starting state; call does not exist yet. 191 AUTH_ORIG_ATTEMPT: switch detects a call setup request. 192 COLLECT_INFO: switch collects the dial string from the calling 193 party. 194 ANALYZE_INFO: complete dial string is translated into a routing 196 Accessing IN services from SIP networks 198 address. 199 SELECT_ROUTE: physical route is selected, based on the routing 200 address. 201 AUTH_CALL_SETUP: switch ensures the calling party is authorize to 202 place call. 203 CALL_SENT: control of call send to terminating side. 204 O_ALERTING: switch waits for the called party to answer. 205 O_ACTIVE: connection established; communication ensue. 206 O_DISCONNECT: connection torn down. 207 O_EXCEPTION: switch detected an exceptional condition. 209 T_BCSM has 8 PICS. These are: 211 T_NULL: starting state; call does not exist yet. 212 AUTH_TERM_ATT: switch verifies whether call can be send to 213 terminating party. 214 SELECT_FACILITY: switch picks a terminating resource to send the 215 call on. 216 PRESENT_CALL: call is being presented to the called party. 217 T_ALERTING: switch alerts the called party, e.g. ringing the line. 218 T_ACTIVE: connection established; communications ensue. 219 T_DISCONNECT: connection torn down. 220 T_EXCEPTION: switch detected an exceptional condition. 222 and 103 respectively. This state machine will be used for subsequent 223 discussion when the IN call states are mapped into SIP. 225 It is beyond the scope of this document to explain all PICs and DPs 226 in an IN call model. It is assumed that the reader has some 227 familiarity with the PICs and DPs of the IN call model. More 228 information can be found in [2]. 230 2.3 SIP call model 232 SIP is a lightweight signaling protocol for Internet telephony. SIP 233 has 6 methods -- INVITE, ACK, OPTIONS, BYE, CANCEL, and REGISTER -- 234 and various response codes divided among the following 6 classes: 236 Class Meaning 237 ------------------------ 238 1xx Informational 239 2xx Success 240 3xx Redirection 241 4xx Request failure 242 5xx Server failure 244 Accessing IN services from SIP networks 246 6xx Global failure 248 Table 1: SIP response codes 250 To establish a mapping between IN call state and SIP, the SIP 251 protocol state machine can be viewed as essentially consisting of an 252 INVITE message, interim response codes for the invitation ("100 253 Trying" or "180 Ringing"), an acceptance (or a decline) of the INVITE 254 message, and an acknowledgement for the acceptance (or decline). If 255 the invitation was accepted, SIP provides a BYE message for signaling 256 the end of the call. 258 It is beyond the scope of this document to cover SIP in a justifiable 259 manner. It is assumed that the reader has some familiarity with SIP. 260 More information can be found in [4] 262 3. Issues in IN call model mappings 264 One way in which IN services can be invoked transparently from a SIP 265 server processing a telephony call is to overlay the SIP protocol 266 state machine with the IN call model. Thus the call receives 267 treatment from two call models, both working in synchrony; the SIP 268 state machine handles the acceptance and final delivery of the call 269 while the IN call model interfaces with the IN to provide services 270 for the call. Figure 1 demonstrates this concept: a SIP server 271 accepts a call, notifies the IN call handling layer of this event; 272 the IN call handling layer interfaces with the IN elements to provide 273 services for the call, ultimately informing the SIP server on how to 274 deliver the call. The interface between the IN call handling layer 275 and the SCP is not specified by this I-D and indeed, can be any one 276 of the following depending on the interfaces supported by the SCP: 277 INAP over IP, INAP over SIGTRAN, INAP over TALI or INAP over SS7. 279 Accessing IN services from SIP networks 281 +-----+ 282 | S | 283 | C | 284 +---------->| P | 285 | +-----+ 286 | 287 V 288 +------------------------+ 289 | IN call handling | 290 +------------------------+ 291 | ^ Process | 292 | / \ call | 293 | | | 294 --------->| SIP call handling |-----------> 295 Accept +------------------------+ Deliver call 296 Call 297 Figure 1: IN call model overlayed on SIP 299 The notion of feature interaction, i.e. the notion about where a call 300 gets its features serviced from -- SIP or IN -- is not addressed 301 here. SIP itself has a rich set of features that can be applied on a 302 call by call basis, as does IN. While it is entirely possible that a 303 SIP server applies certain features to an incoming call before 304 handing it to the IN layer, this draft limits its discussion on 305 services accessed from the IN by a SIP proxy server. The underlying 306 assumption is that IN is servicing the call by providing it features, 307 and SIP is simply routing the call based on the decisions made by the 308 IN layer. 310 Another fundamental problem here lies in the notion of a call state. 311 The IN call model is necessarily a stateful one. A SIP proxy can 312 operate in either stateful or stateless mode, depending on the needs 313 of the application. For speed, reliability and scalability, SIP 314 proxies may be run in the stateless mode. The duration and amount of 315 state maintained at a SIP proxy are small compared to the traditional 316 telephone network, where the switch must maintain the call state for 317 the entire duration of the call. For a SIP proxy to run in the 318 call-stateful mode, it has to indicate a willingness to remain in the 319 signaling path till the call is disconnected. This is accomplished 320 using the Record-Route header field of a SIP message. 322 4. SIP/IN architecture 324 In order to apply the stateful IN call model to a SIP proxy, the 325 originating and terminating SIP network servers must run in call- 326 state aware mode and have the IN call model layer working in 328 Accessing IN services from SIP networks 330 conjunction with SIP as depicted in Figure 1. Other intervening SIP 331 proxies may remain stateless and have no need to run the IN call 332 model layer. The originating and terminating SIP network servers 333 mimic the originating and terminating switches in a traditional phone 334 network. IN services accessed through DPs on originating or 335 terminating side can now be handled by the IN layer on the 336 originating or terminating SIP proxy. Figure 2 demonstrates this: 338 +---+ +---+ 339 | S | | S | 340 | C |<--+ +-->| C | 341 | P | | | | P | 342 +---+ | | +---+ 343 | | 344 +-------|-------------------------------------|-------+ 345 | | SIP network | | 346 | V V | 347 | +-------+ +-------+ | 348 | | IN | | IN | | 349 | +-------+ +-------+ +-------+ +-------+ | 350 Calling | | O SIP |---->| C SIP | ... | C SIP |---->| T SIP | | Called 351 Party ----|>+-------+ +-------+ +-------+ +-------+-|---> Party 352 | | 353 +-----------------------------------------------------+ 355 Legend: 356 O SIP: Originating SIP network server, running IN call model layer 357 T SIP: Terminating SIP network server, running IN call model layer 358 C SIP: Core SIP network servers (may be proxy or redirect) 359 IN: IN layer 361 Figure 2: IN-controlled SIP network 363 There are three other points worth mentioning in Figure 2: 365 1) If the called party and the calling party are handled by the same 366 SIP server, both halves of the IN call model will run on that server. 367 This is analogous to the traditional telephone network. 369 2) In the traditional telephone network, the interexchange switches 370 can run both halves of the call model. This can also be accomplished 371 in the SIP network if desired. Figure 2 shows the IN call model 372 running on originating and terminating SIP proxies. However, any of 373 the core SIP proxies could also have hosted the IN call model if 374 needed. 376 Accessing IN services from SIP networks 378 3) If the called party and calling party are handled by different SIP 379 network servers, each with its own IN layer, the IN call state 380 information has to be propagated between these servers. This draft 381 does not include any information on such a transaction, except to 382 note that there are other protocols like SIP+ which address such 383 problems. Or in fact, the IN layers of the originating and 384 terminating SIP proxies can communicate directly with each other 385 using ISUP over IP to share call state between themselves. 387 Figure 2 showed an end-to-end SIP network, with SIP proxies running 388 the IN call model reaching out to the SCP for service logic. Figure 389 3 shows a SIP network providing services from the SCP through the IN 390 call model and routing the call to the GSTN. In this example, it is 391 assumed that both halves of the IN call model are running on the same 392 SIP proxy: 394 +---+ 395 | S | 396 | C |<--+ 397 | P | | 398 +---+ | 399 | 400 +-------|-----------------+ +---------- ... 401 | | SIP network | | GSTN network 402 | V | | 403 | +-------+ | | 404 | | IN | | | 405 | +-------+ +-------------+ | 406 Calling | | O SIP |------>| SIP Gateway |------->| 407 Party ----|>+-------+ +-------------+ | 408 | | | 409 +-------------------------+ +---------- ... 411 Figure 3: SIP network with GSTN gateway 413 5. Mapping call states 415 At first glance, it would appear that mapping a 19 PIC and 35 DP IN 416 call model into SIP is a losing proposition. However, such is not 417 the case. In fact, certain IN services like freephone, originating 418 call screening, caller name identification, are very easy to 419 implement. By and large, IN services that have a "query-response" 420 nature are easily translated to SIP. On the other hand, services 421 involving the media path (e.g. "prompt-and-collect", mid-call 422 announcement capability) are comparitively harder to implement; and 423 in fact these services may be implemented in a specialized 425 Accessing IN services from SIP networks 427 "application server" instead of a SIP proxy [5]. 429 IN states (listed in Section 2.3) will be mapped to the appropriate 430 SIP methods or response codes (also listed in Section 2.3). While 431 mapping call states from SIP to IN, it is important to note that 432 there will not be a 1-to-1 mapping between IN call states and SIP 433 states. 435 5.1 SIP and O_BCSM 437 The 11 PICs of O_BCSM come into play when a call request (SIP INVITE 438 message) arrives from an upstream SIP client to an originating SIP 439 proxy running the IN call model. This SIP proxy will create a O_BCSM 440 object and initialize it in the O_NULL PIC. The next five IN PICs -- 441 AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO, SELECT_ROUTE and 442 AUTH_CALL_SETUP -- can all be mapped to the SIP INVITE message. 444 The SIP INVITE message has enough functionality to absorb these five 445 PICs as described below: 447 AUTH_ORIG_ATT - In this PIC, an IN SSP has detected that someone 448 wishes to make a call. Under some circumstances (e.g. the user is 449 not allowed to make calls during certain hours), such a call cannot 450 be placed. SIP has the ability to authorize the calling party 451 using a set of policy directives configured by the SIP 452 administrator. If the called party is authorized to place the call, 453 the IN layer is instructed to enter the next PIC, COLLECT_INFO. 455 COLLECT_INFO - This PIC is responsible for collecting a dial string 456 from the calling party. The SIP proxy can detect a malformed 457 address and may send the calling party a "484 Address Incomplete" 458 message and remain in this state until a valid "dial string" is 459 received. Once it has obtained a valid dial string, the IN layer 460 is instructed to enter the next PIC, ANALYZE_INFO. 462 ANALYZE_INFO - This PIC is responsible for translating the dial 463 string to a routing number. Many IN service such as freephone, 464 LNP, OCS, etc. occur during this PIC. The IN layer can use the 465 Request-URI of the SIP INVITE request for analysis. If the 466 analysis succeeds, the IN layer is instructed to enter the next 467 PIC, SELECT_ROUTE. 469 SELECT_ROUTE - In the circuit-switched network, the actual physical 470 route has to be selected at this point. The SIP analogue of this 471 would be to determine the next hop SIP server. The next hop SIP 472 server could be chosen by a variety of means. For instance, if the 474 Accessing IN services from SIP networks 476 Request URI in the incoming INVITE request is an E.164 number, the 477 SIP proxy can use a protocol like TRIP [6] to find the best gateway 478 to egress the request onto the GSTN. 480 AUTH_CALL_SETUP - Certain service features restrict the type of 481 call that may originate on a given line or trunk. This PIC is the 482 point at which relevant restrictions are examined. 484 If the above 5 PICs have been successfuly negotiated, the SIP proxy 485 running the IN call model now sends the SIP INVITE message to the 486 next hop server. If the SIP proxy running the IN call layer gets 487 back a "100 Trying" message for that call, it can instruct the IN 488 layer to enter enter the next PIC, CALL_SENT. In IN terms, the 489 control over the establishment of the call has been transferred to 490 the T_BCSM object, and the O_BCSM object is waiting for a signal 491 confirming that either the call has been presented to the called 492 party or that the called party cannot be reached for a particular 493 reason. 495 When the SIP proxy running the IN call layer gets back a "180 496 Ringing" for the call, it now instructs the IN layer to enter the 497 next PIC, O_ALERTING. At this point, O_BCSM is waiting for the 498 called party to answer. Assuming the called party answers, the SIP 499 proxy running the IN layer receives a "200 OK". The receipt of this 500 message is followed by the SIP proxy instructing the IN layer to 501 enter the next PIC, O_ACTIVE. The call is now active. 503 When either of the party hangs up, the SIP proxy running the IN call 504 layer receives a SIP BYE message. Since it is running in call- 505 stateful mode, it can correlate the BYE message with the call that 506 needs to be torn down. The SIP server instructs the IN layer to 507 enter its next PIC, O_DISCONNECT and perform cleanup. Subsequently, 508 the state of the call in the SIP proxy itself is also destroyed. 510 Figure 4 below provides a visual mapping from the SIP proxy protocol 511 state machine to the originating half of the IN call model. Note 512 that control of the call shuttles between the SIP protocol machine 513 and the IN O_BCSM call model while it is being serviced. 515 Accessing IN services from SIP networks 517 SIP O_BCSM 519 +----------------+ +-----------------+ 520 | INVITE |======================>| O_NULL | 521 +--+-------------+ +--------+--------+ 522 | /\ | 523 | || | 524 | || +--------V--------+ 525 | || | AUTH_ORIG_ATT | 526 | || +--------+--------+ 527 | || | 528 | || | 529 | || +--------V--------+ 530 | ||<========================>| COLLECT_INFO | 531 | || +--------+--------+ 532 | || | 533 | || | 534 | || +--------V--------+ 535 | || | ANALYSE_INFO | 536 | || +--------+--------+ 537 | || | 538 | || | 539 | || +--------V--------+ 540 | || | SELECT_ROUTE | 541 | || +--------+--------+ 542 | || | 543 | || | 544 | || +--------V--------+ 545 | ||<======================== | AUTH_CALL_SETUP | 546 | +-----------------+ 547 | 548 +--V--------------+ +-----------------+ 549 | 100 Trying |=====================>| CALL_SENT | 550 +--+--------------+ +--||-------------+ 551 | /\ || 552 | || || 553 | ||=============================|| 554 | 555 +--V--------------+ +-----------------+ 556 | 180 Ringing |=====================>| O_ALERTING | 557 +--+--------------+ +--||-------------+ 558 | /\ || 559 | || || 560 | ||=============================|| 561 | 562 +--V--------------+ +-----------------+ 564 Accessing IN services from SIP networks 566 | 200 OK |=====================>| O_ACTIVE | 567 +-----------------+ +-----------------+ 569 ------------------------------------------------------------ 570 Communication established; call active 571 ------------------------------------------------------------ 573 +-----------------+ +-----------------+ 574 | BYE |=====================>| O_DISCONNECT | 575 +-----------------+ +--||-------------+ 576 /\ || 577 || || 578 ||==============================|| 579 Legend: 581 | Communication between 582 | states in the same 583 V protocol 585 ======> Communication between IN layer and SIP 587 Figure 4: Mapping from SIP to O_BCSM 589 5.2 SIP and T_BCSM 591 The T_BCSM object is created when a SIP INVITE message makes its way 592 to the terminating SIP proxy running the IN layer. The SIP proxy 593 creates the T_BCSM object and initializes it to the T_NULL PIC. 595 The IN layer is instructed to enter the next PIC, AUTH_TERM_ATT, 596 during which the fact that the called party wishes to receive the 597 present type of call is ascertained. IN services such as Caller 598 Identification and Call Forwarding are normally triggered from DPs 599 associated with this PIC. Once a positive indication is received 600 from the AUTH_TERM_ATT PIC, the IN layer is instructed to enter the 601 next PIC, SELECT_FACILITY. 603 The intent of this PIC, in traditional circuit networks, is to select 604 a line or a trunk to reach the called party. In a hybrid (GSTN/IP) 605 network, where the callee resides on the GSTN, a SIP proxy can use 606 SELECT_FACILITY PIC to interface with a gateway and select a 607 line/trunk to route the call. If a facility was thus successfully 608 seized, the SIP INVITE request is deemed to be successfull. 610 In a traditional circuit-switched network, PRESENT_CALL presents (via 612 Accessing IN services from SIP networks 614 ISUP ACM or Q.931 Alerting messages) the call to the called party. 615 Since the incoming INVITE succeeded, the SIP proxy server instructs 616 the IN layer to enter PRESENT_CALL. The IN layer will remain in this 617 state (the SIP proxy remains in the INVITE state) until the SIP proxy 618 gets back a "180 Ringing", whereupon it instructs the IN layer to 619 enter the next state, T_ALERTING. 621 T_ALERTING "alerts" the called party by ringing the phone. When the 622 SIP proxy receives a "200 OK", it instructs the IN layer to enter the 623 next PIC, T_ACTIVE. The call is now active. 625 When either of the party hangs up, the SIP proxy running the IN call 626 layer receives a SIP BYE message. Since it is running in call- 627 stateful mode, it can correlate the BYE message with the call that 628 needs to be torn down. The SIP server instructs the IN layer to 629 enter its next PIC, T_DISCONNECT and perform cleanup. Subsequently, 630 the state of the call in the SIP proxy itself is also destroyed. 632 Figure 5 below provides a visual mapping from the SIP proxy protocol 633 state machine to the terminating half of the IN call model: 635 Accessing IN services from SIP networks 637 SIP T_BCSM 639 +----------------+ +-----------------+ 640 | INVITE |======================>| T_NULL | 641 +--+-------------+ +--------+--------+ 642 | /\ | 643 | || | 644 | || +--------V--------+ 645 | || | AUTH_TERM_ATT | 646 | || +--------+--------+ 647 | || | 648 | || | 649 | || +--------V--------+ 650 | || | SELECT_FACILITY | 651 | || +--------+--------+ 652 | || | 653 | || | 654 | || +--------V--------+ 655 | ||========================= | PRESENT_CALL | 656 | +-----------------+ 657 | 658 +--V--------------+ +-----------------+ 659 | 180 Ringing |=====================>| T_ALERTING | 660 +--+--------------+ +--||-------------+ 661 | /\ || 662 | || || 663 | ||=============================|| 664 | 665 +--V--------------+ +-----------------+ 666 | 200 OK |=====================>| T_ACTIVE | 667 +-----------------+ +-----------------+ 669 ------------------------------------------------------------ 670 Communication established; call active 671 ------------------------------------------------------------ 673 +-----------------+ +-----------------+ 674 | BYE |=====================>| T_DISCONNECT | 675 +-----------------+ +--||-------------+ 676 /\ || 677 || || 678 ||==============================|| 679 Legend: 681 | Communication between 683 Accessing IN services from SIP networks 685 | states in the same 686 V protocol 688 ======> Communication between IN call model and SIP 689 protocol state machine 691 Figure 5: Mapping from SIP to T_BCSM 693 6. Call flows 695 Two examples are provided here to understand how SIP protocol state 696 machine and the IN call model work synchronously with each other. 698 In the first example, a SIP UAC originates a call request destined to 699 a 800 freephone number: 701 INVITE sip:18005551212@lucent.com SIP/2.0 702 From: sip:16309795218@il0015vkg1.ih.lucent.com 703 To: sip:18005551212@lucent.com 704 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 705 Call-ID: 67188121@lucent.com 706 CSeq: 1 INVITE 708 The request makes its way to the originating SIP network server 709 running an IN call model. The SIP network server hands, at the very 710 least, the To: field and the From: field to the IN layer for 711 freephone number translation. The IN layer proceeds through its PICs 712 and in the ANALYSE_INFO PIC consults the SCP for freephone 713 translation. The translated number is returned to the SIP network 714 server, which forwards the message to the next hop SIP proxy, with 715 the freephone number replaced by the translated number: 717 INVITE sip:16302240216@lucent.com SIP/2.0 718 From: sip:16309795218@il0015vkg1.ih.lucent.com 719 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 720 Via: SIP/2.0/UDP sip-in1.ih.lucent.com 721 To: sip:18005551212@lucent.com 722 Call-ID: 67188121@lucent.com 723 CSeq: 1 INVITE 725 In the next example, a SIP UAC originates a call request destined to 726 a 900 number: 728 INVITE sip:19005551212@lucent.com SIP/2.0 729 From: sip:16302240216@lucent.com 730 To: sip:19005551212@lucent.com 732 Accessing IN services from SIP networks 734 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 735 Call-ID: 88112@lucent.com 736 CSeq: 1 INVITE 738 The request makes its way to the originating SIP network server 739 running an IN call model. The SIP network server hands, at the very 740 least, the To: field and the From: field to the IN layer for 900 741 number translation. The IN layer proceeds through its PICs and in 742 the ANALYSE_INFO PIC consults the SCP for the translation. During 743 the translation, the SCP detects that the originating party is not 744 allowed to make 900 calls. It passes this information to the 745 originating SIP network server, which informs the SIP UAC using SIP 746 "403 Forbidden" response status code: 748 SIP/2.0 403 Forbidden 749 From: sip:16302240216@lucent.com 750 To: sip:19005551212@lucent.com 751 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 752 Call-ID: 88112@lucent.com 753 CSeq: 1 INVITE 755 7. Implementation Status 757 The work described in this I-D has been implemented. A SIP proxy 758 server has been written to map the states of the IN call model to the 759 SIP protocol state machine as described in this I-D. A portable Call 760 Model object has also been implemented in C++ and used successfully 761 with the SIP proxy server to provide the services mentioned in this 762 I-D. Implementation experience and other details related to it are 763 provided in [7]. 765 8. Security Considerations 767 The work described in this I-D did not focus too deeply into the 768 security aspects. However, that does not imply that security 769 considerations do not exist. Listed below are some of the security 770 implications inherent in implementing services that cross (Internet 771 and GSTN) domains: 773 (1) Obviously, if a SIP proxy server is to access IN services in 774 the GSTN domain, a trust relationship should exist between the 775 provider of the SIP proxy and the provider of the IN-related data 776 (if they are not the same entity). 778 (2) A SIP proxy that receives SIP requests from an upstream UAC 779 must be able to authenticate the (user of the) UAC for services 781 Accessing IN services from SIP networks 783 that are triggered on the detection points in the originating BCSM. 785 (3) Services such as Calling Name Delivery (triggered on the 786 detection points in the TBCSM) can be easily accomplished in SIP by 787 querying the From general header field of a SIP request. However, 788 some guarantee must be made that the name displayed in the From 789 header field and the person who originated the call are indeed the 790 same entities. 792 Overall, the security considerations tend to cluster around the well 793 known axes: authentication, authorization, encryption, and trust. 794 There are various proposals, both SIP-specific, as well as general 795 proposals, to deal with these issues. Further work needs to be done 796 to codify and quantify the security threats and how to address them. 798 9. Acknowledgements 800 Many thanks to Alec Brusilovksy, Janet Douglas, Igor Faynberg, 801 Jonathan Rosenberg, John Stanaway, and Kumar Vemuri for their 802 insights, inputs, and comments. 804 10. Changes from earlier versions 806 10.1 Changes from draft -04 808 o Changed text in Section 3 to specify possible interfaces between 809 the IN call handling layer and the SCP. 811 o In Section 3, took out the phrase "...using SIP as a signaling 812 transport" since that conveyed the idea that the body of the SIP 813 message consisted of INAP (or TCAP) payload. Rephrased the 814 latter part of the second paragraph in Section 3. 816 10.2 Changes from draft -03 818 o Changed references of SIP "server" to SIP "proxy" wherever 819 appropriate. 821 o Mapped IN PICs SELECT ROUTE and SELECT_FACILITY to SIP states. 823 10.3 Changes from draft -02 825 o Added section on Security. 827 Accessing IN services from SIP networks 829 o Updated section on Implementation Status. 831 11. Abbreviations: 833 DP Detection Point 834 GSTN Global Switched Telephone Network 835 IN Intelligent Network 836 INAP Intelligent Network Application Protocol 837 IP Internet Protocol or Intelligent Peripheral 838 LNP Local Number Portability 839 O_BCSM Originating Basic Call State Model 840 OCS Originating Call Screening 841 PIC Point In Call 842 PRI Primary Rate Interface 843 SCP Service Control Point 844 SIP Session Initiation Protocol 845 SMF Service Management Function 846 SS7 Signaling System 7 847 SSP Service Switching Point 848 T_BCSM Terminating Basic Call State Model 849 UAC (SIP) User Agent Client 850 UAS (SIP) User Agent Server 852 12. References: 853 [1] Uyless Black, "The Intelligent Network: Customizing 854 Telecommunications and Services," Prentice Hall, 1998. 855 [2] I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The 856 Intelligent Network Standards: Their Application to 857 Services," McGraw-Hill, 1997. 858 [3] ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network 859 Distributed Functional Plane Architecture," International 860 Telecommunications Union Standardization Section, Geneva. 861 [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 862 "SIP: Session Initiation Protocol", IETF Standards RFC 863 2543, March 1999. 864 [5] J. Rosenberg, J. Peterson, H. Schulzrinne, "Third Party Call Control 865 in SIP", IETF Internet Draft , Expires 866 September 2000, Work in Progress. 867 [6] Jonathan Rosenberg, Henning Schulzrinne, "A Framework for Telephony 868 Routing Over IP", IETF Informational RFC 2871, June 2000. 869 [7] Vijay Gurbani, "SIP enabled IN Services - an implementation report", 870 IETF Internet Draft , Expires 871 May, 2001, Work in Progress. 873 Accessing IN services from SIP networks 875 10. Authors' Address 877 Vijay K. Gurbani 878 E-mail: vkg@lucent.com 879 Telephone: +1-630-224-0216 880 Fax: +1-630-713-5840 881 Lucent Technologies 882 2000 Lucent Lane, Rm 6G-440 883 Naperville, IL 60566 USA 885 Vidhi Rastogi 886 E-mail:vidhi.rastogi@wipro.com 887 Telephone: 91-80-5539134 888 Fax: 91-80-5539701 889 Wipro Technologies 890 271, Sri Ganesha Complex 891 Hosur Main Road, Madiwala 892 Bangalore - 560 068, INDIA