Date: Dec 1, 98
Group number and name: Phonetics, Group 4
Team members: Jingyang Xu (jx20), Ming Wai Lam (ml79)
Task number and name: Management and Integration, Team 6

 

List of things accomplished since last report:

  1. "Phonetics Management Console" (PMC)

User Interface design and coding - We designed a very appealing and user-friendly management GUI. It displays the following bird’s eye view of our telephony network:

We are on our way to implement it. As of now, half of the frames and special features are completed. Here is a sample screen displaying user information (username is Joy, extension 30, at an unknown location, has been talking for 10 minutes, and billed $200).

 

Interface coding – By report 2, we had implemented our null interfaces and superclasses of the server components we provide to all the teams which we need to receive data from. In the last week, we completed the interfaces (server stubs) that we provide to signaling, billing, voice mail and multiparty conferencing. We have also completed the client on the PMC that communicates with our servers. We also completed internal data structures that store information polled from server stubs. The work left in the stubs is to check for errors and handle exceptions.
  1. PMC "User Registration" design and coding

    2. Users need to be added to the Directory database. We are implementing an add-on app to PMC that allows the network manager to enter user information (email, password, IP, extension, etc.). "User Registration" is being worked on.

  2. Setting milestones

    3. We called a meeting on November 28, 1998, the day before Thanksgiving break. All teams attended the meeting. We set milestones and deadlines for each team to provide working code. As of today, Milestone –2 and –1 are completed. The group is on schedule. The following are the schedules:

    Date

    Milestone

    Description

    Teams involved

    Nov 26

    -2

    PC-to-PC sending and receiving text files (simplex)

    Teams 1, 2

    Nov 30

    -1

    PC-to-PC microphone-to-headphone connection (simplex)

    Teams 1, 2

    Dec 3

    0

    Phone-to-PC or PC-to Phone connection

    Teams 1, 2, 3, 4

    Dec 6

    1

    Multiparty conversation among PC’s

    Teams 1, 2, 3, 4, 8

    Dec 10

    2

    Multiparty conversation among PC’s and Phones

    All teams

    Dec 18

    N/A

    Demo (4-6pm)

    All teams

  3. Participating in accomplishing milestones

    4. We realized that the deadline is coming up fast and we needed to make our milestones. Therefore, we expanded our responsibilities as the management and integration team by working as a supporting team for all of the other teams.

    On Thanksgiving night, the date we set for milestone –2, with some code stolen from team 7, working with signaling and data, we built a simple console application that calls functions provided by Teams 1 (Data) and 2 (Signaling), successfully transferring text over the data connection. We passed this code down to Team 1 for use with their Telephony application.

    On November 30, again we coordinated efforts between signaling and data to complete milestone –1.

  4. Clarifying concepts with team members

    5. We spent time explaining to individual teams who have questions on how the system works as a whole and their individual responsibilities. Our main concern was to get the big four backbone teams’ (data, signaling, gateway and directory) interfaces and code working as soon as possible. We have completed our goal to this end. This involved many hours spent in lab speaking individually or with subsets of the whole group. In addition, some teams needed to be brought up to speed with the API that the backbone teams were providing.

  5. Meeting on Dec. 1

Met on December 1 to make sure everyone is on track. Worked out misconceptions Multiparty Conferencing had about APIs.

 

Problems:

  1. Null Interfaces – After asking for null interfaces, it took all team members one and a half weeks after the deadline to complete everything.
  2. Language Conflicts – We found out on the Nov. 28th that team 8 has decided to implement their code in C++ after confirming with the group that they will be in Java in an earlier meeting. We had to work with them to realize the interfacing between Java and C++.

What we learnt:

  1. Socket programming and WFC programming in Java
  1. Effective UI design

    2. We exercised a lot of creativity to design our GUI so that it is user-friendly, appealing, and most importantly, it best presents the Phonetics telephony system to the network manager, and helps him or her identify errors.

  2. Effective internal data structure design

    3. We learnt the built-in Java data structures such as enumeration, hashtable, dictionary, and vector. Among these, we found hashtables and vectors most useful for our purposes. Vectors are most frequently used in read buffers and hashtables are very effective for retrieving user/conference information.

  3. Coordination among teams

We learnt the art of having the big picture. As the management team, it is our responsibility that all the teams are on track and interfacing with each other. We needed to be aware of all the APIs and interfaces between the teams and to be able to explain to any team member other teams’ interface they need to use. In many instances, we sat two teams down and resolved with them the needed interfaces so that the teams may work with one another. In addition, we have teams that have attended almost every meeting but did not voice their needs and concerns. We needed to identify these group members and keep them on track. It’s a full time job!

What we would do differently next time:

Interfaces

Interfaces that we provide:

Teams that we provide the interface to:

Class and functions provided

Team 5: Billing

Class PMServerBilling{

PMServerBilling(Billing billing);

public void setUserAmount(String username, float charges, int howlong);

void start();

}

Team 7: Voice Mail

Class PMServerVoiceMail{

PMServerVoiceMail(VMail_Service vmail);

void start();

}

Team 8: Multiparty Conferencing

Class PMServerConf{

PMServerConf(Conf conf);

void start();

}

Team 2: Signaling

Class PMServerSignal{

PMServerSignal(UpperMascLayer signalapp)

void start();

void reportAction(String whatdone);

}

 

 

 

 

 

 

