Consistency support for a decentralized management in close multiparty conferences using SIP

Consistency Support for a Decentralized Management in Close Multiparty Conferences Using SIP1 Eduard C. Popovici, Ralf Mahlo, Mario Zuehlke and Hartmut Koenig Brandenburg University of Technology Cottbus Departement of Computer Science PF 10 13 44, 03031 Cottbus, Germany email:{popovici, rmahlo, mz, koenig}@informatik.tu-cottbus.de Abstract--Distributed multimedia applications such as conference and collaborative applications require an appropriate conference management. Close group conferences like meetings, discussions, teleseminars, or consultations need a strictly controlled group membership. Current conference systems achieve this by using a centralized group server as specified in the H.32x standards. Decentralized approaches are scarcely used so far, although they are more flexible. They avoid infrastructure dependencies and single point of failure problems which are often encountered in group server approaches, e.g. in classical virtual private networks. A decentralized conference management requires a consistency support by the underlying communication service. The Session Initiation Protocol (SIP) has become a widely applied protocol to support the signaling of multimedia applications in the Internet. It is also applied to support multiparty conference applications. The great majority of these approaches is related to open group and centralized organized conferences. For closed decentralized managed conferences, no solutions have been proposed up to now. In this paper we present such a group communication service based on SIP that ensures the consistency of decentralized managed group data. Index Terms—conference applications, collaborative work, distributed group management, signaling, SIP.

I. INTRODUCTION HE interest in conference applications (audio, video, or web based conferences) in the Internet is growing. Compared to e-mail or the World Wide Web these applications, however, are less used. The reason is that conference services are mainly deployed for open group applications to transfer, for instance, public events like lectures, conferences, internet TV, or concerts. Multiparty conference systems with a strictly controlled group membership (close groups) are better suited to set up meetings, discussions, teleseminars, or consultations. Depending on the required confidence of the meeting, authentication as well as encryption of the data streams may be added, but not all multiparty conferences, e.g. a seminar, require this just as not every e-mail must be encrypted. Existing products for close multiparty conferences are still not matured enough for a broad application, especially as a service offered at most desktop systems. Multiparty conference systems for close groups currently deployed in practice use a centralized conference management. They are mainly based on the ITU-T H.323-standard [6]. These systems need a Multipoint Control Unit (MCU) to control the conference, to merge the audio and video streams, and to distribute them to the participants. Further a Gatekeeper is required to manage the group and to handle address mappings. MCUs and gatekeepers are commercially provided by different providers. They are, however, still pretty expensive and require additional management support. In addition, specialized end system equipment is often needed. The set up of a conference depends therefore on the availability of a group server either as private property or offered by a service provider. As an alternative decentralized,

T

1

Accepted for 11th IEEE International Conference on Networks (ICON2003), September 2003, Sydney, Australia

