ECMA TR 68-1994 Scenarios for Computer Supported Telecommunications Applications (CSTA) Phase II《计算机支持的电信应用(CSTA)第II阶段的情境》.pdf

《ECMA TR 68-1994 Scenarios for Computer Supported Telecommunications Applications (CSTA) Phase II《计算机支持的电信应用(CSTA)第II阶段的情境》.pdf》由会员分享，可在线阅读，更多相关《ECMA TR 68-1994 Scenarios for Computer Supported Telecommunications Applications (CSTA) Phase II《计算机支持的电信应用(CSTA)第II阶段的情境》.pdf（68页珍藏版）》请在麦多课文档分享上搜索。

1、ECMA Technical Report TR/68December 1994Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chScenarios for ComputerSupported TelecommunicationsApplications (CSTA) Phase IIECMA Technical Report TR/68Dece

2、mber 1994Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chMonica Broxner - TR-068.DOC - 03.05.95 16,09Scenarios for ComputerSupported TelecommunicationsApplications (CSTA) Phase IIBrief HistoryThis

3、Technical Report is based upon Phase II of Services for Computer Supported Telecommunications Applications (CSTA)and introduces CSTA Scenarios. This Technical Report uses Standards ECMA-217 Services for Computer SupportedTelecommunications Applications Phase II and ECMA-218 Protocol for Computer Sup

4、ported TelecommunicationsApplications Phase II to illustrate how CSTA services and events may be used in typical call scenarios. It reflects a commonunderstanding of ECMA member companies. Additional phases of this Technical Report are anticipated. This TechnicalReport is based on the practical expe

5、rience of ECMA member companies and represents a pragmatic and widely-basedconsensus.The Phase II CSTA standards are not fully backwards compatible with the Phase I standards. Although backwardscompatibility is an important consideration and has been maintained whenever possible, the addition of new

6、 parameters incertain services and events, as well as the deletion of unused Phase I services and the addition of entirely new Phase IIservices and events, did not allow complete backwards compatibility.This Technical Report is dedicated to the memory of Terry WuerfelThis ECMA Technical Report has b

7、een adopted by the ECMA General Assembly of December 1994.- i -Table of contentsPage1 Scope 12 References 13 Make Call Scenarios 33.1 Successful Make Call 33.2 Successful manual Call (Off-hook dialling) 53.3 Make Call meets Called Party Busy 63.4 Make Call meets Calling Party Busy 83.5 Make Call mee

8、ts no answer 93.6 Make Call to an invalid number 113.6.1 Make Call to an invalid number - User already off-hook 123.7 Make Call encounters Privilege Violation on Calling Device 133.7.1 Make Call encounters Privilege Violation on Calling Device - User off-hook 143.7.2 Make Call encounters Privilege V

9、iolation on Called Device 153.7.3 Make Call encounters Privilege Violation on Called Device - User off-hook 163.8 Offnode Make Call (Networked reached) 173.9 Make Call while listening to Dial tone 183.10 Make Call Hands-free operation 193.11 Successful manual Offnode Call (“Overlap“ off-hook diallin

10、g) 204 Successful ISDN (“En-bloc“) Call 215 Call Release Scenarios 235.1 Call Release 235.2 The CSTA Blocked Call State 246 Consultation Calls 256.1 Successful Consultation Call 256.2 Consultation Call Rejected 276.3 Consulted party busy 286.4 Consulted party clears - consulting party receives dial

11、tone 306.5 Held party clears 317 Successful Alternate Call 328 Transfers 338.1 Successful Supervised Transfer 338.2 Successful Unsupervised Transfer 348.3 Single Step Transfer 35- ii -8.4 Transfer on Busy 379 Conference Calls 399.1 Conference Call Service 399.2 Multiple Party (Meet Me) Conference 40

12、9.3 Single Step Conference 4210 Divert Deflection Service 4311 Call Completion Service 4412 A Manually Invoked Call Park 4613 Route Services 4713.1 Route Request Service 4713.2 Route Used Service 4913.3 Re-Route Service 5114 Incoming Calls 5314.1 Successful incoming Call 5314.2 Incoming call to ACD

13、with no available agents 551 ScopeServices for Computer Supported Telecommunications Applications are defined by Standard ECMA-217 and theProtocol for those services by Standard ECMA-218. Our intention here is to illustrate how, for a range of callscenarios, the services offered by ECMA CSTA are int

14、ended to be used by application developers and switchmanufacturers.Each scenario includes a textual description and an illustration. Illustrations use the same key as described withinECMA-217 section 9.3. For each scenario, message sequences are listed for all monitored devices - call typemonitors h

15、ave not been illustrated. All devices have device type monitors set with no events masked. The Activitycolumn includes a brief description of the event or service invocation, the Monitored Device column lists events andservice invocations with the associated parameter list. Optional parameters withi

