SHORT DESCRIPTION OF THE PROJECT...3 INTRODUCTION...4 MOTIVATION...4 Session Initiation Protocol (SIP)...5 Java Media Framework (JMF)...

Transcription

1 VoIP Conference Server Evgeny Erlihman Roman Nassimov Supervisor Edward Bortnikov Software Systems Lab Department of Electrical Engineering, Technion - Israel Institute of Technology 1

2 SHORT DESCRIPTION OF THE PROJECT...3 INTRODUCTION...4 MOTIVATION...4 Session Initiation Protocol (SIP)...5 Java Media Framework (JMF)...5 PROJECT GOAL...6 THE SOLUTION...7 INTRODUCTION...7 REQUIREMENTS LIST...8 SERVER PACKAGE...9 Architecture Overview...9 Use case Sscenarios...11 Class Diagram...14 USER AGENT PACKAGE...15 Architecture Overview...15 Main Classes...15 Class Diagram...17 FUTURE DEVELOPMENT...18 APPENDIX A...19 SIP Requests Codes...19 Literature

3 Short description of the project The project goal is to build remote Server for routing VoIP packets between conference participants and User Application for starting and managing conference. User agent interface allows starting a call between two users and extend it to conference - invite other users to participate in call. Each conference has its own moderator that can perform different actions as invite users to conference, remove users from it or end the entire conference. VoIP Conference Server supports multiple conferences, so at the same time multiple conferences can be carried. Thus, user can be member of one conference only at the same time. Both Server and User Agent (UA) are built using Java technology with JMF package for handling (playing/sending/receiving) voice. The connection and messaging between the Server and UAs is handled using SIP protocol. 3

4 Introduction Motivation There are may ways to implement conference calls using VoIP technology. For example, consider following possible implementations direct connection between participating users, while most efficient user (powerful computer, wide bandwidth) is used as a server, or alternatively using single server receiving chunks of data from peers and sending it to other participants of conference. Thus, each one of these implementations has its own advantages and disadvantages. While first implementation strongly depends on computer force of participants, the second is not, and it can give better results, but in case of server failure all existing calls are closed. Number of connections on each computer is also important (direct connection requires about 2 n connections for n users), while in case of single server each computer has single opened connection to server. So, in that way, our goal is to build user independent and transparent for the user server with minimum required connections during the session. 4

5 Session Initiation Protocol (SIP) The Session Initiation Protocol (SIP) is a signaling protocol used for establishing sessions in an IP network. A session could be a simple two-way telephone call or it could be a collaborative multi-media conference session. The ability to establish these sessions means that a host of innovative services become possible, such as voice-enriched e-commerce, web page click-to-dial, instant messaging with buddy lists, and IP Centrex services. Over the last couple of years, the Voice over IP community has adopted SIP as its protocol of choice for signaling. SIP is an RFC standard from the Internet Engineering Task Force (IETF), the body responsible for administering and developing the mechanisms that comprise the Internet. SIP is still evolving and being extended as technology matures and SIP products are socialized in the marketplace. The IETF's philosophy is one of simplicity: specify only what you need to specify. SIP is very much of this mould; having been developed purely as a mechanism to establish sessions, it does not know about the details of a session, it just initiates, terminates and modifies sessions. This simplicity means that SIP scales, it is extensible, and it sits comfortably in different architectures and deployment scenarios. SIP is a request-response protocol that closely resembles two other Internet protocols, HTTP and SMTP (the protocols that power the World Wide Web and ); consequently, SIP sits comfortably alongside Internet applications. Java Media Framework (JMF) The Java Media Framework API (JMF) enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and decode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology. 5

6 Project Goal The main goals of the project are: Developing independent server that will support voice conferences between multiple users (technically receiving and forwarding RTP streams to appropriate users). Developing user agent application for starting managing conference. As educational project further goals are: Getting familiar with Java programming language and particular JMF package technology for handling multimedia. Getting familiar with SIP protocol. 6

7 The Solution Introduction The VoIP conference server aims to create a SIP established VoIP conference call between multiple users. This project is based on an off-the-shelf SIP managing module and JMF package. The first is written for two participants call setup and maintenance, hence need to be altered because of some changes in the SIP protocol that where maid in this project. The second one is an official Sun Microsystems multimedia handling package that is used in the project for managing real-time media. In the next part we list the requirements of the project. These requirements will be listed and described by different scenarios that describe how our application should behave. Then we shall describe the design of solution to give a good feeling of the system architecture. 7

8 Functional Requirements Server Application 1. The Server application will support the creation of multiple conference calls.. 2. Conference call will support the following actions for participants: 2.1. A participant (moderator) will be able to create a conference call A participant (moderator) will be able to invite another participant to join the conference A participant (moderator) will be able to disconnect another participant from a conference A participant will be able to leave a conference A participant (moderator) will be able to end a conference. Client Application The Client application will be able to perform the role of call moderator or as a call invitee and as such to perform all the actions (according to the role) described above. Each application will have the physical abilities to perform the described above e.g. the application will be able to use a pre defined protocol for accomplishing a given task. 8