serverless approaches have been proposed [2], [10], [15]. Serverless approaches offer more flexibility and independence to the users. They avoid the dependency of a service provider as well as other shortages of the centralized approach such as server failure and performance bottlenecks. Further they are more suitable for conference applications that involve hosts with different computing power. Decentralized approaches have a great potential to easily set up close and confidential meetings in the Internet as we are used in everyday life. A crucial point of the decentralized concept is the signaling between the partners. Unlike open group sessions in which each participant can join a running conference the participation in a closed meeting is based on invitation. The number of participants is always fixed, i.e. the sender knows the receivers of the media streams. The conference management has to supervise the composition of the group, to invite participants, to react on participants’ leave or failure, and to calculate the Quality of Service (QoS) parameter settings. It has to ensure the close character of the session and to preserve the consistency of the group data at each participant. This requires an appropriate consistency support by the underlying communication service. This can be only achieved if the communication service provides a reliable, atomic, and ordered data delivery. Furthermore, a dynamic join and leave of participants should be supported as well. The Session Initiation Protocol (SIP) has become a widely applied protocol to support the signaling of multimedia applications in the Internet [5]. It offers a generic way to convey signaling data to set up and to control a session. Compared to its main competitor, the H.323 protocol family, SIP offers more flexibility and simplicity, and has a more promising evolution and market. SIP originates from IP telephony. It has been applied to many areas, among them conference applications. SIP, however, does not support closed decentralized managed conference applications so far. Several models have been proposed for a SIP based conference management [14]. They are only dedicated to open or centralized managed groups. Close decentralized managed groups are still considered as open issue. In this paper we present a SIP based communication service to support close multiparty conferences with a decentralized organization. We describe the SIP user agent which implements the required group behavior. Note that we do not focus on the group and QoS management itself but on the underlying group communication service that represents the prerequisite for a distributed management. We also do not consider security aspects in this paper. They will be addressed in another paper. The paper is organized as follows. Section II defines the requirements to a closed group communication service with a decentralized management. Section III gives a short overview of SIP. Section IV describes the SIP user agent for the proposed service. Section V concludes the paper and outlines future work. II. GROUP COMMUNICATION REQUIREMENTS In the sequel we use the term „group management“ to describe all actions concerning the composition of the group. This comprises all information of the group members, the control of the group, the floor control to access shared resources (audio channel, whiteboard) as well as all actions to negotiate, to determine, to maintain, and to renegotiate the QoS requirements of the participants. A decentralized scheme as motivated in the introduction needs a consistent view of all participants on the conference as basis for a decentralized calculation of the QoS parameter settings and the assignment of the floor (speaking right, whiteboard access, and others). This requires an appropriate signaling data exchange in the underlying communication system which ensures that the group data at each participant are equally updated. The requirements to this group communication service are comparable to those in a distrib-

uted system. A multimedia conference, however, is a real-time application in which human beings are actively involved. This can be used for the group management. To assure the consistency of the group management data the exchange of signaling data has to fulfill the following requirements: - Reliability: In contrast to the transmission of continuous data where some frames or data units may be lost, distorted, or discarded the exchange of control information has to be reliable. Lost, distorted, or out of order messages are not allowed. - Atomicity: All participants must be equally updated, i.e. the messages have to be delivered either to all participants or to none of them to indicate an event to all participants. - Ordered delivery: If the order affects the results, data units of different senders have to be delivered to the receivers in the same order as they are sent. This ensures that events like joining or leaving the conference, or assigning the floor are indicated to all participants in the order they occur. Depending on the application, different levels of ordering may be required as described in [3]. In addition, many conference applications require a dynamic group composition which allows the participants to join and leave the conference at any time, and to exclude participants due to system failure. The signaling protocol should be as simple as possible to limit the group communication overhead and to not waste bandwidth and processing power for the video and audio transmission. III. SHORT OVERVIEW OF SIP The Session Initiation Protocol (SIP) is a peer-to-peer signaling protocol used by communication applications to establish, maintain, modify, and terminate sessions between two or more participants in an IP network [5]. It was created using features of other text based protocols such as HTTP. The simplicity, scalability and extensibility of SIP make it a good candidate for creating web applications in different architectures and deployment scenarios. SIP is independent of the media used by the applications, i.e. SIP is able to negotiate any media used within a session. Having its own reliability mechanism it can be used on top of UDP, TCP, or other transport protocols. SIP supports personal mobility by its ability of user location. A called registered party can be reached under a single, location-independent address, even when the user changes the terminals. An existing session can be modified at any time by sending new parameters [13], e.g. the set of media streams, codecs or credentials. This is also important for the conference QoS [12], [8] and resource management [9]. The most successful application of SIP nowadays is Voice over IP (VoIP). The alternative standard for VoIP networks is H.323 recommended by the ITU-T [6]. Its broad application is due to the fact that H.323 was the first accepted standard. Compared to SIP H.323 is more cumbersome because of its complexity, the format of signaling data, the use of vendorspecific non-standard elements, constricted services and others [11]. SIP in contrast provides standard based extensions, a simplified signaling scheme, text-formatted messages, and other advantages which can be useful for future applications. In [14] several models for multiparty conference system based on SIP are described in a consistent and complete fashion. The great majority of these models is related to open group and centralized organized conferences. A fully distributed multiparty model over a full mesh network has not proposed for SIP so far. This is still an open issue [14]. IV. A SIP BASED COMMUNICATION SERVICE FOR CLOSED CONFERENCE GROUPS In this section we describe a possible solution for a SIP based communication service to

