No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Voice Feature Guide 01

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Three Party Conference Call

Three Party Conference Call

This service provides one call connection for multiple users, that is, it allows 3 users to communicate with each other in the same call.

Three Party Conference Call

This topic describes the definition and principle of the three party conference call (3PTY) service.

Definition

This service provides one call connection for multiple users. That is, it allows 3 users to communicate with each other in the same call.

Based on whether 3PTY call resources are allocated locally or allocated by the IMS, the 3PTY service is classified into local 3PTY and remote 3PTY.

The service user can use the 3PTY service in the following ways:
  • The service user can create a 3PTY conference and call the other two users at the same time. After the other two users answer the call, the three users communicate with each other.
  • The service party can call a user first, and then call the third user after a call is set up. After the third user answers the call, the three users communicate with each other.
User A subscribes to the 3PTY service, users B and C are common users. User A creates a 3PTY call with users B and C in the second manner, as shown in Figure 1-53.
Figure 1-53 Principle of the 3PTY service
  1. User A calls and communicates with user B.
  2. User A presses hookflash to place user B on hold. Then, user B hears a call hold tone.
  3. User A calls and communicates with user C.
  4. User A presses hookflash to place user C on hold. Then, user C hears a call hold tone.
  5. User A presses the function key to set up a 3PTY call. Then, users A, B, and C communicate with each other. Generally, the function key is 3.
    NOTE:

    Generally, the function key is 3.

Benefit

Beneficiary

Benefits

Carrier

The 3PTY service supplements the value-added services of carriers, provides multi-party calls for users, and improves user satisfaction.

User

The 3PTY service enables a user to initiate a 3PTY call for discussion, facilitating user communication and improving communication efficiency.

Standards Compliance
  • EN300 188
  • ETSI 300 102-1
  • ETSI TS 183 005
  • 3GPP TS 24147
  • 3GPP TS 24605
  • 3GPP TS 24610
  • 3GPP TS 23218-630
  • ETSI TS 183 036
  • ETSI TS 183 043
  • ITU-T Q.931

Service Flow of Local Three Party Conference Call

In the following service flows of local three party conference call (3PTY) for POTS users or ISDN users, user A is the one who subscribes to the service, and users B and C are common users.

Local 3PTY for POTS Users

Figure 1-54 shows how local 3PTY for POTS users is implemented.

Figure 1-54 Service flow of local 3PTY for POTS users

