Multiparty Conference Signalling using the Session Initiation Protocol (SIP)

Transcription

1 Multiparty Conference Signalling using the Session Initiation Protocol (SIP) I. Miladinovic 1,2 and J. Stadler 1,2 1 Institute of Communication Networks, Vienna University of Technology, Favoritenstrasse 9/388, 1040 Vienna, Austria, {igor.miladinovic, johannes.stadler}@tuwien.ac.at, 2 Forschungszentrum Telekomunikation Wien (ftw.), Tech Gate Vienna, Donau City Strasse 1, 1220 Vienna, Austria Abstract This paper introduces an extension of the Session Initiation Protocol (SIP) for closed multiparty conferences. In a closed conference the identity of all conference participants is known by others and all participants have to be notified when a new user joins the conference. The extension expands SIP for the functionality for discovery of participant identities in a conference. Furthermore, it ensures that each conference participant is notified before a new participant joins. We also verify this extension by applying it to two SIP conference models conference with the conference server and full-mesh conference. A comparison of these conference models completes this paper. Keywords Multiparty conferencing, signalling, SIP, full-mesh conferencing, conference server 1 Introduction Multiparty conferences are becoming an important issue not only for Internet applications but also for mobile networks application. One of the reasons for that is the introduction of Universal Mobile Telecommunications System (UMTS), which offers considerably more bandwidth than Global System for Mobile Communication (GSM). This bandwidth is necessary especially for video conferencing. Depending on the access to the conference, we can differentiate between open and closed conferences. In an open conference everyone can join the conference without notification of current conference participants. It is also not necessary that a participant knows the identity of other participants. Examples for open conferences are TV-channel distributions, open meetings, presentations and lectures, etc. These conferences are usually large and use multicast (Williamson, 2000, Goncalves and Niles, 1999) for data transmission. In a closed conference the identity of each participant is known to the other participants. Furthermore, if a new participant wants to join the conference, this should be announced to all current conference participants before the new participant joins the conference. Closed

2 conferences are usually small and therefore rarely use multicast for data transmission, but rather unicast or explicit multicast (Boivie et al., 2001). For the conference establishment, maintaining and termination a signalling protocol is necessary. In a closed conference the signalling protocol should also manage participant identities and distribute them to all conference participants. Researching the Session Initiation Protocol (SIP) (Handley et al., 1999) of the Internet Engineering Task Force (IETF), which will be used as signalling protocol in UMTS (from release 5), we have seen that SIP does not support participant discovery. Therefore, we have developed a SIP extension that fulfils the needs of closed multiparty conferences as mentioned above. In this paper we describe this extension and apply it on two different conference models. 2 Related Protocols This chapter briefly overviews SIP describing basic SIP components, messages and functionality. We also go into Real-Time Transport Protocol () and Real-Time Control Protocol (RTCP) in order to explain the conference participant discovery proposed in (Rosenberg and Schulzrinne, 2001). 2.1 SIP Session Initiation Protocol (SIP) (Handley et al., 1999) is an application layer protocol used for signalling in IP networks developed by the Multiparty Multimedia Session Control (MMUSIC) working group of the IETF. Now a SIP working group has been formed that continues the development of this protocol. SIP is a text-based Hypertext Transfer Protocol (HTTP) (Fielding et al., 1999) like protocol that is used for establishment, modification and termination of all types of sessions. There are two types of messages in SIP, requests and responses. The type of a request is specified by its method. The SIP standard defines six methods:,, BYE, CANCEL, OPTIONS and REGISTER. Both, requests and responses contain headers that obtain additional information (e.g. to, from, subject etc.). A SIP message also carries a description of the session in its body. The session is usually described by the Session Description Protocol (SDP) (Handley and Jacobson, 1998). For transport of real-time media data (voice and video) in a session (Schulzrinne et al., 1996) is used. There are two types of entities in SIP, SIP User Agents (UA) and SIP network servers. A SIP UA could be seen as end device and acts either as user terminal or as automated connection endpoint, for instance a call answering machine. Network servers are used for call routing and they can be enabled to perform different kinds of applications. They are divided into proxy servers, redirect servers and registers. SIP uses a three-way handshake for call-setup. Firstly, an request is sent, secondly this request is responded with an response and thirdly an request is sent to confirm the call-setup. Instead of the response another response can be sent if the call-setup fails (e.g. DECLINE response if the callee declines the call). To terminate the call a BYE request is sent which is replied with an response.