support a distributed management of closed conference groups. It provides a reliable, atomic, and ordered data delivery which can be used by the group management on top of the service for exchanging information about the composition of the group, about joining or leaving of participants, about the floor assignment, and about the QoS demands of the participants. We describe the protocol between the SIP user agents (UA) that implements this group communication service. A. Service functionality The functionality of the group communication service can be divided in 3 activities: the invitation and joining of a new participant (JOIN), the exchange of signaling data (DAT), and the leaving of participants (LEAVE). The service primitives of these functions with a short description of their semantics are listed in Table I. Table I. Description of the used service primitives

Service Primitive JOINreq JOINind JOINresp JOINrej JOINdis JOINntf DATreq DATind LEAVEreq LEAVEconf LEAVEntf

Description A participant requests a new participant to join. Indication of an invitation to the new participant. The new participant responds that it accepts the invitation. The invited participant rejects the invitation. Indication that the JOIN procedure failed. Notification that a new participant successfully joined the group. Upper layer requests data to be sent. Indication that data have been received. A participant requests to leave the conference. Confirmation of LEAVEreq. Notification that a participant left the conference.

B. Basics of the group communication services In this subsection we give a short overview about the principle behavior of the user agent. A detailed description of the SIP message sequence follows in the next subsections. To provide an ordered delivery a token based mechanism similar to [1] and [7] is applied. The participants form a logical ring on which a token rotates. Only the token holder is allowed to send a signaling message with management data. If there are no messages to send the token is forwarded immediately. All participants have to acknowledge the reception of each message. Unacknowledged messages are retransmitted up to three times, like in TCP. The token is forwarded after all confirmations have been received. The reception of the token has to be acknowledged as well. If there are any outstanding acknowledgements after a certain period of time the so-called forced leave procedure is started which excludes the participants that did not acknowledge the message (it has to leave the conference). The forced leave mechanism is described and justified in subsection IV.F. Since at each token rotation only one data unit can be sent by each participant and acknowledged by the receivers, crossing and overtaking of messages are impossible. The participants receive all messages in the same order. Thus a totally ordered data delivery is achieved. The token rotating mechanism guarantees fairness among the participants. It also facilitates the early detection of participant failures even if no data are exchanged. The problem of token loss and duplication is discussed in the next subsection.

C. Rotating token mechanism The token forwarding procedure is depicted for three participants in Fig. 1. Hereby, it is assumed that the token holder has not to send data each time.

A (Th) timer tA reset tA

B

C (Tnext)

INFO (token) 200 OK (ack token) INFO (continue) 200 OK

(Th) tA

tC INFO (token) 200 OK (ack token) INFO (continue)

(Tnext) timer tC

INFO (token)

(Tnext) tC (Th)

200 OK 200 OK (ack token)

tA

INFO (continue) 200 OK

Fig. 1. Token forwarding (scenario for absence of signaling data)

The token forwarding uses a 3-way handshake. The token holder (Th) forwards the token to the next participant (Tnext) by means of a SIP INFO (token) message. INFO messages are a standard extensions of SIP introduced to carry application level information along the signaling path [4]. Tnext has to confirm the reception of the INFO (token) message by a SIP 200 OK response message. Then the former token holder sends another SIP INFO message indicating that Tnext can continue either by sending signaling data or by forwarding the token. Token losses may occur if the INFO or 200 OK response messages are lost. In order to detect this token holder Th starts a timer tA after sending the INFO (token) message. If the timer expires before the 200 OK response message is received it retransmits the INFO (token) message (see Fig. 2). The retransmission is repeated up to three times. If the retransmissions do not succeed it is assumed that Tnext has failed. In this case the already mentioned forced leave procedure for Tnext is triggered, i.e. Tnext is removed from the group (see subsection IV.F). After that the token ring is reconfigured and Th gives the token to the „new“ Tnext. The same retransmission procedure is applied at Tnext for detecting losses of the second INFO message. Here the timer tC (tC > tA ) is started (see Fig. 3). After three retransmissions it is assumed that Th has failed. The forced leave mechanism for Th is triggered to remove Th from the group. Thereafter the ring is reconfigured and Tnext continues as new token holder. The token may be also getting lost if the token holder itself fails. This is supervised by the token timer tT (tT >> tA) which is started at each participant after sending the token. When the token holder fails timer tT will expire at Tnext and thus trigger the forced leave procedure for the failed token holder.