9 Server Package The server package implements the server application. It is separated into to two logical units. The SIP handling unit and the RTP streams handling unit. The first one is responsible for all the administrative side of the server functionality e.g calls setup, call managing and call teardown. The RTP streams handling unit is responsible for low level handling of UDP packets e.g receiving them, forwarding them to other call participants. Architecture Overview The Model Server application is the main block of our project. The application is divided into two modules that are connected via common database (see Databases section). Each module is responsible for a different functionality of the application. A description of the application is: SIP module Shared Data Structures RTP module The Controllers We have two main controllers. The SIP controller handles all SIP related operations. This includes the addition and removal of participants to a conference call, notifications of participants statuses and etc. It manages HashTables to keep the data in memory, in future if needed the data may also be stored on disk. The RTP controller manages all UDP packets related operations, such as receiving and sending them out to the network and more. The View In this project the server application does not have a GUI or any other user interface, it is initialized once, and from that moment on it responds to SIP messages real time. In future, a more complex administrator maintenance functionality can be added. 9

10 Main Classes As mentioned above, the main classes that perform most of the client functionality are the controller classes. These classes are the manager classes that control the flow of the user requests. Data bases Call structure Each active session (conference) has its unique Call structure instance containing following fields: Call structure{ call_id; //participants list userlist; //moderator id master_id; } Instances of this structure are kept in Hash Table, while call_id serves the key to Hash Table entry. User Node structure Each session participant will have a unique UserNode structure: User Node{ //ip address ip; //port port; //id of participated call call_id; } Instances of this structure are kept in Hash Table, while ip serves the key to Hash Table entry. In such way we can easily determine in which conference the user is participating (for example, after receiving RTP stream from particular IP address) and determine who are the other peers in same conference (for example, to forward the stream to them). 10

11 Use case scenarios In order to start conference and to maintain it moderators and regular callees communicate with each other via Server, sending and receiving SIP messages. Following SIP messages can be send to/from Server to UAs (we listed here only main requests that influence the call. See appendix for SIP requests codes): 1. creation of a new session: INVITE request is received from a new ip address: the Server will start a new session with the invite source as a session moderator (master) and the invitee as a session participant. As shown below: UA Session master invite Server UA invitee 100 invite ACK ACK SESSION 2. adding new participant to existing session: INVITE request received from master of existing session (i.e. existing conference). The diagram is same as in previous case, the only difference is that invitee will be connected to existing session, no new session between master and peers will be made. In this case we omit the diagram since it is same as in previous case. The already existing participant (not moderator) does not receive any SIP request, only additional RTP stream from the new participant. 3. disconnection of participant from session: BYE request received from session participant (i.e. participant wants to disconnect from session). As the following diagram shows: 11

12 UA Session master Server UA invitee BYE BYE(from user) 200 ACK ACK 4. removal participant from session: INVITE request from session master for already existing participant in the session will remove the participant from this session. UA Session master invite Server UA invitee 100 BYE ACK 5. session termination: BYE request received from session master will terminate the entire conference by sending BYE request to all participants and closing it. In this case we will omit the diagram. 12

13 6. user unavailable: INVITE request received from moderator relayed to user that is away or that already participates in conference (this or another): UA Session master invite Server UA invitee 100 invite ACK ACK 13

14 Class Diagram 14

15 User Agent Package The user agent package implements the user agent. Its purpose is to allow user to create, manage, and join conference calls. The package is an event driven, i.e. different features allowed in different scenarios. Architecture Overview Since full RTP and SIP messaging is made via server UA does not maintain list of conference participating users. In that way we do not need to use special structures. Although, SIP and RTP modules are independent (for RTP module see description below). As mentioned before the UA s behavior is event based. It behaves according to user requests or Server instruction through following handlers: oncallincoming - Callback function called when arriving a new INVITE method (incoming call) oncallringing - Callback function that may be overloaded (extended). Called when arriving a 180 Ringing oncallaccepted - Callback function called when arriving a 2xx (call accepted) oncallconfirmed - Callback function called when arriving an ACK method (call confirmed) oncallredirection Overloaded callback function called when remote user (callee) is busy, i.e. participates in other conference oncallrefused - Callback function called when arriving a 4xx (call failure) oncallclosing Callback function called when arriving a BYE request oncallclosed - Callback function called when arriving a response after a BYE request (call closed) Main Classes MyListener class is playing a crucial role in handling SIP requests, both coming from user and from Server. The way user communicates with this class is GUI that allows to use all UA features. RTPGetter / RTPSender RTPGetter and RTPSender are components which responsible for receiving and transmitting audio over RTP from/to a given source/destination (in our case we used *.wav files). These classes run in there own threads and are done parallelly to the main program flow. Since sending RTP needed only during conference time, RTPSender thread instantiated only when conference 15

16 begins. When a voice conversation is terminated sending is not needed (and will not be received by anyone) and thread is terminated. 16

17 Class Diagram 17

18 Future Development This projects gives good base for further extensions with conference specialization. Since the base is ready one can add variety of features, as: Sending voice instead of music files (UA extension) NAT support make Server and UA work behind NATs (both UA and Server extensions) Authentication and Registration add an authentication and registration features (both UA and Server extensions) Messaging between conference users (both UA and Server extensions) Multimedia content video support (UA extension). Good luck!!! 18

19 Appendix A Used SIP Requests Codes 1xx Informational Responses 100 Trying 180 Ringing 2xx Successful Responses 200 OK 4xx Client Failure Responses 400 User is unavailable, cannot connect For full list of SIP codes see Literature Internet Communications using SIP by Henry Sinnreich & Alan B. Johnston Java Media Framwork tutorial, can be found at MJSIP documentation can be found at Plenty of additional material can be found in internet, since SIP and VoIP messaging used widely. 19