3 Signalling of multiparty conferences is also supported by SIP, but there is neither a possibility for discovery of participant identities using SIP nor a mechanism to ensure that all participants are notified when a new user joins the conference. The discovery of participant identities is realized through RTCP and has the drawback that before a connection is established the discovery is not possible. Moreover, the participant identity can be suppressed by a participant in stealth mode. SIP is also an extendable protocol (Rosenberg and Schulzrinne, 2002). There are different SIP extensions that extend SIP for new methods and/or headers (Roach, 2002, Rosenberg et al., 2001, Campbell et al., 2002). Especially interesting for this paper is the REFER method (Sparks, 2001), which can be used for signalling of conferences with the conference server. 2.2 In most cases, transmission of real-time based data takes place by using the User Datagram Protocol (UDP) (Postel, 1980). This is due to the fact that the connection-less UDP implies a much lower protocol overhead than the connection oriented Transmission Control Protocol (TCP) (Postel, 1981). Obviously, it is unfavourable to lose packets in real-time connections, but in comparison to non real-time data connections it is tolerable in small amounts. Without a reliable connection on the transport layer, a lot of problems are passed up to the higher layers. The most important of these are packet loss, packet reordering, jitter compensation, inter-media synchronisation and intra-media synchronisation. The Real-time Transport Protocol () has been developed to overcome these effects. Since it became a RFC in 1996 it has evolved to the industrial standard in this area, not at least because it is referred to by both, IETF and ITU. The functionality of is simple. The data to send is divided into smaller parts, covered by a header. The most important parts of this header are the sequence number and the timestamp. The former enables reordering of received packets and detection of packet loss, respectively. The latter provides the functionality of intra- and inter-media synchronisation. Moreover it is important to mention that there is a header field, identifying the type of the payload. An extendible list of predefined payload-types for is given in (Schulzrinne, 1996). The last untreated shortcoming mentioned above is the jitter. is not able to prevent jitter but it provides enough parameters to compensate its effects. In fact it is the Real-time Transport Control Protocol, also defined in (Schulzrinne et al., 1996) which enables the senders and receivers to adapt their sending rates and buffer sizes. RTCP has to be supported by devices in any case. It is suggested that the proportional relation of RTCP in traffic should not exceed 5 percent. There are several types of messages specified for RTCP. Most important of these are the Sender Report (SR), the Reception Report (RR), the Session Description (SDES) and the Explicit Leave (BYE). The combination of SR and RR provides parameters of packet loss, round trip time and jitter estimation back to the sending device. The SDES provides information like the canonical end-point name, the user name, the addressor, the phone number of the sending user s host, respectively the sending user. This information is used in (Rosenberg and Schulzrinne, 2001) for discovery of conference participant identities.

4 3 SIP Extension for closed conferences In this chapter we describe the SIP extension by means of applying it on two SIP conferencing models. We will show the initialisation of a three participant conference for both of these models in two cases - when the conferences is initiated as a three participant conference and when the conference originates by adding a participant to a two party SIP call. These conferences are called ad-hoc conferences. The extension expands SIP for one new method and one new header. The method is called CONF and has the purpose to distribute identities of conference participants. This method must contain the new header called participant, which contains a list of SIP addresses of all conference participants except the sender and the receiver of the message. Optionally, for each participant in the list a status parameter can be presented, which may take the following values: active, invited or joining. If this parameter is missing, the status active is assumed (default value). The CONF method is only allowed within a call; otherwise it should be responded with a BAD REQUEST response. When a UA receives the CONF method, it must check the list given in the participant header with its own list of participants. If there is any difference an update of the own list must be made. This list also contains users that want to join the conference, which is indicated by the status parameter. In order to verify this SIP extension let us consider an initialisation scenario in two conference models suited for small conferences - conferences with the conference server and full-mesh conferences. 3.1 Conferences with the conference server Conferences with the conference server in SIP are described in (Rosenberg and Schulzrinne, 2001). As mentioned before, RTCP is used for the discovery of participant identities and there is no possibility for participant discovery before staring the stream. Therefore, a called user does not know who is in the conference before accepting the invitation. We have modified this conference scenario and added the participant discovery to SIP. In this model a conference is identified by the request URI. This is a part of a SIP request that specifies the destination of the request. Conference participants must know the request URI to participate in the conference. Therefore, a mechanism is necessary to distribute it. For this purpose the method REFER and the headers refer-to and referred-by are used. The user who receives a REFER request does not know the identities of all conference participants, but only of the participant who sent this message. Using the participant header in a REFER request solves this problem. Let us consider the initialisation of a three participant conference where user A wants to initiate a conference with users B and C. The first step is that A generates and distributes the conference request URL. This part is also called announcement of the conference. The distribution is carried out by sending the REFER request to B and C. This request contains a participant header that indicates the potential conference participants, for example B receives the REFER request that contains the address of C with status invited in the participant header and knows that C is a potential participant of this conference.

