CEPT T S 22-09 E-1988 Stage 2 Description of the Three Party Service《第二阶段第三方业务描述》.pdf

1、2326434 0007908 9 m, Page 1 TS22-09 E Recommendation T/S 22-09 (Edidburgh 1988) STAGE 2 DESCRIPTION OF THE THREE PARTY SERVICE Recommendation proposed by Working Group T/WG 11 “Signalling, Protocols and Switching” (SPS) Text of the Recornmendation adopted by the “Telecommimications” Commission: “The

2、 European Conference of Postal and Telecommunications Administrations, considering - that in accordance with the principles outlined in Recommendation T/SPS the exchange and network features - that in several CEPT member countries the Three Party Service is considered to be offered to the customers,

3、 - that it is desirable to handle the Three Party Service in a standardized way especially when calls related to the which are required for the implementation of services and facilities should be identified and specified, Three Party Service are crossing borders, recommends that the members recogniz

4、e and use the following definitions, arrangements and specifications for the Three Party Service.” 1. INTRODUCTION This stage 2 description of the Three Pary Service is based on the stage 1 description of the Three Party Service. This stage 2 description provides a signalling system independent info

5、rmation flow between nodal functions of interest to the Three Party Service, SDL diagrams of some interesting nodal functions, and recommends a scenarium for allocating the nodal functions to physical locations in the network. 2. DEFINITION OF THE THREE PARTY SERVICE The Three Party Service enables

6、a user who is active on a call to hold that call, make an additional call to a third party, switch from one call to the other as required (privacy being provided between the two calls), and/or release one call and return to the other or to join the two calls together into a three-way conversation. 3

7、. 3.1. DESCRIPTION OF THE FUNCTIONAL MODEL Functional Model for the Three Party Service The functional model selected for the Three Party Service is shown in Figure 1 (T/S 22-09). It uses six functional entities as follows: FE 1 : Three Party Service agent of the served user (A) FE 2: Three Party Se

8、rvice control of the served user (A) FE 3: Three Party Service control of the 1st remote user (B) FE 4: Three Party Service agent of the 1st remote user (B) FE 5: Three Party Service control of the 2nd remote user (C) FE 6: Three Party Service agent of the 2nd remote user (C) O I ISE 5 FE 6 Figure 1

9、 (T/S 22-09). Functional entity model. Note. This functional model may need revision with regard of FE 2 in case that the functionality of FE 2 is distributed across a PABX and a local exchange. Edition of October 31, 1989 iL-? 2326434 0007909 O M TIS 22-09 E Page 2 - 4 This functional model applies

10、 to the Three Party Service for one served user. It must be recognized that the remote users may have the capability to become served users if they support and also invoke the Three Party Service. In this case a symmetrical model can be assumed with regard to all functional entities. In the case whe

11、re a dependent user does not invoke the Three Party Service FE 1 and FE 2 on his side are assumed to be in the idle state. In the case where a dependent user does not have the capability to support the Three Party Service FE 1 on his side can be assumed to be non-existent. However it is assumed that

12、 FE 2 on his side will provide interaction (multiparty compatibility) checking for this service. 3,2. Relationship to the Basic Services The functional entities for the Three Party Service are represented as modular extensions to the functional model of the basic services. This approach provides the

13、 flexibility to allow FE 1, the Three Party Service agent, to be colocated either with the call control or the call control agent of the served user. The former represents the stimulus invocation of the Three Party Service together with a functional basic call control, the latter represents the func

14、tional invocation. See Figure 2 (TB 22-09). served I I Ist remote 1 I I I r2 / r4 2nd remote 1 I Figure 2 (T/S 22-09). Relationship between the Three Party Service and the basic services. Key: FE 1 . FE 6: see definitions in section 5 cc : CCA: call control as required for a basic call call control

15、agent as required for a basic call 4. INFORMATION FLOW The information flow between the functional entities illustrating the successful provision of the Three Party Service is shown in Figure 3 (T/S 22-09) on the following pages. 4,l. Diagrams See Figure 3 (T/S 22-09). 4.2. Definitions The definitio

16、ns provided in this section are specific for the Three Party Service. Information flows depicted in the diagrams but not defined here in section 4.2., e.g. SETUP, DISCONNECT, are not specific to the Three Party Servcie and their definitions may be found elsewhere. The call Id contained in an acknowl

17、edging or rejecting information flow is always the same as was used in the request associated with that acknowledging or rejecting information flow. Edition of October 31, 4.2.1. = 2326414 0007910 7 i! TIS 22-09 E Page 3 ALTERNATE (REQ) req.ind Meaning: The ALTERNATE (REQ) req.ind is used by FE 1 to

18、 interrupt the established communication and to request the re-establishment of the held communications. This is a confirmed information flow and appears within relationship rl of the call being active when requesting the alternate. Information Content: - Call Id of the active call when requesting t