16、n the Monitored Device column areshown in italics. DeviceIDs are illustrated by Dn and ConnectionIDs in the form DnCn. All Device IDs are withinthe same switching sub-domain unless otherwise indicated or stated. Any exception comments are made in the finalcolumn Comments.CSTA provides an event repor

17、ting service which contains three parameters. These parameters, crossRefIdentifier,eventSpecificInfo and extensions are fully defined by ECMA-218. Within these scenarios only the content of theeventSpecificInfo parameter within the CSTA Event Reporting Service is shown.These scenarios show a strict

18、order of messaging (i.e. a service request is always followed by a serviceacknowledgement). However, in a true implementation an acknowledgement to a service request may be received inan asynchronous mode by the computing function. Events are generated throughout the life of a call and as suchrepres

19、ent in these scenarios the passing of time.The precise moment in relation to the switching function activity at which a response is generated, shall beimplementation- and Service- dependent. For example, for the Hold Call Service some implementations maygenerate the Service Response after validating

20、 the correctness of the request and when they initiate the requestedService. Other implementations may delay the response until the Hold has completed (or is guaranteed to complete).In this case, a failure of the requested switching Service is reflected in the Service Response.The scenarios are only

21、 for information and as such ECMA-217 (Services) and ECMA-218 (Protocol) standards maydefine additional options or parameters. The purpose of this Technical Report is to provide examples of some CSTAService invocations and illustrate associated call event reports. It is not an exhaustive document an

22、d someimplementations may not perform as illustrated within this document. A method of providing these scenarios as acollection of smaller building blocks which may then be connected together to form more complex scenarios is understudy.SubjectDeviceID is used in some event reports to specify which

23、device the report refers to. If the SubjectDeviceID hashad a monitor invoked upon it then this data is not required and so the implicit NULL encoding for notRequiredshould be returned, as defined by ECMA-218. In these scenarios, as all devices have active device monitors, theSubjectDeviceID is shown

24、 as /NR to indicate Not Required. NK is used to indicate notKnown where appropriate.Within these Scenarios, ( ) indicates that the content is not specified by these scenarios and that anything definedwithin the protocol is valid.2 ReferencesECMA TR/52 Computer Supported Telecommunications Applicatio

25、ns (CSTA) (1990)ECMA-217 Services for Computer Supported Telecommunications Applications (CSTA) Phase II (1994)ECMA-218 Protocol for Computer Supported Telecommunications Applications (CSTA) Phase II (1994)- 2 - 3 -3Make Call Scenarios This section includes examples ofsuccessful Make Calls, initiate

26、d manuallyand byapplications, Make Calls byand tobusy parties and calls which donot getanswered. There are four examples ofcalls rejected because ofprivilege violations. Calls made todevices outside ofthe CSTA domain and anISDN en-bloccall are illustrated. A Make Call Response, positive ornegative,

27、may indicate the result ofthe Make Call Request. For some switch implementations the resultof the request is determined from the CSTA events which follow the Make Call Response.3.1Successful Make Call This scenario initiates acall from device D1to device D2. Inthis scenario both devices are free and

28、 valid, device D1ispermitted tomake the call and thecall reaches establishment. BEFOREAFTERD1C1D1D2D2ccActivityMONITORED DEVICE D1MONITORED DEVICE D2MONITORED DEVICE D3CommentsA MakeCall to a valid device is invoked on behalf of device D1.MakeCallRequest callingDevice calledDirectoryNumber devicePro

29、file accountCode authCode correlatorData extensionsD1 D2 ( ) ( ) ( ) ( ) ( )Acknowledgement.MakeCallResult initiatedCall extensionsD1C1 ( )Indication that service has been initiated from this device.ServiceInitiatedEvent initiatedConnection localConnectionInfo causeD1C1 Initiated makeCallThe generat

30、ion of this event is switch-specific.Device D1 lifts handset ready for call.OriginatedEvent originatedConnection callingDevice calledDevice originatingDevice localConnectionInfo correlatorData causeD1C1 D1/NR D2 ( ) Connected ( ) newCallDevice D2 begins to ring and D1 listens to ringing tone.Deliver

31、edEvent connection alertingDevice callingDevice calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2 D1 D2 NR ( ) Connected ( ) newCallDeliveredEvent connection alertingDevice callingDevice calledDevice lastRedirectionDevice originatingConnection l

32、ocalConnectionInfo correlatorData causeD2C1 D2/NR D1 D2 NR ( ) Alerting ( ) newCall- 4 -Device D2 answers the call.EstablishedEvent establishedConnection answeringDevice callingDevice calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2 D1 D2 NR (

33、) Connected ( ) newCallEstablishedEvent establishedConnection answeringDevice callingDevice calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2/NR D1 D2 NR ( ) Connected ( ) newCallDevice D2 manually answers the call by lifting handset.- 5 -3.2Suc

