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).
Conferencing

Conferencing

The conference service is a caller-side service. The conference service allows a user to make a multi-connection call. That is, multiple users (participants) can participate in the same session at the same time.

Conferencing

This topic describes the definition and benefits of the conferencing service.

Definition

The conferencing service is a service on the originating side. It provides the multi-connection call capability for a user. That is, multiple users (participants) can participate in the same session at the same time. If a user has enabled and activated the service, the user can apply for the resource to create a conference and add or delete the conference participant. The remote user can leave the conference.

NOTE:

The difference between the conference service and the three party service is that the conference can be performed only by the Multimedia Resource Function Controller (MRFC), and the number of conference participants can be more than 3.

User A has the conferencing service permission. Users B, C, and D are common users. User A has created a conferencing service with users B, C, and D. Figure 1-57 shows the conferencing service flow.
Figure 1-57 Conferencing service flow
  1. User A calls user B, and the call between users A and B is set up.
  2. User A presses hookflash. User B hears a call hold tone.
  3. User A calls user C and communicates with user C.
  4. User A presses hookflash to hold user C, and user C hears a call hold tone.
  5. User A calls user and communicates with user D.
  6. User A presses hookflash to hold user D, and user D hears a call hold tone.
  7. User A presses the function key to set up a conference call. Users A, B, C, and D enter a conference call.
Benefit

Beneficiary

Benefits

Carrier

The conferencing service brings added value and provides multi-party session services for users, improving user satisfaction.

User

A user can initiate a conference call at any time and can discuss with multiple users at the same time, which facilitates communication between multiple users and reduces the communication and information transmission costs between multiple users.

Standards Compliance
  • EN300 185
  • ETSI TS 183 005
  • ETSI TS 183 036
  • ETSI TS 183 043
  • ETSI TS 124 505
  • ETSI 300 102-1
  • 3GPP TS 24147
  • 3GPP TS 24605
  • ITU-T Q.931

Conferencing Service Flow

This topic takes users A, B, and C as an example to describe the POTS and ISDN conferencing service flows.

POTS Conferencing Service Flow

Figure 1-58 shows the POTS conferencing service flow.

Figure 1-58 POTS conferencing service flow

The POTS conferencing service flow is as follows:
  1. User A picks up the phone and makes a conference call.
  2. AG1 sends an Invite message to the IMS. The Request-URI in the Invite message is a conference factory URI).
  3. 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.
  4. After receiving the 200 OK message, AG1 sends an Ack message to the IMS.
  5. AG1 sends a Refer message to the IMS, inviting user B to join the conference. The Request-URI in the Refer message is the conference URI, and the Refer-To is user B.
  6. After receiving the Refer message, the IMS sends an Invite message to user B and calls user B.
  7. The IMS returns the 200 OK Refer message to user A.
  8. After receiving the Invite message from user B, AG2 sends the ring tone to user B.
  9. AG2 sends back a 180 ringing message to the IMS.
  10. The IMS sends a Notify message to notify user A.
  11. AG1 sends a 200 OK response to the Notify message from the IMS.
  12. User B picks up the phone.
  13. AG2 returns a 200 OK response to the Invite message from the IMS.
  14. The IMS sends an Ack message to user B.
  15. The IMS sends a Notify message to notify user A.
  16. AG1 sends a 200 OK response to the Notify message from the IMS. Then, both users A and B join the conference. The service flow of joining a conference by other users (such as users C and D) is similar to steps 5 to 16.
ISDN User Conferencing Service Flow (Adding a Service Party to a Conference in Idle Mode)

Figure 1-59 shows the service flow of an ISDN user (service party) joining a conference in idle mode.

Figure 1-59 Service flow of an ISDN user (service party) joining a conference in idle mode