(a)

A

B

C

B

C

INFO (token) timer tA

packet loss

timer expired retransmission (b)

INFO (token)

A INFO (token) timer tA

tC packet loss

timer expired

INFO (token) 200 OK (ack token) INFO (continue)

tC

Fig. 2. Token retransmission caused a) by INFO or b) by 200 OK loss

Token duplicates are detected by introducing a sequence number in the token message INFO. Each time the token is forwarded the sequence number is incremented. When Tnext receives the token it first checks the sequence number. The difference between the current value of sequence number and the former value (before token rotation) should equal the group size. Otherwise a token duplication is assumed and the token message is discarded.

A

B

C

INFO (token) timer tA

200 OK (ack token)

timer stopped

INFO (continue)

tC

200 OK (ack token) INFO (continue)

tC

200 OK

Fig. 3. Retransmission of 200 OK triggered by timer tC

D. Setting up the group and dynamic join The conference group is set up by successive joins of the participants. The conference is initiated by one participant that invites the next one. The others follow the same way. Currently joins are sender-initiated, i.e. only a participant already involved in the conference may invite a new member. This is different to open conference approaches in which users look for existing conferences and join themselves [5]. Closed group conferences, e.g. for meetings, seminars, or consultations, require knowledge of the group members.

A (initiator) JOINreq

B

D (Tnew)

C

INVITE (new)

JOINind

timer tI stopped

timer tR

200 OK

JOINresp

ACK REFER (new) 202 Accepted INVITE 200 OK NOTIFY

stopped

200 OK

ACK JOINntf

REFER (new) timer tR

202 Accepted

stopped

NOTIFY ACK JOINntf

200 OK JOINntf

INVITE 200 OK JOINntf

INFO (token)

Fig. 4. Join procedure

The join procedure begins with a JOINreq primitive from the inviting participant. The invitation is forwarded by an INVITE message to the invited participant Tnew when the inviting participant gets the token (see Fig. 4). The invitation is indicated to the new participant by a JOINind primitive. Tnew has to confirm or reject the invitation by JOINresp. After receiving the JOINresp a SIP 200 OK response message is sent back to the inviting participant that acknowledges it with an ACK message. Next the join of Tnew has to be announced to the other group members to update their local group composition lists. This is done by sending a SIP REFER message. The REFER message is a proposed SIP extension [16] broadly used in SIP applications to announce members of a conference about a new invitation. The REFER messages can be sent sequentially or in parallel to the other group members (see Fig. 4). Following the SIP approach, each group member will invite the new participant to set up peer to peer media connections. After acknowledging REFER each group member sends an INVITE to Tnew that confirms it with 200 OK. When Tnew received all INVITE messages it informs its group management by JOINntf about the successful join. The other group members confirm the success of their invitations to the initiator by means of a SIP NOTIFY message and indicate the join of the new participant to their group management by a JOINntf primitive. After receiving all NOTIFY messages the inviting participant delivers a JOINntf to its group management and passes the token to the next participant. During a join several errors may occur. First the initial INVITE or a 200 OK messages may be lost. In this case a timer tI at the initiator expires and aborts the join procedure by a JOINdis primitive. Further REFER or NOTIFY messages may get lost or one of the participants may fail. The inviting participant supervises these situations by another timer tR that triggers a retransmission of REFER. If the retransmission fails three times the forced leave mechanism is triggered to exclude the participants whose NOTIFY is missing. The loss of INVITE or 200 OK is handled similarly. This is supervised by a timer tJ (tJ < tR) that triggers the retransmission of INVITE. After the third failed retransmissions it sends a NOTIFY (not available) message to the initiator which starts forced leave for the invited participant (who failed to join). E. Data exchange The group management delivers data for transmission by a DATreq primitive. These data are stored until the participant gets the token. Then it sends the data to the group by an INFO message (see Fig 5). The data are delivered by a DATind primitive to the participants’ group management. All participants have to acknowledge the reception of this message by a SIP 200 OK response.