34、cessful manual Call (Off-hook dialling) In this scenario the instrument associated with device D1 is manually lifted to initiate acall from device D1todevice D2. Both devices are initially free andvalid, device D1 is permitted to make the call and the call reaches establishment. BEFOREAFTERD1C1D1D2D

35、2ccActivityMONITORED DEVICE D1MONITORED DEVICE D2MONITORED DEVICE D3CommentsDevice D1 goes off-hook and receives dial tone.ServiceInitiatedEvent initiatedConnection localConnectionInfo causeD1C1 Initiated newCallDevice is authorised to make calls. This event is always generated for a manual MakeCall

36、.Dialling completed - call set-up taking place.OriginatedEvent originatedConnection callingDevice calledDevice originatingDevice localConnectionInfo correlatorData causeD1C1 D1/NR D2 ( ) Connected ( ) newCallDevice D2 is free and begins to ring.DeliveredEvent connection alertingDevice callingDevice

37、calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2 D1 D2 NR ( ) Connected ( ) newCallDeliveredEvent connection alertingDevice callingDevice calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2/N

38、R D1 D2 NR ( ) Alerting ( ) newCallAssuming that no diverts are in operation.AnswerCall service is invoked on behalf of device D2.AnswerCallRequest callToBeAnswered extensionsD2C1 ( )An error will be sent if the device is not able to answer the call without manual intervention.Acknowledgement.Answer

39、CallResult extensions()Device D2 answers the call.EstablishedEvent establishedConnection answeringDevice callingDevice calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2 D1 D2 NR ( ) Connected ( ) newCallEstablishedEvent establishedConnection ans

40、weringDevice callingDevice calledDevice lastRedirectionDevice originatingConnection localConnectionInfo correlatorData causeD2C1 D2/NR D1 D2 NR ( ) Connected ( ) newCall- 6 -3.3Make Call meets Called Party Busy The application initiates a call from device D1 to device D2. Device D1 is prompted tolif

41、t the handset. Device D2isbusy and has not invoked adivert. Thecall fails because the called party is busy. Device D1clears without invoking asupplementary service. Inthis scenario the fact that device D2isbusy isnotindicated in the MakeCallResult but by a subsequence of event reports. BEFOREAFTERD1

42、C1D1D2D2cfActivityMONITORED DEVICE D1MONITORED DEVICE D2MONITORED DEVICE D3CommentsMakeCall service is invoked on behalf of device D1.MakeCallRequest callingDevice calledDirectoryNumber deviceProfile accountCode authCode correlatorData extensionsD1 D2 ( ) ( ) ( ) ( ) ( )Acknowledgement.MakeCallResul

43、t initiatedCall extensionsD1C1 ( )Device D1 notified of initiating call.ServiceInitiatedEvent initiatedConnection localConnectionInfo causeD1C1 Initiated makeCallThe generation of this event is switch-specific.Device D1 lifts handset and establishes the calling connection of the call.OriginatedEvent

44、 originatedConnection callingDevice calledDevice originatingDevice localConnectionInfo correlatorData causeD1C1 D1/NR D2 ( ) Connected ( ) newCallDevice D2 is busy - the call cannot be completed. Device D1 hears busy tone.FailedEvent failedConnection failingDevice calledDevice localConnectionInfo co

45、rrelatorData causeD2C1 D2 D2 Connected ( ) BusyFailedEvent failedConnection failingDevice calledDevice localConnectionInfo correlatorData causeD2C1 D2/NR D2 Failed ( ) BusyDevice D1 now replaces handset.ConnectionClearedEvent droppedConnection releasingDevice localConnectionInfo correlatorData cause

46、D1C1 D1/NR Null ( ) normal ClearingConnectionClearedEvent droppedConnection releasingDevice localConnectionInfo correlatorData causeD1C1 D1 Failed ( ) normal Clearing- 7 -Failed connection D2C1 also clears.ConnectionClearedEvent droppedConnection releasingDevice localConnectionInfo correlatorData ca

47、useD2C1 D2 Null ( ) normal ClearingFailed connections must also clear and therefore report clear connection events.- 8 -3.4Make Call meets Calling Party Busy CSTA Make Call fails because the calling party, device D1, is busy onacall todevice D2when aMakeCallRequest isissued onbehalf ofdevice D1. Onc

48、ertain types of device the switch may beable to launch the call on aseparate line appearance. This operation is implementation-dependent and isthereforenot illustrated here. BEFOREAFTERD1C1D1C1D2D2D3D3*ActivityMONITORED DEVICE D1MONITORED DEVICE D2MONITORED DEVICE D3CommentsUser initiates Make Call.

49、MakeCallRequest callingDevice calledDirectoryNumber deviceProfile accountCode authCode correlatorData extensionsD1 D3 ( ) ( ) ( ) ( ) ( )Make Call fails because calling party is busy.MakeCallError stateErrorsinvalid object state- 9 -3.5Make Call meets no answer The application initiates acall from device D1