idnits 2.17.1 draft-haerens-sip-in-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 389 has weird spacing: '... ensure that ...' == Line 558 has weird spacing: '...horised or DP...' == Line 654 has weird spacing: '...TE will be...' == Line 657 has weird spacing: '...ccepted may b...' == Line 856 has weird spacing: '...ticular reaso...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The called number can be received in just one INVITE method(`en bloc' signalling) or in one INVITE method followed by one or several INVITE's (overlap signalling). In some countries there is no way for the server to know whether the called party' number is already complete. If the server relies on the inter-digit time-out to assume that the number is complete, the establishment of the connection is delayed. Alternatively, if the server sends the INVITE request immediately after receiving the INVITE method, heavy signalling traffic may be generated. Therefore, an individual server might implement a timer and/or a stop digit (such as #). All the digits that arrive before this timer expires will be included in the INVITE sent. The timer can be bypassed by the user sending the stop digit. This timer SHOULD not be larger than 5 seconds. -- 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: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 738 looks like a reference -- Missing reference section? '2' on line 753 looks like a reference -- Missing reference section? '4' on line 698 looks like a reference -- Missing reference section? '3' on line 1562 looks like a reference -- Missing reference section? '5' on line 703 looks like a reference -- Missing reference section? '6' on line 621 looks like a reference -- Missing reference section? '7' on line 626 looks like a reference -- Missing reference section? '8' on line 631 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group F.Haerens 3 Internet Draft Alcatel Bell 4 Vijay K. Gurbani 5 Lucent Technologies 6 Vidhi Rastogi 7 Wipro Technologies 8 Document: draft-haerens-sip-in-01.txt Expires: January 2002 9 Category: Informational 11 SIP-IN Interworking Protocol Architecture and Procedures 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 26 The list of current Internet-Drafts can be accessed at 27 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 1. Abstract 33 This draft gives a first input on the SIP-IN Interworking Protocol 34 Architecture and Procedures for further discussion into the IETF as 35 part of the SIP-IN Interworking (SIN design team). 37 The aim of the SIP/IN Interworking is to consider the support of 38 existing IN-based applications in a SIP-based IP environment for 39 IP-Host-to-Phone calls. There are 40 many telephony applications based on IN: 800 (freephone), PSTN VPN, 41 credit card calling, to name a few. 43 This interworking protocol design team work requires: 45 - Interpreting IN Call Models for the SIP environment 46 - Mapping IN messages into (sequences of) SIP messages and vice 47 versa 48 - Mapping IN parameters into SIP parameters and vice versa 49 - Defining SIP extensions, if necessary 51 It was agreed that the contributors on the SIN design team should 52 first publish respective I-Ds, which are then used as the basis of 53 the informational draft that will be the major output of the design 54 team. 56 2. Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in RFC-2119 [2]. 62 3. Architecture Model 64 3.1 Introduction 66 Figure 1 shows the architecture model involving IN and SIP inter- 67 working. The possible groupings in the Intelligent SIP servers are 68 depicted. 70 The architecture model for accessing IN from SIP/SDP proxy/redirect 71 servers SHOULD have a minimal support for implementing services that 72 require explicit handling of the call configuration: The following 73 capabilities are considered: 75 (i) Number translation services including the storage of 76 related information (time of day) for e.g. portability and free 77 phone based services 79 (ii) Redirection services 81 (iii) Virtual Private Network services 83 (iv) Charging, the charging operations presently defined 84 need to be extended for the internet supported services including 85 credit card calling 86 (v) OA&M functions 88 It should be noted that the single Intelligent SIP Proxy/Redirect 89 Server as modeled in this figure can in fact represent several 90 different physical instances in the network, for example with one 91 Intelligent SIP server in charge of the terminal or access 92 network/domain, and another in charge of the interface to the 93 Switched Circuit Network. 95 Intelligent Network | IP Network 96 | 97 Service/Application | 98 Layer +---+ | 99 |SDF| +---|------+ 100 +-+-+ | | +-----------------+ 101 +---+<-------^ |Signaling | |Intelligent SIP | 102 |SCF|<------------+ |Transport | |Proxy/Redirect...| 103 +-+-+<-----+ | |Gateway | | Server | 104 | | | | | | | and | 105 | +-+-+ | | | | |Bearer Controller| 106 +-+-+ |SRF| | | | | | +----+ | 107 |SSF| +->| |<-+ | | | | | |SSF | | 108 | | | +-+-+ | +---|---|------|-----|->|(IP)| | 109 +---+---- | | | | | | +----+----+ | 110 | |<----+ | | | | | | | | 111 |CCF|<--------------|-----|---|------|-----|------>|CCF | | 112 ==| |===============|=====|==========|=====|=======|(IP)|====|== 113 +---+<-------+ | | | | +---|------>+--o-+ | 114 | | +---|------+ | +----------|------+ 115 | | | | | 116 Call/Bearer | | +---|------+ | | 117 Layer | | | +--+ | | +----o---+ 118 | +-----|->|MG|<---|-+ RTP | | 119 +------------|->| |<---|---------->| SIP | 120 | +--+ | | TE UA | 121 | Media | | | 122 | Gateway | +--------+ 123 +---|------+ 124 | 125 A MRF box need to be added having a Megaco interface to the CCF and 126 a RTP media stream. 128 Figure 1: A SIP based call control configuration using an 129 intelligent SIP Proxy/Redirect Server and Bearer Control Function 131 The following Architecture entities are defined in the Intelligent 132 Network standards: 134 Service Control Function (SCF): 136 IN functional entity that contains the IN service logic and handles 137 service related processing activity. 139 Service Switching Function (SSF): 141 IN functional entity that interacts with call control functions. 143 Call Control Function (CCF): 145 IN functional entity that refers to call and connection handling in 146 the classical sense (e.g. that of an exchange). 148 Service Data Function (SDF): 150 The SDF contains customer and network data for real-time access by 151 the SCF in the execution of an IN provided service. 153 The enhancements to the IN Architecture required for the IN/IP 154 interworking to support SIP/SDP systems are defined in section 3.2 155 while the interfaces as identified in figure 1 are given in section 156 3.3. 158 SRF should be added 159 3.2 Enhancements to the Architecture Entities required for SIP-IN 160 interworking 162 The enhancements to the following architecture entities are required 163 for the IN/IP interworking to support SIP systems: 165 (i) Call Control Function: CCF(IP) 167 (ii) Service Switching Function: SSF(IP) 169 3.2.1 Call Control Function 171 CCF(IP) is an enhanced functional entity, responsible for handling 172 call signaling on either network. To support the ISUP signalling the 173 CCF has to implement the procedures defined by SIP-T. In that case 174 it appears to the IN side CCF as being another CCF. This 175 functionality includes handling the management of the call 176 processing, and call signaling. 178 A Call Control function could be seen as a logical switch (CCF). A 179 Call Control Function can require SCF assistance for these routing 180 decisions, e.g. for 1-800 numbers, number portability, user profile 181 consultation, VPN support. 183 The functions related to the Call Control Function Entity are: 185 i) A sub-function of the Call Control Function is responsible for 186 passing registration and admission related information to and from 187 IN service layer, namely the SCF responsible for managing the IP 188 network services. General functions that need to be supported are: 190 - Data filtering/parsing/mapping 191 - Security/Authentication 192 - Real Time data collection (billing/parsing) 193 - Configuration/dimensioning 194 - Flow control 196 ii) The Call control function contains a high layer resource manager 197 function call Media Gateway Control (MGC) function. This MGC 198 function is responsible for controlling the lower layer resource 199 control function referred to as Media Gateway (MG). 201 iii) The Call Control function inter-works with and maps to the 202 underlying call control signalling (SIP/SDP). The call control may 203 invoke media and connection operations, for legs, media, packages 204 independent of before or after the IN interaction. Where call 205 control protocol is encapsulated in SIP (e.g. ISUP in SIP-T), 206 mapping to this package, or the embedded protocol may also need to 207 be specified. 209 v) Circuit switching and ancillary processes are removed 210 3.2.2 Service Switching Function:SSF(IP) 212 The enhanced SSF(IP) interacts with the IN Service Control Function 213 (SCF) and the IP representation of the Call Control Function (CCF), 214 mapping the Call Control Protocol into the INAP events trigger 215 points and procedures, where applicable. 217 This entity is responsible for passing service related information 218 to and from IN service layer, namely the SCF, and managing the 219 service control relationship. As such, the CCF may contain a SSF- 220 like functionality or subset thereof, to model the pre and post 221 conditions that are required to interact with an SCF. 223 The relation of the SSF(IP) to the classical SSF is as follows: 224 Many processes, such as call control, database and billing are 225 retained or enhanced. 227 The interface between the SIP Server and the SSF call control 228 processes MUST: 230 (i) Carry sufficient call data for the SSF to function correctly 231 and to deliver the necessary information to the SCF so that service 232 logic decisions can be made. 234 (ii) Allow the SCF (in combination with SSF and CCF Emulator) to 235 control VoIP calls (e.g. change 'B' party address) and manipulate 236 call information (such as presentation number). 238 3.3. Interfaces required for SIP-IN interworking 240 (i) CCF-to-CCF(IP) interface 242 This interface reflects the requirement to carry an ISDN control 243 plane signalling protocol for Multimedia services. This interface 244 relays the IP Multimedia user plane received from the CCF (Call 245 control Function). This interface is required for Voice over IP 246 based services. 247 This interface may require standardisation but is not expected to be 248 IN specific, work is progressing on this in ETSI TIPHON, IETF, SG11 249 BICC and SG16 H.246 Annex C. 251 (ii) SCF_to-SSF(IP) interface 253 This interface reflects the requirement to carry an IN-based 254 signalling protocol for IP and Multimedia services. This interface 255 relays the IP Multimedia control plane triggered events to and from 256 the SCF. 257 This interface may require standardisation. 258 This interface is required to trigger and control value added 259 services from a SIP Proxy/Redirect Server function in the IP network 260 e.g. for multimedia access from the Internet "dial-up" access. 262 (iii) CCF(IP)-to-Media Manager (MG) interface 264 This interface reflects the requirement to carry an ISDN user plane 265 protocol for Multimedia services. This interface relays the IP 266 Multimedia user plane received from RTP/RTCP and is defined as the 267 Media Gateway Control interface. 268 This interface may require standardisation but is not expected to be 269 IN specific, work is progressing on this interface in ETSI TIPHON, 270 IETF, SG11 BICC and SG16. 271 This interface is required for Voice over IP based services. 273 4. Requirements for In-Interaction with SIP based systems. 275 Functional requirements for the IN Interaction with SIP based 276 systems are listed below : 278 - Relationship of SSF and CCF to the enhanced functional entities 279 introduced in Distributed Functional Plane for IN to decompose the 280 SIP Proxy/Redirect Server (i.e. Call Control Function CCF(IP)). 282 - Mapping of SIP Registration and Call Signaling messages to INAP 283 operations. 285 - Exact set of SIP Registration functionality which needs to be 286 visible to IN (i.e. need to be monitored or manipulated), if any. 287 This includes the considerations on the kind of modeling required. 289 - Possible Separation of the SSF/CCF into different physical 290 entities. 292 - The use of multiple SSFs, where one SSF may model the SIP 293 Registration protocols and another SSF model the SIP Call Control 294 procedures requires consideration. These SSFs may be physically 295 distributed. 297 - The configuration of trigger conditions in the SSF, manage 298 trigger data from an SCP in the IN domain. 300 - The same CCF/SSF triggering mechanism applies to processing SIP 301 based IN-based call. SSF is located at Intelligent SIP 302 Proxy/Redirect Server to interact with SCP in IN domain. 304 - Mapping of the CCF(IP) to the CCF. 306 - For a GW originated IN-based call, the SIP registration server 307 and the SSF may be distributed in different Intelligent SIP 308 Proxy/Redirect Server entities. In this case, dynamic DP arming 309 SHOULD be supported at MGC under the control of Intelligent SIP 310 Server; 312 - The Definition of State Driven Events in the SIP Registration 313 and SIP Call Control Protocols in, there relationship to the CCF 314 functions. How these states map into the current IN BCSM models; all 315 require consideration. 317 - The SCF will be able to select one or more appropriate SSF/ 318 Intelligent SIP Proxy/Redirect servers dependant on different 319 parameters (class of service requested by the user, placement of 320 gateways, tariff, etc.). The SC-GF will be able to perform correct 321 lower layer protocol and address translation functions. 323 User Interaction requirements for the IN Interaction with SIP Based 324 systems are listed below : 326 - Intelligent SIP Proxy/Redirect Server enhancements for user 327 interaction (e.g.: does it provide control of speech path connection 328 and information on tones and announcements). 330 - The user interaction with SIP User Agent at the terminal may 331 be realized through a SIP Registration interface. The user 332 interaction with PSTN user is realized using MGC relay mode. The 333 information exchange path is Intelligent SIP Proxy/Redirect Server 334 to GW interface SIP 336 - The SIP Registration interface may be modified to support user 337 interaction information exchange. A SIP Registration interface 338 between Intelligent SIP Proxy/Redirect Server and SIP terminal could 339 be upgraded to support call-unrelated user access service. 341 The user interaction enhancements will be treated into a separate 342 draft RFC. 344 5. The SIP-IN Protocol Architecture. 346 5.1 Introduction 348 The SIP architecture has the following functional elements defined 349 in [4]: 351 - User agent client: The SIP functional entity that initiates a 352 request. 354 - User agent server: The SIP functional entity that terminates a 355 request by sending 0 or more provisional SIP responses and one final 356 SIP response. 358 - Proxy server: An intermediary SIP entity that can act as both a 359 UAS and a UAC. Acting as a UAS, it accepts requests from UACs, re- 360 writes the R-URI,and,acting as a UAC, proxies the request to a 361 downstream UAS. Proxies may retain significant call control state by 362 inserting them-selves in future SIP transactions beyond the initial 363 INVITE. 365 - Redirect server: An intermediary SIP entity that redirects callers 366 to alternate locations, after possibly consulting a location server 367 to determine the exact location of the callee (as specified in the 368 R-URI) 370 - Registrar: An SIP entity that accepts SIP REGISTER requests and 371 maintains a binding from a high-level URL to the exact location for 372 a user. This information is saved in some data-store that is also 373 accessible to a SIP Proxy and a SIP Redirect server. A Registrar is 374 usually co-located with a SIP Proxy or a SIP Redirect server. 376 - Outbound proxy: An SIP proxy that is located near the originator 377 of requests. It receives all outgoing requests from a particular 378 UAC, including those requests whose Request-URLs identify a host 379 other than the outbound proxy. The outbound proxy sends these 380 requests, after any local processing, to the address indicated in 381 the Request-URI. 383 This section provides information flows that illustrate an overview 384 of the interaction of SIP and IN capabilities. In particular it 385 provides a proposal for the triggering of 386 IN services as well as a mapping between the IN call states and 387 related Session Initiation Protocol (SIP) call states. 389 An overall objective is to ensure that IN control of VoIP services 390 in networks can be readily specified and implemented by adapting 391 standards and software used in the present networks. This approach 392 leads to services that function the same when a user connect to 393 present or future networks, simplifies service evolution from 394 present to future, and leads to more rapid implementation. 396 This section investigates the possibility of IN service control 397 based on the SIP proxy Server approach. This means that a locally 398 configured proxy server is required for outgoing calls that require 399 legacy service support based on existing IN services. Subsequent 400 sections will specify the interworking protocol based on the defined 401 SIP-IN Protocol architecture in this section 403 The section is organized as follows: Section 5.2 outlines the 404 proposed functional protocol architecture for the support of SIP-IN 405 interaction. Section 5.3 briefly describes the concepts for IN 406 service triggering based on IN Subscription Information. 408 5.2. SIP-IN Functional Protocol Architecture 410 The Figure 2 specifies the IP/IN proposed architecture based on the 411 IETF IP architecture. 413 +------------------------------+ 414 | +--------------+ | 415 | +-------+ |+-----------+ | | 416 | |SCF/SDFo----oSSF(IP) | | | 417 | +-------+ |+-----o-----+ | | 418 | | | | | 419 | |+-----o-----+ | | 420 | ||CCF(IP) | | | 421 | Intelligent |+-----o-----+ | | 422 | Network | | | | 423 | Protocol | | | | 424 | +------|-------+ | 425 +--------------------|---------+ 426 | 427 +------o----+ 428 | SIP/SDP | 429 +-----------+ 430 / \ 431 +-------+ +---------+ 432 | TCP | | UDP | 433 +-------+ +---------+ 434 / \ 435 +----------------------+ 436 | IP v4, IP v6 | 437 +----------------------+ 439 Figure 2: IETF IP/IN proposed Architecture 441 The SIP-IN functional protocol architecture at the network level is 442 given in Figure 3. 444 +-------+ +-------+ 445 | SCF | | SDF | 446 +---o---+ +---o---+ 447 | | 448 +-----+-----------+ 449 | 450 **********|*********************************** 451 * +-------|-------------------+ * 452 * |+------o------+ | * 453 * || SSF(IP) | | * 454 * |+-------------+ | * 455 * || CCF(IP) | | * 456 * |+------o------+ | * 457 * +-------|-------------------+ * 458 * | Extended * 459 * +-------o-------------------+ SIP * 460 * | SIP Server | Server * 461 * +---o---------o---------o---+ * 462 ******|*********|*********|******************* 463 | | | 464 (^^^^) +---+ +----o----+ +---+ (^^^^) 465 ( ) | | SIP | | ( ) 466 ( +-----o-+ |Terminal | (^^^^ ) 467 ( |Gateway| +---------+ ( Packet ) 468 ( +-------+ ( Network ) 469 ( ) ( +--------+ 470 ( SCN ) ( |Terminal| 471 (......) (....+--------+ 473 Figure 3: Proposed functional protocol Architecture for SIP-IN 474 interaction. 476 5.3 Basic concepts for In service triggering 478 The following assumptions are made concerning the SIP-IN functional 479 protocol architecture control flows. 481 (i) All the call flows show that the SIP Proxy Server and the SSF 482 have been co-located in order to avoid showing information 483 flows between the two entities. Standardisation of the 484 messages for this interface is for further study. 486 (ii) Originating and terminating SIP Proxy servers MUST operate in 487 a call-state aware mode. 489 (iii) As registration with a SIP Proxy server is not mandatory, it 490 shall be possible to determine whether a registration exists 491 for that particular subscriber when a subscriber places an 492 incoming call. This allows the subscriber data information to 493 be fetched from the home SDF if the subscriber is not 494 registered. (Note: Absence of the originating subscriber data 495 does not necessarily mean that the user is not registered, 496 merely that the originating subscriber data may not exist for 497 that subscriber). 499 (iv) The information flows make no consideration for inter-working 500 with other networks (e.g. PSTN via gateways) 502 6. Mapping examples of SIP message to the IN State Models 504 6.1 Mapping of SIP messages to the IN Basic Call State Models 506 This section deals with the Registration process and how the 507 Originating (O-BCSM) and Terminating (T-BCSM) Basic Call State Model 508 Points in Call (PICs) and Detection Points (DPs) or dynamic events 509 are mapped to the appropriate SIP messages. 511 Although a mapping is possible, there is not always the same analogy 512 between the circuit switched environment that the BCSM were designed 513 for and the IP environment, and as a result a direct mapping is not 514 always possible. 515 The state models for the INAP O-BCSM and the T-BCSM are based on the 516 INAP CS 3. 517 The mapping examples given in this section allow for an initial 518 inside of how the detailed IN state models operate. Detailed mapping 519 examples are provided in Annex A of this RFC draft. 521 6.2 Registration process 522 This section is intended to define the registration process based on 523 the SIP REGISTER message, which allows subscription of information 524 to be stored in the SIP Server/SSF. 526 IETF RFC 2543 [x]defines the term Registrar for registration 527 purposes and it is the SIP registrar that accepts the REGISTER 528 method.. With the SIP REGISTER method, it is assumed that 529 registration with a location server takes place. 531 The users who wish to receive incoming calls need to register with a 532 SIP Proxy server and a location server. Callers placing calls are 533 not required to register. 535 6.3 Mapping to Originating BCSM for Originating calls 537 The mapping between the SIP methods and responses for O-BCSM 538 relating to Originating Calls is shown in Figure 4. Only the 539 successful case is described. 541 {1} The Calling User Agent Client initiates a SIP request by 542 issuing an INVITE method to the SIP Proxy server. 544 {2} The INVITE message arrives at the proxy server, indicating that 545 the subscriber has requested to set up a call. The SIP Proxy server 546 determines if Originating subscriber exists for this user. The 547 SDF/LDAP functionality in the SIP Proxy is checked to determine if 548 the calling party has previously registered. If no registration is 549 found, then step {3} is followed. If the SSF determines that the 550 calling user has a valid registration then step {4} is followed. 552 {3} The SSF establishes a dialogue with the SDF or LDAP of the 553 subscriber's network. 555 {4} The originating subscriber data is analyzed and if the 556 necessary triggering criteria are met, the SCF is invoked via an 557 InitialDP message. The SCF can be invoked at either DP 558 Origination_Attempt or DP Origination Attempt_Authorised or DP 559 Collected_Information or DP Analysed_Information. 561 {5} Instructions are received from the SCF on how the call is to be 562 routed, together with which EDPs are armed. The state Send_Call 563 entered and the INVITE method is forwarded to the destination. 565 {6} A response `180 Ringing' indicates that the destination has 566 been alerted in session invitation. State O_Aleting is entered, DP 567 O_Term_Seized may be reported to the SCF and an `180 Ringing' is 568 sent to the originating party. 570 {7} A response `200 OK' indicates that the destination has accepted 571 in session invitation, indicating that a session has been 572 established. State O_Active is entered, DP O_Active may be reported 573 to the SCF and an ACK is sent to the originating party. 575 (8) Either party may release the call with a BYE method. On receipt 576 of the BYE, transition to the PIC O_Null takes place and the DP 577 O_Disconnect may be reported to the SCF. 579 +-----------+ +--------+ +-----------+ 580 |Originating| |Extended| |Terminating| 581 | UAC | |Proxy | UAS | 582 +-----------+ +--------+ +-----------+ 583 | | | 584 | INVITE [2] [3] | 585 1 o--------------->o | 586 | | [4] | +-----------------+ 587 | o-------------------------| O_Null | 588 | | | +--------o--------+ 589 | | | | 590 | | | +--------o--------+ 591 | | | | Authorize_ | 592 | | | | Origination_ | 593 | | | | Attempt | 594 | | | +--------o--------+| 595 | | | | 596 | | | +--------o--------+ 597 | | | | Collect_ | 598 | | | | Information | 599 | | | +--------o--------+ 600 | | | | 601 | | | +--------o--------+ 602 | | | | Analyse_ | 603 | | | | Information | 604 | | | +--------o--------+ 605 | | | | 606 | | | +--------o--------+ 607 | | | | Select_Route | 608 | | | +--------o--------+| 609 | | | | 610 | | | +--------o--------+ 611 | | | | Authorise_ | 612 | | | | Call_Setup | 613 | | | +--------o--------+ 614 | | | | 615 | | [5] | +-----------------+ 616 | o-------------------------| Send_Call | 617 | | INVITE | +--------o--------+ 618 | |------------->| | 619 | | 180 Ringing | | 620 | 180 Ringing |<-------------| | 621 |<---------------| [6] | +--------o--------+ 622 | o-------------------------| O_Alerting | 623 | | | +--------o--------+ 624 | | 200 OK | | 625 | 200 OK |<-------------| | 626 |<---------------| [7] | +--------o--------+ 627 | o-------------------------| O_Active | 628 | | | +--------o--------+ 629 | | BYE | | 630 | BYE |<-------------| | 631 |<---------------| [8] | +--------o--------+ 632 | o-------------------------| O_Null | 633 | | | +--------o--------+ 635 Figure 4: Mapping to O-BCSM and corresponding PICs for 636 Successful Originating calls 638 6.4 Mapping to Terminating BCSM for successful terminating calls 640 The mapping between the SIP methods and responses for T-BCSM to 641 Terminating Calls is shown in Figure 5. The information flows for 642 the successful case are described below: 644 {1} When the INVITE method arrives at the destination SIP Proxy 645 server, the server SSF shall determine if a Terminating Subscriber 646 data exists for the called user 648 {2} If the terminating subscriber data exists it shall be analyzed 649 and if the necessary triggering criteria are met, the SCF is invoked 650 )by establishing a dialogue and e.g. by sending an InitialDP message 651 between the SSF and SCF. The SCF can be invoked either at DP 652 Termination_Attempt or DP Termination_Attempt_Authorized. 653 Transition to state Select_Facility occurs and DP 654 Facility_Selected_and_Available may be reported. The INVITE will be 655 sent during the Present_Call PIC. 657 {3} Call alerts the terminating parting. DP Call_accepted may be 658 reported to the SCF, the state T_Alerting is entered. 660 {4} Call answered by the terminating party. DP T_Answer may be 661 reported to the SCF, state T_Active entered. 663 {5} Either party may terminate the call by sending a BYE and 664 transition to PIC T_Null takes place and the DP T_Disconnect may be 665 reported. 667 +-----------+ +--------+ +-----------+ 668 |Originating| |Extended| |Terminating| 669 | UAC | |Proxy | UAS | 670 +-----------+ +--------+ +-----------+ 671 | | | 672 | INVITE [1] [2] | +-----------------+ 673 o--------------->o-------------------------| T_Null | 674 | | | +--------o--------+ 675 | | | | 676 | 100 Trying | | +--------o--------+ 677 |<---------------o | | Authorize_ | 678 | | | | Termination_ | 679 | | | | Attempt | 680 | | | +--------o--------+| 681 | | | | 682 | | | +--------o--------+ 683 | |[2} | | Select_ | 684 | o-------------------------| Facility | 685 | | | +--------o--------+ 686 | | | | 687 | | [2] | +-----------------+ 688 | o-------------------------| Present_Call | 689 | | INVITE | +--------o--------+ 690 | |------------->| | 691 | | 180 Ringing | | 692 | 180 Ringing |<-------------| | 693 |<---------------| [3] | +--------o--------+ 694 | o-------------------------| T_Alerting | 695 | | | +--------o--------+ 696 | | 200 OK | | 697 | 200 OK |<-------------| | 698 |<---------------| [4] | +--------o--------+ 699 | o-------------------------| T_Active | 700 | | | +--------o--------+ 701 | | BYE | | 702 | BYE |<-------------| | 703 |<---------------| [5] | +--------o--------+ 704 | o-------------------------| T_Null | 705 | | | +--------o--------+ 707 Figure 5: Mapping to O-BCSM for Successful Originating calls 709 6.5 Mapping to Terminating BCSM for unsuccessful terminating calls 711 This subsection explores the mapping and the reporting of the DPs 712 that may be encountered when the call is not successfully 713 established. The information flows are shown in Figure 6 and is 714 further explained below: 716 {1} INVITE method arrives at the destination SIP proxy server. 717 Server/SSF determines if the Terminating subscriber data exists for 718 the called user. 720 {2} Terminating subscriber data is analysed and if necessary 721 triggering criteria are met, SCF is invoked. Transition to state 722 Present_Call PIC and an INVITE is sent to the terminating 723 subscriber. 725 {3} The destination does not accept the incoming call _ reason 726 response may be any value in 4xx response range. The mapping of 727 client error codes (4xx) to the possible Detection Points in PIC 728 Terminating_Call_Handling is performed. For example, DP T_Busy can 729 be mapped onto ' 486 Busy' . The mapping of the various DP's such 730 as T_Abandon , T_No_Answer ect. onto the error codes are specified 731 in the section 8. 733 +-----------+ +--------+ +-----------+ 734 |Originating| |Extended| |Terminating| 735 | UAC | |Proxy | UAS | 736 +-----------+ +--------+ +-----------+ 737 | | | 738 | INVITE [1] | +-----------------+ 739 o--------------->o-------------------------| T_Null | 740 | | | +--------o--------+ 741 | | | | 742 | 100 Trying | | +--------o--------+ 743 |<---------------o | | Authorize_ | 744 | | | | Termination_ | 745 | | | | Attempt | 746 | | | +--------o--------+| 747 | | | | 748 | | | +--------o--------+ 749 | | | | Select_ | 750 | | | | Facility | 751 | | | +--------o--------+ 752 | | | | 753 | | [2] | +-----------------+ 754 | o-------------------------| Present_Call | 755 | | INVITE | +--------o--------+ 756 | |------------->| | 757 | |4xx Error Code| | 758 | 4xx Error Code |<-------------| | 759 |<---------------| [3] | +--------o--------+ 760 | o-------------------------| T_Null | 761 | | | +--------o--------+ 763 Figure 6: Mapping to T-BCSM for Unsuccessful Terminating calls 765 7. Call State Mapping 767 NOTE: 768 This section is based on the information contained in [3] and has 769 been extended as follows: 771 i) the distinction between 100 Trying, 181 Call Is Being Forwarded, 772 182 Queued and 183 Session Progress has been handled 774 ii) the mapping to the IN Abstract Signalling Primitive conventions 775 has been given. 777 iii) the IN half call concept has been applied. 779 The mapping of the PIC's (Points In Call)and the DP (Detection 780 Point) of the IN call model into SIP can be easily translated for IN 781 services that have a "query-response" like freephone, originating 782 call screening, caller name identification. 784 IN states will be mapped to the appropriate SIP methods or response 785 codes. While mapping call states from SIP to IN, it is important to 786 note that there will not be a 1-to-1 mapping between IN call states 787 and SIP states. 789 7.1 SIP and O_BCSM 791 The PICs of O_BCSM come into play when a call request SIP INVITE 792 message arrives from a SIP UAC to an SIP server running 793 the IN Originating call model. This SIP proxy will create a O_BCSM 794 object and initialize it into the O_NULL PIC. 796 In the AUTH_ORIG_ATT PIC, a SIP proxy running the IN call model has 797 detected that someone wishes to make a call. Under some 798 circumstances (e.g. the user is not allowed to make calls during 799 certain hours), such a call cannot be placed. SIP has the ability 800 to authorize the calling party using a set of policy directives 801 configured by the SIP administrator. If the calling party is 802 authorized to place the call, the BCSM transits to the next PIC, 803 COLLECT_INFO. 805 This COLLECT_INFO PIC is responsible for collecting a dial string 806 from the calling party. The SIP proxy can detect an incomplete 807 address (e.g. by inter digit timeout or by digit analysis) and may 808 send to the calling party a "484 Address Incomplete" message and 809 remain in this state until a valid "dial string" is received via a 810 subsequent INVITE method. This INVITE contains the same "From" and 811 "Call-ID" headers. The "To" field is updated to reflect the entire 812 called number as known so far. Since the "To" field is different, 813 this INVITE represents a different transaction than the initial 814 INVITE; consequently, there is no relationship between the CSeq 815 values in the two INVITE messages. 817 Once it has obtained a valid dial string, the BCSM transits to the 818 next PIC, ANALYZE_INFO. 820 The ANALYZE_INFO PIC can either generate the 100 TRYING if the 821 analyzed information function has been performed successfully, or 822 like the COLLECT_INFO PIC, it may also cause the SIP proxy to send a 823 _484 Address Incomplete_ response (e.g. by inter digit timeout or by 824 digit analysis) and remain in this state until a valid "dial string' 825 is received via a subsequent INVITE method. 827 This PIC is ultimately responsible for translating the dial string 828 to a routing number. Many IN services such as freephone, LNP, OCS, 829 etc. are triggered from DP's associated with this PIC. The SIP 830 proxy can send the SIP URI in the To: field to the IN layer to have 831 it analyzed. If the analysis succeeds, the BCSM transits to the 832 next PIC, SELECT_ROUTE. 834 The next PIC encountered is SELECT_ROUTE. In the circuit-switched 835 network, the actual physical route has to be selected at this point. 837 The SIP analogue of this would be to determine the next hop SIP 838 server. The next hop SIP server could be chosen by a variety of 839 means. For instance, if the Request URI in the incoming INVITE 840 request is an E.164 number, the SIP proxy can use a protocol like 841 TRIP to find the best gateway to egress the request onto the GSTN. 843 The AUTH_CALL_SETUP PIC is used for certain service features to 844 restrict the type of call that may originate on a given line or 845 trunk. This PIC is the point at which relevant restrictions are 846 examined. 848 If the above PICs have been successfully negotiated, the SIP proxy 849 running the IN call model now sends the Setup.Req.Ind Abstract 850 Signalling Primitive to the T_BCSM. This will lead to the eventual 851 processing of the SIP INVITE message at the next hop server. The 852 next PIC, SENT_CALL is now entered. In IN terms, the control over 853 the establishment of the call has been transferred to the T_BCSM 854 object, and the O_BCSM object is waiting for a signal confirming 855 that either the call has been presented to the called party or that 856 the called party cannot be reached for a particular reason. If in 857 the SENT_CALL PIC a _181 Call Is Being Forwarded_, a _182 Queued_, a 858 _183 Session Progress_, or a _100 Trying_ message is received, 859 control stays in this PIC. 861 When the SIP proxy running the IN call layer gets back a "180 862 Ringing" for the call, it instructs the BCSM to transit to the next 863 PIC, O_ALERTING. At this point, O_BCSM is waiting for the called 864 party to answer. 866 Assuming the called party answers, the SIP proxy running the IN 867 layer receives a "200 OK". The receipt of this message is followed 868 by the SIP proxy instructing the BCSM to transit to the next PIC, 869 O_ACTIVE. The call is now active. 871 When either of the party hangs up, the SIP proxy running the IN call 872 layer receives a SIP BYE message. Since it is running in call- 873 stateful mode, it can correlate the BYE message with the call that 874 needs to be torn down. The SIP server instructs the BCSM to transit 875 to O_DISCONNECT DP and perform cleanup. Subsequently, the state of 876 the call in the SIP server itself is also destroyed. 878 Figure 7 below provides a the mapping from the SIP server protocol 879 state machine to the originating half of the IN call model. 881 SIP O_BCSM 883 +-----------------+ 884 (1) ===============>| O_NULL PIC | 885 +--------o--------+ 886 | 887 +--------V--------+ 888 (2) <===============| AUTH_ORIG_ATT | 889 | PIC | 890 +--------o--------+ 891 | 892 +--------V--------+ 893 (3) <==============>| COLLECT_INFO PIC| 894 +--------o--------+ 895 | 896 +--------V--------+ 897 (4) <===============| ANALYSE_INFO PIC| 898 (5) <==============>| | 899 +--------o--------+ 900 | 901 +--------V--------+ 902 | SELECT_ROUTE PIC| 903 +--------o--------+ 904 | 905 +--------V--------+ 906 | AUTH_CALL_SETUP | 907 | PIC | 908 +--------+--------+ 909 | 910 +--------V--------+ 911 (6) <===============| SENT_CALL PIC |------->+---------+ 912 | |-----+ |O_Called_| 913 +--------o--------+ | |Party_ | 914 (10) <========================|==============|==|BusyDP | 915 | +-|->+---------+ 916 +--------V--------+ | | 917 (7) <===============| O_ALERTING PIC |---+ +->+---------+ 918 | |------->|O_No_ _| 919 +--------o--------+ |AnswerDP | 920 (11) <========================|=================| | 921 | +---------+ 922 +--------V--------+ 923 (8) <===============| O_ACTIVE PIC | 924 (9) ===============>| | 925 (12) ===============>| | 926 +-o------o--+----++ 927 (16) <=================|======|==| | O_Re-AnswerDP 928 | | +---+ 929 +--------+ | | ^ 930 (13) ===>|O_Discon|<---+ | | 931 (14) <===|nectDP |<---+ | | 932 +---- ---+ | +-V--+ | 933 (15) <=================|====| | | O_SuspendDP 934 +-o--- +----+-o---+ 935 (8) <===============| O_SUSPENDED PIC | 936 (9) ===============>| | 937 (12) ===============>| | 938 +-----------------+ 939 Legend: 940 | Communication between 941 | states 942 V 944 ======> Communication between IN layer and SIP 946 Figure 7: Mapping of the SIP methods to O_BCSM 948 Note: ABANDON should be included 949 The following mapping to the IN Abstract Signalling Primitive 950 conventions and call signalling indications applies: 952 (1) An Indication is sent from Ingress Server/User to O_BCSM to 953 initiate call establishment (e.g. Setup.Ind Abstract Signalling 954 Primitive mapped from a INVITE method). 955 (2) An Indication is sent from O_BCSM to Ingress Server/User that 956 network is unable to initiate call (e.g.Release.Req Abstract 957 Signalling Primitive mapped to 401 Unauthorised). 958 (3) The Ingress Server/User sends call (dialling) information to 959 the O_BCSM (e.g. SubsequentAddress Abstract Signalling Primitive 960 mapped from INVITE method as a result of receiving an 484 Address 961 Imcomplete from the O_BCSM). 962 (4) An Indication is sent from O_BCSM to the Ingress Server/User to 963 terminate the sending of call information (e.g. 964 CallProgress(Progress).Req Abstract Signalling Primitive mapped to 965 100 Trying). 966 (5) An Indication is sent from the Ingress Server/User to the 967 O_BCSM upon completion of call information (e.g. SubsequentAddress 968 Abstract Signalling Primitive mapped from INVITE method as a result 969 of receiving an 484 Address Imcomplete from the O_BCSM) 970 (6) Ingress Server/User is informed that call has been routed to 971 another environment of network (e.g. CallProgress(Progress).Req 972 Abstract Signalling Primitive mapped to either: a 181 Call Is Being 973 Forwarded; or a 182 Queued, or a 183 Session Progress message 974 (7) An Indication is sent from the O_BCSM to the Ingress 975 Server/User when the called party is being alerted (e.g. 976 CallProgress(Alert).Req Abstract Signalling Primitive mapped to a 977 180 RINGING). 978 (8) An Indication is sent from the O_BCSM to the Ingress 979 Server/User when the call is accepted. (e.g. Setup.Resp Abstract 980 Signalling Primitive is mapped to 200 OK) 981 (9) The Ingress Server/User acknowledges that the call is accepted. 982 (receipt of the ACK method) 983 (10) The O_BCSM sends an Indication to the Ingress Server/User that 984 the called party is unable to accept the call, due to busy 985 condition. (sending of the 484 Busy Here or 600 Busy Everywhere. 986 (11) The O_BCSM sends an Indication to the Ingress Server/User since 987 the called party is unable to accept the call, due to no answer 988 condition. (sending of the 480 Temporarily unavailable) 989 (12) An Indication is received by the O_BCSM from the Ingress 990 Server/User to end the call.( receipt of CANEL or BYE method) 991 (13) The O_BCSM indicates to the Ingress Server/User that the call 992 is being disconnected.(sending of BYE method) 993 (14) The Ingress Server/User acknowledges to the O_BCSM that the 994 call is being disconnected.(receipt of ACK) 996 (15) An Indication is sent to the Ingress Server/user when the 997 connection towards the Called Party is suspended. In SCN networks, 998 the user can generate a suspend (timer supervised)in order to unplug 999 the terminal from the socket and plug it in another one. 1000 When a network suspend arrives from the SCN, the server/MGC sends an 1001 INVITE towards the calling user in order to put the media stream on 1002 hold. 1004 (16) An Indication is sent to the Ingress Server/user when the 1005 connection towards the Called Party is reconnected. A resume is sent 1006 once the terminal has been reconnected and the timer has not expired 1007 this will be seen as an network resume. The reception of a resume 1008 triggers another INVITE toward the calling user/Ingress server that 1009 resumes the media stream. For the SIP UAC/UAS the result is an 1010 interruption in the voice path until the other party picks up the 1011 phone again. 1013 7.2. SIP and T_BCSM 1015 The T_BCSM object is created when the termination half call of the 1016 SIP server running the IN layer receives the Setup.Req.Ind Abstract 1017 Signalling Primitive from the O_BCSM. The SIP proxy initializes 1018 T_BCSM object it to the T_NULL PIC. 1020 The T BCSM transits to the next PIC, AUTH_TERM_ATT, during which the 1021 called party wishes that the present type of call is ascertained. 1022 IN services such as Called Line Identification and Call Forwarding 1023 are normally triggered from DPs associated with this PIC. 1025 Once a positive indication is received from the AUTH_TERM_ATT PIC, 1026 the BCSM transits to the next PIC, SELECT_FACILITY. The intent of 1027 this PIC, in traditional circuit networks, is to select a line or a 1028 trunk to reach the called party. In a hybrid (GSTN/IP) network, 1029 where the callee resides on the GSTN, a SIP proxy can use 1030 SELECT_FACILITY PIC to interface with a gateway and select a 1031 line/trunk to route the call. If a facility was thus successfully 1032 seized, the SIP INVITE request is deemed to be successful and 1033 control enters the next PIC, PRESENT_CALL. 1035 In a traditional circuit-switched network, PRESENT_CALL presents 1036 (via ISUP IAM or Q.931 Setup messages) the call to the called party. 1037 When the SIP proxy sends out the INVITE to the UAS, it instructs the 1038 BCSM to transit to this state. The BCSM will remain in this state 1039 until the SIP proxy gets back a "180 Ringing", whereupon it 1040 instructs the BCSM to enter the next state, T_ALERTING. 1042 T_ALERTING "alerts" the called party by ringing the phone. When the 1043 SIP proxy receives a "200 OK", it instructs the BCSM to enter the 1044 next PIC, T_ACTIVE. The call is now active. 1046 When either of the party hangs up, the SIP proxy running the IN call 1047 layer receives a SIP BYE message. Since it is running in call- 1048 stateful mode, it can correlate the BYE message with the call that 1049 needs to be torn down. The SIP proxy instructs the BCSM to transit 1050 to the next PIC, T_DISCONNECT and perform cleanup. Subsequently, 1051 the state of the call in the SIP proxy itself is also destroyed. 1053 Figure 8 below provides a visual mapping from the SIP server 1054 protocol state machine to the terminating half of the IN call model: 1056 SIP O_BCSM 1058 +-----------------+ 1059 | T_NULL PIC | 1060 +--------o--------+ 1061 | 1062 +--------V--------+ 1063 |AUTH_TERMINATION | 1064 +---| _ATTEMPT PIC |================> (1) 1065 | +--------o--------+ 1066 | | 1067 +---------+ | +--------V--------+ 1068 | |<--+ | SELECT_FACILITY | 1069 |T_BusyDP_| | PIC | 1070 | |<----+ +--------o--------+ 1071 +---------+ | | 1072 | +--------V--------+ 1073 | | PRESENT_CALL PIC|<===============> (1) to (6) 1074 +--|-| | 1075 | | +--------o--------+ 1076 | | | 1077 | | | 1078 +---------+ | | +--------V--------+ 1079 |T No_ |<-+ +-| T_ALERTING PIC | 1080 |AnswerDP |<------| |<================ (7) 1081 | | +--------o--------+ 1082 +---------+ | 1083 +--------V--------+ 1084 | T_ACTIVE PIC |================> (8) 1085 | |================> (11) 1086 | |--------+ 1087 ++---+---o--------+ | 1088 T_Re-AnswerDP | | |<================|======== (9) 1089 +---+ | | 1090 ^ | | 1091 |<====|========================== (10) 1092 | | | 1093 | +-V--+ | 1094 | | | T_SuspendDP | 1095 +--o-- +----+-o---+ +--V-----+ 1096 (8) <===============| T_SUSPENDED PIC | |T_Discon|<=======(13) 1097 (9) ===============>| |---->|nectDP |=======>(14) 1098 (12) ===============>| | +--------+ 1099 +-----------------+<======================(12) 1101 Legend: 1102 | Communication between 1103 | states 1104 V 1106 ======> Communication between IN layer and SIP 1108 Figure 8: Mapping of the SIP methods to T_BCSM 1110 T-Abandon should be included 1111 The following mapping to the IN Abstract Signalling Primitive 1112 conventions and call signalling indications applies: 1114 (1) An Indication is sent from T_BCSM to the Egress Server/User to 1115 terminate the call to an idle facility (e.g. Setup.Req Abstract 1116 Signalling Primitive mapped to the INVITE method). 1118 (2) An Indication is sent from Egress server/user to T_BCSM 1119 indicating that the Egress server/user cannot accept the call. 1120 (e.g. Release.Req Abstract Signalling Primitive mapped to BYE 1121 method). 1123 The called number can be received in just one INVITE method(`en 1124 bloc' signalling) or in one INVITE method followed by one or several 1125 INVITE's (overlap signalling). In some countries there is no way for 1126 the server to know whether the called party' number is already 1127 complete. 1128 If the server relies on the inter-digit time-out to assume that the 1129 number is complete, the establishment of the connection is delayed. 1130 Alternatively, if the server sends the INVITE request immediately 1131 after receiving the INVITE method, heavy signalling traffic may be 1132 generated. Therefore, an individual server might implement a timer 1133 and/or a stop digit (such as #). All the digits that arrive before 1134 this timer expires will be included in the INVITE sent. The timer 1135 can be bypassed by the user sending the stop digit. This timer 1136 SHOULD not be larger than 5 seconds. 1138 The following signalling indications (3) to (5) treat the case of 1139 overlap based on the following procedures. 1141 (3) An indication is sent from the T_BCSM to forward any remaining 1142 call information to the Egress server/user (e.g. by means of INVITE 1143 request and 484 Address Incomplete responses). Thus, after 1144 receiving the INVITE and possibly one or several INVITE's, the 1145 server issues an INVITE request towards the called user. The "To" 1146 field contains the digits received so far. If, after sending this 1147 INVITE request, one or more INVITE's are received, the server sends 1148 a new INVITE to the called user. This new INVITE has the same "From" 1149 and "Call-ID" as the previous INVITE sent. The "To" field is 1150 updated and contains all the available digits.`484 Address 1151 Incomplete' responses will be received for all the INVITE's sent 1152 with the incomplete called party number. Thus, all the call legs 1153 (same `Call-ID', different to) created while the digits are arriving 1154 MUST be deleted. 1156 (4) An Indication is sent from the T_BCSM to the Egress server/user 1157 upon the sending of sufficient call information. This can be done by 1158 including a stop digit into the INVITE method sent to the called 1159 user. 1161 (5) An Indication is sent from the Egress server/user to the T_BCSM 1162 upon receipt of sufficient call information (e.g. 1163 CallProgress(Progress).Ind Abstract Signalling Primitive 1164 SubsequentAddress Abstract Signalling Primitive mapped from 100 1165 Trying). 1166 If a provisional response different than 100 Trying arrives 1167 (typically a 183 Session Progress) the server SHOULD send all its 1168 subsequent INVITEs to the server that generated the response. This 1169 avoids in SIP bridging situations sending subsequent INVITEs to 1170 different gateways. This would generate several messages in the 1171 network for just one call (rather than a one initial address message 1172 followed by one or subsequent messages). Therefore, subsequent 1173 INVITE's would contain an updated To field, the same Call-ID and a 1174 Route header built with the Record-route and the Contact headers 1175 received in the provisional response. If two or more provisional 1176 response are received from a different location it means that the 1177 INVITE's generated reached different UAS's.The gateway SHOULD choose 1178 which UAS will handle the call and send a CANCEL specifically 1179 addressed to the rest of UAS's (Record-Route, Contact and tag in 1180 the To field). The server typically SHOULD choose the UAS that 1181 returned the provisional response to the INVITE that contained more 1182 digits 1184 (6) Egress server/user sends an Indication to the T_BCSM that 1185 alerting is taking place (e.g. CallProgress(Alert).Ind Abstract 1186 Signalling Primitive mapped from 180 RINGING). 1187 (7) An Indication is sent from the Egress server/user to the T_BCSM 1188 upon acceptance of the incoming call 1189 (e.g. Setup.Conf Abstract Signalling Primitive mapped from 200 OK). 1190 (8) An Indication is sent from the T_BCSM to the Egress server/user 1191 acknowledging that the call can now be connected. (ACK) 1192 (9) An Indication is sent from the Egress server/user to the T_BCSM 1193 that the Egress server/user suspends the call.15) This is an INVITE 1194 method with a media stream put on hold 1195 (10) An Indication is sent from the Egress server/user to the T_BCSM 1196 that the Egress server/user resumes the call. This is another INVITE 1197 method in order to resume a previous media stream which was put on 1198 hold 1199 (11) The T_BCSM sends an Indication to the Egress server/user 1200 indicating that the calling party has gone on-hook. This is the BYE 1201 method sent towards the user. 1202 (12) An Indication is received by the T_BCSM from the Egress 1203 server/user to end the call. This is a BYE method received from the 1204 user. 1205 (13) The T_BCSM indicates to the Egress server/user that the call is 1206 being disconnected. 1207 (14) The Egress server/user acknowledges to the T_BCSM that the call 1208 is being disconnected. 1210 7.3. Intra Server BCSM indications 1212 The following figure 9 illustrates the communication between two 1213 call segments in the CCF/SSF for a basic two-party call, as 1214 described in the CCF/SSF Model. It shows the indications that flow 1215 between the originating BCSM and terminating BCSM . All possible 1216 indications are shown, except for any which may occur at the O- 1217 Exception and the T-Exception PICs. Note that these indications are 1218 not intended to be mapped to explicit information flows. 1220 (1) Initiate T_BCSM after the authority to place the call has been 1221 verified. The O_BCSM is currently in the Send_Call PIC. The 1222 originating Basic Call Manager has sent the call attempt to the 1223 terminating Basic Call Manager for further processing, i.e. the 1224 Setup.Req.Ind Abstract Signalling Primitive is sent on the IBI from 1225 the O-BCSM to the T_BCSM. 1227 (2) An Indication is sent from the T_BCSM to O_BCSM that the 1228 terminating user is busy, i.e. the Release.Req.Ind Abstract 1229 Signalling Primitive is sent on the IBI from the T-BCSM to the 1230 O_BCSM. 1231 (Causes Send_Call PIC to O_Called_Party_Busy BCSM transition in 1232 O_BCSM.) 1234 (3) An Indication is sent from the T_BCSM to O_BCSM that the 1235 terminating user is busy, i.e. the Release.Req.Ind Abstract 1236 Signalling Primitive is sent on the IBI from the T-BCSM to the 1237 O_BCSM. 1238 (Causes O_Alerting PIC to O_Called_Party_Busy DP BCSM transition in 1239 O_BCSM.) 1241 (4) An Indication is sent from the T_BCSM to O_BCSM that the call 1242 can not be presented, i.e. the Release.Req.Ind Abstract Signalling 1243 Primitive is sent on the IBI from the T-BCSM to the O_BCSM. 1244 (Causes Send_Call PIC to Select_Route PIC, O_Called_Party_Busy DP, 1245 or O_No_Answer DP.) 1247 (5) An Indication is sent from the T_BCSM to the O_BCSM that an 1248 Called Party has signalled call acceptance with immediate BCSM 1249 transition to an answered condition,i.e. the Setup.Resp.Conf 1250 Abstract Signalling Primitive is sent on the IBI from the T-BCSM to 1251 the O_BCSM (causes Send_Call PIC to O_Answer DP BCSM transition in 1252 O_BCSM). 1254 (6) An Indication is sent from T_BCSM to O_BCSM that Called Party 1255 is being alerted i.e. the CallProgress(Alert).Req.Ind Abstract 1256 Signalling Primitive is sent on the IBI from the T-BCSM to the 1257 O_BCSM (causes O_BCSM to transit from Send_Call PIC O_Alerting PIC 1258 and prepare to send 180 RINGING response to the Calling Party). 1260 (7) An Indication is sent from T_BCSM to O_BCSM that Called Party 1261 has rejected the call, i.e. the Release.Req.Ind Abstract Signalling 1262 Primitive is sent on the IBI from the T-BCSM to the O_BCSM (this is 1263 indicated to the O_BCSM with a busy cause and causes O_BCSM to 1264 transit from O_Alerting PIC to Select_Route PIC or 1265 O_Called_Party_Busy DP). 1267 (8) An Indication is sent from T_BCSM to O_BCSM that Called Party 1268 has not answered within a specified time period, i.e. the 1269 Release.Req.Ind Abstract Signalling Primitive is sent on the IBI 1270 from the T_BCSM to the O_BCSM (causes O_Alerting PIC to O_No_Answer 1271 DP BCSM transition in O_BCSM). 1273 (9) An Indication is sent from the T_BCSM to the O_BCSM that called 1274 party has not answered within a specified time period, i.e. the 1275 Release.Req.Ind Abstract Signalling Primitive is sent on the IBI 1276 from the T_BCSM to the O_BCSM. (Causes Send_Call PIC to O_No_Answer 1277 DP BCSM transition in O_BCSM.). 1279 (10) An Indication is sent from T_BCSM to O_BCSM that Called Party 1280 has accepted and answered the call attempt, i.e. the Setup.Resp.Conf 1281 Abstract Signalling Primitive is sent on the IBI from the T_BCSM to 1282 the O_BCSM (causes O_Alerting PIC to O_Answer DP BCSM transition in 1283 O_BCSM). 1285 (11) An Indication is sent from the T_BCSM to the O_BCSM that the 1286 called party has accepted and answered the call attempt, i.e. the 1287 Setup.Resp.Conf Abstract Signalling Primitive is sent on the IBI 1288 from the T-BCSM to the O_BCSM. (Causes Send_Call PIC to O_Answer DP 1289 BCSM transition in O_BCSM.) 1291 (12) An Indication is sent from T_BCSM to O_BCSM that Called Party 1292 has disconnected, i.e. the NetworkSuspend.Req.Ind Abstract 1293 Signalling Primitive is sent on the IBI from the T_BCSM to the 1294 O_BCSM (e.g. on-hook), (causes O_Active PIC to O_Suspend DP BCSM 1295 transition in O_BCSM). 1296 (13) An Indication is sent from T_BCSM to O_BCSM that Called Party 1297 re-answers is received before the timer expires , i.e. the 1298 NetworkResume.Req.Ind Abstract Signalling Primitive is sent on the 1299 IBI from the T-BCSM to the O_BCSM (causes O_Suspended PIC to 1300 O_Re_Answer DP BCSM transition in O_BCSM). 1302 (14) An Indication is sent from O_BCSM to T_BCSM that Calling Party 1303 has disconnected, i.e. the Release.Req.Ind Abstract Signalling 1304 Primitive is sent on the IBI from the O_BCSM to the T_BCSM, while 1305 T_BCSM was in T_Active PIC (causes T_Active PIC to T_Disconnect DP 1306 BCSM transition in T_BCSM). 1308 (15) An Indication is sent from O_BCSM to T_BCSM that Calling Party 1309 has disconnected, , i.e. the Release.Req.Ind Abstract Signalling 1310 Primitive is sent on the IBI from the O_BCSM to the T_BCSM, while 1311 T_BCSM was in T_Suspended PIC (causes T_Suspended PIC to 1312 T_Disconnect DP BCSM transition in T_BCSM). 1314 (16) An Indication is sent from T_BCSM to O_BCSM that Called Party 1315 has disconnected, i.e. the Release.Req.Ind Abstract Signalling 1316 Primitive is sent on the IBI from the T_BCSM to the O_BCSM, (causes 1317 O_Suspended PIC to O_Disconnect DP BCSM transition in O_BCSM). 1319 (17) An Indication is sent from the T_BCSM (T_Disconnect DP) to 1320 O_BCSM that the called party has disconnected, i.e. the 1321 Release.Req.Ind Abstract Signalling Primitive is sent on the IBI 1322 from the T_BCSM to the O_BCSM,. (Causes O_Active PIC to O_Disconnect 1323 DP BCSM transition in O_BCSM.). 1325 (18) An Indication is sent from O_BCSM to T_BCSM that Calling Party 1326 has abandoned, i.e. the Release.Req.Ind Abstract Signalling 1327 Primitive is sent on the IBI from the O_BCSM to the T_BCSM, (causes 1328 Authorize_Termination_Attempt PIC, Select_Facility PIC, Present_Call 1329 PIC or T_Alerting PIC to T_Abandoned DP BCSM transition in T_BCSM). 1331 NOTE: 1333 i) Indications (14) and (16) are mutually exclusive: 1335 ii) All indications are for intra-switch; 1337 iii) The indications do not explicitly include the modelling of 1338 SRFs; 1340 iv) Indications which are preceded by a DP may be affected 1341 depending on whether the DP is active and the SCF response. 1343 ********************************* 1344 * Figure to be provided * 1345 ********************************* 1347 Figure 9: Intra Server BCSM Indications 1349 7.5. Mapping of 4xx _ 6xx responses in SIP to IN Detections Points 1351 The mapping of error codes (4xx) _ 6xx responses in SIP to the 1352 possible Detection Points in PIC Originating and Terminating Call 1353 Handling is indicated in the table below. 1355 Response received from SIP DP mapping to IN 1356 ----------------- ---------------------- 1357 400 Bad request Route_Select_Failure or T_Exception 1358 401 Unauthorized Origination_Attempt_Denied or 1359 Termination_Attempt_Denied 1360 402 Payment required Route_Select_Failure or T_Exception 1361 403 Forbidden Route_Select_Failure or T_Exception 1362 404 Not found Route_Select_Failure or T_Exception 1363 405 Method not allowed Route_Select_Failure or T_Exception 1364 406 Not acceptable Route_Select_Failure or T_Exception 1365 407 Proxy authentication Origination_Attempt_Denied or 1366 required Termination_Attempt_Denied 1367 408 Request timeout O_Exeption or T_Exception 1368 409 Conflict Route_Select_Failure or T_Exception 1369 410 Gone Route_Select_Failure or T_Exception 1370 411 Length required Route_Select_Failure or T_Exception 1371 413 Request Entity too long Route_Select_Failure or T_Exception 1372 414 Request-URI too long Route_Select_Failure or T_Exception 1373 415 Unsupported media type Route_Select_Failure or T_Exception 1374 420 Bad extension Route_Select_Failure or T_Exception 1375 480 Temporarily unavailable O_No_Answer or T_No_Answer 1376 481 Call leg/transaction 1377 doesn't exist Route_Select_Failure or T_Exception 1378 482 Loop detected Route_Select_Failure or T_Exception 1379 483 Too many hoops Route_Select_Failure or T_Exception 1380 484 Address incomplete see Section 7 1381 485 Ambiguous Route_Select_Failure or T_Exception 1382 486 Busy here O_Called_Party_Busy or T_Busy 1383 500 Server internal error Route_Select_Failure or T_Exception 1384 501 Not implemented Route_Select_Failure or T_Exception 1385 502 Bad gateway Route_Select_Failure or T_Exception 1386 503 Service unavailable Route_Select_Failure or T_Exception 1387 504 Gateway time-out O_Exception or T_Exception 1388 505 Version not supported Route_Select_Failure or T_Exception 1389 600 Busy everywhere O_Called_Party_Busy or T_Busy 1390 603 Decline Route_Select_Failure or T_Exception 1392 Note: further study required on the mapping one other possibility 1393 could be to map this to O_No_Answer or T_No_Answer 1394 604 Does not exist anywhere Route_Select_Failure or T_Exception 1395 606 Not acceptable Route_Select_Failure or T_Exception 1397 The mapping of the error response received from SIP to the cause 1398 values of IN based on the ITU-T Q.850 Recommendation is as follows. 1400 Response received from SIP Cause value mapping to IN 1401 ----------------- ---------------------- 1402 400 Bad request 127 Interworking 1403 401 Unauthorized 21 Call rejected 1404 402 Payment required 21 Call rejected 1405 403 Forbidden 1 Unallocated number 1406 404 Not found 1 Unallocated number 1407 405 Method not allowed 63 Service/option 1408 unavailable 1409 406 Not acceptable 79 Service/option not 1410 implemented 1411 407 Proxy authentication required 21 Call rejected 1412 408 Request timeout 102 Recovery on timer expiry 1413 409 Conflict 48 Temporary failure 1414 410 Gone 22 Number changed 1415 411 Length required 127 Interworking 1416 413 Request Entity too long 127 Interworking 1417 414 Request-URI too long 127 Interworking 1418 415 Unsupported media type 79 Service/option not 1419 implemented 1420 420 Bad extension 127 Interworking 1421 480 Temporarily unavailable 18 No user responding 1422 480 Temporarily unavailable 20 Subscriber absent 1423 481 Call leg/transaction doesn't exist 127 Interworking 1424 482 Loop detected 127 Interworking 1425 483 Too many hoops 25 Exchange-routing error 1426 484 Address incomplete 28 Invalid Number Format 1427 485 Ambiguous 1 Unallocated number 1428 486 Busy here 17 User busy 1429 500 Server internal error 41 Temporary failure 1430 501 Not implemented 38 Network out of order 1431 502 Bad gateway 38 Network out of order 1432 503 Service unavailable 41 Temporary failure 1433 504 Gateway time-out 102 Recovery on timer expiry 1434 505 Version not supported 127 Interworking 1435 600 Busy everywhere 17 User busy 1436 603 Decline 21 Call rejected 1437 604 Does not exist anywhere 1 Unallocated number 1438 606 Not acceptable 38 Network out of order 1440 The mapping of error codes (4xx) _ 6xx received in SIP to the 1441 possible Detection Points in PIC Originating and Terminating Call 1442 Handling is performed as indicated in the mapping from cause to DP 1443 section of the CS3 Core INAP specification ETSI DEN/SPAN-03063-1.2 1444 section 6.3.5 of the SCF-SSF Interface based on the above table. 1446 7.6. Support of mid-call signalling 1448 Pure SIP does not have any provision for carrying any mid-call 1449 control information that is generated during. The INFO method SHOULD 1450 be used for this purpose. Draft-ietf-sip-info-method-04.txt. 1452 Further input will be provided on this topic. 1454 8. Protocol Procedures 1456 Topics to be provide are: 1458 8.1. Mapping of SIP messages containing: 1460 * Methods (how is the Sip OPTIONS method supported) 1461 * 1xx Information messages 1462 * 2xx OK 1463 * 3xx Redirection 1464 * 4xx Messages (integration of section 7.4 with further protocol 1465 details) 1466 * 5xx Messages (integration of section 7.4 with further protocol 1467 details) 1468 * 6xx Global Failures (integration of section 7.4 with further 1469 protocol details) 1471 8.2. Mapping of SIP URLs 1473 8.3. Mapping of media stream descriptions 1475 8.4. SIP call Forking in Multi-Party Calls 1477 8.5. Third Party Call Control 1479 8.6. Call Transfer 1481 9. Security Considerations 1483 Security is a general property which relates to safe and reliable 1484 operation. The high level requirements of a secure system are: 1486 i) Confidentiality: 1488 This is defined in ITU-T Recommendation X.800 as < the avoidance of 1489 the disclosure of information without the permission of its owner >. 1490 Thus, confidentiality may be considered as a property which ensures 1491 that conversations or interactions remain private. 1493 ii) Integrity: 1495 This is defined in ITU-T Recommendation X.800 as . 1497 Integrity may then be considered as a property which ensures that 1498 operations occur as they are expected to. 1500 iii) Availability: 1502 This may be considered as a property relating to the readiness of 1503 resources for authorized use. 1505 iv) Accountability: 1507 This may be considered as a property which ensures that any 1508 operational request can be correctly attributed in case of doubt or 1509 dispute. 1511 The components of an IN system MUST be assembled and operated in 1512 such a way as to provide a defined level of security. 1514 To assist in this, any interface within the IN functional 1515 architecture may have the need to apply security assisting functions 1516 to the information flows passing across the interface such as: 1518 i) Network access security functions : 1520 This includes user/terminal authentication (i.e. the result of a 1521 process by which a service user proves his or her identity to an IN 1522 system), user profile verification (i.e. the verification that a 1523 user is authorised to use a functionality). 1525 ii) Internetworking security functions: 1527 This includes peer entity authentication (i.e., a process which 1528 allows a communicating entity to prove its identity to another 1529 entity in the network), signalling data or TMN data integrity, non- 1530 repudiation, confidentiality, entity profile verification (i.e. the 1531 verification that an entity is authorised to use a functionality). 1533 A. Best Current Practice for SIP to IN Mapping 1535 To be provided 1537 B. References 1539 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1540 9, RFC 2026, October 1996. 1541 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1542 Levels", BCP 14, RFC 2119, March 1997 1543 3 Gurbani, V., Rastogi, V., "Accessing IN Services from SIP 1544 Networks", IETF I-D, Work in Progress, 1545 http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip- 1546 to-in-04.txt, expires August 2001 1547 4 M. Handley, H. Schulzrinne, J. Rosenberg, E. Schooler, "SIP: 1548 Session Initiation Protocol", RFC 2543, March 1999. 1550 C. Acknowledgments 1551 I thank specially Mr Ray C. Forbes from Marconi Communications 1552 Limited for his valuable contribution on the system and network 1553 architectural aspects as Co-chair in the ETSI SPAN. 1554 I also thank Hui-Lan Lu, Doris Lebovits, Kamlesh Tewani, Janusz 1555 Dobrowloski, Vijay Gurbani, Jack Kozik, Warren Montgomery, Lev 1556 Slutsman, Igor Faynberg, Henning Schulzrinne and Jonathan Rosenberg 1557 who all contributed to the discussions on the relationship of IN and 1558 SIP call models 1560 D. Changes 1561 Changes since -00 1562 . Included SIP/IN Call Model mapping as described in [3]. 1563 . Included comments from ETSI obtained by Frans Haerens. 1565 . Not all changes discussed on the SIN DT email list have been 1566 included - stay tuned for -02 coming up after 51st IETF. 1568 E. Author's Addresses 1570 Frans Haerens 1571 Alcatel Bell 1572 Francis Welles Plein,1 1573 Belgium 1574 Phone: +32 3 240 9034 1575 Email: frans.haerens@alcatel.be 1577 Vijay K. Gurbani 1578 Lucent Technologies, Inc. 1579 263 Shuman Blvd, Rm 1A-413 1580 Naperville, Illinois 60532 1581 USA 1582 Phone: +1 630 224 0216 1583 Email: vkg@lucent.com 1585 Vidhi Rastogi 1586 Wipro Technologies 1587 271, Sri Ganesha Complex 1588 Hosur Main Road, Madiwala 1589 Bangalore - 560 068, INDIA 1590 Phone: +91 80 5539701 1591 Email: vidhi.rastogi@wipro.com 1592 Full Copyright Statement 1594 "Copyright (C) The Internet Society (date). All Rights Reserved. 1595 This document and translations of it may be copied and furnished to 1596 others, and derivative works that comment on or otherwise explain it 1597 or assist in its implmentation may be prepared, copied, published 1598 and distributed, in whole or in part, without restriction of any 1599 kind, provided that the above copyright notice and this paragraph 1600 are included on all such copies and derivative works. However, this 1601 document itself may not be modified in any way, such as by removing 1602 the copyright notice or references to the Internet Society or other 1603 Internet organizations, except as needed for the purpose of 1604 developing Internet standards in which case the procedures for 1605 copyrights defined in the Internet Standards process MUST be 1606 followed, or as required to translate it into