A DATreq

B

C

INFO (message) DATind INFO (message)

timer tD 200 OK (ack. msg.)

DATind 200 OK (ack. msg.)

INFO (token)

timer stopped

Fig. 5. Data exchange

A timer tD is used to trigger the retransmission in case that not all receivers confirmed the transmission. INFO is only retransmitted to those receivers that did not acknowledge the reception. There are again three retransmission attempts before excluding the participant is by forced leave. F. The leave procedure There are two LEAVE procedures: the regular leave when a participant wants to leave the conference and the forced leave as reaction to irregular situations in the group. The procedures are identical in part. They have different starting points. A (Tnext)

B

200 OK

200 OK

D (Tleave)

C

BYE (token) BYE BYE 200 OK

LEAVEconf

INFO (D leave) INFO (D leave) 200 OK LEAVEntf

LEAVEreq

LEAVEntf 200 OK

LEAVEntf

INFO (token)

Fig. 6: Regular leave

Regular leave: The regular leave is called by a LEAVEreq primitive of the participant Tleave. When Tleave gets the token it sends a BYE message to the group. After receiving all 200 OK responses the leaving participant delivers a LEAVEconf to its group management. When receiving the BYE message the next participant Tnext takes the token and the control over the leave phase. It sends an INFO (leave) message to the other group members to announce the leave (see Fig 6) which confirm it with 200 OK. After that they delivers a LEAVEntf to notify the group management about the change in group membership. For missing acknowledgements, again a selected threefold retransmission of the INFO (leave) message is applied. Any further outstanding 200 OK responses will trigger the forced leave mechanism for these participants. After receiving all acknowledgements the token holder delivers a LEAVEntf to inform the group management about the group change and passes the token. Forced leave: The procedure is called as already mentioned when a grave error is detected in the group communication which can endanger the consistency of the management data. The forced leave procedure is identical with the regular leave procedure starting from the point when Tnext takes the control. The exclusion of a participant due to an outstanding acknowledgement after three retransmissions seems to be very rough and unusual. In today networks, however, it can be assumed that the reason for an outstanding acknowledgement is less a transmission error but probably

a system failure which also will affect the audio and video transmission in the conference. In this case it seems more appropriate that the respective participant leaves the conference (and explicitly joins it again) than implementing a complicated error recovery procedure. A (Tnext)

B

D

C

(not responding)

timer expired 3rd time INFO (D leave)

(Th)

(Tleave)

INFO (D leave) 200 OK LEAVEntf 200 OK LEAVEntf

INFO (token)

LEAVEconf

Fig. 7. Forced leave

