4 Conference call control Service Sequence Diagrams

29.198-04-53GPPOpen Service Access (OSA) Application Programming Interface (API)Part 4: Call controlSubpart 5: Conference call control Service Capability Feature (SCF)TS

4.1 Meet-me conference without subconferencing

This sequence illustrates a pre-arranged meet-me conference for a specified time period. During this timeslot parties can ‘call in to’ the meet-me conference by dialling a special number.

For each participant joining the conference, the application can decide to accept the participant in to the conference.

The application can also be notified when parties are leaving the conference.

1: The application creates a new object to receive the callbacks from the conference call control manager.

2: The application reserves resources for some time in the future.

With this same method the application registers interest in the creation of the conference (e.g. when the first party to joins the conference or at the specified start time, this is implementation dependant).

The reservation also includes the conference policy. One of the elements is whether joined parties must be explicitly attached. If so, this is treated as an implicit joinMonitorReq.

3: The conference is created.

4: The message is forwarded to the application.

5: The application creates an object to receive the call back messages from the conference call.

6: The application also requests to be notified when parties leave the conference.

7: The application is notified of the first party that joined the conference.

8: When the party is allowed to join the conference, the party is added.

Alternatively, the party could have been rejected with a releaseCallLeg.

9: A new party joins the conference and the application is notified.

10: The message is forwarded to the application.

11: This party also is allowed into the conference by attaching the leg.

12: A party leaves the conference.

13: The message is forwarded to the application.

14: The application decides to release the entire conference.

4.2 Non-add hoc add-on with subconferencing

This sequence illustrates a prearranged add-on conference. The end user that initiates the call, communicates with the conference application via a web interface (not shown). By dragging and dropping names from the addressbook, the end-user adds parties to the conference.

Also via the web-interface, the end-user can group parties in subconferences. Only parties in the same subconference can talk to each other.

1: The application creates a new interface to receive the callbacks from the conference call.

2: The application initiates the conference. There has been no prior resource reservation, so there is a chance that no resources are available when parties are added to the conference.

The conferenceCall interface object is returned.

3: Together with the conference a subconference is implicitly created.

However, the subconference is not returned as a result of the createConference, therefore the application uses this method to get the subconference.

4: The application creates a new IpAppCallLeg interface.

5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in the following not all steps are shown.

6: The gateway creates a new IpCallLeg interface.

7: The application adds parties to the subconference.

8: The application adds parties to the subconference.

9: The application adds parties to the subconference.

10: When a party A answers the application is notified.

We assume that all parties answer. This happens in the same way as for party A and is not shown in the following.

11: The message is forwarded to the application.

12: The application decides to split the conference. Party C & D are indicated in the message.

The gateway will create a new subconference and move party C and D to the new subconference.

The configuration is A & B are in speech, C & D are in speech. There is no bearer connection between the two subconferences.

13: The application moves one of the legs from the second subconference back to the first. The configuration now is A, B & C are in speech configuration. D is alone in its own subconference.

14: The second subconference is released. Since party D was in this subconference, this callleg is also released.

This leaves one subconference with A, B & C.

4.3 Non-addhoc add-on multimedia

This sequence illustrates a prearranged add-on multi-media conference. The end user that initiates the call, communicates with the conference application via a web interface (not shown). By dragging and dropping names from the addressbook, the end-user adds parties to the conference.

Also via the web-interface, the end-user can do things that normally the chair would be able to do, e.g. determine who has the floor (e.g. whose video is being broadcast to the other participants) or inspect the video of participants who do not have the floor (e.g. to see how they react to the current speaker).

1: The application creates a new object for receiving callbacks from the MMSubConference.

2: When the user selects the appropriate option in the web interface, the application will create a conference without resource reservation. The policy for video is set to ‘chairperson switched.

3: The application requests the subconference that was implicitly created together with the conference.

4: The application creates a new IpAppCallLeg interface.

5: The application adds the first party to the subconference. This process is repeated for all 4 parties. Note that in the following not all steps are shown.

6: The gateway creates a new IpCallLeg interface.

7: The application creates a new IpAppCallLeg interface.

8: The application adds parties to the conference and monitors on success.

9: The gateway creates a new IpCallLeg interface.

10: The application adds parties to the conference and monitors on success.

11: The application adds parties to the conference and monitors on success.

12: When a party A answers the application is notified.

We assume that all parties answer.

14: We assume that A was the initiating party.

The initiating end-user is assigned the chairpersonship.

This message is needed to synchronise the chairpersonship in the application with the MCU chairpersonship, since the chair can also use H.323 messages to control the conference.

15: When a party B answers the application is notified. We assume the other parties answer as well and this is not shown below in the sequence.

16: Chairperson (A) decides via WWW interface that party B is the speaker. This means that the video of B is broadcast to the rest.

17: The chairperson selects the video of C in order to judge their reactions on B’s proposal.

18: The chairperson selects the video of D in order to judge their reactions on B’s proposal.

19: The chairperson goes back to receiving the broadcasted videostream (B).

20: User C requests the floor via the H.323 signals. The application is notified of this.

21: The message is forwarded to the application logic.

22: The chairperson (via the WWW interface) grants the request by appointing C as the speaker.

4.4 Resource Reservation

This sequence illustrates how an application can check and reserve resources for a meet-me conference.

1: The application checks if enough conference resources are available in a given time period.

2: The application creates an object to receive callback messages.

3: The application reserves resources for the time period. The callback object is in order to receive a notification when the conference is started.

4: Because the time was wrong by accident, the application cancels the earlier reservation.

5: The application makes a new reservation.

6: At the specified time, or when the first party joins the conference the application is notified.

7: The event is forwarded to the application.