5 After the conference announcement each user sends an request to the conference server using the request URL generated by A. These messages are shown in figure 1. A B C CONF CONF CONF Figure 1: Initialisation of a conference with the conference server Firstly, A sends the request to the conference server and creates a new conference. Secondly, B also sends the request (note that the order of users invitation is not important, i.e. B or C can also send first ), but the conference server finds this conference and sends the CONF request to all participants of this conference (at this point the only participant of the conference is A) to let them know about the new participant B. By this way, all conference participants can learn about the new participant before the new participant joins the conference. The new participant also knows about the other participants because of the participant header in REFER. This header is also presented in the response from the conference server to the new participant (in this case B) in order to make sure that B s list of participants is up-to-date. Finally, C sends the request to the conference server, the conference server notifies A and B about the new participant using the CONF request and afterwards sends the response with the actual list of participants to C. The same mechanism is used when a participant leaves the conference. The second case we want to treat here is when A and B are in a two party call and want to initiate a conference with C. The only way to do this is to terminate the existing call and to make a new one with the conference server. Like in the first case, A generates the conference request URI and sends it in the REFER request to B, but in this case A connects to the conference server before sending the REFER request to B. Using the conference request URI, B also connects to the conference server and A is notified about this by receiving the CONF method from the server. Afterwards, A ends the first call with B and sends the REFER request to C. The participation of C in the conference is carried out in exactly the same way as in the first case. 3.2 Full-mesh conferences In a full-mesh conference a conference participant has a signalling connection with each other participant. Unlike conferences with the conference server, there is no additional network element necessary, which represents a single point of failure, and the state of the conference is maintained by each UA involved in the conference. Therefore, there is no need for a conference identifier that must be distributed to all conference participants.

6 Consider the same example as in 3.1, where A wants to initiate a conference with B and C. This example is pictured in the figure 2. A Participant:C;status=invited B Participant:B;status=invited Participant:B;status=active Participant:A;status=active C Figure 2: Initialisation of a full-mesh conference with three participants In order to initiate the conference A sends requests to B and C with the participant header that contains the SIP address of C and B, respectively. In both cases the status parameter is set to invited. This way users B and C are aware that it is an invitation to a conference and, furthermore, they also know the other potential participants. Let us say that user B wants to participate and responds with an response to A. Afterwards, A confirms the invitation by sending and data transmission between A und B starts (indicated by in figure 2). Suppose that C also wants to participate in the conference and sends an response to A. The request from A contains the participant header with the SIP address of B with the active status. Therefore, C knows that B already participates and therefore sends an request to B. The participant header in this request specifies other participants (in this example it is only A). B answers this request with an response, because B already knows about C and C confirms this initialisation by sending an request. Thereafter, the data transmission between all participants is established. When a participant leaves the conference it sends the BYE request to all other conference participants. A B C CONF Participant:C;status=joining Participant:B Participant:A Figure 3: Ad-hoc conference scenario An ad-hoc conference scenario where A and B are in a two party call at the beginning is shown in figure 3. During the call between A and B, which is indicated by the in figure 3, A decides to invite C. Firstly, A has to notify B about this invitation by sending the