User A is the conferencing service party. The service flow of an ISDN user (service party) joining a conference in idle mode is as follows:
  1. User A sends a SETUP message carrying FacilityIE to AG1, asking to set up a conference.
  2. AG1 sends a dial tone to user A. User A dials a number. AG1 receives the number and matches the digitmap successfully. The entire flow is the same as a basic call flow.
  3. AG1 applies to the IMS conference factory for creating a conference. The IMS allocates conference resources.
  4. The IMS returns a 200 OK response carrying the conference ID to AG1.
  5. AG1 sends a Connect message carrying Facility to user A. The Connect message carries the conference ID, indicating that A joins the conference successfully.
  6. User A replies AG1 with a ConnectAck message.
  7. AG1 sends an Ack message to the IMS. Then, user A joins the conference in the idle state.
ISDN User Conferencing Service Flow (Adding a Party to a Conference)

Figure 1-60 shows the service flow of an ISDN user adding a party to a conference.

Figure 1-60 Service flow of adding the other party to a conference

User A is the conferencing service party. The service flow of adding the other party to a conference is as follows:
  1. During a conference, user A can hold a call with the conference factory before initiating a call with user B.
  2. User A (service party) and user B (non-service party) set up a basic call. The call can also be set up by user B.
  3. User A can hold the call with user B before adding user B to the conference.
  4. User A requests to add user B to the conference through a terminal operation. AG1 sends a Refer message to the IMS, asking the IMS to add user B to the conference.
  5. After receiving the Refer request, the IMS establishes a new call between the conference factory and user B, and releases the call between users A and B.
ISDN User Conferencing Service Flow (Service Party Joining a Conference in the Running State)

Figure 1-61 shows the service flow of an ISDN user joining a conference in the running state.

Figure 1-61 Service flow of an ISDN user joining a conference in the running state

User A is the conferencing service party. Before the conference, users A and B are in a basic call. The service flow of the ISDN user in the running state is as follows:
  1. User A sends a Facility message to AG1, asking to set up a conference. AG1 sends an Invite request to the IMS and conference factory to set up a conference. The IMS accepts the request. The service flow is the same as that in the idle state. For details, see ISDN User Conferencing Service Flow (Adding a Service Party to a Conference in Idle Mode).
  2. AG1 sends a Refer message to the IMS, inviting user B to join the conference.
  3. After receiving the Refer request, the IMS establishes a new call between the conference factory and user B and releases the call between users A and B.
ISDN User Conferencing Service Flow (Disconnecting One Party in a Conference)

Figure 1-62 shows the service flow of disconnecting a party from an ISDN user conference.

Figure 1-62 Service flow of disconnecting a party from an ISDN user conference

The service flow of disconnecting a party from an ISDN user conference is as follows:
  1. User A requests to disconnect user B from the conference.
  2. AG1 sends a Refer message to the IMS, asking the IMS to disconnect user B from the conference.
  3. After receiving the Refer request, the IMS releases the call between the conference factory and user B, and notifies AG1 of user A.
  4. AG1 sends a Facility response to notify user A of the disconnection result.
ISDN User Conferencing Service Flow (Non-Service Party Quitting a Conference)

Figure 1-63 shows the service flow of an ISDN user (non-service party) exiting a conference.

Figure 1-63 Service flow of an ISDN user (non-service party) exiting a conference

In the preceding figure, steps 1 to 5 indicate that user B releases the call with the conference factory. Then, the IMS notifies conference participants that participant B leaves the conference.

ISDN User Conferencing Service Flow (Releasing a Conference by the Service Party)

Figure 1-64 shows the service flow of an ISDN user (service party) releasing a conference.

Figure 1-64 Service flow of an ISDN user (service party) releasing a conference

User A is the conferencing service party. The service flow of an ISDN user (service party) releasing a conference is as follows:
  • Steps 1 to 6: User A (service party) releases the call with the conference factory.
  • Steps 7 to 10: The IMS releases the conference resources and releases the call between the conference factory and other participants.
Translation
Download
Updated: 2019-02-22

Document ID: EDOC1100067358

Views: 13445

Downloads: 131

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