Explanation:

For brevity, abbreviate the team we are providing the stub to App, and the corresponding server stub PMServerApp. Each PMServerApp is a thread that is started by the corresponding app and is killed when the app exits.

The constructor PMServerApp(App app):

  1. Creates an instance of PMServerApp
  2. Passes a reference of the calling class App to PMServerApp.

The function void start():

  1. Starts the thread of PMServerApp
  2. Establishes a listening port on the machine App is running
  3. Registers with Directory server with App’s name, IP address and listening port established
  4. During the time App is running, PMServerApp will be accepting and handling requests from PMC through a TCP connection.

Explanation of reportAction(String whatdone) we provide to Signaling:

Whenever Signaling successfully performs a task, it calls reportAction() and passes us a String that describes what it just did, an example will be "Sent an invitation to john@phonetics.com from tom@phonetics.com"

The record of actions will be buffered up, and sent to PMC on the next request.

Explanation of setUserAmount(String username, float charges, int howlong) we provide to Billing:

Billing calls setUserAmount() periodically to update an internal buffer in PMServerBilling that stores: for each user, how much he is currently charged (in USD) and how long (in min) he has been in conference if he is currently in one . The buffer will be sent to PMC on next request.

 

Interfaces that we need:

 

Team that we need interface from

Class and function definition

Description

Team 2

class UpperMascLayer{

public boolean killConn (String user)

}

Called by: PMServerSignal

Usage:

PMServerSignal calls killConn using the handle to signaling’s server class named UpperMascLayer.

Action:

killConn() remove user specified from the conference he is in

Team 3

class gatewayInterface{

public gatewayInterface() {}

public static int numCallsMade()

public static int LinesInUse()

public static float cntLantency()

public static float percentPacketsReceived()

public static int packetsReceived()

public static float percentPacketsRecovered()

public static int packetsRecovered()

public static float percentPacketsLost()

public static int packetsLost()

public static float percentPacketsLate()

public static int packetsLate()

public static int numPacketsSent()

public static int avgPacketRate()

public static int cntPacketRate()

}

Called by:

Phonetics Management Console (PMC)

Usage:

PMC creates an instance of gatewayInterface and calls the class functions which return the performance statistics of data on the internet.

Team 4

class DirectoryService{

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)

 

 

 

Called by:

PMC -- User Registration

Usage:

PMC creates an instance of DirectoryService and calls its class functions

Actions:

AddUser() is called to add a new user to database and sets his IP/password/etc. with directory.

RemoveUser() removes the user from the database

boolean ListAllUsers(Vector ReturnData)

}

//ReturnData is a vector of //UserInfo’s, as defined below:

class UserInfo implements Serializable{

String name;

Address currentAddress;

int conferenceHandle;

int extension;

}

boolean ListAllConferences(Vector ReturnData)

//Return Data is a vector of //ConferenceInfo’s

class ConferenceInfo implements Serializable

{

Vector currentMembers;

Vector allMembers;

//currentMembers and allMembers are //vectors of UserInfo’s

int qos;

int length; //in minutes

}

ListAllUsers() and ListAllConferences() are user dumps and conference dumps. From these we get the following information:

For each user:

  • IP/Phone he is reachable at
  • extension to access user from a phone
  • which conference he is in

For each conference:

  • which users are participating
  • which users have left
  • QoS: Bits per second
  • duration of the conference

Team 7

void getVMailStat(VMailStat vms)

class VMailStat implements Serializable

{

VMailStat()

Vector VMailUserList;

//A vector containing "VMailUser"'s

public int actionIdentifier;

// 0 = no action

// 1 = user is listening to mail

// 2 = someone’s recording mail

public String currActionUser;

//who's listening to or receiving mail

public float percentPacketsReceived;

public int packetsReceived;

public float percentPacketsRecovered;

public int packetsRecovered;

public float percentPacketsLost;

public int packetsLost;

public float percentPacketsLate;

public int packetsLate;

public int numPacketsSent;

public int avgPacketRate;

public int cntPacketRate;

}

class VMailUser implements Serializable

{

VMailUser(){}

public string username;

//currently serving user

public int numNewMail;

// new mails waiting for user

public int numAllMail;

//total no. of mails user has

}

Called by:

PMServerVMail

Usage:

PMServerVMail calls getVMailStat using a handle to Vmail_Server (Voice mail’s main application) upon a request from PMC.

Actions:

(Note that Vmail_server handles one request, whether it is checking mail or leaving mail, at a time)

We obtained the following information:

  • names and account information of all voice mail users
  • whether the Vmail_Server is active or not and what it is doing
  • which user is currently using the service
  • some data sent/loss/recovery information

Team 8

public void getMConfStat(MConfStat stat)

class MConfStat{

String username;

int conferenceID;

String conferenceName;

int moderator;

int canSpeak;

int canScribble;

int canType;

DATA dataInfoFromDataGroup;

}

 

 

 

Called by:

PMServerMConf

Usage:

on a request from PMC, PMServerMConf calls getMConfStat using a handle to app’s main class and obtains the following information:

  • who has started the application and IP of computer the app is running on
  • whether user is in a conference and which one it is
  • whether he is a moderator
  • whether he is currently speaking
  • whether he is currently scribbling on whiteboard
  • data sent/loss/recovery information

 

What you need from the course staff:

nothing

References

MSDN Documentation