- Email: [email protected]
Description of a teleconferencing floor control protocol and its implementation
Engineering Applications of Artificial Intelligence 21 (2008) 430–441 www.elsevier.com/locate/engappai
Description of a teleconferencing floor control protocol and its implementation Mohammed Ouzzif a,, Mohammed Erradia, Hassan Mountassirb a
Laboratoire Alkhawarizmi de Ge´nie Informatique, Equipe Re´seaux et Te´le´communication, Universite´ Mohamed V-Souissi, ENSIAS B.P. 713 Agdal, Rabat, Morocco b Laboratoire d’Informatique de l’Universite´ de Franche-Comte´ (LIFC) 6, Route de Gray, 25030-F Besanc- on-cedex, France Received 7 November 2006; received in revised form 30 October 2007; accepted 8 November 2007 Available online 30 January 2008
Abstract In this paper, we present a formal specification of a teleconferencing floor control protocol and its implementation. The services provided by this protocol are described within the SCCP IETF document (Simple Conference Control Protocol). Finite state machines are used to model services behaviours part of this protocol. Temporal properties are defined as constraints of the teleconferencing system using SCCP protocol. The dynamic properties are described by the LTL logic (Linear Temporal Logic) and verified using the modelchecker Spin/Promela. A prototype of a multimedia teleconferencing system is implemented and it is based on the specified protocol. This implementation uses UML notation and is developed with JMF (Java Media Framework) API. r 2007 Elsevier Ltd. All rights reserved. Keywords: Floor control; SCCP; Specification; Verification; LTL properties; Promela/Spin; Multimedia; Teleconferencing
1. Introduction Advances in multimedia technologies and high-speed networks led to the emergence of several platforms that support multimedia teleconferencing systems MMTS. Various approaches are proposed in Baudin et al. (2006), Fluckiger (1995), Gomes et al. (2005), Ibriz et al. (1999), Kirsten (1999), Scholler (1996). An MMTS system allows a group of users, geographically distributed, to work together. An e-learning system is an example of a multimedia teleconferencing system where the group is composed of teachers and students (Baudin et al., 2001; Owezarski et al., 1997). The teacher initiates a session, which is joined and left dynamically by students. During a course, the teacher is seen and heard by all the students and handles a set of shared resources (whiteboard, slides, pointers). To improve understanding, a student gets the right to speak, which will be given to him if the teacher Corresponding author. Tel.: +212 7451 0356; fax: +212 2225 2245.
E-mail addresses: [email protected] (M. Ouzzif), [email protected] (M. Erradi), [email protected] (H. Mountassir). 0952-1976/$ - see front matter r 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.engappai.2007.11.003
accepts his request. This allows the student to be shown to all group members and to be able to use some shared resources. The management of these interactions is referred as floor control and presented in Dommel and GarciaLuna-Aceves (1999), Kausar and Crowcroft (1999), Ouzzif and Erradi (2002) and Ouzzif et al. (2005). A Floor is a temporary permission granted dynamically to collaborating users in order to mitigate race condition and guarantee mutually exclusive resource usage (Dommel and Garcia-Luna-Aceves, 2003). A MMTS must also allow for the conference members management which is referred as Conference (Villemur et al., 2003). Providing conference management without floor control is analogous to a transportation infrastructure without traffic control. These two issues should be supported by a MMTS. A Simple Conference Control Protocol SCCP was proposed by the IETF community (Bormann et al., 2001). The SCCP document defines the services required for simple conference control of tightly coupled conference. These services are guided by the IUT-T recommendations of the H.323 (ITU-T-H. 323, 2000) series and concern three aspects: the management of a set of members; the management of a set of media/application session and the
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
floor control which enables especially conducted conference. However, this document provides an informal description of the services to be provided and do not specify the dynamic behaviour of the conference control and management protocol. The behaviour must be defined and formalized in order to be able to check the protocol consistence and to test its implementation. The formalization process allows accomplishing specifications that are clear, consistent and unambiguous. Therefore, the verification becomes possible and aims to check if the subsystem satisfies the desired properties. This formalization allows also conformance testing to check that the external behaviour of a given implementation is equivalent to its specification. In this paper, we first describe a formal description of the SCCP using the finite states model. Therefore, we present patterns of temporal properties expressed by LTL (Linear Temporal Logic). These properties are checked using the Promela/Spin verification tool. Additionally, an implementation of a multimedia teleconferencing system, based on floor protocol, is given in the last of the paper. This paper is organized as follows: Section 2 presents a multimedia teleconferencing architecture and the floor control protocol. Section 3 describes the provided services of SCCP. Section 4 defines the behaviours of the floor control protocol with states machines. Sections 5 and 6 focus on temporal properties and their specification using the LTL logic. Section 7 proposes an implementation of a simple prototype conferencing. In last, Section 8 concludes this work and plans future work. 2. Floor control architecture The floor control architecture is composed of six logical entities: a floor control server, a conference server, one or more SIP server (SIP for Session Initiation Server), a conference owner, one or more floor chairs (moderators) and any number of regular conference participant (Schulzrine et al., 2004). A floor control protocol conveys the floor control messages among the floor chairs of the conference, the floor control server and the participants of the conference (Fig. 1). A centralized architecture is assumed in which all messages go via one point: the floor server. Processing (granting or rejecting) floor control requests are done by one or more floor chairs or by the server itself, depending on the policy. A conference server corresponds to a nodes group that makes a conference. It stores and maintains dynamically the conference information concerning this group in a ‘‘conference context’’. It receives services requests from the owner, the chairs and the participants. These requests concern the conference creation/termination and the participant joining/leaving. A conference owner interacts with the session server to create floors, appoints and changes the floor chairs of the conference. The participants may claim the floor for
Conference Server
431
Floor Control Server
Internet
Floor Chair
Floor Chair SIP Server
SIP Server
Conference participant
Conference participant
Conference Owner
Conference group
Fig. 1. Floor control architecture.
particular resources by sending floor requests to the floor control server. Floor requests from the participants are received by the floor server and kept in an—at level of the floor control protocol—‘‘unordered’’ floor request set. The current floor holders are reflected in a current floor holder set. Floor chairs are capable of manipulating both sets to, e.g. grant, revoke, reject and pass the floor. The order in which requests are processed, whether they are granted or rejected, how many participants obtain a floor simultaneously is determined by a higher layer application operating on these sets and is not confined by the floor control protocol. The SIP server interacts with the floor server and session server. It allows them to localize and invite a participant in a sub-network. The logical entities interact according to a conference policy located in the floor control server. This policy defines the rules of these interactions and allows the floor control server to answer to the requests received from the different other logical entities. 3. Floor control services In this work, we focus mainly on the conference control and conference management in tightly coupled conferences. It consists of tools to control the floor and to manage a conference. Conference management administrates membership, maintains connectivity, orchestrates sessions including tool invocation and provides session’s state information and teardown based on a connection management protocol. The floor control allows users of networked multimedia application to utilize and share resources such as remote devices, distributed data set, pointers, or continuous media such as audio and video without access conflicts. Floors are temporary permissions granted dynamically to collaborating users in order to mitigate race conditions and guarantee mutually exclusive resource usage. Providing conference management without floor control is analogous
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
432
Conference Controller
Media Agent
SCCP Entity
SIP
Audio / Video
TCP
Schared Application
UDP
IP and IP Multicast
Fig. 2. SCCP entity.
to a transportation infrastructure without traffic control. Any architecture that allows entities to coordinate and cooperate needs protocols to mitigate race conditions and to either avoid or resolve conflicts and their implications. In Bormann et al. (2001), the authors define a set of services for simple conference control, namely: management of the set of members participating in the conference; management of the set of media/application sessions that constitute the conference; and floor control. These services are provided by the SCCP (Simple Conference Control Protocol) entity that interacts, on one hand, with a user via a conference controller entity; and with a media agent and the SIP entity on other hand (Fig. 2). The conference controller is an application that represents an interface between the participant and the SCCP entity. The SIP entity provides the localization and invitation services to the SCCP entity. The SIP-entity behaviour is described in the SIP document (Handley and Jacobson, 1998). The services provided by the SCCP entity are of two kinds: conference management services and floor control services.
3.2. Floor control services The Floor control services are used in following:
3.1. Conference management services
The conference management services are described as follows:
SCCP_Create_Conference: allows to create a new conference by a conference owner (the responsible of a conference); SCCP_Conference_Created: notifies the conference creation; SCCP_Join: allows to dynamically join a conference. The conference context is updated appropriately. SCCP_Ack_Join: notifies the Acknowledgement of the conference join; SCCP_Leave: allows to dynamically leaving a conference without disturbance. The conference context is updated appropriately; SCCP_Ack_Leave: notifies the Acknowledgement of the conference leave; SCCP_Invite: SCCP users may invite other users to participate in the current SCCP conference;
SCCP_Accept: expresses that the invited participant accepts an invitation; SCCP_Pause: provides to take pause in a conference; SCCP_Resume: resumes a conference after a taking pause; SCCP_Remove: permits to a conference owner, in the case of a ‘‘conducted’’ conference, to remove a selected participant; SCCP_Request_Conference_Context: allows to request for information about a conference; SCCP_Terminate: in the case of a ‘‘conducted’’ conference, the conference owner may terminate a running conference; SCCP_Ack_Terminate: notifies the Acknowledgement of the conference terminate.
SCCP_Create_Floor: allows to create a new floor by a conference owner (the responsible of a conference); SCCP_Floor_Created: notifies the floor creation; SCCP_Appointe_Floor: allows the conference owner to appoint a floor to a participant which will be a floor chair; SCCP_Ack_Appointe: notifies the Acknowledgement of the floor appointing; SCCP_Floor_Appointed: notifies a conference owner that the floor has been appointed; SCCP_Floor_Not_Appointed: notifies that the floor has not been appointed; SCCP_Give_Floor: grants an exclusive floor to another participant; SCCP_Grab_Floor: allocates a floor for exclusive use by the requesting participant; SCCP_Release_Floor: releases a previously allocated floor; SCCP_Ask_Floor: asks the floor holder to grant an exclusive floor to the requesting SCCP entity; SCCP_Reject_Floor: allows the floor chair to reject a floor request; SCCP_Ask_Floor_Pending: notifies the participant that his floor request is pending and will be processed later; SCCP_Request_Floor_Context: allows asking for the floor context; SCCP_Give_Floor_Context: gives the floor context to the floor chair.
4. Floor control protocol description A tightly coupled conference has more formal control policies with respect to the underlying Social Protocol of the specific scenario. The authors in Hilt et al. (2001) identify four main floor control policies: no control, implicit floor control, explicit floor control and chair
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
control. In this work, we adopt the last one. In this policy, one person is designated as the chairperson or the moderator of a floor by the conference owner. He or she can give or grab the floor for certain resources at any time. Floor requests of participants have to be queued and monitored to the chairperson.
Ready
? SCCP_Create_Conference / !.
?. / ! SCCP_Conference_Created /
Conference Creation ? SCCP_Join / ! .
?. / ! SCCP_ACK_Join Conference Joining
? SCCP_Leave / !.
? SCCP_Terminate / ! .
Conference Leaving
Conference Terminating
?. / ! SCCP_ACK_Leave
? SCCP_ACK_Terminate / !.
Fig. 3. Session server behaviour.
Recall that the SCCP document in Bormann et al. (2001) presents the protocol service primitives only. It did not specify the behaviour of such protocol. The aim of our work is to give a description and a formal specification of the behaviour of this protocol in order to check temporal properties of this protocol. In this section, we describe the SCCP entity behaviour using a finite state machine. According to the architecture presented in Fig. 1, there are three kinds of the SCCP entity: the conference server SCCP entity located in the conference server, the floor server SCCP entity located in the floor control server and the customer SCCP entity located in the other logical entity of this architecture (owner site, chair site or participant site). Fig. 3 depicts the SCCP entity behaviour of the session server. This behaviour consists mainly of the ready state and the states in which it is making a particular service (conference creation state, conference joining state, conference leaving state and conference terminating state). It is initially in the ready state and transits to an other state when it receives a SCCP conference service request (create, join, leave or terminate). Once this service is made, it returns to the ready state.
Floor_Request_Processing Floor_Creation
? SCCP_Ask_Floor / ! .
?. / ! SCCP_Ask_Floor_Pending
? SCCP_Create_Floor / !. ?. / ! SCCP_Floor_Created
Ready
? SCCP_Release_Floor /!. ?. / ! SCCP_Give_Floor ? OK (SIP) / ! SCCP_Give_Floor ! SCCP_Reject_Floor to Floor_Release_Processing ? SCCP_Give_Floor / other participants ! INVITE (SIP) ? BYE (SIP) / ! SCCP_Give_Floor
SIP Inviting
? SCCP_Grab_Floor / ! SCCP_Grab_Floor
Grab Processing
? SCCP_Request_Floor_Context / !.
? SCCP_Appointe_Floor / ! INVITE (SIP)
? SCCP_Release_Floor / ! SCCP_Give_Floor
Floor Context Request Processing
?./ ! SCCP_Give_Floor_Context ? SCCP_ACK_Appoint / ! SCCP_Floor_Appointed
SIP Inviting
433
Appointing
? OK / ! SCCP_Appointe_Floor
Fig. 4. Floor server behaviour.
? Time_Out / ! SCCP_Floor_Not_Appointed
? BYE (SIP) / ! SCCP_Not_Appointed
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
434
? SCCP_Give_Floor / ! SCCP_Give_Floor ?. / ! SCCP_Ask_Floor_Pending
Holder
?. / ! SCCP_Grab_Floor Init Wainting Floor ? SCCP_Reject_Floor / ! SCCP_Reject_Floor ? SCCP_Grab_Floor / SCCP_Release_Floor ? SCCP_Release_Floor / !SCCP_Release_Floor
?. / ! SCCP_Ask_Floor ? SCCP_Give_Floor / ! SCCP_Give_Floor
? SCCP_Create_Conference / ! SCCP_Create_Conference ? SCCP_Join / ! SCCP_Join Participant
?. / ! SCCP_Give_Floor ?. / ! SCCP_Give_Floor_Context
? SCCP_Ack_Join / ! ? SCCP_Appointe_Floor / ! SCCP_Ack_Appointe_Floor Waiting
Chair ? SCCP_Create_Floor / ! SCCP_Create_Floor ? SCCP_Conference_Created / . ? SCCP_Appointe_Floor / ! SCCP_Appointe_Floor ? SCCP_Floor_Appointed /. ? SCCP_Floor_Created / . ? SCCP_Request_Floor_Context / !. ? SCCP_Floor_Not_Appointed /.
? SCCP_Give_Floor_Context / !.
Wainting Floor Context
Owner
? SCCP_Terminate / ! SCCP_Terminate
End Fig. 5. Customer behaviour.
The floor control server behaviour is depicted in Fig. 4. It is initiated by the ready state. When it receives a floor control service request (e.g. floor creation request), it transits to a floor control service rendering state (e.g. floor creation state). Once the service is made, it sends a notification (e.g. SCCP_Floor_Created) to the logical entity that has requested the service (e.g. owner) and return to the ready state. To localize and invite a participant, the floor server uses the SIP invite primitive. Fig. 5 describes the customer SCCP entity. It is initially in the init state. It consists mainly in the following states:
participant and holder states related to the simple participant behaviour; owner state related to the owner behaviour; chair state related to the chair behaviour.
The owner behaviour can be in the waiting state when it is waiting for a particular service from the floor control server or the conference server. The participant behaviour and the chair behaviour transit to the waiting_floor state when they do not hold the floor and are waiting for it. The floor is exchanged between the chairs and the participants. It is the chair which controls the floor holding. It requests periodically for the floor context to the floor server which contains the set of floor requesting participants. Based on this information, it gives the floor to a particular participant which becomes the holder and rejects the floor requests of the other participants. A participant in a holder state may release the floor and return to the participant state. The chair may grab the floor to the holder if he does not release the floor in a particular delay.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441 Conference Participant
Conference Owner
Conference participant
Conference Server
435 SIP Server
Floor Server
SCCP_Create_Conference SCCP_Conference_Created SCCP_Join_Conference SCCP_Ack_Join SCCP_Create_Floor SCCP_Floor_Created SCCP_Appointe_Floor INVITE (SIP) OK (SIP) SCCP_Appointe_Floor SCCP_Ack_Appoointe SCCP_Join_Conference Conference chair
SCCP_Ack_Join SCCP_Ask_Floor SCCP_Ask_Floor_Pending
SCCP_Request_Floor_Context SCCP_Give_Floor_Context SCCP_Give_Floor INVITE (SIP) OK (SIP) SCCP_Give_Floor SCCP_Release_Floor SCCP_Give_Floor
SCCP_Grab_Floor SCCP_Grab_Floor
or SCCP_Release_Floor SCCP_Give_Floor SCCP_Leave_Conference SCCP_Terminate_Conference
Fig. 6. An example of a scenario.
Fig. 6 depicts the MSC (Message Sequence Chart) as a script of interactions among the logical entities of the architecture presented in Fig. 1. These interactions are:
A conference creation formulated by a SCCP_Create_ Conference request from the conference owner to the conference server; A Conference join: by sending a SCCP_Join message to the conference server; The floor appoint: by the conference owner to a conference participant (which becomes a conference chair) by sending a SCCP_Appointe_Floor to the floor server; A floor request: sent by a participant to the floor server in a SCCP_Ask_Floor message; A SIP invitation formulated by the floor server to the SIP Server by the ‘‘INVITE’’ message in order to localize and invite a participant; A floor context request formulated by a SCCP_ Request_Floor_Context from a floor chair to the floor server;
A floor grant formulated by the SCCP_Give_Floor from a floor chair to the floor server which is relayed to the participant; A floor release formulated by the SCCP_Release_Floor from a participant to the floor server; A floor revoke formulated by the SCCP_Grab_Floor from a floor chair to the floor server which is relayed to the concerned participant.
5. Floor control properties In this section, we give a set of properties to be satisfied by our teleconferencing system. Then, we describe them using the LTL. 5.1. Properties In Schulzrine et al. (2004), a description of properties as requirements of a floor control protocol is given. We are
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
436
interested for some properties in following:
Property 1: It must be possible to define who is allowed to create, change and remove a floor in a conference. It is assumed that the conference has always these privileges. Property 2: It must be possible to use a chair-controlled floor policy in which the floor control server notifies the floor chair and waits for the chair decision. This enables the chair to fully control who has the floor. Property 3: Participants must be able to request a floor. Property 4: It must be possible to grant a floor to a participant. Property 5: A participant must be informed that he has been granted the floor. Property 6: It must be possible to reject a participant’s floor request. Property 7: The floor chair or moderator must be able to grab the floor from its current holder. Property 8: A participant must be informed that the floor was revoked.
where o Waiting_Floor_Context: means customer automaton is in the floor context waiting state; o Floor_Context_Request_processing: means that the floor server is processing the floor context request; o Waiting_Floor: represents that the customer automaton is waiting the floor.
Property 3: & (Participant - B (participant_Waiting_ Floor) where o Paricipant: means customer automaton is in the participant state; o Participant_Waiting_Floor: means that the customer automaton is related to a participant role and it is waiting floor state.
Property 4: & (chair - B (Waiting_Floor) where o Chair: means customer automaton is in the chair state; o Chair_Waiting_Floor: means that the customer automaton is related to a chairman role and it is waiting floor state.
Property 5: & (Participant_Waiting_Floor - B (Floor_Holder) where o Floor_Holder: means that the customer automaton is related to a participant and is in the holder state.
Property 6: & (Participant_Waiting_Floor_1 4 Participant_Waiting_Floor_2 - B (Floor_Holder_1 4 Participant_2) 3 (Floor_Holder_2 4 Participant_1) To describe this property, we use a configuration where there is a conference owner, a chair and two participants. Atomic propositions are o Participant_Waiting_Floor_i: means that the customer automaton related to the participant ‘‘i’’ is in the waiting floor state; o Floor_Holder_i: means that the customer automaton related to the participant ‘‘i’’ is in the holder state; o Participant_i: means that the customer automaton related to the participant ‘‘i’’ is in the participant state.
Property 7: & (Chair_Waiting_Floor - B (Chair) Property 8: & (Floor_Holder - B (Participant)
5.2. LTL description The properties mentioned above are described according to the states of automata presented in the previous section. For each property, we give the atomic propositions and temporal operators used in linear logic. Afterwards, we use the notations for the LTL described in Manna and Pnuelli (1992): the always operator symbolized by & and the eventually operator by B. The propositions use classical logic operators: like 4, : and -. The dynamic properties of the protocol are expressed with the following patterns: & (p - q) or & (p - B q), where p and q are atomic propositions. The first case expresses the fact that at every time a state of system verifies p, it should verify q. The second case expresses that at every time the system verifies p, in all the future executions, it should verify q.
Property 1: & (Floor_Server_Ready 4 Owner) - B (Floor_Server_Appointing 4 Owner_Waiting) where o Floor_Server_Ready: describes that the floor server is in the ready state; o Floor_Server_Appointing: means that the floor server is in the appointing state; o Owner: means that the costumer automaton is in the owner state; o Owner_Waiting: represents that the owner is in the waiting state.
6. Verification of properties
Property 2: & (Waiting_Floor_Context4Floor_Context_ Request_Processing) - B (Waiting_FLoor and Floor_Server_Ready)
In this section, we discuss the verification of temporal properties using the Promela/Spin tool. This verification needs a description of the automata in Promela language.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
437
Fig. 7. Promela specification of the chairman.
6.1. Promela description Create Conference
A Promela automaton description (Holzmann, 1996) consists in a global loop ‘‘do .. od’’ composed of indeterministic choice that are described by the ‘‘if .. fi’’ statement, proposing then several alternatives as shown in Fig. 7. The reactive or operational part of it is described by a guard whose evaluation allows (or not) the execution of the action. Each alternative corresponds to a particular state of the automata. Therefore, for the choice 2 for example, when the automaton is at INIT state (state ¼ ¼ INIT) and receives a SCCP_CREATE_CONFERENCE message from the conference controller, it sends the same message to the conference server and transits to the WAINTING state. In order to set up the interaction between processes, we use communication channels that are described as follow. For example, CHANNEL_RECEPTION: a channel from which the customer automaton receives incoming messages; CHANNEL_CONFERENCE_SERVER: a channel in which the customer automaton sends messages to conference server. 6.2. Verification with spin We start the validation of our Promela Model by checking that there are no deadlocks, no dead code. This means that
Request Floor
Create Floor
Exploit
Conference Owner Release Floor
Appointe Floor
Participant
Terminate Conference
Join Conference Chairman Leave Conference Invite Participant Manage Conference Remove Participant Give Floor Control Floor Grab Floor
Fig. 8. Use case diagram.
all the transitions are executed. We also check that there are neither livelocks nor end_state unless for terminal states that belong to the specification of whole of processes. The verification is done using Spin from Bell Labs. It consists to translate the LTL properties to Bu¨chi automaton that are afterwards translated into Promela. The verification uses the model-checking technique based on the accessible states and consists in confronting this model to the property that has to be checked. The obtained diagnosis is the result of synchronous product of both the automata.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
438
use cases. The actors of the system are the conference owner, the chairman and the participant. The conference owner may create the conference, creates the floors, assigns them to the chairmen and may terminate the conference. The conference participants (simple participants or chairmen) may join or leave the conference. The chairman may also manage the participants group of the conference (invite participants or remove them from the conference). Once a floor has been assigned to the chairman, this chairman controls the floor according to a chaired policy (gives floor, grab floor, etc.). A participant may request or release a floor.
Practically, for each property, we start by writing down the propositions used by the property. This is done by using the macro-instruction #define in the symbols definition part. Thereafter, we introduce the property in question, and we generate the automata related to the property (with the Never Claim generator) before launching the verification process. 7. Design and implementation In this section, we present a design and an implementation of a multimedia teleconferencing system according to the formal description presented above. The design is done by using the standard notation UML.
7.1.2. Class diagram We have identified six main classes as shown in Fig. 9. The first class, named ‘‘Interface’’ offers graphical interface which allows users to communicate with the system. It provides operations which can be invoked by users such as: create a conference, create a floor, etc. The second class denoted ‘‘Customer Entity’’ represents the control and management entity instance associated to a
7.1. System design 7.1.1. Use case diagram Fig. 8 shows the use case diagram of the proposed system. This diagram consists in actors who interact with Media Agent ID_Media_Agent Send_Media() Stop_Send_Media()
CSE_Join_Conference() CSE_Create_Conference() CSE_Leave_Conference() CSE_Terminate_Conference() CSE_Request_Conference_Context() CSE_Give_Conference_Context()
Interface Join_Conference() Create_Conference() Create_Floor() Appointe_Floor() Request_Floor() Give_Floor() Release_Floor() Grab_Floor() Invite() Leave_Conference() Terminate_Conference() Request_Floor_Context() Request_Conference_Context() Give_Floor_Context() Give_Conference_Context()
Conference Server Entity ID_Conference_Server
Invoke
Consult
Interact
Conference Context
Customer Entity
Participant_List
ID_Customer_Entity Invoke
CE_Join_Conference() CE_Create_Conference() CE_Create_Floor() CE_Appointe_Floor() CE_Request_Floor() CE_Give_Floor() CE_Release_Floor() CE_Grab_Floor() CE_Invite() CE_Leave_Conference() CE_Terminate_Conference() CE_Request_Floor_Context() CE_Request_Conference_Context() CE_Give_Floor_Context() CE_Give_Conference_Context()
CC_Request_Conference_Context() Add_participant() Remove_Participant()
SIP Entity Invoke
ID_SIP_Entity INVITE() OK() BYE() CANCEL() Invoke
Interact
Floor Context Holder_List Requester_List
Floor Server Entity Ask_Floor() Create_Floor() Give_Floor() Grab_Floor() Release_Floor() Appointe_Floor() Request_Floor_Context() FSE_Request_Floor_Context() FSE_Give_Floor_Context() OK_SIP() Bye_SIP()
Fig. 9. Class diagram.
Consult
FC_Request_Floor_Context() Add_Holder() Remove_Holder() Add_Requester() Remove_Requester()
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
user. It provides services which can be invoked by the ‘‘Interface’’ class and conveys them to the appropriate server (conference server or floor Server). The third class denoted ‘‘Conference Server Entity’’ represents the conference server and provides services related to participants group management. It interacts with the ‘‘Conference Context’’ Class which is composed of the participants list which should be updated after a participant joining or leaving. The fourth class: ‘‘Floor Server Entity’’, represents the floor server. It provides the floor control services and uses the ‘‘Floor Context’’ in order to update the floors holders list or the floors requesters list. The fifth class denoted ‘‘Media Agent’’ class provides the services of conveying different media. The sixth class, ‘‘SIP Entity’’, offers the services of users localization and their invitation to participate to conferences or to use floor. 7.1.3. Sequence diagram For each use case, we design a sequence diagram. Fig. 10 depicts the sequence diagram of the ‘‘Give Floor’’ use case. Interface : (Chairman)
Customer Entity : (Chairman)
Floor Server Entity
Floor_Context
439
In order to give the floor to a participant, the chairman needs to consult the floor context. Therefore, he requests the context floor by invoking the ‘‘Floor Context Request’’ on its interface, which is relayed to its ‘‘Customer Entity’’ instance and then to the ‘‘Floor Server entity’’. This entity replies by giving the chairman the floor context which allows him to decide whose participant will be the following floor holder. The chairman gives the floor to this participant by invoking the ‘‘Give floor’’ operation. This will be sent to the floor server which updates the floor context. 7.2. Implementation In this section, we present the implementation of a Multimedia Teleconferencing System. This implementation was made by using the JAVA language and Java Media Framework API over LINUX above the 10 Mbps local area network of our laboratory. Fig. 11 shows the chairman interface which is organized as a set of components which allows the conference control SIP Entity
Customer Entity : (Participant)
Media Agent : (Participant)
CE_Request_Floor_Context FSE_Request_Floor_Context FC_Request_Floor_Context
FC_Give_Floor_Context
CE_Give_Floor_Context
Give_Floor_Context
CE_Give_Floor
FSE_Give_Floor INVITE (SIP)
OK (SIP)
CE_Give_Floor Send_Media
Give_Floor
Fig. 10. Floor sequences diagram.
Interface : (Participant)
440
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
8. Conclusion
Fig. 11. Interaction diagram.
In this paper, we have presented a formal description, a design and an implementation of Floor Control protocol for a teleconferencing system over Internet. The specification of this protocol is done using the finite-state machine model. The protocol interactions are based on primitives services presented in the SCCP IETF document. Our aim here consists to present a formal description and check some properties described in the floor requirements document. Properties are expressed using the LTL logic with some known patterns as form p-Q where p is a proposition and Q a temporal formula. Specifications are translated into Promela language and it is composed by several parallel processes. The properties that the protocol has to fulfil have been translated into Bu¨chi automata that encode their negations. These properties have been confronted to the model by the synchronous product achieved by Spin and the verification is ensured. Once validated and checked, this specification has been used as a base for a design an implementation using Java and JMF Java Multimedia Framework. We plan in future to evaluate really this application in a large environment and to extend its functionality to teleteaching. References
Fig. 12. Interaction diagram.
and management. The first component is the floor panel that allows the chairman to give a floor, grab a floor, or ask for its state and the floor context. The second component is the group management panel which permits to consult the list of the conference group or the list of the floors requesters, and to remove participants from the conference. The third component is the resource panel which allows activating or deactivating the used resource like audio, video, with board, etc. The fourth component is the conference panel which permits to initiate, resume, pause or terminate the conference. Fig. 12 presents the participant interface which seems the same of the chairman interface but offers more restricted functionalities. In the floor panel, the participant may just request or release the floor. In the resource panel, the participant may choose the resource specified by the chairman. In the conference panel, the participant may leave the conference.
Baudin, V., Royo, K.V., Owezarski, P., Gayraud, T., Owezarski, S. Une Visioconfe´rence sur IP, JRES’2001, Lyon, 10–14 De´cembre 2001. Baudin, V., Raymond, D., Matsuura, K., Kanenishi, K., Yano, Y., 2006. De´ploiement et E´valuation d’un Environnement de Travail Coope´ratif dans un Sce´nario D’apprentissage de Langue. NOTEE’06, Toulouse, 2006. Bormann, C., Ott, J., Kutscher, H. SCCP: Simple Conference Control Protocol, Internet Draft, draft-ietf-mmusic-sccp-01-txt, 13 February 2001. Dommel, H.-P, Garcia-Luna-Aceves, J.J., 1999. Network support for turn-taking in multimedia collaboration. In: Proceedings of the IS& T/SPIE Symposium on Electronic Imaging: Multimedia Computing and Networking, San Jose, CA, February 1999. Dommel, H.-P, Garcia-Luna-Aceves, J.J., 2003. Efficient group coordination in multicast trees. The Journal of Supercomputing. Kluwer Academic, New York and Dordrecht, NL 24 (February (2)) 183–192. Fluckiger, F., 1995. Understanding Networked Multimedia Applications and Technology. Prentice-Hall, New York. Gomes, R.L, Hoyos-Rivera, G.J., Courtiat, J.P., 2005. LEICA: Un Environnement Faiblement Couple´ Pour l’inte´gration, NOTERE’05, Ottawa. Handley, M., Jacobson, V., 1998. SIP: Session Initiation Protocol, RFC 2543. Hilt, V., Schremmer, C., Kuhmu¨nch, C., Vogel, J. Creation and use of multimedia Teachware in synchronous and asynchronous teleteaching. WI-Schwerpunktheft ‘‘Virtuelle Aus- und Weiterbildung’’ 43 (01/2001), pp. 23–33, February 2001. Holzmann, G., 1996. The model checker Spin. IEEE Transactions on Software Enginnering 23 (15). Ibriz, A., Erradi, M., Trehel, M. A Layered Cooperative Architecture and its Application in Tele-teaching Framework, PDPTA’99, Las Vegas, June 1999. ITU-T- H. 323, 2000. Visual Telephone Systems and Equipment for Local Area Networks with Non-Guaranteed Quality of Service, ITU-T Recommendation H. 323. Kausar, N., Crowcroft, J. An architecture of conference control functions. In: Proceedings of Photonics East, Boston, Massachusetts, September 20–22, 1999.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441 Kirsten, P.T., 1999. The MECCANO Internet Multimedia Conferencing Architecture. Technical Report, University College London. Manna, Z., Pnuelli, A., 1992. The Temporal Logic of Reactive and Concurrent Systems: Specification. Spinger, ISBN 0-387-97664-7. Ouzzif, M., Erradi, M., 2002. A formal specification and verification of a floor control protocol. Technical Report. Computer Networks and Multimedia Research Group, UFR-RT, Mohammed V Souissi University, ENSIAS Marocco. Ouzzif, M., Erradi, M., Courtiat, J.-P., 2005. Gestion Dynamique de groupe dans un environnement de controˆle de visioconfe´rence, NOTERE’05, Ottawa-Hull, Canada.
441
Owezarski, P., Baudin, V., Diaz, M., 1997. Conception et De´veloppement d’un Syste`me de Te´le´ -formation Professionnelle, Calculateurs Paralle`les, vol. 9, nume´ro 2. Scholler, E.M., 1996. Conferencing and Collaborative Computing. Multimedia Systems, Springer. Schulzrine, H., Wu, X., Koskelainen, P., Ott, J. Requirements for Floor Control Protocol, Internet Draft, draft-ietf-xcon-floor-control-req-00, January 8, 2004. Villemur, T., Rodriguez Peralta, L.M., Drira, K., Conception d’un service de gestion de session oriente´ mode`le pour des groupes collaboratifs synchrones, CFIP’03, 2003.
Description of a teleconferencing floor control protocol and its implementation Mohammed Ouzzif a,, Mohammed Erradia, Hassan Mountassirb a
Laboratoire Alkhawarizmi de Ge´nie Informatique, Equipe Re´seaux et Te´le´communication, Universite´ Mohamed V-Souissi, ENSIAS B.P. 713 Agdal, Rabat, Morocco b Laboratoire d’Informatique de l’Universite´ de Franche-Comte´ (LIFC) 6, Route de Gray, 25030-F Besanc- on-cedex, France Received 7 November 2006; received in revised form 30 October 2007; accepted 8 November 2007 Available online 30 January 2008
Abstract In this paper, we present a formal specification of a teleconferencing floor control protocol and its implementation. The services provided by this protocol are described within the SCCP IETF document (Simple Conference Control Protocol). Finite state machines are used to model services behaviours part of this protocol. Temporal properties are defined as constraints of the teleconferencing system using SCCP protocol. The dynamic properties are described by the LTL logic (Linear Temporal Logic) and verified using the modelchecker Spin/Promela. A prototype of a multimedia teleconferencing system is implemented and it is based on the specified protocol. This implementation uses UML notation and is developed with JMF (Java Media Framework) API. r 2007 Elsevier Ltd. All rights reserved. Keywords: Floor control; SCCP; Specification; Verification; LTL properties; Promela/Spin; Multimedia; Teleconferencing
1. Introduction Advances in multimedia technologies and high-speed networks led to the emergence of several platforms that support multimedia teleconferencing systems MMTS. Various approaches are proposed in Baudin et al. (2006), Fluckiger (1995), Gomes et al. (2005), Ibriz et al. (1999), Kirsten (1999), Scholler (1996). An MMTS system allows a group of users, geographically distributed, to work together. An e-learning system is an example of a multimedia teleconferencing system where the group is composed of teachers and students (Baudin et al., 2001; Owezarski et al., 1997). The teacher initiates a session, which is joined and left dynamically by students. During a course, the teacher is seen and heard by all the students and handles a set of shared resources (whiteboard, slides, pointers). To improve understanding, a student gets the right to speak, which will be given to him if the teacher Corresponding author. Tel.: +212 7451 0356; fax: +212 2225 2245.
E-mail addresses: [email protected] (M. Ouzzif), [email protected] (M. Erradi), [email protected] (H. Mountassir). 0952-1976/$ - see front matter r 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.engappai.2007.11.003
accepts his request. This allows the student to be shown to all group members and to be able to use some shared resources. The management of these interactions is referred as floor control and presented in Dommel and GarciaLuna-Aceves (1999), Kausar and Crowcroft (1999), Ouzzif and Erradi (2002) and Ouzzif et al. (2005). A Floor is a temporary permission granted dynamically to collaborating users in order to mitigate race condition and guarantee mutually exclusive resource usage (Dommel and Garcia-Luna-Aceves, 2003). A MMTS must also allow for the conference members management which is referred as Conference (Villemur et al., 2003). Providing conference management without floor control is analogous to a transportation infrastructure without traffic control. These two issues should be supported by a MMTS. A Simple Conference Control Protocol SCCP was proposed by the IETF community (Bormann et al., 2001). The SCCP document defines the services required for simple conference control of tightly coupled conference. These services are guided by the IUT-T recommendations of the H.323 (ITU-T-H. 323, 2000) series and concern three aspects: the management of a set of members; the management of a set of media/application session and the
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
floor control which enables especially conducted conference. However, this document provides an informal description of the services to be provided and do not specify the dynamic behaviour of the conference control and management protocol. The behaviour must be defined and formalized in order to be able to check the protocol consistence and to test its implementation. The formalization process allows accomplishing specifications that are clear, consistent and unambiguous. Therefore, the verification becomes possible and aims to check if the subsystem satisfies the desired properties. This formalization allows also conformance testing to check that the external behaviour of a given implementation is equivalent to its specification. In this paper, we first describe a formal description of the SCCP using the finite states model. Therefore, we present patterns of temporal properties expressed by LTL (Linear Temporal Logic). These properties are checked using the Promela/Spin verification tool. Additionally, an implementation of a multimedia teleconferencing system, based on floor protocol, is given in the last of the paper. This paper is organized as follows: Section 2 presents a multimedia teleconferencing architecture and the floor control protocol. Section 3 describes the provided services of SCCP. Section 4 defines the behaviours of the floor control protocol with states machines. Sections 5 and 6 focus on temporal properties and their specification using the LTL logic. Section 7 proposes an implementation of a simple prototype conferencing. In last, Section 8 concludes this work and plans future work. 2. Floor control architecture The floor control architecture is composed of six logical entities: a floor control server, a conference server, one or more SIP server (SIP for Session Initiation Server), a conference owner, one or more floor chairs (moderators) and any number of regular conference participant (Schulzrine et al., 2004). A floor control protocol conveys the floor control messages among the floor chairs of the conference, the floor control server and the participants of the conference (Fig. 1). A centralized architecture is assumed in which all messages go via one point: the floor server. Processing (granting or rejecting) floor control requests are done by one or more floor chairs or by the server itself, depending on the policy. A conference server corresponds to a nodes group that makes a conference. It stores and maintains dynamically the conference information concerning this group in a ‘‘conference context’’. It receives services requests from the owner, the chairs and the participants. These requests concern the conference creation/termination and the participant joining/leaving. A conference owner interacts with the session server to create floors, appoints and changes the floor chairs of the conference. The participants may claim the floor for
Conference Server
431
Floor Control Server
Internet
Floor Chair
Floor Chair SIP Server
SIP Server
Conference participant
Conference participant
Conference Owner
Conference group
Fig. 1. Floor control architecture.
particular resources by sending floor requests to the floor control server. Floor requests from the participants are received by the floor server and kept in an—at level of the floor control protocol—‘‘unordered’’ floor request set. The current floor holders are reflected in a current floor holder set. Floor chairs are capable of manipulating both sets to, e.g. grant, revoke, reject and pass the floor. The order in which requests are processed, whether they are granted or rejected, how many participants obtain a floor simultaneously is determined by a higher layer application operating on these sets and is not confined by the floor control protocol. The SIP server interacts with the floor server and session server. It allows them to localize and invite a participant in a sub-network. The logical entities interact according to a conference policy located in the floor control server. This policy defines the rules of these interactions and allows the floor control server to answer to the requests received from the different other logical entities. 3. Floor control services In this work, we focus mainly on the conference control and conference management in tightly coupled conferences. It consists of tools to control the floor and to manage a conference. Conference management administrates membership, maintains connectivity, orchestrates sessions including tool invocation and provides session’s state information and teardown based on a connection management protocol. The floor control allows users of networked multimedia application to utilize and share resources such as remote devices, distributed data set, pointers, or continuous media such as audio and video without access conflicts. Floors are temporary permissions granted dynamically to collaborating users in order to mitigate race conditions and guarantee mutually exclusive resource usage. Providing conference management without floor control is analogous
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
432
Conference Controller
Media Agent
SCCP Entity
SIP
Audio / Video
TCP
Schared Application
UDP
IP and IP Multicast
Fig. 2. SCCP entity.
to a transportation infrastructure without traffic control. Any architecture that allows entities to coordinate and cooperate needs protocols to mitigate race conditions and to either avoid or resolve conflicts and their implications. In Bormann et al. (2001), the authors define a set of services for simple conference control, namely: management of the set of members participating in the conference; management of the set of media/application sessions that constitute the conference; and floor control. These services are provided by the SCCP (Simple Conference Control Protocol) entity that interacts, on one hand, with a user via a conference controller entity; and with a media agent and the SIP entity on other hand (Fig. 2). The conference controller is an application that represents an interface between the participant and the SCCP entity. The SIP entity provides the localization and invitation services to the SCCP entity. The SIP-entity behaviour is described in the SIP document (Handley and Jacobson, 1998). The services provided by the SCCP entity are of two kinds: conference management services and floor control services.
3.2. Floor control services The Floor control services are used in following:
3.1. Conference management services
The conference management services are described as follows:
SCCP_Create_Conference: allows to create a new conference by a conference owner (the responsible of a conference); SCCP_Conference_Created: notifies the conference creation; SCCP_Join: allows to dynamically join a conference. The conference context is updated appropriately. SCCP_Ack_Join: notifies the Acknowledgement of the conference join; SCCP_Leave: allows to dynamically leaving a conference without disturbance. The conference context is updated appropriately; SCCP_Ack_Leave: notifies the Acknowledgement of the conference leave; SCCP_Invite: SCCP users may invite other users to participate in the current SCCP conference;
SCCP_Accept: expresses that the invited participant accepts an invitation; SCCP_Pause: provides to take pause in a conference; SCCP_Resume: resumes a conference after a taking pause; SCCP_Remove: permits to a conference owner, in the case of a ‘‘conducted’’ conference, to remove a selected participant; SCCP_Request_Conference_Context: allows to request for information about a conference; SCCP_Terminate: in the case of a ‘‘conducted’’ conference, the conference owner may terminate a running conference; SCCP_Ack_Terminate: notifies the Acknowledgement of the conference terminate.
SCCP_Create_Floor: allows to create a new floor by a conference owner (the responsible of a conference); SCCP_Floor_Created: notifies the floor creation; SCCP_Appointe_Floor: allows the conference owner to appoint a floor to a participant which will be a floor chair; SCCP_Ack_Appointe: notifies the Acknowledgement of the floor appointing; SCCP_Floor_Appointed: notifies a conference owner that the floor has been appointed; SCCP_Floor_Not_Appointed: notifies that the floor has not been appointed; SCCP_Give_Floor: grants an exclusive floor to another participant; SCCP_Grab_Floor: allocates a floor for exclusive use by the requesting participant; SCCP_Release_Floor: releases a previously allocated floor; SCCP_Ask_Floor: asks the floor holder to grant an exclusive floor to the requesting SCCP entity; SCCP_Reject_Floor: allows the floor chair to reject a floor request; SCCP_Ask_Floor_Pending: notifies the participant that his floor request is pending and will be processed later; SCCP_Request_Floor_Context: allows asking for the floor context; SCCP_Give_Floor_Context: gives the floor context to the floor chair.
4. Floor control protocol description A tightly coupled conference has more formal control policies with respect to the underlying Social Protocol of the specific scenario. The authors in Hilt et al. (2001) identify four main floor control policies: no control, implicit floor control, explicit floor control and chair
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
control. In this work, we adopt the last one. In this policy, one person is designated as the chairperson or the moderator of a floor by the conference owner. He or she can give or grab the floor for certain resources at any time. Floor requests of participants have to be queued and monitored to the chairperson.
Ready
? SCCP_Create_Conference / !.
?. / ! SCCP_Conference_Created /
Conference Creation ? SCCP_Join / ! .
?. / ! SCCP_ACK_Join Conference Joining
? SCCP_Leave / !.
? SCCP_Terminate / ! .
Conference Leaving
Conference Terminating
?. / ! SCCP_ACK_Leave
? SCCP_ACK_Terminate / !.
Fig. 3. Session server behaviour.
Recall that the SCCP document in Bormann et al. (2001) presents the protocol service primitives only. It did not specify the behaviour of such protocol. The aim of our work is to give a description and a formal specification of the behaviour of this protocol in order to check temporal properties of this protocol. In this section, we describe the SCCP entity behaviour using a finite state machine. According to the architecture presented in Fig. 1, there are three kinds of the SCCP entity: the conference server SCCP entity located in the conference server, the floor server SCCP entity located in the floor control server and the customer SCCP entity located in the other logical entity of this architecture (owner site, chair site or participant site). Fig. 3 depicts the SCCP entity behaviour of the session server. This behaviour consists mainly of the ready state and the states in which it is making a particular service (conference creation state, conference joining state, conference leaving state and conference terminating state). It is initially in the ready state and transits to an other state when it receives a SCCP conference service request (create, join, leave or terminate). Once this service is made, it returns to the ready state.
Floor_Request_Processing Floor_Creation
? SCCP_Ask_Floor / ! .
?. / ! SCCP_Ask_Floor_Pending
? SCCP_Create_Floor / !. ?. / ! SCCP_Floor_Created
Ready
? SCCP_Release_Floor /!. ?. / ! SCCP_Give_Floor ? OK (SIP) / ! SCCP_Give_Floor ! SCCP_Reject_Floor to Floor_Release_Processing ? SCCP_Give_Floor / other participants ! INVITE (SIP) ? BYE (SIP) / ! SCCP_Give_Floor
SIP Inviting
? SCCP_Grab_Floor / ! SCCP_Grab_Floor
Grab Processing
? SCCP_Request_Floor_Context / !.
? SCCP_Appointe_Floor / ! INVITE (SIP)
? SCCP_Release_Floor / ! SCCP_Give_Floor
Floor Context Request Processing
?./ ! SCCP_Give_Floor_Context ? SCCP_ACK_Appoint / ! SCCP_Floor_Appointed
SIP Inviting
433
Appointing
? OK / ! SCCP_Appointe_Floor
Fig. 4. Floor server behaviour.
? Time_Out / ! SCCP_Floor_Not_Appointed
? BYE (SIP) / ! SCCP_Not_Appointed
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
434
? SCCP_Give_Floor / ! SCCP_Give_Floor ?. / ! SCCP_Ask_Floor_Pending
Holder
?. / ! SCCP_Grab_Floor Init Wainting Floor ? SCCP_Reject_Floor / ! SCCP_Reject_Floor ? SCCP_Grab_Floor / SCCP_Release_Floor ? SCCP_Release_Floor / !SCCP_Release_Floor
?. / ! SCCP_Ask_Floor ? SCCP_Give_Floor / ! SCCP_Give_Floor
? SCCP_Create_Conference / ! SCCP_Create_Conference ? SCCP_Join / ! SCCP_Join Participant
?. / ! SCCP_Give_Floor ?. / ! SCCP_Give_Floor_Context
? SCCP_Ack_Join / ! ? SCCP_Appointe_Floor / ! SCCP_Ack_Appointe_Floor Waiting
Chair ? SCCP_Create_Floor / ! SCCP_Create_Floor ? SCCP_Conference_Created / . ? SCCP_Appointe_Floor / ! SCCP_Appointe_Floor ? SCCP_Floor_Appointed /. ? SCCP_Floor_Created / . ? SCCP_Request_Floor_Context / !. ? SCCP_Floor_Not_Appointed /.
? SCCP_Give_Floor_Context / !.
Wainting Floor Context
Owner
? SCCP_Terminate / ! SCCP_Terminate
End Fig. 5. Customer behaviour.
The floor control server behaviour is depicted in Fig. 4. It is initiated by the ready state. When it receives a floor control service request (e.g. floor creation request), it transits to a floor control service rendering state (e.g. floor creation state). Once the service is made, it sends a notification (e.g. SCCP_Floor_Created) to the logical entity that has requested the service (e.g. owner) and return to the ready state. To localize and invite a participant, the floor server uses the SIP invite primitive. Fig. 5 describes the customer SCCP entity. It is initially in the init state. It consists mainly in the following states:
participant and holder states related to the simple participant behaviour; owner state related to the owner behaviour; chair state related to the chair behaviour.
The owner behaviour can be in the waiting state when it is waiting for a particular service from the floor control server or the conference server. The participant behaviour and the chair behaviour transit to the waiting_floor state when they do not hold the floor and are waiting for it. The floor is exchanged between the chairs and the participants. It is the chair which controls the floor holding. It requests periodically for the floor context to the floor server which contains the set of floor requesting participants. Based on this information, it gives the floor to a particular participant which becomes the holder and rejects the floor requests of the other participants. A participant in a holder state may release the floor and return to the participant state. The chair may grab the floor to the holder if he does not release the floor in a particular delay.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441 Conference Participant
Conference Owner
Conference participant
Conference Server
435 SIP Server
Floor Server
SCCP_Create_Conference SCCP_Conference_Created SCCP_Join_Conference SCCP_Ack_Join SCCP_Create_Floor SCCP_Floor_Created SCCP_Appointe_Floor INVITE (SIP) OK (SIP) SCCP_Appointe_Floor SCCP_Ack_Appoointe SCCP_Join_Conference Conference chair
SCCP_Ack_Join SCCP_Ask_Floor SCCP_Ask_Floor_Pending
SCCP_Request_Floor_Context SCCP_Give_Floor_Context SCCP_Give_Floor INVITE (SIP) OK (SIP) SCCP_Give_Floor SCCP_Release_Floor SCCP_Give_Floor
SCCP_Grab_Floor SCCP_Grab_Floor
or SCCP_Release_Floor SCCP_Give_Floor SCCP_Leave_Conference SCCP_Terminate_Conference
Fig. 6. An example of a scenario.
Fig. 6 depicts the MSC (Message Sequence Chart) as a script of interactions among the logical entities of the architecture presented in Fig. 1. These interactions are:
A conference creation formulated by a SCCP_Create_ Conference request from the conference owner to the conference server; A Conference join: by sending a SCCP_Join message to the conference server; The floor appoint: by the conference owner to a conference participant (which becomes a conference chair) by sending a SCCP_Appointe_Floor to the floor server; A floor request: sent by a participant to the floor server in a SCCP_Ask_Floor message; A SIP invitation formulated by the floor server to the SIP Server by the ‘‘INVITE’’ message in order to localize and invite a participant; A floor context request formulated by a SCCP_ Request_Floor_Context from a floor chair to the floor server;
A floor grant formulated by the SCCP_Give_Floor from a floor chair to the floor server which is relayed to the participant; A floor release formulated by the SCCP_Release_Floor from a participant to the floor server; A floor revoke formulated by the SCCP_Grab_Floor from a floor chair to the floor server which is relayed to the concerned participant.
5. Floor control properties In this section, we give a set of properties to be satisfied by our teleconferencing system. Then, we describe them using the LTL. 5.1. Properties In Schulzrine et al. (2004), a description of properties as requirements of a floor control protocol is given. We are
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
436
interested for some properties in following:
Property 1: It must be possible to define who is allowed to create, change and remove a floor in a conference. It is assumed that the conference has always these privileges. Property 2: It must be possible to use a chair-controlled floor policy in which the floor control server notifies the floor chair and waits for the chair decision. This enables the chair to fully control who has the floor. Property 3: Participants must be able to request a floor. Property 4: It must be possible to grant a floor to a participant. Property 5: A participant must be informed that he has been granted the floor. Property 6: It must be possible to reject a participant’s floor request. Property 7: The floor chair or moderator must be able to grab the floor from its current holder. Property 8: A participant must be informed that the floor was revoked.
where o Waiting_Floor_Context: means customer automaton is in the floor context waiting state; o Floor_Context_Request_processing: means that the floor server is processing the floor context request; o Waiting_Floor: represents that the customer automaton is waiting the floor.
Property 3: & (Participant - B (participant_Waiting_ Floor) where o Paricipant: means customer automaton is in the participant state; o Participant_Waiting_Floor: means that the customer automaton is related to a participant role and it is waiting floor state.
Property 4: & (chair - B (Waiting_Floor) where o Chair: means customer automaton is in the chair state; o Chair_Waiting_Floor: means that the customer automaton is related to a chairman role and it is waiting floor state.
Property 5: & (Participant_Waiting_Floor - B (Floor_Holder) where o Floor_Holder: means that the customer automaton is related to a participant and is in the holder state.
Property 6: & (Participant_Waiting_Floor_1 4 Participant_Waiting_Floor_2 - B (Floor_Holder_1 4 Participant_2) 3 (Floor_Holder_2 4 Participant_1) To describe this property, we use a configuration where there is a conference owner, a chair and two participants. Atomic propositions are o Participant_Waiting_Floor_i: means that the customer automaton related to the participant ‘‘i’’ is in the waiting floor state; o Floor_Holder_i: means that the customer automaton related to the participant ‘‘i’’ is in the holder state; o Participant_i: means that the customer automaton related to the participant ‘‘i’’ is in the participant state.
Property 7: & (Chair_Waiting_Floor - B (Chair) Property 8: & (Floor_Holder - B (Participant)
5.2. LTL description The properties mentioned above are described according to the states of automata presented in the previous section. For each property, we give the atomic propositions and temporal operators used in linear logic. Afterwards, we use the notations for the LTL described in Manna and Pnuelli (1992): the always operator symbolized by & and the eventually operator by B. The propositions use classical logic operators: like 4, : and -. The dynamic properties of the protocol are expressed with the following patterns: & (p - q) or & (p - B q), where p and q are atomic propositions. The first case expresses the fact that at every time a state of system verifies p, it should verify q. The second case expresses that at every time the system verifies p, in all the future executions, it should verify q.
Property 1: & (Floor_Server_Ready 4 Owner) - B (Floor_Server_Appointing 4 Owner_Waiting) where o Floor_Server_Ready: describes that the floor server is in the ready state; o Floor_Server_Appointing: means that the floor server is in the appointing state; o Owner: means that the costumer automaton is in the owner state; o Owner_Waiting: represents that the owner is in the waiting state.
6. Verification of properties
Property 2: & (Waiting_Floor_Context4Floor_Context_ Request_Processing) - B (Waiting_FLoor and Floor_Server_Ready)
In this section, we discuss the verification of temporal properties using the Promela/Spin tool. This verification needs a description of the automata in Promela language.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
437
Fig. 7. Promela specification of the chairman.
6.1. Promela description Create Conference
A Promela automaton description (Holzmann, 1996) consists in a global loop ‘‘do .. od’’ composed of indeterministic choice that are described by the ‘‘if .. fi’’ statement, proposing then several alternatives as shown in Fig. 7. The reactive or operational part of it is described by a guard whose evaluation allows (or not) the execution of the action. Each alternative corresponds to a particular state of the automata. Therefore, for the choice 2 for example, when the automaton is at INIT state (state ¼ ¼ INIT) and receives a SCCP_CREATE_CONFERENCE message from the conference controller, it sends the same message to the conference server and transits to the WAINTING state. In order to set up the interaction between processes, we use communication channels that are described as follow. For example, CHANNEL_RECEPTION: a channel from which the customer automaton receives incoming messages; CHANNEL_CONFERENCE_SERVER: a channel in which the customer automaton sends messages to conference server. 6.2. Verification with spin We start the validation of our Promela Model by checking that there are no deadlocks, no dead code. This means that
Request Floor
Create Floor
Exploit
Conference Owner Release Floor
Appointe Floor
Participant
Terminate Conference
Join Conference Chairman Leave Conference Invite Participant Manage Conference Remove Participant Give Floor Control Floor Grab Floor
Fig. 8. Use case diagram.
all the transitions are executed. We also check that there are neither livelocks nor end_state unless for terminal states that belong to the specification of whole of processes. The verification is done using Spin from Bell Labs. It consists to translate the LTL properties to Bu¨chi automaton that are afterwards translated into Promela. The verification uses the model-checking technique based on the accessible states and consists in confronting this model to the property that has to be checked. The obtained diagnosis is the result of synchronous product of both the automata.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
438
use cases. The actors of the system are the conference owner, the chairman and the participant. The conference owner may create the conference, creates the floors, assigns them to the chairmen and may terminate the conference. The conference participants (simple participants or chairmen) may join or leave the conference. The chairman may also manage the participants group of the conference (invite participants or remove them from the conference). Once a floor has been assigned to the chairman, this chairman controls the floor according to a chaired policy (gives floor, grab floor, etc.). A participant may request or release a floor.
Practically, for each property, we start by writing down the propositions used by the property. This is done by using the macro-instruction #define in the symbols definition part. Thereafter, we introduce the property in question, and we generate the automata related to the property (with the Never Claim generator) before launching the verification process. 7. Design and implementation In this section, we present a design and an implementation of a multimedia teleconferencing system according to the formal description presented above. The design is done by using the standard notation UML.
7.1.2. Class diagram We have identified six main classes as shown in Fig. 9. The first class, named ‘‘Interface’’ offers graphical interface which allows users to communicate with the system. It provides operations which can be invoked by users such as: create a conference, create a floor, etc. The second class denoted ‘‘Customer Entity’’ represents the control and management entity instance associated to a
7.1. System design 7.1.1. Use case diagram Fig. 8 shows the use case diagram of the proposed system. This diagram consists in actors who interact with Media Agent ID_Media_Agent Send_Media() Stop_Send_Media()
CSE_Join_Conference() CSE_Create_Conference() CSE_Leave_Conference() CSE_Terminate_Conference() CSE_Request_Conference_Context() CSE_Give_Conference_Context()
Interface Join_Conference() Create_Conference() Create_Floor() Appointe_Floor() Request_Floor() Give_Floor() Release_Floor() Grab_Floor() Invite() Leave_Conference() Terminate_Conference() Request_Floor_Context() Request_Conference_Context() Give_Floor_Context() Give_Conference_Context()
Conference Server Entity ID_Conference_Server
Invoke
Consult
Interact
Conference Context
Customer Entity
Participant_List
ID_Customer_Entity Invoke
CE_Join_Conference() CE_Create_Conference() CE_Create_Floor() CE_Appointe_Floor() CE_Request_Floor() CE_Give_Floor() CE_Release_Floor() CE_Grab_Floor() CE_Invite() CE_Leave_Conference() CE_Terminate_Conference() CE_Request_Floor_Context() CE_Request_Conference_Context() CE_Give_Floor_Context() CE_Give_Conference_Context()
CC_Request_Conference_Context() Add_participant() Remove_Participant()
SIP Entity Invoke
ID_SIP_Entity INVITE() OK() BYE() CANCEL() Invoke
Interact
Floor Context Holder_List Requester_List
Floor Server Entity Ask_Floor() Create_Floor() Give_Floor() Grab_Floor() Release_Floor() Appointe_Floor() Request_Floor_Context() FSE_Request_Floor_Context() FSE_Give_Floor_Context() OK_SIP() Bye_SIP()
Fig. 9. Class diagram.
Consult
FC_Request_Floor_Context() Add_Holder() Remove_Holder() Add_Requester() Remove_Requester()
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
user. It provides services which can be invoked by the ‘‘Interface’’ class and conveys them to the appropriate server (conference server or floor Server). The third class denoted ‘‘Conference Server Entity’’ represents the conference server and provides services related to participants group management. It interacts with the ‘‘Conference Context’’ Class which is composed of the participants list which should be updated after a participant joining or leaving. The fourth class: ‘‘Floor Server Entity’’, represents the floor server. It provides the floor control services and uses the ‘‘Floor Context’’ in order to update the floors holders list or the floors requesters list. The fifth class denoted ‘‘Media Agent’’ class provides the services of conveying different media. The sixth class, ‘‘SIP Entity’’, offers the services of users localization and their invitation to participate to conferences or to use floor. 7.1.3. Sequence diagram For each use case, we design a sequence diagram. Fig. 10 depicts the sequence diagram of the ‘‘Give Floor’’ use case. Interface : (Chairman)
Customer Entity : (Chairman)
Floor Server Entity
Floor_Context
439
In order to give the floor to a participant, the chairman needs to consult the floor context. Therefore, he requests the context floor by invoking the ‘‘Floor Context Request’’ on its interface, which is relayed to its ‘‘Customer Entity’’ instance and then to the ‘‘Floor Server entity’’. This entity replies by giving the chairman the floor context which allows him to decide whose participant will be the following floor holder. The chairman gives the floor to this participant by invoking the ‘‘Give floor’’ operation. This will be sent to the floor server which updates the floor context. 7.2. Implementation In this section, we present the implementation of a Multimedia Teleconferencing System. This implementation was made by using the JAVA language and Java Media Framework API over LINUX above the 10 Mbps local area network of our laboratory. Fig. 11 shows the chairman interface which is organized as a set of components which allows the conference control SIP Entity
Customer Entity : (Participant)
Media Agent : (Participant)
CE_Request_Floor_Context FSE_Request_Floor_Context FC_Request_Floor_Context
FC_Give_Floor_Context
CE_Give_Floor_Context
Give_Floor_Context
CE_Give_Floor
FSE_Give_Floor INVITE (SIP)
OK (SIP)
CE_Give_Floor Send_Media
Give_Floor
Fig. 10. Floor sequences diagram.
Interface : (Participant)
440
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441
8. Conclusion
Fig. 11. Interaction diagram.
In this paper, we have presented a formal description, a design and an implementation of Floor Control protocol for a teleconferencing system over Internet. The specification of this protocol is done using the finite-state machine model. The protocol interactions are based on primitives services presented in the SCCP IETF document. Our aim here consists to present a formal description and check some properties described in the floor requirements document. Properties are expressed using the LTL logic with some known patterns as form p-Q where p is a proposition and Q a temporal formula. Specifications are translated into Promela language and it is composed by several parallel processes. The properties that the protocol has to fulfil have been translated into Bu¨chi automata that encode their negations. These properties have been confronted to the model by the synchronous product achieved by Spin and the verification is ensured. Once validated and checked, this specification has been used as a base for a design an implementation using Java and JMF Java Multimedia Framework. We plan in future to evaluate really this application in a large environment and to extend its functionality to teleteaching. References
Fig. 12. Interaction diagram.
and management. The first component is the floor panel that allows the chairman to give a floor, grab a floor, or ask for its state and the floor context. The second component is the group management panel which permits to consult the list of the conference group or the list of the floors requesters, and to remove participants from the conference. The third component is the resource panel which allows activating or deactivating the used resource like audio, video, with board, etc. The fourth component is the conference panel which permits to initiate, resume, pause or terminate the conference. Fig. 12 presents the participant interface which seems the same of the chairman interface but offers more restricted functionalities. In the floor panel, the participant may just request or release the floor. In the resource panel, the participant may choose the resource specified by the chairman. In the conference panel, the participant may leave the conference.
Baudin, V., Royo, K.V., Owezarski, P., Gayraud, T., Owezarski, S. Une Visioconfe´rence sur IP, JRES’2001, Lyon, 10–14 De´cembre 2001. Baudin, V., Raymond, D., Matsuura, K., Kanenishi, K., Yano, Y., 2006. De´ploiement et E´valuation d’un Environnement de Travail Coope´ratif dans un Sce´nario D’apprentissage de Langue. NOTEE’06, Toulouse, 2006. Bormann, C., Ott, J., Kutscher, H. SCCP: Simple Conference Control Protocol, Internet Draft, draft-ietf-mmusic-sccp-01-txt, 13 February 2001. Dommel, H.-P, Garcia-Luna-Aceves, J.J., 1999. Network support for turn-taking in multimedia collaboration. In: Proceedings of the IS& T/SPIE Symposium on Electronic Imaging: Multimedia Computing and Networking, San Jose, CA, February 1999. Dommel, H.-P, Garcia-Luna-Aceves, J.J., 2003. Efficient group coordination in multicast trees. The Journal of Supercomputing. Kluwer Academic, New York and Dordrecht, NL 24 (February (2)) 183–192. Fluckiger, F., 1995. Understanding Networked Multimedia Applications and Technology. Prentice-Hall, New York. Gomes, R.L, Hoyos-Rivera, G.J., Courtiat, J.P., 2005. LEICA: Un Environnement Faiblement Couple´ Pour l’inte´gration, NOTERE’05, Ottawa. Handley, M., Jacobson, V., 1998. SIP: Session Initiation Protocol, RFC 2543. Hilt, V., Schremmer, C., Kuhmu¨nch, C., Vogel, J. Creation and use of multimedia Teachware in synchronous and asynchronous teleteaching. WI-Schwerpunktheft ‘‘Virtuelle Aus- und Weiterbildung’’ 43 (01/2001), pp. 23–33, February 2001. Holzmann, G., 1996. The model checker Spin. IEEE Transactions on Software Enginnering 23 (15). Ibriz, A., Erradi, M., Trehel, M. A Layered Cooperative Architecture and its Application in Tele-teaching Framework, PDPTA’99, Las Vegas, June 1999. ITU-T- H. 323, 2000. Visual Telephone Systems and Equipment for Local Area Networks with Non-Guaranteed Quality of Service, ITU-T Recommendation H. 323. Kausar, N., Crowcroft, J. An architecture of conference control functions. In: Proceedings of Photonics East, Boston, Massachusetts, September 20–22, 1999.
M. Ouzzif et al. / Engineering Applications of Artificial Intelligence 21 (2008) 430–441 Kirsten, P.T., 1999. The MECCANO Internet Multimedia Conferencing Architecture. Technical Report, University College London. Manna, Z., Pnuelli, A., 1992. The Temporal Logic of Reactive and Concurrent Systems: Specification. Spinger, ISBN 0-387-97664-7. Ouzzif, M., Erradi, M., 2002. A formal specification and verification of a floor control protocol. Technical Report. Computer Networks and Multimedia Research Group, UFR-RT, Mohammed V Souissi University, ENSIAS Marocco. Ouzzif, M., Erradi, M., Courtiat, J.-P., 2005. Gestion Dynamique de groupe dans un environnement de controˆle de visioconfe´rence, NOTERE’05, Ottawa-Hull, Canada.
441
Owezarski, P., Baudin, V., Diaz, M., 1997. Conception et De´veloppement d’un Syste`me de Te´le´ -formation Professionnelle, Calculateurs Paralle`les, vol. 9, nume´ro 2. Scholler, E.M., 1996. Conferencing and Collaborative Computing. Multimedia Systems, Springer. Schulzrine, H., Wu, X., Koskelainen, P., Ott, J. Requirements for Floor Control Protocol, Internet Draft, draft-ietf-xcon-floor-control-req-00, January 8, 2004. Villemur, T., Rodriguez Peralta, L.M., Drira, K., Conception d’un service de gestion de session oriente´ mode`le pour des groupes collaboratifs synchrones, CFIP’03, 2003.