idnits 2.17.1 draft-gurbani-sin-02.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 27 form feeds but 98 pages 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.) ** There are 14 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1135: '...Standards process MUST be followed, or...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 160 has weird spacing: '... ensure that ...' == Line 173 has weird spacing: '...mapping betwe...' == Line 613 has weird spacing: '...N layer has...' -- 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 503 looks like a reference -- Missing reference section? '2' on line 456 looks like a reference -- Missing reference section? '4' on line 139 looks like a reference -- Missing reference section? '3' on line 991 looks like a reference -- Missing reference section? '5' on line 369 looks like a reference -- Missing reference section? '6' on line 370 looks like a reference -- Missing reference section? '7' on line 372 looks like a reference -- Missing reference section? '8' on line 457 looks like a reference -- Missing reference section? '9' on line 457 looks like a reference -- Missing reference section? '10' on line 652 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Vijay K. Gurbani 3 June 2002 Lucent Technologies, Inc. 4 Expires: December 2002 Frans Haerens 5 Alcatel Bell 6 Vidhi Rastogi 7 Wipro Technologies 9 Document: draft-gurbani-sin-02.txt 10 Category: Informational 12 Interworking SIP and Intelligent Network (IN) Applications 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 Public Switched Telephone Network (PSTN) services such as 800 number 42 routing (freephone), time-and-day routing, credit-card calling, 43 virtual private network (mapping a private network number into a 44 public number) are realized by the Intelligent Network (IN). This 45 draft addresses means to support existing IN services from Session 46 Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. 47 The call request is originated on a SIP endpoint, but the services to 48 the call are provided by the data and procedures resident in the 49 PSTN/IN. To provide IN services in a transparent manner to SIP 50 endpoints, this draft describes the mechanism for interworking SIP 51 and Intelligent Network Application Part (INAP). 53 Table of Contents 54 1 INTRODUCTION.................................................. 3 55 2 ACCESS TO IN-SERVICES FROM A SIP ENTITY....................... 4 56 3 ADDITIONAL SIN CONSIDERATIONS................................. 7 57 3.1 The concept of state in SIP.............................. 7 58 3.2 Relationship between SCP and a SIN-enabled SIP entity.... 8 59 3.3 SIP REGISTER and IN services............................. 8 60 3.4 Support of announcements and mid-call signaling.......... 8 61 4 THE SIN ARCHITECTURE.......................................... 9 62 4.1 Definitions.............................................. 9 63 4.2 IN Service control based on the SIN approach.............10 64 5 MAPPING OF THE SIP STATE MACHINE TO THE IN STATE MODEL........11 65 5.1 Mapping SIP protocol state machine to O_BCSM.............12 66 5.2 Mapping SIP protocol state machine to T_BCSM.............17 67 6 EXAMPLE CALL FLOWS............................................22 68 7 SECURITY CONSIDERATIONS.......................................23 69 Appendix A.......................................................23 70 Normative References.............................................24 71 Informative References...........................................24 72 Acknowledgments..................................................25 73 Changes from previous drafts.....................................25 74 Author's addresses...............................................26 76 List of Acronyms 78 B2BUA Back-to-Back User Agent 79 BCSM Basic Call State Model 80 CCF Call Control Function 81 DP Detection Point 82 DTMF Dual Tone Multi-Frequency 83 IN Intelligent Network 84 INAP Intelligent Network Application Part 85 IP Internet Protocol 86 ITU-T International Telecommunications Union - Telecommunications 87 Standardization Sector 88 O_BCSM Originating Basic Call State Model 89 PIC Point in Call 90 PSTN Public Switched Telephone Network 91 RTP Real Time Protocol 92 R-URI Request URI 93 SCF Service Control Function 94 SCP Service Control Point 95 SIGTRAN Signal Transport Working Group in IETF 96 SIN SIP/IN Interworking 97 SIP Session Initiation Protocol 98 SS7 Signaling System No. 7 99 SSF Service Switching Function 100 SSP Service Switching Point 101 T_BCSM Terminating Basic Call State Model 102 UA User Agent 103 UAC User Agent Client 104 UAS User Agent Server 105 VoIP Voice over IP 106 VPN Virtual Private Network 108 1 Introduction 110 PSTN services such as 800 number routing (freephone), time-and-day 111 routing, credit-card calling, virtual private network (mapping a 112 private network number into a public number) are realized by the 113 Intelligent Network. IN is an architectural concept for the real- 114 time execution of network services and customer applications [1]. IN 115 is, by design, de-coupled from the call processing component of the 116 PSTN. In this draft, we describe the means to leverage this 117 decoupling to provide IN services from SIP-based entities. 119 We first explain the basics of IN. Figure 1 shows a simplified IN 120 architecture, in which telephone switches, called Service Switching 121 Points (SSPs), are connected via a packet network called Signaling 122 System No. 7 (SS7) to Service Control Points (SCPs), which are 123 general purpose computers. At certain points in a call, a switch can 124 interrupt a call and request instructions from an SCP on how to 125 proceed with the call. The points where a call can be interrupted 126 are standardized within the Basic Call State Model (BCSM) [1, 2]. 127 The BCSM models contains two processes, one each for the originating 128 and terminating part of a call. 130 When the SCP gets an request for instructions, it can reply with a 131 single response, such a simple number translation augmented by 132 criteria like time of day or day of week, or, in turn, get into a 133 complex dialog with the switch. The situation is further complicated 134 by the necessity to engage other specialized devices, which collect 135 digits, play recorded announcement, perform text-to-speech or 136 speech-to-text conversion, etc. (These devices are not discussed 137 here.) The related protocol as well as the BCSM is standardized by 138 the ITU-T and known as the Intelligent Network Application Part 139 protocol (INAP) [4]. Only the protocol, not an SCP API, have been 140 standardized. 142 +-----------+ 143 | | 144 | SCP | 145 | | 146 +-----------+ 147 | 148 | 149 / \ 150 / \ 151 / INAP \ 152 / \ 153 / \ 154 +--------+ ISUP +--------+ 155 | SSP |*********| SSP | 156 +--------+ +--------+ 158 Figure 1. Simplified IN Architecture 160 The overall objective is to ensure that IN control of Voice over IP 161 (VoIP) services in networks can be readily specified and implemented 162 by adapting standards and software used in the present networks. This 163 approach leads to services that function the same when a user connect 164 to present or future networks, simplifies service evolution from 165 present to future, and leads to more rapid implementation. 167 The rest of this draft is organized as follows: Section 2 contains 168 the architectural model of an IN aware SIP entity. Section 3 169 provides some issues to be taken into account when performing SIP/IN 170 interworking (SIN). Section 4 discusses the IN service control based 171 on the SIN approach. The technique outlined in this draft focuses on 172 the call models of IN and the SIP protocol state machine; section 5, 173 thus establishes a complete mapping between the two state machines 174 which allows for access to IN services from SIP endpoints. Section 6 175 includes call flows of IN services executing on SIP endpoints. These 176 services are readily enabled by the technique described in this 177 draft. Finally, section 7 covers security aspects of SIN. 179 2 Access to IN-services from a SIP entity 181 The intent of this draft is to provide means to support existing IN- 182 based applications in a SIP [3] environment. One way to gain access 183 to IN services transparently (i.e., through the same detection points 184 (DPs) and point-in-call (PIC) used by traditional switches) from SIP 185 is to map the SIP protocol state machine to the IN call models [1]. 187 From the viewpoint of IN elements like the SCP, the fact that the 188 request originated from a SIP entity versus a call processing 189 function on a traditional switch is immaterial. Thus, it is 190 important that the SIP entity be able to provide features normally 191 provided by the traditional switch, including operating as a SSP for 192 IN features. The SIP entity should also maintain call state and 193 trigger queries to IN-based services, just as traditional switches 194 do. 196 It is not the intent of this draft to specify which SIP entity shall 197 operate as a SSP; however, for the sake of completeness it should be 198 mentioned that this task should be performed by SIP entities at (or 199 near the) core of the network instead of the SIP end points 200 themselves. To that extent, SIP entities like proxy servers and 201 Back-to-Back UAs (B2BUAs) may be employed. Generally speaking, proxy 202 servers can be used for IN services that occur during a call setup 203 and teardown. For IN services requiring specialized media handling 204 (such as DTMF detection), or specialized call control (such as 205 placing parties on hold), B2BUAs will be required. 207 The most expeditious manner for providing existing IN services in the 208 IP domain is to use the deployed IN infrastructure as much as 209 possible. The logical point in SIP to tap into for accessing 210 existing IN services is either the UAs or one of the proxy located 211 physically closest to the UA (and presumably in the same 212 administrative domain as the UA). However SIP entities do not run an 213 IN call model; to transparently access IN services, the trick then, 214 is to overlay the state machine of the SIP entity with an IN layer 215 such that call acceptance and routing is performed by the native 216 state machine and services are accessed through the IN layer using an 217 IN call model. Such an IN-enabled SIP entity, operating in synchrony 218 with the events occurring at the SIP transaction level and 219 interacting with the IN elements (SCP) is depicted in Figure 2: 221 +-------+ 222 | SCP | 223 +---+---+ 224 | 225 | INAP 226 | 227 +--------+ 228 | SIN | 229 +........+ 230 | SIP | 231 ---------->| Entity |---------> 232 Requests | | Requests out 233 in +--------+ (after applying IN 234 services) 236 SIN: SIP/IN Interworking layer 238 Figure 2: SIP Entity accessing IN services 240 Section 5 proposes such a mapping between the IN layer and the SIP 241 protocol state machine. Essentially, a SIP entity exhibiting such a 242 mapping becomes a SIN-enabled SIP entity. 244 This draft does not propose any extensions to SIP. 246 Figure 3 expands the SIP entity depicted in Figure 2 and further 247 details the architecture model involving IN and SIP interworking. 248 Events occurring at the SIP layer will be passed to the IN layer for 249 service application. More specifically, since IN services deal with 250 E.164 numbers, it is reasonable to assume that a SIN-enabled SIP 251 entity that wants to provide services on such a number will consult 252 the IN layer for further processing, thus acting as a SIP-based SSP. 253 The IN layer will proceed through its BCSM states, and at appropriate 254 points in the call, will send queries to the SCP for call 255 disposition. Once a decision has been made on the disposition of the 256 call, the SIP layer is so informed and it processes the transaction 257 accordingly. 259 It should be noted that the single SIP entity as modeled in this 260 figure can in fact represent several different physical instances in 261 the network, for example with one SIP entity in charge of the 262 terminal or access network/domain, and another in charge of the 263 interface to the Switched Circuit Network (SCN). 265 +-------+ 266 | SCP | 267 +---o---+ 268 | 269 +-----+ 270 | 271 **********|*********************************** 272 * +-------|-------------------+ * 273 * |+------o------+ | * 274 * || SSF(IP) | | * 275 * |+-------------+ | * 276 * || CCF(IP) | | * 277 * |+------o------+ | * 278 * +-------|-------------------+ * 279 * | SIN-enabled * 280 * +-------o-------------------+ SIP * 281 * | SIP Layer | Entity * 282 * +---------------------------+ * 283 ********************************************** 285 Figure 3: Functional architecture of an SIN-enabled SIP entity 287 The following architecture entities, used in Figure 3, are defined in 288 the Intelligent Network standards: 290 Service Switching Function (SSF): IN functional entity that 291 interacts with call control functions. 293 Call Control Function (CCF): IN functional entity that refers 294 to call and connection handling in the classical sense (e.g. 295 that of an exchange). 297 3 Additional SIN considerations 299 When interworking between Internet Telephony and IN-PSTN networks, 300 the main issue is to translate between the states produced by the 301 Internet Telephony signaling and those used in traditional IN 302 environments. Such a translation entails attention to the 303 considerations listed below. 305 3.1 The concept of state in SIP 307 IN services occur within the context of a call; i.e. either during 308 call setup, teardown, or in the middle of a call. SIP entities 309 such as proxies, where some of these services may be realized, 310 typically run in transaction- stateful (or stateless) mode. In 311 such a mode, a SIP proxy that proxied the initial INVITE is not 312 guaranteed to receive a subsequent request, such as a BYE. 313 Fortunately, SIP has primitives to force proxies to run in a call- 314 stateful mode; namely, the Record-Route header. This header forces 315 the UAC and UAS to create a "route set" which consists of all 316 intervening proxies through which subsequent request must traverse. 317 Thus SIP proxies must run in call- stateful mode in order to 318 provide IN services on behalf of the UAs. 320 A B2BUA is another SIP element where IN services can be realized. 321 Since a B2BUA is a true SIP UA, it maintains complete call state 322 and is thus capable of providing IN services. 324 3.2 Relationship between SCP and a SIN-enabled SIP entity 326 In architecture model proposed in this draft, each SIN-enabled SIP 327 entity is pre-configured to communicate with one logical SCP 328 server, using whatever communication mechanism is appropriate. 329 Different SIP servers (e.g., those in different administrative 330 domains) may communicate with different SCP servers, so that there 331 is no single SCP server responsible for all SIP servers. 333 As Figures 1 and 2 depict, the IN-portion of the SIN-enabled SIP 334 entity will communicate with the SCP. This interface between the 335 IN call handling layer and the SCP is not specified by this draft 336 and indeed, can be any one of the following depending on the 337 interfaces supported by the SCP: INAP over IP, INAP over SIGTRAN, 338 or INAP over SS7. 340 This draft is only applicable when SIP-controlled Internet 341 telephony devices are to inter-operate with PSTN devices. The SIP 342 UAs using this interface would typically appear together with a 343 media gateway. It is *not* applicable in an all-IP network and is 344 not needed where PSTN media gateways (not speaking SIP) need to 345 communicate with SCPs. 347 3.3 SIP REGISTER and IN services 349 SIP REGISTER provisions a SIP Proxy or SIP Registration server. The 350 process is similar to the provisioning of an SCP/HLR in the 351 switched circuit network. SCPs which provide VoIP based services 352 can directly leverage this information. However, this draft neither 353 endorses or prohibits such an architecture, and in fact, considers 354 it an implementation decision. 356 3.4 Support of announcements and mid-call signaling 358 Services in the IN such as credit-card calling typically play 359 announcements and collect digits from the caller before a call is 360 set up. Playing announcements and collecting digits require the 361 manipulation of media streams. In SIP, proxies do not have access 362 to the media data path. Thus such services should be executed in a 363 B2BUA. 365 While the SIP specification [3] allows for end points to be put on 366 hold during a call, or a change of media streams to take place, it 367 does not have any primitives to transport other mid-call control 368 information. This may include transporting DTMF digits, for 369 example. Extensions to SIP, such as the INFO method [5] or the SIP 370 event notification extension [6] can be considered for services 371 requiring mid-call signaling. Alternatively, DTMF can be 372 transported in RTP itself [7]. 374 4 The SIN Architecture 376 4.1 Definitions 378 The SIP architecture has the following functional elements defined in 379 [3]: 380 - User agent client: The SIP functional entity that initiates a 381 request. 383 - User agent server: The SIP functional entity that terminates a 384 request by sending 0 or more provisional SIP responses and one 385 final SIP response. 387 - Proxy server: An intermediary SIP entity that can act as both 388 a User Agent Server (UAS) and a User Agent Client (UAC). 389 Acting as a UAS, it accepts requests from UACs, rewrites the 390 Request-URI (R-URI), and, acting as a UAC, proxies the request 391 to a downstream UAS. Proxies may retain significant call 392 control state by inserting them-selves in future SIP 393 transactions beyond the initial INVITE. 395 - Redirect server: An intermediary SIP entity that redirects 396 callers to alternate locations, after possibly consulting a 397 location server to determine the exact location of the callee 398 (as specified in the R-URI) 400 - Registrar: An SIP entity that accepts SIP REGISTER requests 401 and maintains a binding from a high-level URL to the exact 402 location for a user. This information is saved in some data- 403 store that is also accessible to a SIP Proxy and a SIP 404 Redirect server. A Registrar is usually co-located with a 405 SIP Proxy or a SIP Redirect server. 407 - Outbound proxy: An SIP proxy that is located near the 408 originator of requests. It receives all outgoing requests 409 from a particular UAC, including those requests whose R-URIs 410 identify a host other than the outbound proxy. The outbound 411 proxy sends these requests, after any local processing, to 412 the address indicated in the R-URI. 414 - Back-to-Back UA (B2BUA): An SIP entity that receives a request 415 and processes it as a UAS. It also acts as a UAC and 416 generates requests in order to determine how the incoming 417 request is to be answered. A B2BUA maintains complete dialog 418 state and must participate in all request sent within the 419 dialog. 421 4.2 IN Service control based on the SIN approach 423 Figure 4 depicts the possibility of IN service control based on the 424 SIN approach. On both, the originating and terminating ends, a SIN- 425 capable SIP entity is assumed (it can be a proxy or a B2BUA). The "O 426 SIP" entity is required for outgoing calls that require support for 427 existing IN services. Likewise, on the callee's side (or terminating 428 side), an equally configured entity ("T SIP") will be required to 429 provide terminating side services. Note that the "O SIP" and "T SIP" 430 entities correspond, respectively, to the IN O_BCSM and T_BCSM halves 431 of the IN call model. 433 +---+ +---+ 434 | S | (~~~~~~~~~~~~~) | S | 435 | C |<--+ ( ) +-->| C | 436 | P | | ( ) | | P | 437 +---+ | ( Switched ) | +---+ 438 | ( Circuit ) | 439 V ( Network ) V 440 +-------+ ( ) +-------+ 441 | SIN | +---------+ +---------+ | SIN | 442 +-------+----| Gateway | ... | Gateway |------+-------+ 443 | O SIP | +---------+ +---------+ | T SIP | 444 +-------+ ( ) +-------+ 445 ( ) 446 (.............) 448 O SIP: Originating SIP entity 449 T SIP: Terminating SIP entity 451 Figure 4: Overall SIN architecture. 453 5 Mapping of the SIP state machine to the IN state model 455 This section establishes the mapping of the SIP protocol state 456 machine to the IN generic basic call state model (BCSM) [2], 457 independent of any capability sets [8, 9]. The BCSM is divided into 458 two halves - an originating call model (O_BCSM) and a terminating 459 call model (T_BCSM). There are a total of 19 PICs and 35 DPs between 460 both the halves (11 PICs and 21 DPs for O_BCSM; 8 PICs and 14 DPs for 461 T_BCSM) [1]. The SSPs, SCPs and other IN elements track a call's 462 progress in terms of the basic call model. The basic call model 463 provides a common context for communication about a call. 465 O_BCSM has 11 PICs. These are: 467 O_NULL: starting state; call does not exist yet. 468 AUTH_ORIG_ATTEMPT: switch detects a call setup request. 469 COLLECT_INFO: switch collects the dial string from the calling 470 party. 471 ANALYZE_INFO: complete dial string is translated into a routing 472 address. 473 SELECT_ROUTE: physical route is selected, based on the routing 474 address. 475 AUTH_CALL_SETUP: switch ensures the calling party is authorize to 476 place call. 477 CALL_SENT: control of call send to terminating side. 478 O_ALERTING: switch waits for the called party to answer. 479 O_ACTIVE: connection established; communication ensue. 480 O_DISCONNECT: connection torn down. 481 O_EXCEPTION: switch detected an exceptional condition. 483 T_BCSM has 8 PICS. These are: 485 T_NULL: starting state; call does not exist yet. 486 AUTH_TERM_ATT: switch verifies whether call can be send to 487 terminating party. 488 SELECT_FACILITY: switch picks a terminating resource to send the 489 call on. 490 PRESENT_CALL: call is being presented to the called party. 491 T_ALERTING: switch alerts the called party, e.g. ringing the line. 492 T_ACTIVE: connection established; communications ensue. 493 T_DISCONNECT: connection torn down. 494 T_EXCEPTION: switch detected an exceptional condition. 496 and 103 respectively. This state machine will be used for subsequent 497 discussion when the IN call states are mapped into SIP. 499 The next two sections contain the mapping of the SIP protocol state 500 machine to the IN BCSMs. It is beyond the scope of this draft to 501 explain all PICs and DPs in an IN call model. It is assumed that the 502 reader has some familiarity with the PICs and DPs of the IN call 503 model. More information can be found in [1]. For a quick reference, 504 Appendix A contains a mapping of the DPs to the SIP response codes as 505 discussed in the next two sections. 507 5.1 Mapping SIP protocol state machine to O_BCSM 509 The 11 PICs of O_BCSM come into play when a call request (SIP INVITE 510 message) arrives from an upstream SIP client to an originating SIN- 511 enabled SIP entity running the IN call model. This entity will 512 create a O_BCSM object and initialize it in the O_NULL PIC. The next 513 seven IN PICs -- O_NULL, AUTH_ORIG_ATT, COLLECT_INFO, ANALYZE_INFO, 514 SELECT_ROUTE, AUTH_CALL_SETUP, and CALL_SENT -- can all be mapped to 515 the SIP "Calling" state. 517 Figure 5 below provides a visual mapping from the SIP protocol state 518 machine to the originating half of the IN call model. Note that 519 control of the call shuttles between the SIP protocol machine and the 520 IN O_BCSM call model while it is being serviced. 522 SIP O_BCSM 524 | INVITE 525 V 526 +---------+ +---------------+ 527 | Calling +=======================>+ O_NULL +<----+ 528 +--+---/\-+ +-/\---+--------+ | 529 | | || +-------------+ | | | 530 | | ||<===+O_Exception +---------+ +--V-+ +--+-+ 531 | | || +--/\---------+ |DP 1| |DP21| 532 | | || | +----+ +-----+----+------+ +--+-+ 533 | | || +<---+DP 2|<-----+ Auth_Orig._Att +---->+ 534 | | || | +----+ +--------+--------+ | 535 | | || | | | 536 | | || | +--V-+ | 537 | | || | |DP 3| | 538 | | || | +----+ +-----+----+------+ | 539 | | || +<---+DP 4|<-----+ Collect_Info +---->+ 540 | | || | +----+ +--------+--------+ | 541 | | || | | | 542 | | || | +--V-+ | 543 | | || | |DP 5| | 544 | | || | +----+ +-----+----+------+ | 545 | | || +<---+DP 6|<-----+ Analyze_Info +---->+ 546 | | || | +----+ +--------+--------+ | 547 | | || | | | 548 | | || | +--V-+ | 549 | | || | |DP 7| | 550 | | || | +----+ +-----+----+------+ | 551 | | || +<---+DP 8|<-----+ Select_Route +---->+ 552 | | || | +----+ +--------+--------+ | 553 | | || | | | 554 | | || | +--V-+ | 555 | | || | |DP 9| | 556 | | || | +----+ +-----+----+------+ | 557 | | || +<---+DP10|<-----+ Auth._Call_Setup+---->+ 558 | | || +----+ +--------+--------+ 559 +----+ | || | 560 | | || +--V-+ 561 | | || |DP11| 562 | 1xx | || +-----+----+------+ 563 | | ++========================+ Call_Sent | 564 | | +----/\----+------+ 565 | | On 100,180,2xx process DP14 || | 566 | | On 3xx, process DP12 || | 567 | V On 486, process DP13 || | 568 | +--+-------+ On 5xx, 6xx and 4xx || | 569 | |Proceeding| (except 486) process DP21|| | 570 | +-+-+------+<=========================++ | 571 | | | | 572 | | | | 573 | | | | 574 | | +--200------------------+ | 575 | +----4xx to 6xx--------+ | | 576 | | | +--V-+ 577 | On DPs 21, 2, 4, 6, 8, 10 | | |DP14| 578 | send 4xx-6xx final response | | +--------+----+--+ 579 +-------+ | | | O_Alerting | 580 | | | +---------+------+ 581 +--V-------+ | | | 582 |Completed |<------------+ | +--V-+ 583 +--+-------+ | |DP16| 584 | | +------+----+----+ 585 +--V-------+ | +-+ O_Active | 586 |Terminated|<---------------+ | +-------------+--+ 587 +----------+ | | 588 +-----+ +--V-+ 589 | |DP19| 590 +--V-+ +--------+----+ 591 |DP17| | O_Disconnect| 592 +--+-+ +-------------+ 593 | 594 V 595 To O_EXCEPTION 596 Legend: 598 | Communication between 599 | states in the same 600 V protocol 602 ======> Communication between IN layer and SIP protocol 603 state machine to transfer call state 605 Figure 5: Mapping from SIP to O_BCSM 607 The SIP "Calling" protocol state has enough functionality to absorb 608 the seven PICs as described below: 610 O_NULL - This PIC is basically a fall through state to the next 611 PIC, AUTHORIZE_ORIGINATION_ATTEMPT. 613 AUTHORIZE_ORIGINATION_ATTEMPT - In this PIC, the IN layer has 614 detected that someone wishes to make a call. Under some 615 circumstances (e.g. the user is not allowed to make calls during 616 certain hours), such a call cannot be placed. SIP has the ability 617 to authorize the calling party using a set of policy directives 618 configured by the SIP administrator. If the called party is 619 authorized to place the call, the IN layer is instructed to enter 620 the next PIC, COLLECT_INFO through DP 3 621 (Origination_Attempt_Authorized). If for some reason, the call 622 cannot be authorized, DP 2 (Origination_Denied) is processed and 623 control transfers to the SIP state machine. The SIP state machine 624 must format and send a non-2xx final response (possibly 403) to the 625 upstream entity. 627 COLLECT_INFO - This PIC is responsible for collecting a dial string 628 from the calling party and verifying the format of the string. If 629 overlap dialing is being used, this PIC can invoke DP 4 630 (Collect_Timeout) and transfer control to the SIP state machine, 631 which will format and send a non-2xx final response (possibly a 632 484). If the dial string is valid, DP 5 (Collected_Info) is 633 processed and the IN layer is instructed to enter the next PIC, 634 ANALYZE_INFO. 636 ANALYZE_INFO - This PIC is responsible for translating the dial 637 string to a routing number. Many IN service such as freephone, LNP 638 (Local Number Portability), OCS (Originating Call Screening), etc. 639 occur during this PIC. The IN layer can use the R-URI of the SIP 640 INVITE request for analysis. If the analysis succeeds, the IN layer 641 is instructed to enter the next PIC, SELECT_ROUTE. If the analysis 642 failed, DP 6 (Invalid_Info) is processed and the control transfers 643 to the SIP state machine, which will generate a non-2xx final 644 response (possibly one of 400, 401, 403, 404, 405, 406, 410, 414, 645 415, 416, 485, or 488) and send it to the upstream entity. 647 SELECT_ROUTE - In the circuit-switched network, the actual physical 648 route has to be selected at this point. The SIP analogue of this 649 would be to determine the next hop SIP server. The next hop SIP 650 server could be chosen by a variety of means. For instance, if the 651 Request URI in the incoming INVITE request is an E.164 number, the 652 SIP entity can use a protocol like TRIP [10] to find the best 653 gateway to egress the request onto the PSTN. If a successful route 654 is selected, the IN call model moves to PIC AUTH_CALL_SETUP via DP 655 9 (Route_Selected). Otherwise, the control transfers to the SIP 656 state machine via DP 8 (Route_Select_Failure), which will generate 657 a non-2xx final response (possibly 488) and send it to the upstream 658 entity. 660 AUTH_CALL_SETUP - Certain service features restrict the type of 661 call that may originate on a given line or trunk. This PIC is the 662 point at which relevant restrictions are examined. If no such 663 restrictions are encountered, the IN call model moves to PIC 664 CALL_SENT via DP 11 (Origination_Authorized). If a restriction is 665 encountered that prohibits further processing of the call, DP 10 666 (Authorization_Failure) is processed and control is transferred to 667 the SIP state machine, which will generate a non-2xx final response 668 (possibly 404, 488, 502). Otherwise, DP 11 669 (Origination_Authorized) is processed and the IN layer is 670 instructed to enter the next PIC, CALL_SENT. 672 CALL_SENT - At this point, the request needs to be sent to the 673 downstream entity; and the IN layer waits for a signal confirming 674 that either the call has been presented to the called party or that 675 a called party cannot be reached for a particular reason. The 676 control is transferred to the SIP state machine. The SIP state 677 machine should now sent the call to the next downstream server 678 determined in PIC SELECT_ROUTE. The IN call model now blocks until 679 unblocked by the SIP state machine. 681 If the above seven PICs have been successfully negotiated, the 682 SIN-enabled SIP entity now sends the SIP INVITE message to the next 683 hop server. Further processing now depends on the provisional 684 responses (if any) and the final response received by the SIP 685 protocol state machine. The core SIP specification does not 686 guarantee the delivery of 1xx responses, thus special processing is 687 needed at the IN layer to transition to the next PIC (O_ALERTING) 688 from the CALL_SENT PIC. The special processing needed for 689 responses while the SIP state machine is in the "Proceeding" state 690 and the IN layer is in the "CALL_SENT" state is described next. 692 A 100 response received at the SIP state machine elicits no 693 special behavior in the IN layer. 695 A 180 response received at the SIP entity enables the processing 696 of DP 14 (O_Term_Seized), however, a state transition to 697 O_ALERTING is not undertaken yet. Instead, the IN layer is 698 instructed to remain in the CALL_SENT PIC until a final response 699 is received. 701 A 2xx response received at the SIP entity enables the processing 702 of DP 14 (O_Term_Seized), and the immediate transition to the 703 next state, O_ALERTING (processing in O_ALERTING is described 704 later). 706 A 3xx response received at the SIP entity enables the processing 707 of DP 12 (Route_Failure). The IN call model from this point 708 goes back to the SELECT_ROUTE PIC to select a new route for the 709 contacts in the 3xx final response (not shown in Figure 5 for 710 brevity). 712 A 486 (Busy Here) response received at the SIP entity enables 713 the processing of DP 13 (O_Called_Party_Busy) and resources for 714 the call are released at the IN call model. 716 If the SIN-enabled SIP entity gets a 4xx (except 486), 5xx, or 717 6xx final response, DP 21 (O_Calling_Party_Disconnect & 718 O_Abandon) is processed and control passes to the SIP state 719 machine. Since a call was not successfully established, both 720 the IN layer and the SIP state machine can release resources for 721 the call. 723 O_ALERTING - This PIC will be entered as a result of receiving a 724 200-class response. Since a 200-class response to an INVITE 725 indicates acceptance, this PIC is mostly a fall through to the next 726 PIC, O_ACTIVE via DP 16 (O_Answer). 728 O_ACTIVE - At this point, the call is active. Once in this state, 729 the call may get disconnected only when one of the following three 730 events occur: (1) the network connection fails, (2) the called 731 party disconnects the call, or (3) the calling party disconnects 732 the call. If event (1) occurs, DP 17 (O_Connection_Failure) is 733 processed and call control is transferred to the SIP protocol state 734 machine. Since the network failed, there is not much sense in 735 attempting to send a BYE request; thus both the SIP protocol state 736 machine and the IN call layer should release all resources 737 associated with the call and initialize themselves to the null 738 state. The occurrence of event (2) results in the processing of DP 739 19 (O_DISCONNECT) and a move to the last PIC, O_DISCONNECT. Event 740 (3) would be caused by the calling party proactively terminating 741 the call. In this case, DP 21 (O_Abandon & 742 O_Calling_Party_Disconnect) will be processed and control passed to 743 the SIP protocol state machine. The SIP protocol state machine 744 must send a BYE request and wait for a final response. The IN 745 layer releases all its resources and initializes itself to the null 746 state. 748 O_DISCONNECT - When the SIP entity gets a BYE request, the IN layer 749 is instructed to move to the last PIC, O_DISCONNECT via DP19. A 750 final response for the BYE is generated and transmitted by the SIP 751 entity and the call resources are freed by both the SIP protocol 752 state machine as well as the IN layer. 754 5.2 Mapping SIP protocol state machine to T_BCSM 756 The T_BCSM object is created when a SIP INVITE message makes its way 757 to the terminating SIN-enabled SIP entity. This entity creates the 758 T_BCSM object and initializes it to the T_NULL PIC. 760 Figure 6 below provides a visual mapping from the SIP protocol state 761 machine to the terminating half of the IN call model: 763 SIP T_BCSM 765 | INVITE 766 V 767 +----------+ +------------+ 768 |Proceeding+=========================>+ T_Null +<-------+ 769 +-+--+--/\-+ +/\----+-----+ | 770 | | || +-----------+ | | | 771 | | ||<=======+T_Exception+--------+ +--V-+ +--+-+ 772 | | || +-/\--------+ |DP22| |DP35| 773 | | || | +----+ +---+----+------+ +--+-+ 774 | | || +<---+DP23|<------+Auth._Term._Att+---->+ 775 | | || | +----+ +------+--------+ | 776 | | || | | | 777 | | || | +--V-+ | 778 | | || | |DP24| | 779 | | || | +----+ +---+----+------+ | 780 | | || +<---+DP25|<------+Select_Facility+---->+ 781 | | || | +----+ +------+--------+ | 782 | | || | | | 783 | | || | +--V-+ | 784 | | || | |DP26| | 785 | | || | +----+ +---+----+------+ | 786 | | || +<---+DP27|<------+ Present_Call +---->+ 787 | | || | +----+ +------+--------+ | 788 | | || | | | 789 | | || | +--V-+ | 790 | | || | |DP28| | 791 | | || | +----+ +---+----+------+ | 792 | | || +<---+DP29|<------+ T_Alerting +---->+ 793 | | || | +----+ +-/\--+---------+ | 794 | | || +<--------------+ || | | 795 | | || | || | | 796 | | ++==========================|===++ | | 797 | | /\ +-------+ +--V-+ | 798 | | || | +DP30| | 799 | | || +-+--+ +---+----+------+ | 800 | | || |DP31+<-----| T_Active +---->+ 801 | | || +----+ +-/\-----+------+ 802 | | || || | 803 | | || || | 804 2xx | | ++==============================++ | 805 sent | | | 806 +----+ | 3xx - 6xx response +--V-+ 807 | | sent |DP33| 808 | +----V-----+ +------+----+----+ 809 | |Completed | | T_Disconnect | 810 | +----+-----+ +----------------+ 811 | | 812 | | ACK received 813 | | 814 | +----V-----+ 815 | |Confirmed | 816 | +----+-----+ 817 | | 818 +------>| 819 | 820 +----V-----+ 821 |Terminated| 822 +----------+ 824 Legend: 826 | Communication between 827 | states in the same 828 V protocol 829 ======> Communication between IN call model and SIP 830 protocol state machine to transfer call state 832 Figure 6: Mapping from SIP to T_BCSM 834 The SIP "Proceeding" state has enough functionality to absorb the 835 first five PICS -- T_Null, Authorize_Termination_Attempt, 836 Select_Facility, Present_Call, T_Alerting -- as described below: 838 T_NULL - At this PIC, the terminating end creates the call at the 839 IN layer. The incoming call results in the processing of DP 22, 840 Termination_Attempt, and a transition to the next PIC, 841 AUTHORIZE_TERMINATION_ATTEMPT, takes place. 843 AUTHORIZE_TERMINATION_ATTEMPT - In this PIC, the fact that the 844 called party wishes to receive the call is ascertained and that the 845 facilities of the called party are compatible with that of the 846 calling party. If any of these conditions is not met, DP 23 847 (Termination_Denied) is invoked and the call control is transferred 848 to the SIP protocol state machine. The SIP protocol state machine 849 can format and send a non-2xx final response (possibly 403, 405, 850 415, or 480). If the conditions of the PIC are met, processing of 851 DP 24 (Termination_Authorized) is invoked and a transition to the 852 next PIC, SELECT_FACILITY, takes place. 854 SELECT_FACILITY - The intent of this PIC in circuit switched 855 networks is to select a line or trunk to reach the called party. 856 Since lines or trunks are not applicable in an IP network, a SIN- 857 enabled SIP entity can use this PIC to interface with a PSTN 858 gateway and select a line/trunk to route the call. If the called 859 party is busy, or a line/trunk can not be thus seized, the 860 processing of DP 25 (T_Called_Party_Busy) is invoked, followed by a 861 transition of the call to the SIP protocol state machine. The SIP 862 protocol state machine must format and send a non-2xx final 863 response (possibly 486 or 600). If a line/trunk was successfully 864 seized, the processing of DP 26 (Terminating_Resource_Available) is 865 invoked and a transition to the next PIC, PRESENT_CALL, takes 866 place. 868 PRESENT_CALL - At this point, the call is being presented (via the 869 ISUP ACM message, or Q.931 Alerting message, or simply by ringing a 870 POTS phone). If there was an error presenting the call, the 871 processing of DP 27 (Presentation_Failure) is invoked and the call 872 control is transferred to the SIP protocol state machine. The SIP 873 protocol state machine must format and send a non-2xx final 874 response (possibly 480). If the call was successfully presented, 875 the processing of DP 28 (T_Term_Seized) is invoked and a transition 876 to the next PIC, T_ALERTING, takes place. 878 T_ALERTING - At this point, the called party is being "alerted". 879 Control now passed momentarily to the SIP protocol state machine, 880 so it can generate and send a "180 Ringing" response to its peer. 881 Furthermore, since network resources have been allocated for the 882 call, timers are set to prevent indefinite holding of such 883 resources. The expiration of the relevant timers result in the 884 processing of DP 29 (T_No_Answer) and the call control is 885 transferred to the SIP protocol state machine. The SIP protocol 886 state machine must format and send a non-2xx final response 887 (possibly 408). If the called party answers, then DP 30 (T_Answer) 888 is processed, followed by a transition to the next PIC, T_ACTIVE. 890 The rest of the PICs after the above five have been negotiated are 891 mapped as follows: 893 T_ACTIVE - The call is now active. Once this state is reached, the 894 call may become inactive only under one of the following three 895 conditions: (1) the network fails the connection, (2) the called 896 party disconnects the call, or (3) the calling party disconnects the 897 call. Event (1) results in the processing of DP 31 898 (T_Connection_Failure) and call control is transferred to the SIP 899 protocol state machine. Since the network failed, there is not much 900 sense in attempting to send a BYE request; thus both the SIP protocol 901 state machine and the IN call layer should release all resources 902 associated with the call and initialize themselves to the null state. 903 Event (2) results in the processing of DP 33 (T_Disconnect) and a 904 transition to the next PIC, T_DISCONNECT. Event (3) would be caused 905 by the receipt of a BYE request at the SIP protocol state machine 906 (not shown in Figure 6). Resources for the call should be 907 deallocated and the SIP protocol state machine must send a 200 OK for 908 the BYE request (not shown in Figure 6). 910 T_DISCONNECT - In this PIC, the disconnect treatment associated with 911 the called party's having disconnected the call is performed at the 912 IN layer. The SIP protocol state machine sends out a BYE and awaits 913 a final response for the BYE (not shown in Figure 6). 915 6 Example call flows 917 Two examples are provided here to understand how SIP protocol state 918 machine and the IN call model work synchronously with each other. 920 In the first example, a SIP UAC originates a call request destined to 921 a 800 freephone number: 923 INVITE sip:18005551212@lucent.com SIP/2.0 924 From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff 925 To: sip:18005551212@lucent.com 926 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 927 Call-ID: 67188121@lucent.com 928 CSeq: 1 INVITE 930 The request makes its way to the originating SIP network server 931 running an IN call model. The SIP network server hands, at the very 932 least, the To: field and the From: field to the IN layer for 933 freephone number translation. The IN layer proceeds through its PICs 934 and in the ANALYSE_INFO PIC consults the SCP for freephone 935 translation. The translated number is returned to the SIP network 936 server, which forwards the message to the next hop SIP proxy, with 937 the freephone number replaced by the translated number: 939 INVITE sip:16302240216@lucent.com SIP/2.0 940 From: sip:16309795218@il0015vkg1.ih.lucent.com;tag=991-7as-66ff 941 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 942 Via: SIP/2.0/UDP sip-in1.ih.lucent.com 943 To: sip:18005551212@lucent.com 944 Call-ID: 67188121@lucent.com 945 CSeq: 1 INVITE 947 In the next example, a SIP UAC originates a call request destined to 948 a 900 number: 950 INVITE sip:19005551212@lucent.com SIP/2.0 951 From: sip:16302240216@lucent.com;tag=991-7as-66dd 952 To: sip:19005551212@lucent.com 953 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 954 Call-ID: 88112@lucent.com 955 CSeq: 1 INVITE 957 The request makes its way to the originating SIP network server 958 running an IN call model. The SIP network server hands, at the very 959 least, the To: field and the From: field to the IN layer for 900 960 number translation. The IN layer proceeds through its PICs and in 961 the ANALYSE_INFO PIC consults the SCP for the translation. During 962 the translation, the SCP detects that the originating party is not 963 allowed to make 900 calls. It passes this information to the 964 originating SIP network server, which informs the SIP UAC using SIP 965 "403 Forbidden" response status code: 967 SIP/2.0 403 Forbidden 968 From: sip:16302240216@lucent.com;tag=991-7as-66dd 969 To: sip:19005551212@lucent.com;tag=78K-909II 970 Via: SIP/2.0/UDP il0015vkg1.ih.lucent.com 971 Call-ID: 88112@lucent.com 972 CSeq: 1 INVITE 974 7 Security considerations 976 Security considerations for SIN services span both the networks being 977 used, namely, the PSTN and the Internet. SIN uses the security 978 measures in place for both the networks. With reference to Figure 2, 979 the INAP messages between the SCP and the SIN-enabled SIP entity must 980 be secured by the signaling transport used between the SCP and the 981 SIN-enabled entity. Likewise, the requests coming into the SIN- 982 enabled SIP entity must first be authenticated, and if the need be, 983 encrypted as well using the means and procedures defined in [3] for 984 SIP requests. 986 Appendix A: Mapping of 4xx-6xx responses in SIP to IN Detections Points 988 The mapping of error codes 4xx- 6xx responses in SIP to the possible 989 Detection Points in PIC Originating and Terminating Call Handling is 990 indicated in the table below. The reason phrase in the 4xx-6xx 991 response is reproduced from [3]. 993 SIP response code DP mapping to IN 994 ----------------- ---------------------- 995 200 OK DP 14 996 3xx DP 12 997 403 Forbidden DP 2, DP 21 998 484 Address Incomplete DP 4, DP 21 999 400 Bad Request DP 6, DP 21 1000 401 Unauthorized DP 6, DP 21 1001 403 Forbidden DP 6, DP 21, DP 23 1002 404 Not Found DP 6, DP 21 1003 405 Method Not Allowed DP 6, DP 21, DP 23 1004 406 Not Acceptable DP 6, DP 21 1005 408 Request Timeout DP 29 1006 410 Gone DP 6, DP 21 1007 414 Request-URI Too Long DP 6, DP 21 1008 415 Unsupported Media Type DP 6, DP 21, DP 23 1009 416 Unsupported URI Scheme DP 6, DP 21 1010 480 Temporarily Unavailable DP 23, DP 27 1011 485 Ambiguous DP 6, DP 21 1012 486 Busy Here DP 13, DP 21, DP 25 1013 488 Not Acceptable Here DP 6, DP 21 1014 488 Not Acceptable Here DP 8, 1015 404 Not Found DP 10, DP 21 1016 488 Not Acceptable Here DP 10, DP 21 1017 502 Bad Gateway DP 10, DP 21 1018 600 Busy Everywhere DP 21, DP 25 1020 Normative References 1022 1 I. Faynberg, L. Gabuzda, M. Kaplan, and N.Shah, "The 1023 Intelligent Network Standards: Their Application to 1024 Services," McGraw-Hill, 1997. 1025 2 ITU-T Q.1204 1993: Recommendation Q.1204, "Intelligent Network 1026 Distributed Functional Plane Architecture," International 1027 Telecommunications Union Standardization Section, Geneva. 1028 3 Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, 1029 Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley, 1030 and Eve Schooler, "SIP: Session Initiation Protocol", 1031 IETF I-D, Work in Progress, expires August 2002. 1032 1035 Informative References 1037 4 ITU-T Q.1208: "General aspects of the Intelligent Network 1038 Application protocol" 1040 5 S. Donovan, "The SIP INFO Method" IETF RFC 2976, October 1041 2000. 1042 6 Adam Roach, "SIP-Specific Event Notification", IETF I-D, Work 1043 in Progress, expires August 2002. 1045 7 H. Schulzrinne, S. Petrack, "RTP Payload for DTMF Digits, 1046 Telephony Tones and Telephony Signals", IETF RFC 2833, May 1047 2000. 1048 8 ITU-T Q.1218: "Interface Recommendation for Intelligent 1049 Network Capability Set 1" 1050 9 ITU-T Q.1228: "Interface Recommendation for Intelligent 1051 Network Capability Set 2" 1052 10 Jonathan Rosenberg, Hussein Salama, and Matt Squire, 1053 "Telephony Routing over IP (TRIP)", IETF RFC 3219, January, 1054 2002. 1056 Acknowledgments 1058 Special acknowledgement to Hui-Lan Lu for acting as the chair of the 1059 SIN DT and ensuring the focus of the DT did not veer too far. The 1060 authors would also like to thank specially Mr Ray C. Forbes from 1061 Marconi Communications Limited for his valuable contribution on the 1062 system and network architectural aspects as Co-chair in the ETSI 1063 SPAN. Thanks also to Doris Lebovits, Kamlesh Tewani, Janusz 1064 Dobrowloski, Jack Kozik, Warren Montgomery, Lev Slutsman, Henning 1065 Schulzrinne and Jonathan Rosenberg who all contributed to the 1066 discussions on the relationship of IN and SIP call models. 1068 Changes from previous drafts 1070 Changes in draft-gurbani-sin-02.txt 1071 . Incorporated comments from RFC Editor. 1072 . As per the comments from RFC Ed., changed name of draft. 1074 Changes to draft-gurbani-sin-01.txt 1075 . Added list of acronyms. 1076 . Took out table on "Cause value mappings" -- lot of this mapping is 1077 specified in SIP/ISUP the mapping draft. 1078 . Added Applicability Statement. 1080 Changes since draft-ietf-sin-manyfolks-01.txt 1081 . Renamed to ; reverted back to -00. 1082 . Incorporates DT Last Call comments. 1083 . Massive modifications of Figure 5 and 6 -- reflects more of an 1084 en event driven view. 1085 . Updated references. 1086 . Added TOC. 1088 Changes since -01 1089 . Renamed to ; reverted back to -00. 1090 . Major re-write of the original F. Haerens I-D. 1092 Changes since -00 1093 . Included SIP/IN Call Model mapping as described in a now expired I-D 1094 ("Accessing IN Services from SIP networks 1095 ). 1096 . Included comments from ETSI obtained by Frans Haerens. 1097 . Not all changes discussed on the SIN DT email list have been 1098 included - stay tuned for -02 coming up after 51st IETF. 1100 Author's addresses 1102 Vijay K. Gurbani 1103 Lucent Technologies, Inc. 1104 2000 Lucent Lane, Rm 6G-440 1105 Naperville, Illinois 60566 1106 USA 1107 Phone: +1 630 224 0216 1108 Email: vkg@lucent.com 1110 Frans Haerens 1111 Alcatel Bell 1112 Francis Welles Plein,1 1113 Belgium 1114 Phone: +32 3 240 9034 1115 Email: frans.haerens@alcatel.be 1117 Vidhi Rastogi 1118 Wipro Technologies 1119 271, Sri Ganesha Complex 1120 Hosur Main Road, Madiwala 1121 Bangalore - 560 068, INDIA 1122 Phone: +91 80 5539701 1123 Email: vidhi.rastogi@wipro.com 1125 Full Copyright Statement: 1126 This document and translations of it may be copied and furnished to others, 1127 and derivative works that comment on or otherwise explain it or assist in 1128 its implementation may be prepared, copied, published and distributed, in 1129 whole or in part, without restriction of any kind, provided that the above 1130 copyright notice and this paragraph are included on all such copies and 1131 derivative works. However, this document itself may not be modified in 1132 any way, such as by removing the copyright notice or references to the 1133 Internet Society or other Internet organizations, except as needed for the 1134 purpose of developing Internet standards in which case the procedures for 1135 copyrights defined in the Internet Standards process MUST be followed, or 1136 as required to translate it into