The service flow of local 3PTY for POTS users is as follows:
  1. When user A talks with user B, user A presses hookflash.
  2. AG1 detects the hookflash pressing event, converts the event into a ReInvite message, and sends the message to user B.
  3. After the IMS receives the ReInvite message, it applies for announcement playing resources and sends a ReInvite message to user B. After AG2 receives a ReInvite message, AG2 modifies the media attribute of user B so that user B can receive but cannot send media streams.
  4. AG2 replies with a 200 OK response carrying an SDP packet, indicating that user B only receives media streams.
  5. The IMS sends a 200 OK response, and AG1 receives the 200 OK message.
  6. AG1 sends an Ack message to user B.
  7. The IMS sends an Ack message to user B, and AG2 receives the Ack message.
  8. User B is successfully placed on hold and hears a call hold tone.
  9. User A hears a special dial tone or hears nothing.
  10. User A dials user C's number.
  11. AG1 sends an Invite message to user C after detecting the dialing event.
    NOTE:

    In steps 11 to 19, AG1 initiate a call to user C. The flow is the same as a basic call flow.

  12. After the IMS receives the Invite message, it sends the Invite message to user C. AG2 receives the Invite message.
  13. AG2 alerts user C.
  14. AG2 sends a 180 response to AG1.
  15. The IMS sends the 180 response sent by AG2. User C picks up the phone after hearing a ringing tone.
  16. AG2 sends a 200 OK message.
  17. The IMS sends the 200 OK message sent by AG2.
  18. AG1 sends an Ack response.
  19. The IMS sends an Ack message to user B, and AG2 receives the Ack message. Then a call is set up between users A and C.
  20. User A presses hookflash again.
  21. After pressing hookflash, user A hears a special dial tone.
  22. User A dials service code "3" in an attempt to participate in a three-party conference.
  23. After AG1 detects the hookflash event and service code "3", AG1 locally applies for conference resources, converts data into a ReInvite message carries isfocus parameter data, and sends the message to the IMS, asking the IMS to add B to the conference.
  24. After the IMS receives the ReInvite message, it sends the ReInvite message to user B. After AG2 receives the ReInvite message, AG2 modifies the media attribute and direction of user B to sendrecv.
  25. AG2 sends a 200 OK response to the IMS. The 200 OK response carries an SDP packet, instructing that user B can receive and send media streams.
  26. The IMS sends a 200 OK response to user A connected to AG1.
  27. After AG1 receives the 200 OK message, it sends an Ack message to user B.
  28. The IMS sends an Ack message to user B, and AG2 receives the Ack message.
  29. AG1 sends a ReInvite message (the SDP direction is sendrecv), and user C is added to the conference.
  30. After the IMS receives the ReInvite message, it sends the ReInvite message to user C connected to AG2.
  31. After AG2 receives the ReInvite message, AG2 modifies the media direction and sends a 200 response to C.
  32. AG1 receives the 200 message that is sent from the IMS to user C.
  33. After AG1 receives the 200 message that is sent from the IMS to user C, AG1 sends an Ack message to the IMS.
  34. After user C connected to AG2 receives the Ack message, user C is added to the conference. Then all the three parties (A, B, and C) are in the conference.
Local 3PTY for ISDN Users

Figure 1-55 shows how local 3PTY for ISDN users is implemented.

Figure 1-55 Service flow of local 3PTY for ISDN users

The service flow of local 3PTY for ISDN users is as follows:
  1. User A places user B on hold and sets up a call with user C. User A initiates a three-party call on an ISDN terminal. That is, user A sends a Facility message to AG1 through CR1.
  2. AG1 locally applies for three-party conference room resources. To make user B enter a conference room for normal conversation, AG1 sends a ReInvite message to user B and modifies the stream mode to sendrecv.
  3. After the IMS receives the ReInvite message, it modifies SDP data and sends the ReInvite message to user B. After AG2 receives the ReInvite message, AG2 modifies the media attribute and direction of user B to sendrecv.
  4. After AG2 receives the message, it converts the message into a Notify message to notify user B.
  5. The AG to which user B is connected sends a 200 OK message.
  6. The IMS sends a 200 OK response, and AG1 receives the 200 OK message.
  7. AG1 sends an Ack message to user B.
  8. The IMS sends an Ack message to user B, and AG2 receives the Ack message.
  9. Similarly, AG1 invites user C to the conference room. AG1 sends a ReInvite message to user C. Because a bidirectional call is already set up between users A and C, the flow mode does not need to be modified.
  10. After the IMS receives the ReInvite message, it sends the ReInvite message to user C. AG2 receives the ReInvite message.
  11. After AG2 receives the message, it converts the message into a Notify message to notify user C.
  12. The AG to which user C is connected sends a 200 OK message.
  13. The IMS sends a 200 OK response, and AG1 receives the 200 OK message.
  14. After AG1 receives the ReInvite response, AG1 sends a Facility message to user A.
  15. AG1 sends an Ack message to user C.
  16. The IMS sends an Ack message to user C. The AG to which user C is connected receives the Ack message. Then users A, B, and C successfully join the three-party conference.

Service Flow of Remote Three Party Conference Call

In the following service flows of remote three party conference call (3PTY) for POTS users or ISDN users, user A is the one who subscribes to the service, and users B and C are common users.

Remote 3PTY for POTS Users

Figure 1-56 shows how remote 3PTY for POTS users is implemented.

Figure 1-56 Service flow of remote 3PTY for POTS users