The forced leave procedure is started when the token holder (Th) notices an outstanding acknowledgment as explained above. It sends an INFO (leave) to the group announcing the forced leave (see Fig 7). The remaining members remove Tleave from their group composition list. The group members have to confirm INFO in the usual way. After finishing the LEAVE phase the token holder forwards the token. V. FINAL REMARKS In this paper we presented an approach for setting up closed decentralized managed groups based on SIP. The described solution ensures the consistency of the management data at each participant. It also supports a dynamic group composition. The provided service supports a reliable, atomic, and ordered, data delivery. These properties are assured as follows: A reliable transmission is accomplished by acknowledging all messages and selective retransmissions when required. Atomic transmission is ensured by the selective retransmission in combination with the forced leave mechanism which excludes participants that do not acknowledge the reception of a SIP message as required. A total ordering of the message exchange is achieved by applying the rotating token mechanism that only allows the token holder to send. This simplifies the communication and avoids message crossing and overtaking. It also facilitates the early detection of participants’ failures even if no data is transmitted. The presented solution fills a gap in the application range of SIP which has been considered as an issue so far: the support of close multiparty conference applications with a decentralized management. Meetings in everyday life are mainly close meetings. So far this kind of conferences can only be set up by means hardware based centralized conference systems. These systems are rather inflexible and still expensive. Decentralized conferences provide a greater flexibility. They better support spontaneous conferences and the mobility of users. Our approach focuses on groups between 2 and 20 members which is a typical size for many meetings and discussions. Preliminary simulations showed a token rotation time between 40 and 100 ms in local and regional networks which are the main application areas for this type of conferences. Currently, we are introducing this SIP based service in the IP version of our formerly developed video conference system GCSVA [2] which based on ATM. The new version of the video conference system, called BRAVIS [17], uses the service for signaling to support the group management. BRAVIS is a peer-to-peer video conference system for IP networks with an overlay multicast infrastructure for media distribution. After finishing the implementation we will evaluate the performance of the system and in particular the described SIP based signaling service. We also plan to introduce other advanced conferencing services provided by

SIP such as personal mobility, preferences and capabilities exchange including indication about available media components or security mechanisms. REFERENCES [1] D.A. Agarwal: “Totem: A Reliable Ordered Delivery Protocol for Interconnected Local-Area Networks”, Ph.D Thesis, USB, 1994 [2] I. Beier, H. Koenig, “GCSVA - A Multiparty Videoconferencing System with Distributed Group and QoS Management”, Proc. of ICCCN'98, Lafayette, USA, pp. 594-598, 1998. [3] S. T. Chanson, A. Hui, E. Siu, I. Beier, H. Koenig, M. Zuehlke,: “OCTOPUS - A Scalable Global Multiparty Video Conferencing System.”, Proc. of ICCCN’99, Boston, USA, IEEE Operations Center, 1999 [4] S. Donovan, “The SIP INFO Method”, IETF RFC 2976, 2000. [5] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, “SIP: Session Invitation Protocol”. IETF RFC 3261, June 2002 [6] ITU-T, “Visual Telephone Systems and Equipment for Local Area Networks with Non-Guaranteed Quality of Service”, ITU-T Recommendation H.323, 2000. [7] J.C. Lin, S. Paul, “RMTP: A Reliable Multicast Transport Protocol”, IEEE INFOCOM’96, San Francisco, 1996 [8] V. Luca, S. Salsano, D. Papalilo, “SIP Extensions for QoS support in Diffserv Networks”, IETF Internet Draft , October 2001, Work in Progress. [9] W. Marshall, et al.: “Integration of Resource Management and SIP”, IETF Internet Draft , March 1, 2002, Work in Progress. [10] K. Muthukrishnan, A. Malis, “A Core MPLS IP VPN Architecture.” IETF RFC 2917, September 2000. [11] J. Rosenberg, H. Schulzrinne, “A Comparison of SIP and H.323 for Internet Telephony”, Proc. NOSSDAV 98, Cambridge, UK, 1998. [12] J. Rosenberg, “SIP Caller Preferences and Callee Capabilities”, IETF Internet Draft, , November 21, 2001, Work in progress. [13] J. Rosenberg, “The SIP UPDATE Method”, IETF Internet Draft , April 30, 2002, Work in Progress. [14] J. Rosenberg, H. Schulzrinne, “Models for Multi Party Conferencing in SIP”, IETF Internet Draft , November 17, 2000, Work in Progress. [15] D. Sisalem, H. Schulzrinne, “The Multimedia Internet Terminal (MInT)”, Telecommunications Systems, 9 (1998) 3-4, 423-444. [16] R. Sparks, “The Refer Method”, IETF Internet Draft , Nov. 25, 2002, Work in Progress. [17] E. Popovici, M. Zühlke, R. Mahlo, H. König: BRAVIS – An Approach for Closed Multiparty Video Conferences in the Internet, Proc. KIVS 2003, Leipzig, February 2003 (in German)