FINAL REPORT

 

Group 4 - Phonetics

 

Team 2 - Signaling

12/18/98

 

Madhav Ranjan

Abhideep Singh

 

 

 

 

 

Project Description

Q1) What did you set out to do? Use a figure and accompanying text to describe what you set out to do. You can reuse part of your first report if you wish. You should have sufficient detail so that someone who is not familiar with the project would still be able to understand the scope of your work. For instance, imagine giving this to a friend who is not in the class--write something that this person would be able to understand without having to ask you for help.

 

Signaling is the basic functionality in the control plane. It allows voice calls to be set up in the Internet and the telephone network, and the Gateway to associate telephone numbers with IP addresses and vice versa. Our goal as the Signaling team was to provide functionality to all the applications and ensure that all aspects of the control plane are hidden from the applications. Since almost all the teams in the group use Signaling, the project was extremely challenging in terms of coordination among teams. The project also allowed us to learn new technologies like JTAPI, SIP, Java Socket Programming etc. The first time we made a phone ring using JTAPI was a phenomenal experience!

 

We as the Signaling team set out to provide the following functionality:

 

 

 

 

 

 

 

 

 

  • Provide an interface to all Desktop Applications like Voice Mail (Team 7), Telephone Application (Team 1) and Conferencing (Team 8) to enable them to dial out and receive calls.

 

 

These were the salient features that we were expected to provide according to the project description. Since we had considerable freedom in designing the interfaces and implementing the designs, the exact sequence of events is slightly different from that of the project description. The end result is, of course, the same – Internet Telephony! After reading the outline of what we actually accomplished the sequence of events will be clear. Two figures, illustrate the Dial and Handle Incoming Call sequences of our implementation. They follow on the next two pages.

 

 

 

 

 

Accomplishments

Q2) What did you actually accomplish? Write down exactly what you managed to get done by the time of the demo. Did you achieve all the goals you set out to do? Did you do something that you didn't expect to be doing when you started?

 

Overview

 

When we started this project, we knew little about socket programming. So we knew the final project would be extremely challenging and interesting. Since signaling was to deal with almost all the teams, we wanted to provide an interface as soon as possible and begin the integration process.

 

Our signaling model consists of the following classes. We have a DesktopSignaling java file that compiles with all applications that require signaling features. The applications can call functions like Dial and Hangup using DesktopSignaling as if they are part of a library. Now, the DesktopSignaling communicates with a UpperMascLayer server which is the main Signaling server listening for requests. "MASC" stands for MAin Signaling Component. The UpperMascLayer has a handle on the Masc class file that contains all the logic, including the Jtapi functionality. The Jtapi functionality is provided by a java class called JtapiHandler. When an instance of this class is created, the program gets a handle on the provider or the PBX and is ready to make calls. There is also a Dialer class that extends the java.lang.Thread class and contains the makeCall() and Hangup() functions. Since dialing takes a considerable amount of time this functionality is provided on a separate thread so that signaling can handle other requests. Since there are four lines available, we can make 4 outgoing calls at any given instance, all running on separate threads. It is, of course, possible for one or more lines to be in use for an incoming call. If all lines are busy then the PC application gets a SignalPacket that contains a BUSY flag. SignalPacket is a data structure that contains information about the source and destination. The most important varibale in the SignalPacket is the boolean SignalFlag that all the applications refer to, in order to find out the result of their function call. Public methods are provided to all applications to access the information contained in SignalPackets.

 

Specific Features Supported

 