7 CONF request to B. The header participant in this request indicates that C is a potential participant. B replies this request with an response and afterwards A can send an request to C. Because of the participant header, C knows that it is a conference and can accept or decline this invitation. In this example C accepts the invitation from A and finally initialises the call with B as in the case of conference initialisation. 4 Signalling traffic In this section we investigate signalling traffic in a conference produced by sending of CONF messages. For simplicity, the reliability mechanism in SIP, which is based on repeated messages, is not considered here. Provisional responses after an request are also not included in this analysis, because these responses are optional. Note that provisional responses increase SIP signalling without this extension and not the signalling caused by CONF method. In order to obtain the number of messages that are sent in a conference, we implemented a prototype of a SIP UA and a SIP conference server. With this implementation we measured the number of messages that are sent in an ad-hoc conference in both modes, full-mesh and with a conference server. The number of conference participants varies from three to seven. In a full-mesh conference (figure 4a) the number of messages caused by this extension (dashed line) is always less than the number of messages caused by SIP signalling (dotted line) and takes 25% and almost 33% of overall signalling messages for four and seven participants, respectively. Overall signalling traffic is quite big with 93 messages for seven participants. Messages Overa ll s ignalling SIP signalling CONF signalling Messages Overallsignalling SIP signalling CONF signalling Conference participants Conference participants (a) (b) Figure 4: Signalling traffic for initialisation of a bridge and a full-mesh conference In conferences with a conference server (figure 4b) there is only one connection with the conference server per participant. The SIP signalling traffic increases linear with the number of participants. Note that the traffic necessary for conference announcement is also included in this analysis. The number of messages generated by CONF requests and responses is slightly higher than for full-mesh conferences. For conferences with more than five participants, it is also higher than the number of SIP signalling messages. For four participants it amounts to 40% and for seven participants even to 56% of overall signalling traffic, which is considerably less with 75 messages for seven participants than for full-mesh conferences.

8 However, the overall traffic for conferences with three participants is bigger than for fullmesh conferences (19 vs. 11 messages) and it is also bigger for conferences with four and five participants. 5 Conclusion SIP signalling of multiparty conferences does not include discovery of participant identities, which is necessary for closed conferences. In order to solve this problem, we have introduced a SIP extension that adds support for closed conferences to SIP. We described the functionality of this extension on the basis of two conference models. The first conference model uses a conference server for managing the conference. Using the SIP extension, the identity of all participants in the conference is known by others. If a user is invited to join a conference, the extension ensures that this user gets a list of current conference participants. The drawback of this model is that an additional network element is necessary that arouses scaling problems and also represents the single point of failure. In the case when a conference call is formed from a normal SIP call, the normal SIP call has to be terminated and a new call with the conference server must be initiated and it could be also seen as a drawback of this model. The full-mesh conference model does not require any additional network element because the conference is maintained by UAs of the conference participants. Each participant has a signalling connection to all other participants. There is no single point of failure since the state of the conference is distributed. One drawback of this model is that the logic of the UA is slightly more complex. Another drawback is the rapidly increasing signalling traffic with the number of conference participants. References Williamson, B. (2000), Developing IP Multicast Networks, Volume 1, Cisco Press, ISBN: Goncalves, M. and Niles, K. (1999), IP Multicasting, Concept and Applications, McGraw-Hill, ISBN: Boivie, R., Feldman, N., Imai, Y., Livens, W., Ooms, D. and Paridaens, O. (2001), Explicit Multicast (Xcast) Basic Specification, IETF Internet Draft, work in progress. Handley, M., Schulzrinne, H., Schooler, E. and Rosenberg, J. (1999), SIP: Session Initiation Protocol, IETF RFC Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and Berners-Lee, T. (1999), Hypertext Transfer Protocol - HTTP/1.1, IETF RFC Rosenberg, J. and Schulzrinne, H. (2001), Models for Multi Party Conferencing in SIP, IETF Internet Draft, work in progress. Handley, M. and Jacobson, V. (1998), SDP: Session Description Protocol, IETF RFC Schulzrinne, H., Casner, S., Frederick, R. and Jacobson, V. (1996), : A Transport Protocol for Real-Time Applications, IETF RFC Rosenberg, J. and Schulzrinne H. (2002), Guidelines for Authors of SIP Extensions, IETF Internet Draft, work in progress. Roach, A. (2002): SIP-Specific Event Notification, IETF Internet Draft, work in progress. Rosenberg, J., et al. (2001), SIP Extensions for Presence, IETF Internet Draft, work in progress. Campbell, B., et al. (2002), SIP Extensions for Instant Messaging, IETF Internet Draft, work in progress. Sparks, R. (2001), The Refer Method, IETF Internet Draft, work in progress. Postel, J. (1980), User Datagram Protocol, IETF RFC 768. Postel, J. (1981), Transmission Control Protocol, IETF RFC 793. Schulzrinne H. (1996), Profile for Audio and Video Conferences with Minimal Control, IETF RFC 1890.