The service flow of remote 3PTY for POTS users is as follows:
  1. When user A talks with user B, user A presses hookflash.
  2. AG1 detects the hookflash pressing event, converts the event into a ReInvite message, and sends the message to user B.
  3. After the IMS receives the ReInvite message, it applies for announcement playing resources and sends a ReInvite message to user B. After AG2 receives a ReInvite message, AG2 modifies the media attribute of user B so that user B can receive but cannot send media streams.
  4. AG2 replies with a 200 OK response carrying an SDP packet, indicating that user B only receives media streams.
  5. The IMS sends a 200 OK response, and AG1 receives the 200 OK message.
  6. AG1 sends an Ack message to user B.
  7. The IMS sends an Ack message to user B, and AG2 receives the Ack message.
  8. User B is successfully placed on hold and hears a call hold tone.
  9. User A hears a special dial tone.
  10. A dials user C's number.
  11. AG1 sends an Invite message to user C after detecting the dialing event.
    NOTE:

    In steps 11 to 19, AG1 initiate a basic call to user C until user C picks up the phone and user A starts to talk with user C. The flow is the same as a basic call flow.

  12. After the IMS receives the Invite message, it sends the Invite message to user C. AG2 receives the Invite message.
  13. AG2 alerts user C.
  14. AG2 sends a 180 response to AG1.
  15. The IMS sends the 180 response sent by AG2.
  16. User C picks up the phone after hearing a ringing tone.
  17. AG2 sends a 200 OK message.
  18. The IMS sends the 200 OK message sent by AG2.
  19. AG1 sends an Ack message to user C.
  20. The IMS sends an Ack message to user C, and AG2 receives the Ack message. Then a call is set up between users A and C.
  21. User A presses hookflash again.
  22. After pressing hookflash, user A hears a special dial tone.
  23. User A dials service code "3" in an attempt to participate in a three-party conference.
  24. After AG1 detects the hookflash event and service code "3", AG1 sends an Invite message to the IMS. The message carries Request-URI information (indicating the conference factory URI) and applies for a three-party call.
  25. After receiving the Invite message, the IMS applies for resources to create a conference. After the conference is successfully created, user A returns the 200 OK message.
  26. After AG1 receives the 200 OK message, AG1 sends an Ack message to the IMS.
  27. AG1 sends a Refer message to the IMS, inviting user B to join the conference. In the Refer message, Request-URI indicates the conference focus URI, and Refer-To is user B.
  28. The IMS receives the Refer message for inviting user B to the conference and finds that user A is talking with user B. Therefore, the IMS sends a ReInvite message to user B.
  29. AG1 receives a 200 OK message from the IMS.
  30. After AG2 receives the ReInvite message, AG2 redirects user B to the created conference and sends a 200 message to the IMS.
  31. The IMS sends an Ack message to user B, and AG2 receives the Ack message.
  32. The IMS sends a Bye message to user A to release the session between users A and B.
  33. After AG1 releases the session, AG1 returns a 200 OK response to the IMS.
  34. AG1 sends a Refer message to the IMS, inviting user C to join the conference. In the Refer message, Request-URI indicates the conference focus URI, and Refer-To is user C.
  35. The IMS receives the Refer message for inviting user C to the conference and finds that user A is talking with user C. Therefore, the IMS sends a ReInvite message to user C.
  36. AG1 receives a 200 OK message from the IMS.
  37. After AG2 receives the ReInvite message, AG2 redirects user C to the created conference and sends a 200 message to the IMS.
  38. The IMS sends an Ack message to C.
  39. The IMS sends a Bye message to user A to release the session between users A and C.
  40. After AG1 releases the session, AG1 returns a 200 OK response to the IMS. Then all the three parties (A, B, and C) are in the conference.
NOTE:

The service flow for ISDN users is the same as that for POTS users.

Standards Compliance

EN300 359

EN301 134

EN301 065

ETSI TS 300 359

ETSI TS 183 036

ETSI TS 124 642

Translation
Download
Updated: 2019-02-22

Document ID: EDOC1100067358

Views: 13178

Downloads: 129

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next