During the development phase we learned new technologies like JTAPI, SIP and Java Socket programming. At present we have completed the integration process with all the teams. We have also completed all the goals that we had set for ourselves. The features we support include:

 

  • Handle an Incoming Call from a telephone – If a call comes into the Gateway we use Directory Service to get the IP address of the computer associated with the extension entered. If the extension is invalid then the caller receives a busy signal. If the extension is valid we figure out which application to invite. We use the SIP protocol to accomplish this task. If the invite is accepted, we provide the application with the IP Address and port on the Gateway (associated with the line on which the call came in) in a SignalPacket. The application then uses the information to set up a Data Exchange connection with the telephone. The conversation can now commence. When the application or the Telephone hang up, we clear the line and inform the necessary parties. If the extension entered corresponds to that of Voice Mail, we inform the application via an Invite sequence. If the call is accepted we tell Voice Mail the line number to talk to and handle the call. If the call is rejected then the telephone receives a busy signal. If it is a conference call we update the Directory Service and join the caller to the conference call and inform the conferencing application.

 

  • Handle an Outgoing Call from a Workstation – All an application needs to do in order to dial another PC or telephone is to call a signaling function Dial(). The Dial function takes the source email address, destination email address, and an application ID. Using this information, the Main Signaling Component (MASC) queries the Directory Service for an IP address or a telephone number for the destination.

 

  • If the destination is a telephone, then the telephone number is dialed using a free line provided by the Gateway. The application receives the IP address and Port to send data to in order to converse. The call is made on a separate thread so that Signaling can continue handling other requests.
  • If an IP address is returned and it is Voice Mail, we initiate an invite sequence with Voice Mail. If they accept the call, the application is given the IP address and port to communicate with for the call else they get a Reject packet from Signaling.
  • If an IP address is returned, and it is Team 1’s telephone we initiate an invite sequence with the application. If the destination application accepts the call, the source application is given the IP address and port to communicate with for the call, otherwise they get a Reject packet from Signaling.
  • If an IP address is returned, and it is Conferencing, we initiate an invite sequence with the Team 8’s application. If the destination application accepts the call, the source application is given the IP address and port to communicate with for the call, otherwise they get a Reject packet from Signaling.

 

All applications call a signaling hang-up function that clears lines and informs applications. If a telephone line is hung up we inform the application associated with the line about the termination.

 
  • Handle Errors and Race Conditions – At present signaling has the capability to find out whether an application is active or not, i.e., if there is silence for some time then Data Exchange and/or Gateway informs us. We query the application(s) involved and report the results. The end result may be clearing up a line, telling an active application that the other party has stopped responding etc. Also, if an application or a telephone hang up suddenly then we inform the other application(s) or clear the line.

 

  • Design a protocol in order to allow signaling components to communicate – Signaling is divided up into 3 layers. The top layer is the interface that compiles with the application code. This layer knows the location of the Main Signaling Server defined in the UpperMascLayer class. The UpperMascLayer is the middle layer that acts the go-between the desktop applications and the Main Signaling Component (MASC). MASC is the lowest layer that contains all the logic, the JtapiHandler (to make calls). Currently, each time an application starts up, the DesktopSignaling class registers itself with MASC via UpperMascLayer. If the application exits then it unregisters itself with MASC. Therefore, at a given time MASC knows all the IP Addresses of the signaling components that are running and the type of application they are. All communication is done via UDP and TCP sockets programmed in Java. For example, the Dial method can be called by an application, say Team 1’s telephone, as follows:

 

DesktopSignaling ds = new DesktopSignaling("1");//"1" is the application ID

SignalPacket sp = new SignalPacket();

 

sp = ds.Dial("src@phonetics.com", "dest@phonetics.com", "1");

 

When the function returns, sp contains all the information necessary to use Data Exchange to start the call provided the SignalFlag in sp, is not BUSY or REJECT.

 

Essentially, the DesktopSignaling class sends a UDP packet to the UpperMascLayer which decodes the packet, calls the corresponding method on MASC, encodes a packet containing the result and sends it back via TCP back to the DesktopSignaling component which is waiting for a response. The DesktopSignaling class then decodes the result (an object that is cast appropriately) and returns the value to the caller.

 

  • Multi-Party Conferencing Support – We have incorporated multi-party conferencing support in Signaling. Our main task is to join callers to a conference by manipulating the Directory and informing the Conferencing application. We also take care of removing a user from a conference by telling the conferencing application and updating the Directory Service.

 

  • Allow Management to Interrogate All Signaling Components – This facility is provided by Signaling in totality. The Management team was supposed to design the team and we were to implement that interface. The Management team decided to have a Central Management Server and a separate thread running on Signaling. Whenever, we do anything, we inform the thread via ReportAction(String action). The report is buffered up in the thread class and whenever Management queries the thread they get all the reports. This was essentially like printing System.out’s that were printed to the Management Console instead of the Signaling Console.

 

  • Tell Accounting All Relevant Events – This functionality is complete and integrated into Signaling. Each time a call comes in for an application, Billing is informed. We tell Billing if it is Voice Mail, Conferencing or a Telephone Call. We provide the start time. When a call is hung up, we inform Billing about the event, again mentioning the type of application and end time. The interface was designed by Accounting and we make sure that there are no free calls being made! We are also kind enough to end calls at the correct time so that our valuable customers remain satisfied J .

 

  • Control the PBX and interact with the Gateway – The PBX control is within a class called Jtapihandler. This class is instantiated by MASC when Signaling first starts up. Whenever a call is made, it is dialed via a Dialer Class that extends java.lang.Thread. When we dial a number it is done on a separate thread so that the Signaling server is not blocked and can continue handling other requests.

 