19、he alternate - alternate request ALTERNATE (ACK) respxonf Meaning: This is sent by FE 2 to FE 1 to indicate completion of the alternate request. Information Content: - Call Id - alternate request acknowledgement ALTERNATE (REJ) resp.conf Meaning : This is sent by FE 2 to FE 1 to indicate failure to

20、a request to alternate. Information Content: - Call Id - alternate request reject 3PS-HOLD (REQ) req.ind Meaning: The 3PS-HOLD (REQ) req.ind is sent toward the served users equipment. The 3PS-HOLD (REQ) req.ind is the information sent from FE 2 to FE 1 causing the user equipment to detach the design

21、ated call from the B-channel. This is a confirmed information flow and appears within relationship rl of the call to be held. Information Content: - Call Id of the call to be held - hold request 3PS-HOLD (ACK) resp.conf Meaning: 3PS-HOLD (ACK) resp.conf is the information sent from FE 1 to FE 2 to i

22、ndicate completion of the hold actions. The user equipment has disconnected from the B-Channel, if there is no other call within theuser equipment the B-Channel is assigned to. Information Content: - Call Id - hold request acknowledgement 3PS-HOLD (REJ) respxonf Meaning: The application of a 3PS-HOL

23、D (REJ) resp-conf sent by FE 1 to FE 2 within the context of this service is for further study. CONNECTED req.ind Meaning: CONNECTED req.ind is used to acknowledge that a previously sent SETUP resp.conf has been received and accepted. This is an unconfirmed information flow within the rl relationshi

24、p and is sent from the CC to the CCA. Information Content: - as Basic Service - in particular Call Id of the awarded call - in particular Assignment indication Meaning of the Assignment indication: This is an indication that a specified B-Channel exclusively has-to be used for this call. 4.2.2. 4.2.

25、3. 4.2.4. 4.2.5. 4.2.6. 4.2.7. Edition of October 31, 1989 .-. . .,- f- 2326414 O007911 9 TIS 22-09 E Page 4 4.2.8. RECALL (REQ) req.ind Meaning: RECALL (REQ) reqhd is the information sent from FE 2 towards FE 1 to offer to the service user a held call. RECALL (REQ) req.ind is a confirmed informatio

26、n flow and appears within the relationship rl of the call to be retrieved. Information Content : - Call Id of the call to be retrieved - B-Channel indication of the channel to be exclusively used for the connection 4.2.9. RECALL (ACK) resp.conf Meaning: RECALL (ACK) resp.conf is the information sent

27、 from FE 1 towards FE 2 to indicate that the served user accepted the recall offer. Information Content: - Call Id of the call to be retrieved - B-Channel indication (see Note) Note. An indication that a specified B-Channel is assigned to the call is optional. However the B-Channel must be the one o

28、ffered within the RECALL (REQ) req.ind. 42.10. RECALL (REJ) resp.conf Meaning: The application of a RECALL (REJ) resp.conf sent by FE 1 to FE 2 within the context this service is for further study. 4.2.1 1. 3PS-RETRIEVE (REQ) req.ind Meaning: 3PS-RETRIEVE (REQ) req.ind is the information sent from F

29、E 2 to FE 1 causing the user equipment to attach the designated call to the indicated B-Channel. 3PS-RETRIEVE (REQ) req.ind is a confirmed information flow and appears within relationship rl of the call to be retrieved. Information Content: - Call Id of the call to be retrieved - B-Channel indicatio

30、n of the channel to be used exclusively for the connection 4.2.12. 3PS-RETRIEVE (ACK) resp.conf Meaning: This is the information sent from FE 1 to FE 2 acknowledging that communication has been re-established. The user equipment is attached to the B-Channel indicated in the previous 3PS-RETRIEVE (RE

31、Q) reqhd. Information Content: - Call Id of the retrieved call - retrieve request acknowledgement - B-Channel indication (see Note) Note. An indication that a specified B-Channel is assigned to the call is optional. However the B-Channel must be the one offered within the 3PS RETRIEVE (REQ) req.ind.

32、 4.2.13. 3PS-RETRIEVE (REJ) resp.conf Meaning: The application of a 3PS-RETRIEVE (REJ) resp.conf sent by FE I to FE 2 within the context of this service is for further study. SETUP req.ind of the enquiry call Meaning: As Basic Service, additionally an information is included that indicates the corre

33、lation to the other call within the relationship between FE 1 and FE 2. Information Content: - as Basic Service - additionally the correlated Call Id is included 4.2.14. Edition of October 31, 198- r 232b414 O007912 O-= TIS 22-09 E Page 5 4.2.15. SETUP resp.conf of the enquiry call Meaning: As Basic

