idnits 2.17.1 draft-ietf-spirits-lucentocc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 3) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 156 has weird spacing: '...ticular treat...' == Line 367 has weird spacing: '...ge, the corre...' == Line 416 has weird spacing: '...on with a SCP...' == Line 453 has weird spacing: '... of the newly...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft I.Faynberg 2 draft-ietf-spirits-lucentocc-00.txt H. Lu 3 February 2000 J. Voelker 4 Expires August 2000 M. Weissman 5 W. Zhang 6 Lucent Technologies 8 On a pre-SPIRITS Implementation in 9 the Lucent Technologies Online Communications Center 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes the pre-SPIRITS Implementation of the 33 SPIRITS-like services in the Lucent Technologies Online 34 Communications Center (OCC). To this end, this document is a 35 contribution to the future Informational RFC, which is to be 36 published by the SPIRITS WG as indicated in its charter. 38 On the PSTN side, the OCC platform systematically uses the 39 Intelligent Network (IN) solutions, which were industry-proven to be 40 reliable, scalable, and compatible with the existing PSTN 41 infrastructure and services, yet easily adaptable to the Internet 42 requirements. Other essential elements of the platform include the 43 use of 45 1) Session Initiation Protocol (SIP) messaging services 47 2) Point-to-Point (PPP) Protocol 49 3) Interactions with the Voice-over-IP (VoIP) Gateway and Gatekeeper 50 for establishing the combined voice path through PSTN and Internet 52 Lucent Online Communications Center February 2000 54 4) Microsoft NetMeeting (tm) software at the end-users' PCs (or 55 Internet appliances) 57 5) Java (tm) Run-Time Environment (JRE), and 59 6) 1.2 Java Native Interface (JNI) for certain security capabilities 61 1. Introduction 63 This document describes the pre-SPIRITS Implementation of the 64 SPIRITS-like services in the Lucent Technologies Online 65 Communications Center (OCC). To this end, this document is a 66 contribution to the future Informational RFC, which is to be 67 published by the SPIRITS WG as indicated in its charter. 69 The rest of this document contains the platform and service 70 description, architecture description, protocol and operations 71 considerations, and the conclusion, in respective sections numbered 2 72 through 5. Section 7 contains references, and Section 8 is the 73 appendix. 75 The authors wish to acknowledge an earlier draft [1], which started 76 the discussion of this topic and provided the information partly used 77 in this document. OCC includes the next generation of Lucent's 78 Internet Call Waiting solution described in [1]. 80 2. The OCC Platform and Its Services 82 The strength of the OCC platform is in its foundation on the 83 Intelligent Network (IN) solutions, which were industry-proven to be 84 reliable, scaleable, and compatible with the existing PSTN 85 infrastructure and services, yet easily adaptable to the Internet 86 requirements. 88 Other essential elements of the platform include the use of 90 1) Session Initiation Protocol (SIP) [2] messaging services 92 2) Point-to-Point Protocol [3] 94 3) Interactions with the Voice-over-IP (VoIP) Gateway and Gatekeeper 95 (and, consequently, the H.323 family of protocols) for establishing 96 the combined voice path through the PSTN and the Internet 98 4) Microsoft NetMeeting (tm) (version 2.1) software at the end-users' 99 PCs (or Internet appliances) 101 5) Java (tm) Run-Time Environment (JRE) and 103 6) 1.2 Java Native Interface (JNI) for certain security capabilities. 105 For the purposes of the service description, the basic components of 107 Lucent Online Communications Center February 2000 109 the OCC platform are the OCC Server and OCC Client, which are 110 described in detail in the Architecture section. The OCC Server 111 interacts with the PSTN entities over the secure intranet via plain- 112 text SIP messages. With the PC Client, the OCC Server interacts via 113 encrypted SIP messages. 115 The OCC Server run-time environment effectively consists of two 116 multi-threaded processes responsible for Call Registration and Call 117 Notification services, respectively. 119 OCC Call registration services are initiated from an end-user's PC 120 (or Internet appliance). With those, a subscriber registers for the 121 Notification services from his or her end-point. (Thus, these types 122 of services are not, strictly speaking, SPIRITS services but rather 123 have a flavor of PINT services.) 125 All OCC call notification services are PSTN-initiated. One common 126 feature of these services is that of informing the user of the 127 incoming telephone call via the Internet, without having any effect 128 on the line already used by the modem. (A typical call waiting tone 129 would interrupt the Internet connection, and it is a standard 130 practice to disable the "old" PSTN call waiting service for the 131 duration of the call in support of the Internet connection between 132 the end-user and the ISP.) 134 When a call comes in, the user is presented with a pop-up dialog box, 135 which displays the caller's number (if available), name (again, if 136 available), as well as the time of the call. If the called party does 137 not initiate an action within a specified period of time the call is 138 rejected. 140 Once informed of the incoming call, the end-user has the following 141 options (indicated in the pop-up window) as far as the disposition of 142 the call is concerned: 144 - Accept the call via the PSTN line (thus terminating the Internet 145 session) 147 - Reject the call 149 - Forwarding the call to voice mail 151 - Forwarding the call to another number (Incidentally, this feature 152 is implemented using a mechanism similar to that developed for the 153 PINT click-to-call [4].) 155 - Playing a pre-recorded message to the calling party and 156 disconnecting the call (In the future this particular treatment can 157 be modified so as to give the caller a choice of options) 159 - Answering the PSTN call via the Internet using Voice-over-IP. 160 (Microsoft's NetMeeting software is required for this feature and the 161 subscriber's PC must be equipped with a microphone and speaker 162 system.) 164 Lucent Online Communications Center February 2000 166 In addition, certain actions expected of the called party can be 167 pre-defined by the subscriber. To this end, the following features 168 have been implemented: 170 - Automatic Incoming Call Treatment: when activated, provides the 171 subscriber with the capability to pre-define a disposition that will 172 be used automatically for all incoming calls during a particular OCC 173 session. In the 'PREFERENCES' file, the subscriber can select any 174 available call treatment for this feature. If the subscriber selects 175 Mail,' all subsequent incoming calls will be subjected to the 176 selected disposition without any subscriber intervention. 178 - Intelligent Profiles: provides the subscriber with the capability 179 to determine dispositions automatically, based on the calling party 180 numbers. The subscriber selects a particular disposition for each 181 such number and stores this information in a profile. The OCC Client 182 checks the profile and sends the appropriate response to the server 183 without presenting the call to the called party. The subscriber can 184 determine the outcome of these calls from the caller log (described 185 below). 187 - Unpublished/Private Call Treatment: provides the subscriber with 188 the ability to pre-define a disposition for all incoming calls where 189 the calling party name (or number) is private or unpublished. 191 - Caller Log: provides the OCC Subscriber with a detailed log of 192 incoming calls. The caller log contains the following fields: 194 1) incoming call date and time 196 2) incoming calling party number 198 3) incoming calling party name (whenever available) and 200 4) call disposition. 202 The caller log is accessible from the OCC pull-up menu. 204 3. Architecture 206 Figure 1 of the Appendix depicts the joint PSTN/Internet physical 207 architecture relevant to OCC operation. The CSN and SCP are Lucent 208 implementations of the ITU-T IN Recommendations (in particular, the 209 Recommendation Q.1205 where these entities are defined) augmented by 210 the requirements of Bellcore's Advanced Intelligent Network (AIN) 211 Release 1.0) and equipped with other features. The Central Office may 212 be any switch supporting the Integrated Services Digital Network 213 (ISDN) Primary Rate Interface (PRI) and the call forwarding feature 214 that would allow it to interwork with the CSN. Alternatively, in 215 order to interwork with the SCP, it needs to be an IN Service 216 Switching Point (SSP) (defined in the ITU-T IN Recommendation 217 Q.1205). In the latter case, the central office is connected to the 218 SCP via signaling system No. 7 and Intelligent Network Application 220 Lucent Online Communications Center February 2000 222 Part Protocol (INAP) at the application layer. 224 The Service Management System (SMS) is responsible for provisioning 225 of the SCPs, CSNs, and central offices. In particular, for IN support 226 of the Internet Call Waiting, it must provision the Central Office to 227 direct a terminating attempt query to the subsystem number 228 corresponding to the OCC SCP SPA based on the Termination Attemp 229 Trigger (TAT). In addition the Subscriber Directory Number (DN), 230 Personal Identification Number(PIN) and Language ID are provisioned 231 for each subscriber into the OCC Subscriber entry of the SCP Real 232 Time Data Base (RTDB). The structure of an RTDB entry is presented in 233 Figure 2 of the Appendix. 235 The Central Office, SMS, CSN, and SCP are the only PSTN elements of 236 the architecture. 238 The other elements are VoIP Gateway and Gatekeeper defined in the 239 ITU-T Recommendation H.323, whose roles are to establish and provide 240 the part of the voice path over IP. The Central Office is explicitly 241 connected to the VoIP Gateway via the ISDN PRI connection. In this 242 architecture, CSN, VoIP Gateway, and VoIP Gatekeeper are the only 243 entities connected to the Internet, with each respective connection 244 protected by a firewall. The CSN and SCP are interconnected via a 245 secure IP Intranet. There may be more than one CSN or SCP (or both) 246 (and the SCPs come in mated pairs interconnected by X.25, anyway) in 247 a network, but these details are not essential to the level of 248 description chosen for this document. However, we note that load 249 balancing and adaptation to failures by the use of alternative nodes 250 is incorporated into the architecture. 252 When someone attempts to call the subscriber, the central office 253 serving that subscriber interrupts normal termination processing and 254 notifies the SCP which, in turn, can check whether that subscriber 255 has registered that he/she is logged onto the internet. Exploiting 256 the standardized layering of service logic that characterizes the 257 intelligent network, the central office will do this without 258 requiring the installation or development of any central office 259 software specific to OCC. The central office is simply provisioned to 260 query the SCP when there is a termination attempt (the so-called 261 Termination Attempt trigger -TAT) directed to the subscriber's 262 directory number. (Note that the Central Office has no bearer 263 circuit connection to the SCP, only a signaling one [over Signaling 264 System No.7]). 266 TCP/IP communication between the SCP and CSN utilizes a secure 267 intranet. The subscriber, of course, is assumed to have access only 268 to the Internet. 270 The intelligent network entities, the SCP and CSN, do have OCC 271 related software. The OCC server is implemented on the CSN. One 272 service package application (SPA) is installed on the Service 273 Control Point (SCP). The other SPA is located in the CSN and is 274 needed only when the subscriber elects to accept an incoming call via 275 VOIP. 277 Lucent Online Communications Center February 2000 279 The OCC Server is a collection of Java servers on the CSN whose 280 responsibilities include: 282 - listening for incoming Call Notification (TCP/IP) messages from the 283 SCP SPA. 285 - de-multiplexing/multiplexing incoming Call Notification messages 286 sent from the SCP SPA. 288 - relaying messages between the OCC Client and the SCP SPA. 290 - listening for and authentication of OCC Client requests for service 291 registration. 293 - handling encryption/decryption of messages exchanged with the OCC 294 Client, and generating session-specific encryption/decryption keys. 296 The OCC Client is a collection of software components that run on the 297 Subscriber's PC. Its components include the SIP User Agent Server 298 (which handles the exchange of SIP messages with the OCC Server and 299 invokes the Call Notification pop-up window) and a daemon process 300 that monitors the Point-to-Point Protocol (PPP) actions and is 301 responsible for starting and stopping the SIP User Agent Server. 303 4. Protocol and Operations Considerations 305 The OCC Server uses distinct TCP/IP ports configured on the CSN to 307 1) Listen for incoming SIP REGISTER messages (in support of 308 registration service) sent from the OCC Client 310 2) Listen for incoming SIP INVITE (in support of call notification 311 service) sent from the SCP. 313 During call notification, the SCP SPA is the client and thus is 314 started after the OCC Server has been started. The SCP SPA and OCC 315 Server exchange SIP messages over TCP/IP (via the Secure Intranet) 316 using a "nailed-up" connection which is initiated by the SCP SPA. 317 This connection is initiated at the time the SCP SPA receives the 318 very first SIP REGISTER request from the OCC Server, and must prevail 319 for as long as the SPA is in the in-service state. The SCP SPA also 320 supports restarting the connection after any failure condition. 322 The OCC Server supports multithreading. For each Call 323 Notification/Call Disposition event, a separate thread is used to 324 handle the call. This model supports multi-threading on a "per 325 message" basis where every start message (SIP INVITE) received from 326 the SCP SPA uses a separate thread of control to handle the call. 327 Subsequent messages containing the same session Call-ID (which 328 includes the SPA's instance known as "call_index" and the SCP 329 hostname) as the original start message is routed to the same thread 330 that previously handled the respective initiating message. 332 Lucent Online Communications Center February 2000 334 The OCC Server dynamically opens a new TCP/IP socket with the OCC 335 Client for each Call Notification/Call Disposition session. This 336 socket connection uses the IP address and a pre-configured port on 337 the PC running the OCC Client software. 339 For session registration, the OCC Server dynamically opens TCP/IP 340 sessions with the SCP SPA. The SCP SPA listens at a pre-configured 341 port to incoming SIP REGISTER messages sent by OCC Clients via the 342 OCC Server. To exchange SIP messages with the OCC Server, the OCC 343 Client dynamically opens a TCP/IP socket connection with the OCC 344 Server using a pre-configured port number on the CSN and the CSN's IP 345 address. 347 For the VoIP Scenario, the CSN SPA, acting as a client, dynamically 348 opens TCP/IP sessions with the SCP that handled the initial TAT 349 query. As soon as the CSN SPA has successfully made the correlation 350 and connected the two incoming call legs pertaining to a VoIP call 351 back, the SIP 180 RINGING message will be sent back to the SCP SPA 352 running on the actual SCP that instructed the SSP to forward the 353 Caller to the CSN. This SIP message, which contains the VoIP Call 354 Back DN dialed by one of the bridged call legs, is an indication to 355 the SCP SPA that the VoIP Call Back DN is freed up. 357 A typical subscription scenario works like this: 359 1) Each VoIP Gateway is provisioned with a list of authorized VoIP 360 Call Back DNs, each terminating on a particular CSN. These special 361 DNs are used when an on-line subscriber elects to receive an incoming 362 call via VOIP. In particular, they assist in routing an outgoing 363 call from the subscriber's NetMeeting to the particular CSN to which 364 to SCP is (roughly concurrently) forwarding the incoming call. 365 (These two calls are joined in the CSN to connect the incoming call 366 to the subscriber's Netmeeting client.) Furthermore, these special 367 DNs permits that CSN to associate, and hence bridge, the correct 368 pair of call legs to join the party calling the subscriber to the 369 call from the subscriber's NetMeeting client. 371 2) The subscriber calls a PSTN service provider and signs up for the 372 service 374 3) An active Terminating Attemp Trigger (TAT) is assigned to the 375 subscriber's DN at his central office. 377 4) The PSTN service provider uses the SMS to create a record for the 378 subscriber and provision the Subscriber DN and PIN in the OCC RTDB 379 table in the SCP 381 5) The subscriber is provided with the OCC Client software, a PIN and 382 a file containing the OCC Server IP Addresses. 384 At that point the subscriber can install the OCC Client software on 385 his or her PC. 387 This draft concentrates in detail on the particular scenario of the 389 Lucent Online Communications Center February 2000 391 OCC Call Disposition-namely the acceptance of the call via voice over 392 IP, which proceeds as follows: 394 1. The OCC subscriber clicks on "Accept VoIP". 396 2. The OCC Client sends a "SIP 380 Alternative Service" message to 397 the OCC Server. This message includes a reference to the Call Back 398 DN which will ultimately be used by the CSN to associate the call leg 399 (soon to be initiated by the subscriber's NetMeeting) connecting to 400 the subscriber (via the VOIP gateway) to the corresponding the PSTN 401 call leg connecting to the calling party. 403 3. The OCC Server closes the TCP/IP session with the OCC Client and 404 sends to the SCP SPA the "SIP 380 Alternative Service" message which 405 includes the Call Back DN. 407 4. The SCP SPA instructs the Central Office to forward the call 408 incoming to the subscriber to the CSN. This instruction includes the 409 Call Back DN. 411 5. The SSP forwards the Caller to the CSN referencing the Call Back 412 DN. Note the Call Back DN, originally assigned the OCC client by the 413 SCP when the subscriber was alerted to the presence of an incoming 414 call attempt, flowed next to the OCC server when the client elected 415 to receive the call via VOIP, then to the SCP, then to the central 416 office in association with a SCP command to forward the incoming 417 call to the CSN, then to the OCC server on the CSN in association 418 with that forwarded call. 420 6. Meanwhile, the OCC Client extracts 1) the VoIP Call Back DN from 421 the SIP INVITE message received during Call Notification and 2) the 422 H323UID and H323PIN values from its properties file and updates the 423 'netmtg.cnf' file. 425 7. The NetMeeting application is launched and sets up a connection 426 with the VoIP Gateway. 428 8. Once a connection is established between NetMeetingTM and the VoIP 429 Gateway, NetMeetingTM initiates a phone call - passing to the VoIP 430 Gateway the Call Back DN as the destination DN. 432 9. The VoIP Gateway consults the VoIP Gatekeeper and authenticates 433 the NetMeetingTM call by verifying the H323UID and H323PIN values, 434 and by ensuring the called DN (= Call Back DN) is authorized for use. 436 10. After passing the authentication step, the VoIP Gateway dials 437 (via PSTN) the Call Back DN and gets connected to the CSN. The CSN 438 notes that it was reached by the particular Call Back DN. 440 11. The CSN bridges the Calling and Called parties together by 441 matching on the basis of the Call Back DN. 443 12. The CSN notifies the SCP (SIP 180 Ringing) of status and 444 references the Call Back DN so that the SCP can reuse it for other 446 Lucent Online Communications Center February 2000 448 calls. 450 13. If the central office supports that two B channel transfer 451 (Lucent, Nortel, and perhaps other central office vender's do), an 452 optimization is possible. The CSN can have the central office 453 rearrange the topology of the newly connected call in such a way 454 that it flows only through the central office and no longer through 455 the CSN. 457 5. Conclusion 459 This document has described the pre-SPIRITS Implementation of the 460 SPIRITS-like services in the Lucent Technologies Online 461 Communications Center (OCC). To this end, this document is a 462 contribution to the future Informational RFC, which is to be 463 published by the SPIRITS WG as indicated in its charter. 465 6. Acknowledgements 467 We would like to thank Buddy Bright and Kumar Vemuri for providing 468 incisive comments on the draft. 470 7. References 472 [1] Brusilovsky, A., E. Gausmann, V. 473 Gurbani, A.Jain, "A Proposal for Internet Call Waiting Service using 474 SIP ," January 1999. Work in Progress. 476 [2] Handley, H., H., Schulzrinne, E. Schooler, and J. Rosenberg. 477 SIP: Session Initiation Protocol. RFC 2543. March, 1999 479 [3] Simpson, W. The Point-to-Point Protocol (PPP). RFC 1661. July, 480 1994. 482 [4] . Petrack, S. and L. Conroy, The 483 PINT Service Protocol: Extensions to SIP and SDP for IP Access to 484 Telephone Call Services. Work in Progress. October, 1999 486 Lucent Online Communications Center February 2000 488 8. Appendix 490 ------------------------- 491 |PC or Network Appliance| (OCC Client) 492 ------------------------- 493 | -------------- 494 +---| Internet | 495 -------------- 496 | 497 ---------------- 498 | Compact | -------------- 499 | Service | | Service | 500 | Node (CSN) |------------| Management | 501 | OCC Server | | System(SMS)| 502 | OCC CSN SPA | -------------- 503 | | : 504 |______________|-------[ IP INTRANET ]----------------------+ 505 | | | : | 506 | | | .................. | 507 --------- | | -------- 508 |Central|--|-------|------------------------|Service| 509 |Office | | | |Control| 510 ---|----- | | |Point | 511 | | | | (SCP) | 512 ---|----- | -----|-------- | | 513 | VoIP |--+ | VoIP | |OCC SCP| 514 |Gateway| | Gatekeeper | | SPA | 515 --------- -------------- --------- 517 Figure 1: OCC Physical Architecture 519 -------------------------------------------------------- 520 DN | PIN | IP Address | Session Key | CNF | Language ID | 521 -------------------------------------------------------- 523 Field Descriptions: 525 (DN) Directory Number - The subscriber's telephone number 527 (PIN) Personal Identification Number - The subscriber's password 529 IP Address - Internet Protocol Address of the subscriber 531 (CNF) Call Notification In Progress Flag(boolean) - Indicates if an 532 attempt to notify the subscriber of a call is currently in progress 534 Session Key - Unique Identifier for the current registration session 535 of the subscriber 537 Language ID - Language Identifier for the subscriber 539 Figure 2: Structure of the RTDB Subscriber Record 541 Lucent Online Communications Center February 2000 543 9. Authors' Addresses 545 Igor Faynberg 546 Lucent Technologies 547 Room 4L-334 548 101 Crawfords Corner Road 549 Holmdel, NJ 07733-3030 US 550 E-mail: faynberg@lucent.com 551 Telephone: +1 732 949 0137 553 Hui-Lan Lu 554 Lucent Technologies 555 Room 4L-317 556 101 Crawfords Corner Road 557 Holmdel, NJ 07733-3030 US 558 E-mail: huilanlu@lucent.com 559 Telephone: +1 732 949 0321 561 John Voelker 562 Lucent Technologies 563 Room 1A-417 564 263 Shuman Blvd PO Box 3050 565 Naperville, IL 60566-7050 566 E-mail: jvoelker@lucent.com 567 Telephone: +1 630 713 5538 569 Mark Weissman 570 Lucent Technologies 571 SUITE 500 572 2000 Regency Pky 573 Cary, NC 27511-8506 US 574 E-mail: maw1@lucent.com 575 Telephone: +1 919 380 6813 577 Weizhong Zhang 578 Lucent Technologies 579 Room 01-A5-17 580 2000 Regency Parkway 581 Cary, NC 27511-8506 582 E-Mail: wzz@lucent.com 583 Telephone: +1 919 380-6638 585 Lucent Online Communications Center February 2000