We interact with the Gateway to get a line to use for dialing. If a telephone hangs up we are informed by Gateway and we inform the respective application(s). We also inform Gateway if an application hangs up so that the line can be freed for incoming or outgoing calls. We also maintain information about the lines in use so that if all are busy then we can return a BUSY signal to the application, without querying the Gateway.

 
  • Provide an interface to all Desktop Applications - This feature is complete and integrated with all applications. Without this component applications cannot use Signaling functions. The functions that we provide are listed in our answer to question 6.

 

We essentially achieved much more than we expected. Working on this project was great fun and an exceptional learning experience. This may be the reason we worked harder to get all features incorporated into the project. We could use some more work on race conditions and errors. For that we need extensive testing to find small errors and how to handle them.

 

We also ended up interacting much more and helping in the design of other team’s applications. This was a pleasant surprise as it allowed us to work in a real world team situation. We organized meetings, discussed interfaces and figured out the best way to implement a feature and made sure it was feasible for all teams. Overall this has been the best project we have worked on in school and during our internships.

 

 

 

Problems and Lessons

 

 

3. Problems: It is possible that you did not actually accomplish what you set out to do :-( If so, why? What problems did you run into? Include both technical problems, and problems in coordinating your work with others. Be as specific as you can about technical problems. This is the only way we have to determine whether you really tried to solve the problem, instead of just giving up with token effort.

 

Internet telephony is new and exciting field and this posses great challenges in development of a system around this technology. Research and fair deal of brainstorming helped us overcome these problems. Over the course of the semester we realized that issue like learning about new technologies are simpler that solving problems that arise during the design phase and integration phase of a large project (Or perhaps we feel this was at this point of time). Most problems are a result of not only technical issues but have fair share coordinating problems associated with it. Here are some of the problems that we encountered over the course of the semester.

 

Integration Problems: It often seen during the course of developing the project that although different parts of code might work independently, new complication always arise during the integration of different components. It was true that different components might work in independent testing but create while interacting with other components of the Project. We once had a problem with passing of data from on component to another due to the very nature of the structure of the system. The Gateway was sending up a char (since there were only 4 lines) representing the line numbers that was free to make the call. Now while in C it is OK to pass a char off as a byte if you are trying to send a char, Java finds a problem with this. So while Gateway was pretty sure that it was sending us the right data, we never got the right data from them (And there certainly couldn't be packet corruption everytime). Problems such as these are difficult to pin point in a big project and make the job of integration extremely challenging. This is particularly true for Signaling because of the need to interact we all the application and all other components.

 

Preventing Layering Violations: In a big project, the line between application and control plane is often fuzzy. We tried to strictly enforce a system that avoids the layering violation. In the beginning itself, we sat down with every team to discuss their needs and explain to them what signaling can and cannot provide them. As people started working on their different components it was often seen that they went ahead and implemented the some aspects of the control plane itself, As soon as such a situation was discovered, we rectified the situation in conjunction with the application team. For example, it may seem that the management team needed to interact with very team to capture the current state of the network. It seems natural to expect that they implement way to find out state of the system by contacting every required component. On the other hand, the state of the system is changed ONLY by signaling. If signaling was to inform Management of every change that happens in the system, they can build the state of the system from the state-change transaction without continuously interacting with every component.

 

New Technologies: A big challenge we faced was working with JTAPI and finding out how we can provide certain functionality with JTAPI. Since Internet telephony is still quite a young technology, there are not many sample snippets of code other than the ones already posted. This problem was over come with a two-fold strategy. Firstly we did a lot of research on Internet telephony on sites like Lucent and IBM. The second was basically a lot of experimentation with the current code base we had accessed. A lot of functionality that we had to provide and the proper use of JTAPI was discovered by an exhaustive process of debugging. The course staff, especially Donna have been really helpful in this entire process. We have definitely learned a lot!

 

Interface Change and Availability Problems: Since signaling interacts with almost all the teams, we were careful to define methods that were providing full functionality to all the teams. Due to this reason we have spent considerable time to ensure that we reuse code as much as possible and avoid redundancy at all costs. The same sort of cooperation was also displayed by a majority of our group members. But as the project progresses, specs change and this involved changes both in our code as well as interfaces other people provided us. Coming up with changes such that it provides the added functionality, keeps in mind possible future needs as yet minimizes the work to be done is a great learning experience. It reinforces the concept of first coming up with a pseudo code of paper and then sitting down to solving problems.

 

Another big problem was the non-availability of some the interfaces required by signaling to start on a rigorous process of testing. Some of the teams did not provide us with their interfaces in time and thus were unable to provide them with control function that helped them integrate with the system. The signaling component is incomplete until everyone finished their code and has tested out their components using the control plane provided.

 

Testing - Robustness, Race Conditions etc: Since signaling provides the only component that provides the control, it reserves the exclusive right to change the state of the system. Thus it is imperative that signaling be continuously up and running to cater to the needs of a constantly changing system environment. Thus a rigorous set of tests was undertaken while testing the robustness of program. We made sure that even while designing the component we catch every freak exception that could result. The possible causes of crash of both signaling and other components were carefully explored an implemented. During the integration process, the behavior of the signaling had to be altered to make sure that Voicemail doesn’t crash or hang-up if it is in the middle of an operation that involves signaling. The same holds for other applications whose behavior and future actions were dependent on calls made to signaling (which was almost all apps). Lets say if we an app wants to make a call - a number of situation like failure of Directory service, or non-availability of gateway or even loss of packets can result in signaling to crash or wait indefinitely. A process of error check, timeout and retries made sure that the behavior of components like Directory Service etc doesn’t result in the crashing of the clients. Signaling made sure that the level of abstraction was maintained and the system was always operational no matter what happens to individual components.

 

Conflict between various Components: A components such as signaling faces problems of making sure that their code works properly with other components and the flow of information between components is fully functional. But it also bears the burden of acting as a means of communicating between various components. So if A is using Signaling to talk to B, we need to not only deal with incompatibilities with A or B, but also incompatibilities that might exist between A and B. The addition of more components complicates issue further and makes debugging a real challenge. It is extremely difficult to trace out which component is the one responsible for a certain problem. And in fact we found that, more often than not, problems are a result of multiple errors distributed evenly among the various components. The slow process of discovering these errors was interesting and gave an opportunity to understand everyone's code.

 

 

Learning

 

 

4. What you learnt: What did you learn by working on the project? Include details on technical things you learnt, as well as what you learnt about dealing with large projects, collaborating with other busy people, and dealing with other coursework.

 

Technical Learning

 

The most exciting aspect of the project is learning new technologies like JTAPI, SIP and RMI. One thing we realized is that Internet Telephony project is extremely challenging. There are various companies that are beginning to invest in this area and believe in its potential. Being a technology in its infancy it also has various undefined boundaries which with both its pluses and its limitations. Working with these limitations has been a really educational experience.

 

Design and Coordination of Big Projects

 

Since signaling deals with most of the team members, we had a great opportunity to be closely involved in the designing of the system as whole. Even though the interfaces and project descriptions were quite detailed, we also got a chance to work on the design of the project. It was a great learning experience and we have learnt a lot from each other. We learnt how to coordinate effectively and produce results in as short a time span as possible. It is easy to waste time and keep arguing about the best way to go about doing something. The hard part, we learnt, is to brainstorm and come up with the best solution. We believe in teamwork and that the best results are produced by good groups and individual’s hard work and dedication. We also learnt that sometime things don’t go as expected and overcoming these problems as a team can be a great feeling. These problems also made us realize that in life sometimes it is more important to come up with something that works rather than something that is the most efficient.

 

 

 

 

 

Scope for Improvement

 

5. What would you do differently next time: Everyone makes mistakes. But good learners don't repeat mistakes, they make all new ones! This project gave you a lot of freedom to make mistakes. What will you look out for the next time you undertake a large collaborative project?

 

More Brainstorming sessions: The brainstorming sessions that we had as a team proved to be extremely effective. They not only help come up with great solutions but also give an insight into the progress of a team as a whole. It give an opportunity to develop friendly relationships with other team members, which is a great asset in the smooth functioning of the team. If we had to do this all over again, we would plan a lot more of these sessions earlier in the semester.

 

Correctly Estimating Time Commitment: This project is a very ambitious one and requires a lot of time. It would be ideal to do this project with very little to no other work. That is, however, not possible in a college environment. We feel better time management and more time for the project, is something we definitely need to concentrate on. Given another chance for the first month we would do more testing and try to speed up the design process. As we mentioned earlier, it is better to lay out a detailed design than to work with a sketchy one and change a lot of code at a later time.

 

Start Integration Early: Although signaling is not really complete till every other component is fully functional, the process of integration can start pretty early on. We realized this slightly late in the semester that even the most basic of code can be integrated and should be integrated early on. This greatly removes the complexity of integration when the different components are huge and cumbersome.

 

 

 

Interfaces

 

 

6. Interface that your team will provide to other teams or use: Please give the exact procedure calls that you will make or support. This is your final interface spec. C/C++/Java code is OK.

 

Interfaces That We Use

 

 

TEAM 1 - Telephone Application

 

  • public int Accept_call(String sIP, String sCaller);//invite application at sIP
  • public void start_call (String sIP, int port1, int flag, String IP_addr);//Give the App. Info about caller and start the call.
  • public void Hangup(String sIP);//Tell the App. that the call is complete and has been hung up by the sIP.
  • public int isAlive(String sIP);//Query application to check if they are still in a call.

 

TEAM 3 - GATEWAY

 

  • int lineQuery(String IPAddress);//returns line number we should use for full-duplex calling; IPAddress is the source application, so that Gateway can route packets to them.
  • void hangup(int linenumber);//hang up the line, second is automatically hung up by the Gateway

 

TEAM 4 - DIRECTORY SERVICE

 

  • boolean AddUser(String Email, int Extension, String Password, BitSet Week, byte Group0Time0, byte Group0Time1, byte Group0Time2, byte Group1Time0, byte Group1Time1, byte Group1Time2);
  • boolean RemoveUser(String Email, String Password);
  • boolean ChangePassword(String Email, String OldPassword, String NewPassword)

 

// Methods to obtain numbers, emails and IP addresses

  • boolean GetIP(String Email, byte Pref, Address ReturnIP)
  • boolean GetIP(int Extension, byte Pref, Address ReturnIP)
  • boolean GetPhone(String Email, byte Pref, Address ReturnPhone)
  • boolean GetPhone(int Extension, byte Pref, Address ReturnPhone)
  • boolean GetIPorPhone(String Email, byte Pref, Address ReturnAddress)
  • boolean GetIPorPhone(int Extension, byte Pref, Address ReturnAddress)
  • String GetUserByExtension(int number)

 

// Listing features

  • boolean ListAllUsers(Vector ReturnData)
  • boolean ListAllConferences(Vector ReturnData)

 

// Conferencing support functions

  • int CreateConference(int qos)
  • boolean AddUserToConference(int conf, String Email)
  • boolean RemoveUserFromConference(String Email)
  • boolean DestroyConference(int conf)
  • int GetConference(String Email)
  • boolean GetCurrentUsersInConference(int conf, Vector ReturnUsers)
  • boolean GetAllUsersInConference(int conf, Vector ReturnUsers)
  • int GetMaxInConference(int conf)
  • int GetConferenceLength(int conf)
  • int GetConferenceQoS(int conf)

 

 

TEAM 5 - ACCOUNTING & BILLING

 

//Tells billing all they need to know via various flags

 

  • public static void SendSignalingData (String Caller, String CallerAddress, String Target, String TargetAddress, String QOS, String CallType, String Conference, String Fax, String VoiceMail)

 

TEAM 6 - MANAGEMENT & INTEGRATION

 

//Tells Management what we did via a String. The Strings are buffered up at the client-side server running on a separate thread and queried by Management off and on.

 

  • public void reportAction (String action);

 

TEAM 7 - VOICE MAIL

 

  • public int Accept_call();//invite application
  • public void start_call (int port, int flag, String IP_addr);//give them app’s info
  • public int Vmail_Hangup(int line);//tell them phone call is over and that they should hang up
  • public int Vmail_Hangup(String IP, int port); //tell them PC call is over and that they should hang up.
  • public int isAlive(String IP, int line); //Query Voice Mail to check if they are still handling a call.

 

 

TEAM 8 – CONFERENCE

 

  • public int CallQuery(String connectionTo, String connectionFrom, int number, int code, String email);// Invite Sequence to start a call
  • public int HangUp(String source, String destination, int number, int code, String email);//Tell them to hang up/remove user source from the conference
  • public int IsActive(String connectionTo); //Query Conferencing Application at IP: connectionTO, to check if they are still in a conference.

 

 

Note: We had all the logic to support Conferencing in our code. The team, however, was working on their native application code till the last moment, hence we were unable to demonstrate that during the various demos. Given a couple of hours Signaling have the functionality to support Multi-Party Conferencing.

 

Interface That We Provide

 

Please note that we might add more functions to this list if applications realize that they need more functions. Once conferencing is incorporated into our logic we might have to provide more methods for that team. We also have two private methods that register DesktopSignaling Components with the MASC upon instantiation. This way we have a list of all active signaling components. There is an unRegister() method that removes a component as well. All other methods are private methods for parsing and providing low level support.

 

 

LIST OF METHODS

 

//Main function Applications use to Dial, a computer, Voice Mail or Telephone

//Dial also contains the logic to join callers to Conferences.

public SignalPacket Dial(String source, String destination, String yourID){

 

//Terminates calls

public boolean Hangup(String source, String destination, String line, String yourID){

 

//Gateway uses this to tell us that a telephone has hung up

public boolean gateHangup(String number, String line){

 

//check is a computer application is active and tell Gateway or Data Transfer

public boolean isActive(String address){

 

//check is two computers are active and tell Gateway or Data Transfer

public boolean isActive(String source, String destination){

 

//Hang up a call for voice mail

public boolean vMailHangup(String destIP, String port, String lineNo){

 

//gateway uses this to check for the validity of an extension entered

public SignalPacket isValid(String number){//1 it is active; 0 it is inactive

 

//Gateway tells us that a call is coming in, handle it.

public int handleIncomingCall(String number, int line)

 

//Management uses this to tell us to kill a connection

public boolean killConn(String user)

 

 

Course Staff

 

7. Advice for the course staff: What mistakes did we make in running this project? Please help us improve the course.

 

 

You all did a super job!!! Very approachable and always ready to help, we would never have been able to do this project, if it was not for your help and guidance. The staff was very knowledgeable about most of the issues and the requirements set for us. They were also willing to learn with us on issue that they were unsure of and were extremely good about getting back to us promptly.

 

Regarding the availability of resources, although we did have a lot of help, a few more sample codes for things like JTAPI and SIP would have been great. We were often referred to great sites, where we could find this information, but sorting through information of huge sites can sometimes be a fruitless effort. With the experience that the staff has, they are in a better position to identify useful code and information.

 

One possible step to look into could be towards encouraging interaction between Signaling groups of different teams. I know that this sort of interaction certainly helped James in our gateway team. But for those of us who are not friends with each other a possible solution is common brain storming sessions. This way we can help each other come up with ideas, exchange problems that other had encountered and possibly make friends with people for further interaction.

 

I also feel that the workload among the teams was somewhat unevenly. It would be a good idea to make sure that core components like Gateway, Signaling and Data Exchange have more people working on them. I feel steps should also be taken to find out people's interest in the development of a certain component, rather than making First come first served assignments. This step can help the entire group best utilize the talent the group as well keep people motivated in doing a good job.

References

 

 

 

8. References: What sources did you consult in working out the details of your project? URLs for Web pages are acceptable for references.