34、 Service, additionally an information is included that indicates the correlation to the other call within the relationship between FE 1 and FE 2. Information Content: - as Basic Service, - additionally the correlated CaU Id is included 4.2.16. SPLIT (REQ) req.ind Meaning: This request is only used d

35、uring the active phase of the three-way conversation mode to identify one party in order to have a privae communication with that party. This is a confirmed information flow and appears within relationship rl of the call that shall remain active. A SPLIT (REQ) req.ind implicitly requests the release

36、 of the three-way conversation bridge. Information Content: - Call Id of the Cal to remain active - split request 4.2.11. SPLIT (REJ) resp.conf Meaning: This information is sent by FE 2 to FE 1 to indicate a failure of the split actions. Information Content: - Call Id - split request reject 4.2.18.

37、SPLIT (ACK) resp.conf Meaning: This information is sent from FE 2 to FE I to indicate that the call to the indicated party is active, the call to the other party is placed on hold, and the three-way conversation bridge was released. Information Content: - Call Id - split request acknowledgement 4.2.

38、19. 3PS (REQ) req.ind Meaning : The 3PS (REQ req.ind is used to activate the Three Party Service. This information flow is conirmed and appears within relationship rl of the original call. Information Content: - Call Id - Three Party Service request 4.2.20. 3PS (REJ) resp.conf Meaning: This informat

39、ion is sent by FE 2 to FE 1 Information Content: - Call Id - Three Party Service request reject 4.2.21. 3PS (ACK) resp.conf Meaning: 3 indicate a failure D activate the Three Party Service. This information is sent by FE 2 to FE 1 to indicate the completion of the activation of the Three Party Servi

40、ce. Information Content: - Call Id - Three Party Service request acknowledgement Edition of October 31, 1989 f I 232b414 0007913 2 E TIS 22-09 E Page 6 4,2.22. 3- WAY-CONV (REQ) req.ind Meaning: This information is used by FE 1 to request a three-way conversation. This is a confirmed information flo

41、w and appears within relationship rl of the call being active. Information Content: - Call Id of the call being active - three-way conversation request 4.2.23. 3- WAY-CONV (ACK) resp.conf Meaning: This information is sent by FE 2 to FE 1 to indicate the provision of the three-way conversation mode.

42、Information Content: - Call Id - three-way conversation request acknowledgement 4.2.24. 3- WAY-CONV (REJ) resp.conf Meaning: This information is sent by FE 2 to FE 1 to indicate a failure in providing the three-way conversation mode. Information Content: - Call Id - three-way conversation request re

43、ject 4.2.25. 3-WAY-CONV (ENQ) req.ind Meaning: This information is sent by the served user?s FE 2 handling the Three Party Service to the remote FE 2 handling the Three Party Service to enquire whether it is allowed to switch the specified call into a multi-party call. This is a confirmed informatio

44、n flow and appears within relationships r2 and r4. Information Content: - Call Id - multi-party call enquiry 4.2.26. 3- WAY-CONV (ACC) resp.conf Meaning: This information is sent by the remote FE 2 handling the Three Party Service to the served user?s FE 2 handling the Three Party Service to indicat

45、e that the specified call is allowed to be switched into a multi-party call. Information Content: - Call Id - multi-party call acceptable 4.2.21. 3- WAY-CONV (DEN) resp.conf Meaning: This information ?is sent by the remote FE 2 handling the Three Party Service to the served user?s FE 2 handling the

46、Three Party Service to indicate that the specified call is not allowed to be switched into a multi-party call. Information Content: - Call Id - multi-party call denied 4.2.28. NOTIFY (3 WCN) req.ind Meaning: This information is originated by FE 2 to both the remote FE 3 and FE 5 to indicate that the

47、 specified call is part of a three-way conversation. This information flow is unconfirmed. Information Content: - Call Id - notification that the call is part of a three-way conversation Edition of October 31, 19P- 2326434 0007934 4 m TIS 22-09 E Page 7 4.2.29. NOTIFY (HOLDN) req.ind Meaning: NOTIFY

48、 (HOLDN) req.ind is sent from FE 2 to either the remote FE 3 or FE 5 respectively to indicate that the communication path of the call has been interrupted. This information flow is unconfirmed. Information Content: - Call Id - notification that the communication path has been interrupted NOTIF Y (RE

49、TRIE VEN) ieq. ind Meaning: NOTIFY (RETRIEVEN) req.ind is sent from FE 2 to either the remote FE 3 or FE 5 respectively to indicate that the communication path of the call has been re-established. This information flow is unconfirmed. Information Content: - Call Id - notification that the communication path has been re-established 4.2.30. 4.2.31. NOTIFY (3WCA) req.ind Meaning: NOTIFY (3WCA) req.ind is sent from FE 3 to FE 4 and from FE 5 to FE 6 to indicate that the specified call is part of three-way conversation. This information flow is unconfirmed. Information Content: - Cal