SIST ETS 300 260 E1:2005
(Main)Private Telecommunication Network (PTN); Specification, functional models and information flows; Call transfer supplementary service [ISO/IEC 13865 (2003) modified]
Private Telecommunication Network (PTN); Specification, functional models and information flows; Call transfer supplementary service [ISO/IEC 13865 (2003) modified]
Contains stage 1 and 2 description of the explicit call transfer supplementary service. See ECMA DTR/ECMA-0002 (ECMA-TR/SVC) for a description of the explict call transfer supplementary service. See ENV 41 005 for definition of stages 1 and 2.
Zasebno telekomunikacijsko omrežje (PTN) – Specifikacija, funkcijski modeli in informacijski pretoki - Dopolnilna storitev: predaja klica
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Zasebno telekomunikacijsko omrežje (PTN) – Specifikacija, funkcijski modeli in informacijski pretoki - Dopolnilna storitev: predaja klicaPrivate Telecommunication Network (PTN); Specification, functional models and information flows; Call transfer supplementary service [ISO/IEC 13865 (2003) modified]33.040.35Telefonska omrežjaTelephone networksICS:Ta slovenski standard je istoveten z:ETS 300 260 Edition 1SIST ETS 300 260 E1:2005en01-maj-2005SIST ETS 300 260 E1:2005SLOVENSKI
STANDARD
SIST ETS 300 260 E1:2005
EUROPEANETS 300 260TELECOMMUNICATIONNovember 1993STANDARDSource: ETSI TC-ECMAReference: DE/ECMA-00004ICS:33.080Key words:PTN, ECMA-177, CTSDPrivate Telecommunication Network (PTN);Specification, functional models and information flowsCall transfer supplementary serviceETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEX.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.frTel.: +33 92 94 42 00 - Fax: +33 93 65 47 16Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1993. All rights reserved.SIST ETS 300 260 E1:2005New presentation - see History box
Page 2ETS 300 260: November 1993Whilst every care has been taken in the preparation and publication of this document, errors in content,typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to"ETSI Editing and Committee Support Dept." at the address shown on the title page.SIST ETS 300 260 E1:2005
Page 3ETS 300 260: November 1993Table of contentsForeword71 Scope92 Conformance93 References94 Definitions104.1 External definitions104.2 Additional network feature104.3 Alerting104.4 Answered114.5 Call, Basic call114.6 Primary call114.7 Secondary call114.8 Transfer by join114.9 Transfer by rerouting114.10 User A114.11 User B114.12 User C115 List of acronyms116 SS-CT stage 1 specification126.1 Description126.1.1 General description126.1.2 Qualifications on applicability to telecommunications services126.2 Procedures126.2.1 Provision/withdrawal126.2.2 Normal procedures126.2.2.1 Activation/Deactivation/Registration/Interrogation126.2.2.2 Invocation and Operation126.2.3 Exceptional procedures136.2.3.1 Activation/Deactivation/Registration/Interrogation136.2.3.2 Invocation and operation136.3 Interactions with other supplementary services and ANFs136.3.1 Calling Line Identification Presentation (SS-CLIP)136.3.2 Connected Line Identification Presentation (SS-COLP)136.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)136.3.4 Calling Name Identification Presentation (SS-CNIP)136.3.5 Connected Name Identification Presentation (SS-CONP)146.3.6 Calling/Connected Name Identification Restriction (SS-CNIR)146.3.7 Call Forwarding Services146.3.8 Path Replacement (ANF-PR)146.4 Interworking considerations146.4.1 User B and/or User C in another network146.4.2 User A in another network146.5 Overall SDL157 SS-CT stage 2 specification for transfer by join157.1 Functional model157.1.1 Functional model description157.1.2 Description of Functional Entities167.1.2.1 Transfer Invoke Functional Entity, FE1167.1.2.2 Transfer Execute Functional Entity, FE216SIST ETS 300 260 E1:2005
Page 4ETS 300 260: November 19937.1.2.3 Transfer Complete Receive Functional Entity, FE3167.1.2.4 Transfer Notification Receive Functional Entity FE4167.1.3 Relationship of Functional Model to Basic Call Functional Model177.2 Information flows177.2.1 Definition of information flows177.2.1.1 Transfer Invoke177.2.1.2 Transfer Complete187.2.1.3 Transfer Active187.2.1.4 Transfer Notify197.2.1.5 Terminal Details207.2.1.6 Transfer Update207.2.2 Relationship of information flows to basic call information flows207.2.3 Examples of information flow sequences207.2.3.1 Successful Call Transfer (both calls answered)217.2.3.2 Successful Call Transfer (user C alerting)227.3 Functional Entity actions227.3.1 Functional Entity actions of FE1227.3.2 Functional Entity actions of FE2237.3.3 Functional Entity actions of FE3237.3.4 Functional Entity actions of FE4237.4 Functional Entity behaviour237.4.1 Behaviour of FE1247.4.2 Behaviour of FE2257.4.3 Behaviour of FE3267.4.4 Behaviour of FE4277.5 Allocation of Functional Entities to Physical Locations287.6 Interworking considerations288 SS-CT stage 2 specification for transfer by rerouting298.1 Functional model298.1.1 Functional model description298.1.2 Description of Functional Entities308.1.2.1 Transfer Invoke Functional Entity, FE1308.1.2.2 Transfer Notification Receive Functional Entity, FE4308.1.2.3 Transfer Co-ordinate Functional Entity, FE5308.1.2.4 Transfer Associate Functional Entity, FE6308.1.2.5 Transfer Execute Functional Entity, FE7308.1.3 Relationship of Functional Model to Basic Call Functional Model308.2 Information flows318.2.1 Definition of information flows318.2.1.1 Transfer Invoke318.2.1.2 Transfer Identify318.2.1.2.1 Meaning of Transfer Identify318.2.1.2.2 Information content of Transfer Identify318.2.1.3 Transfer Abandon328.2.1.3.1 Meaning of Transfer Abandon328.2.1.3.2 Information content of Transfer Abandon328.2.1.4 Transfer Initiate328.2.1.4.1 Meaning of Transfer Initiate328.2.1.4.2 Information content of Transfer Initiate328.2.1.5 Transfer Setup338.2.1.5.1 Meaning of Transfer Setup33SIST ETS 300 260 E1:2005
Page 5ETS 300 260: November 19938.2.1.5.2 Information content of Transfer Setup338.2.1.6 Transfer Notify348.2.1.7 Terminal Details348.2.2 Relationship of information flows to basic call information flows348.2.3 Examples of information flow sequences348.2.3.1 Successful Call Transfer (answered)358.2.3.2 Successful Call Transfer (alerting)368.2.3.3 Unsuccessful Call Transfer (setup fails)378.3 Functional Entity actions388.3.1 Functional Entity actions of FE1388.3.2 Functional Entity actions of FE5388.3.3 Functional Entity actions of FE6388.3.4 Functional Entity actions of FE7388.3.5 Functional Entity actions of FE4398.4 Functional Entity behaviour398.4.1 Behaviour of FE5398.4.2 Behaviour of FE6418.4.3 Behaviour of FE7428.5 Allocation of Functional Entities to Physical Locations43Annex A (informative): Relationship to corresponding ETSs for Public ISDNs44Annex B (informative): Bibliography45History46SIST ETS 300 260 E1:2005
Page 6ETS 300 260: November 1993Blank pageSIST ETS 300 260 E1:2005
Page 7ETS 300 260: November 1993ForewordThis European Telecommunication Standard (ETS) has been produced by the European ComputerManufacturers Association (ECMA) on behalf of its members and those of the EuropeanTelecommunications Standards Institute (ETSI).This ETS is one of a series of standards defining services and signalling protocols applicable toPrivate Telecommunication Networks (PTNs) incorporating one or more interconnected nodes. Theseries uses the ISDN concepts as developed by CCITT and is also within the framework of standardsfor open systems interconnection as defined by ISO.This particular ETS specifies the Call Transfer supplementary service.The ETS is based upon the practical experience of ECMA member companies and the results of theiractive and continuous participation in the work of ISO, CCITT, ETSI and other international andnational standardisation bodies. It represents a pragmatic and widely based consensus.The service specified is compatible with the equivalent service specified by CCITT and ETSI forpublic ISDNs. The CCITT stage 1 specification of this service is to be found in Blue BookRecommendation I.252 (part 1). ETSI specifications for public ISDNs are to be found in draftprETS 300 367 (stage 1) and draft prETS 300 368 (stage 2). Annex A describes the relationshipbetween this ETS and the corresponding ETSs for the public ISDN.This ETS was produced by ECMA using the ECMA guidelines for the production of standards andusing the ECMA stylesheet. In order to avoid undue delays in the voting process for this ETS it hasbeen agreed that this ETS will not be converted to the ETSI stylesheet.SIST ETS 300 260 E1:2005
Page 8ETS 300 260: November 1993Blank pageSIST ETS 300 260 E1:2005
Page 9ETS 300 260: November 19931ScopeThis ETS specifies Supplementary Service Call Transfer (SS-CT), which is applicable tovarious basic services supported by Private Telecommunication Networks (PTNs). Basicservices are specified in ETS 300 171.SS-CT is a supplementary service which enables a user to transform two of that user's callsinto a new call between the other two users of these two calls.Service specifications are produced in three stages, according to the method described inENV 41005. This ETS contains the stage 1 and stage 2 specifications of SS-CT. The stage 1specification (clause 60) specifies the supplementary service as seen by users of PTNs. Thestage 2 specification (clauses 70 and 80) identifies the functional entities involved in thesupplementary service and the information flows between them.This ETS contains two stage 2 specifications reflecting different ways of operating the servicewithin the network: transfer by join and transfer by rerouting.2ConformanceIn order to conform to this ETS, a stage 3 standard shall specify signalling protocols andequipment behaviour that are capable of being used in a PTN which supports thesupplementary service specified in this ETS. This means that, to claim conformance, a stage 3standard is required to be adequate for the support of those aspects of clause 6 (stage 1) andclauses 70 and 80 (stage 2) which are relevant to the interface or equipment to which the stage3 standard applies.The requirement that clause 7 (transfer by join) be supported by a stage 3 standard is in orderto provide a basic method of implementing SS-CT. The requirement that clause 80 (transfer byrerouting) be supported by a stage 3 standard is in order to provide an optional method ofimplementing SS-CT which includes an attempt at rerouting the connection between the twotransferred users in order to optimise the use of network resources, with fall-back to transferby join if rerouting is not possible.3ReferencesENV 41005Method for the specification of basic and supplementary services ofprivate telecommunication networks (1989).ENV 41007Definition of terms in private telecommunication networks (1989).ETS 300 171Private Telecommunication Network (PTN); Specification,functional models and information flows, Control aspects of circuitmode basic services (1992).ETS 300 173Private Telecommunication Network (PTN); Specification,functional models and information flows, Identificationsupplementary services (1992).ETS 300 237Private Telecommunication Network (PTN); Specification,functional models and information flows, Name identificationsupplementary services (1993).CCITT Recommendation I.112Vocabulary of terms for ISDNs (1988).CCITT Recommendation I.210Principles of telecommunication services supported byan ISDN and the means to describe them (1988).CCITT Recommendation Z.100Specification and description language (1988).SIST ETS 300 260 E1:2005
Page 10ETS 300 260: November 19934DefinitionsFor the purpose of this ETS the following definitions apply.4.1External definitionsThis ETS uses the following terms defined in other documents:-Basic Service(CCITT Recommendation I.210);-Connection(CCITT Recommendation I.112);-Private(ENV 41007);-Private Telecommunication Network Exchange (PTNX)(ENV 41007);-Public(ENV 41007);-Public ISDN(ENV 41007);-Service(CCITT Recommendation I.112);-Signalling(CCITT Recommendation I.112);-Supplementary Service(CCITT Recommendation I.210);-Telecommunication Network(ENV 41007);-Terminal, Terminal equipment(ENV 41007);-User(ETS 300 171).This ETS refers to the following basic call functional entities (FEs) defined in ETS 300 171:-Call Control (CC);-Call Control Agent (CCA).This ETS refers to the following basic call inter-FE relationships defined in ETS 300 171:-r1;-r2;-r3.This ETS refers to the following basic call information flows defined in ETS 300 171:-Channel_Acknowledge request/indication;-Release request/indication;-Release response/confirmation;-Setup request/indication;-Setup response/confirmation.This ETS refers to the following basic call information flow elements defined in ETS 300171:-Call History (CH);-Connected Number (CN);-Connected Subaddress (CS);-Destination Category (DC).This ETS refers to the following Connected Line Identification Presentation informationflow elements defined in ETS 300 173:-Connected Number (CN);-Connected Subaddress (CS).4.2Additional network featureA capability, over and above that of a basic service, provided by a PTN, but not directly to aPTN user.4.3AlertingThe state of the secondary call when the called user is being alerted but has not yetanswered.SIST ETS 300 260 E1:2005
Page 11ETS 300 260: November 19934.4AnsweredThe state of the primary or secondary call after the called user has answered.4.5Call, Basic callAn instance of the use of a basic service.4.6Primary callOne of the calls involved in the transfer. In the case of a transfer involving an unansweredcall, the primary call is the answered call. In the case where both calls are alreadyanswered, the primary call is chosen arbitrarily by the network.4.7Secondary callThe other call involved in the transfer.4.8Transfer by joinThe effecting of transfer by joining together the connections of the primary and secondarycalls at user A's PTNX.4.9Transfer by reroutingThe effecting of transfer by establishing a new connection to replace all or part of theconnections of the primary and secondary calls.4.10User AThe served user, i.e. the user requesting Call Transfer.4.11User BThe other user in user A's primary call.4.12User CThe other user in user A's secondary call.5List of acronymsAIAlerting IndicationCCCall Control (functional entity)CCACall Control Agent (functional entity)CHCall History (information flow element)CICall Identities (information flow element)CIDCall Identity (information flow element)CNConnected Number (information flow element)CSConnected Subaddress (information flow element)CUGClosed User GroupDCDestination Category (information flow element)EDEnd Designation (information flow element)FEFunctional EntityISDNIntegrated Services Digital NetworkPTNXPrivate Telecommunication Network ExchangeRNRerouting Number (information flow element)SDLSpecification and Description LanguageSS-CTSupplementary Service Call TransferTETerminal EquipmentTIDRTransfer Identity Result (information flow element)TINRTransfer Initiate Result (information flow element)TIVRTransfer Invoke Result (information flow element)SIST ETS 300 260 E1:2005
Page 12ETS 300 260: November 19936SS-CT stage 1 specification6.1Description6.1.1General descriptionSS-CT is a supplementary service which enables a served user (user A) to transform twoof that users calls into a new call between the other two users of the two calls (user B anduser C). Each call can be either an incoming call to user A or an outgoing call from userA. After successful invocation of SS-CT user B and user C will be able to communicatewith each other and user A will no longer be able to communicate with user B and user C.One of the calls may be an outgoing call that has not been answered by the other user(user C). After successful invocation of SS-CT user A will no longer be able tocommunicate with user B. User B and user C will be in a position to communicate witheach other as soon as user C has answered.NOTE 1The establishment of either call as part of a request for transfer is outside the scope ofthis ETS. This ETS assumes that both calls have already been established when therequest for call transfer is made. This does not preclude an implementation whereby asingle user request causes the establishment of a call and its subsequent transfer.6.1.2Qualifications on applicability to telecommunications servicesSS-CT is applicable to all basic services defined in ETS 300 171.6.2Procedures6.2.1Provision/withdrawalSS-CT shall be generally available. There is no need for service profile control.6.2.2Normal procedures6.2.2.1Activation/Deactivation/Registration/InterrogationNot applicable.6.2.2.2Invocation and OperationA Call Transfer request from a user (user A) shall be accepted only if it identifies twoof that user's calls where:-both calls (to/from user B and to/from user C) have been answered; or-one call (to/from user B) has been answered and the other is an outgoing call whichis alerting user C; or-one call (to/from user B) has been answered and the other is an unansweredoutgoing call to user C in a non-ISDN.It shall not be necessary for user A to place either call on hold prior to invocation,although either or both calls may be held.The network shall ensure that the transfer attempt does not allow an illegal connectionto be made, for example one which would infringe CUG restrictions between user Band user C, or one which would result in a connection with incompatible bearercapabilities.NOTE 2It is user A's responsibility to ensure that the two calls are otherwise compatible.Bearer capabilities shall not be considered compatible if they are the same. Bearercapabilities shall also be considered compatible if the only attribute that differs isinformation transfer capability and if one call has the value "speech" and the other callis interworking with a non-ISDN and has the value "3.1 kHz Audio".SIST ETS 300 260 E1:2005
Page 13ETS 300 260: November 1993NOTE 3The provision of interworking functions between different bearer capabilities isoutside the scope of this ETS.The result of successful Call Transfer shall be a new call between users B and C, atwhich point the original connections to user A shall be released. Both users B and Cshall be informed of the transfer and the name and number of the other user (ifavailable and not subject to restriction), and whether the other user is still beingalerted.The network shall permit sub-addresses to be exchanged between user B and user Cafter transfer.If user C is being alerted at the time of completion of transfer, it shall continue to bealerted, and on answer shall be connected to user B.NOTE 4If the call resulting from the invocation of Call Transfer before answer fails toprogress to the answered state within a certain time other actions can be taken, e.g.user A can be recalled and on answer be connected to user B. The definition ofprocedures to support recall is outside the scope of this ETS.6.2.3Exceptional procedures6.2.3.1Activation/Deactivation/Registration/InterrogationNot applicable.6.2.3.2Invocation and operationCall Transfer shall be rejected under the following circumstances:-if invalid call identities are specified;-if neither of the calls is answered;-if only one call is answered and the other is not an outgoing call which is eitheralerting a distant user or interworking with a non-ISDN;-if the two calls have incompatible bearer capabilities;-if interconnection of user B and user C is not permitted.If transfer is rejected, user A shall be informed of the reason and the existing callsshall be unaffected.6.3Interactions with other supplementary services and ANFsInteractions with other supplementary services and ANFs for which PTN standards wereavailable at the time of publication of this ETS are specified below.6.3.1Calling Line Identification Presentation (SS-CLIP)No interaction.6.3.2Connected Line Identification Presentation (SS-COLP)No interaction.6.3.3Calling/Connected Line Identification Restriction (SS-CLIR)User B's and C's restriction requirements from the original call shall be used to restrictthe presentation of that user's number to the other user in a transferred call.6.3.4Calling Name Identification Presentation (SS-CNIP)No interaction.SIST ETS 300 260 E1:2005
Page 14ETS 300 260: November 19936.3.5Connected Name Identification Presentation (SS-CONP)No interaction.6.3.6Calling/Connected Name Identification Restriction (SS-CNIR)User B's and C's restriction requirements from the original call shall be used to restrictthe presentation of that user's name to the other user in a transferred call.6.3.7Call Forwarding ServicesIf Call Transfer occurs while user C is being alerted, the resulting call can subsequentlyundergo Call Forwarding on No Reply.Call Transfer shall not affect the way in which chains of forwarding are controlled. Thusany hop counter value maintained in order to determine whether a forwarding may occurshall have the same value after transfer as it had prior to the transfer. The fact that atransfer has taken place shall not affect the way in which the counter value issubsequently modified due to forwarding.6.3.8Path Replacement (ANF-PR)No interaction.NOTE 5Path Replacement may be invoked as a direct consequence of performing transfer if thetransfer is achieved by joining as opposed to rerouting.6.4Interworking considerationsCall Transfer may take place when one or both of the calls involves interworking with apublic ISDN or a public or private non-ISDN.6.4.1User B and/or User C in another networkSince the execution of the Call Transfer service need only involve the interconnectionwithin the PTN of one end of each of two established connections, the nature of thenetwork (ISDN or non-ISDN) containing user B or user C makes no difference to theoperation of the service as seen by user A.The PTN shall pass on any notifications associated with the transfer to the other networkif the other network is capable of receiving this information, the possibilities being thenotifications that transfer has taken place, whether the transfer has taken place prior toanswer, the name and number (if appropriate) of the other user and the other user'ssubaddress and compatibility information.NOTE 6In the case where both user B and user C are in the same network, and that networksupports a call transfer service across the access to it from a PTNX, a user A's PTNXwhich is acting as a gateway PTNX to the other network on both calls can attempt toinvoke the service of the other network in order to effect a request for Call Transfer. Suchprocedures are outside the scope of this ETS.6.4.2User A in another networkThe PTN shall accept transfer notifications from another network and pass them on to thePTN user. Transfer notifications include notifications that transfer has taken place,whether the transfer has taken place prior to answer, the name and number of the otheruser and the other user's subaddress and compatibility information. Where thisinformation is not provided, a PTN user will have to rely on in-band information.SIST ETS 300 260 E1:2005
Page 15ETS 300 260: November 19936.5Overall SDLFigure 1 contains the dynamic description of SS-CT using the Specification and DescriptionLanguage (SDL) defined in CCITT Recommendation Z.100 (1988). The SDL processrepresents the behaviour of the network in providing SS-CT. The relationship of this processto the basic call process is indicated in the annotations.Input signals from the left and output signals to the left represent primitives from and touser A.Input signals from the right and output signals to the right represent primitives from and tousers B and C.TransferrequestIdlesuccessful?Clear redundantconnectionsTransfersuccessfulIdleYNAttempt toconnect userB to user CTransferThe result is a call between user Band user C. The call is an answeredcall, an alerting call, or a call whichhas encountered interworking with anon-ISDNtowards user ATransfer notifyto user BTransfer notifyto user CGet causeTransferrejectA call transfer request is madewith respect to two calls. One(involving user B) should beanswered. The other (involvinguser C) should be answered, alertingor have encountered interworkingwith a non-ISDNFigure 1 - SS-CT, Overall SDL7SS-CT stage 2 specification for transfer by join7.1Functional model7.1.1Functional model descriptionThe functional model shall comprise the following Functional Entities:FE1Transfer Invoke;FE2Transfer Execute;FE3Transfer Complete Receive;FE4Transfer Notification Receive.There shall be two instances of FE3 and FE4, one of each associated with user B anduser C.SIST ETS 300 260 E1:2005
Page 16ETS 300 260: November 1993The following functional relationships shall exist between these FEs:rrbetween FE1 and FE2;rsbetween FE2 and FE3;rtbetween FE3 and the FE4 associated with the same user;rubetween user B's FE4 and user C's FE4;rvbetween user B's FE3 and user C's FE3.Figure 2 shows these FEs and relationships.FE4rvrurtrsFE3FE4rtrsFE3FE2FE1rrUSER BUSER AUSER CFigure 2 - Functional Model for SS-CT7.1.2Description of Functional Entities7.1.2.1Transfer Invoke Functional Entity, FE1This FE acts on behalf of user A. It is responsible for recognising user A's decision toeffect Call Transfer, and for identifying the two calls.7.1.2.2Transfer Execute Functional Entity, FE2This FE checks that details known concerning the primary and secondary calls do notpreclude the interconnection of user B and user C and creates the new connectionbetween user B and user C by joining together the two existing connections.7.1.2.3Transfer Complete Receive Functional Entity, FE3This FE acts on behalf of user B or user C, and notifies the respective FE4, that atransfer has occurred, along with the details of the new call. Two FE3s exist, one foruser B and one for user C. This FE also passes to the other FE3 details about theassociated user.7.1.2.4Transfer Notification Receive Functional Entity FE4This FE receives on behalf of user B or user C the indication that a transfer hasoccurred, and the details of the new call. Two FE4s exist, one for user B and one foruser C. This FE also passes to the other FE4 details relevant to the transfer which arenot provided by the network.SIST ETS 300 260 E1:2005
Page 17ETS 300 260: November 19937.1.3Relationship of Functional Model to Basic Call Functional ModelFunctional Entity FE1 shall be collocated with user A's CCAs for the two calls, exceptwhere user A's terminal is stimulus with respect to SS-CT but functional with respect tothe basic call, in which case FE1 shall be collocated with user A's CCs for the two calls.Functional Entity FE2 shall be collocated with user A's CCs for the two calls.A functional Entity FE3 shall be collocated with each of user B's and user C's CCs.A functional Entity FE4 shall be collocated with each of user B's and user C's CCAs,except where either or both of user B's and user C's terminals are stimulus with respect toSS-CT but functional with respect to the basic call, in which case the FE4 in questionshall be collocated with the user's CC.An example of a relationship between the FEs for SS-CT and FEs for the basic call isshown in Figure 3. In this example, user A is the called user of the primary call and thecalling user of the secondary call.FE1FE2FE3FE3FE4FE4rrrsrsrvrurtrtCCACCCCCCACCr3r2r2r1CCACCCCCCACCr1r2r2r3USER AUSER BUSER CFigure 3 - Example Relationship between Model for SS-CT and Basic Call7.2Information flows7.2.1Definition of information flowsIn the tables listing the elements in information flows, the column headed "Request"indicates which of these elements are mandatory (M) and which are optional (O) in arequest/indication information flow, and the column headed "Confirm" indicates which ofthese elements are mandatory (M) and which are optional (O) in a response/confirmationinformation flow.7.2.1.1Transfer InvokeThis is a confirmed information flow across rr from FE1 to FE2 which initiates atransfer. The request contains the identities of the calls involving users B and C.Table 1 lists the elements within the Transfer Invoke information flow.SIST ETS 300 260 E1:2005
Page 18ETS 300 260: November 1993Table 1 - Content of Transfer InvokeElementRequestConfirmCall Identities (CI)Transfer Invoke Result (TIVR)M--MElement CI shall contain the identities of the two calls to be transferred.Element TIVR shall contain the result of the transfer invoke request and, if it indicatesrejection, identify the reason for rejection. An indication of rejection means that theprimary and secondary calls have not been affected by the invocation request. Anindication of acceptance means that the transfer has been effected and that users B andC are now involved in the same call, without the involvement of user A.7.2.1.2Transfer CompleteThis is an unconfirmed information flow across rs from FE2 to FE3 which indicatesthat a transfer has been effected.Table 2 lists the elements within the Transfer Complete information flow.Table 2 - Content of Transfer CompleteElementRequestConnected Number (CN)Destination Category (DC)Alerting Indication (AI)End Designation (ED)Call History (CH)Connected NameO (note)OO (note)MOONote: CN and AI are mutually exclusive. AI may onlybe included in the case of an alerting transfer. CNmay only be included in the case of an answeredtransfer.Elements CN, DC and CH shall be as defined in ETS 300 171.Element Connected Name shall comprise the elements of information flow INFORM 3of ETS 300 237.Element AI shall contain user C's number and restriction details if user C's number isknown.Element ED shall contain a designation for the new end PTNXs in the resultant call.Different designations of "Primary" and "Secondary" are given to the two new endPTNXs in order to allow them to be distinguished for the purpose of supportingservices or features which may be invoked following Call Transfer.7.2.1.3Transfer ActiveThis is an unconfirmed flow across rs from FE2 to FE3 which indicates that answer hastaken place following an alerting transfer.SIST ETS 300 260 E1:2005
Page 19ETS 300 260: November 1993Table 3 lists the elements within the Transfer Active information flow.Table 3 - Content of Transfer ActiveElementRequestConnected Num
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.