Project Overview

Phonetics Inc., after years of hard and grueling work, has finally completed their Internet Telephony Project. All major newspapers and television networks scramble to interview employees of this amazing company. Competing long distance carriers are shaken to the core, fearful of Phonetics’ potential. People across the globe rejoice as Phonetics sweeps in the next evolution to communications. Two months later, Phonetics runs out of funds, files Chapter 11 and dissolves. The problem? They didn’t have a Billing and Accounting department.

Our Billing and Accounting team is devoted to making the above scenario an impossibility. The bulk of our work was to design a pricing plan that will both attract customers and generate profits. We had to make our prices low enough so that customers would want to use our service, but we also have to at least recoup our operational costs and then try to make as much profit as possible.

In addition to developing a pricing plan for all our various services, we also had to code a Billing and Accounting module for Phonetics. The module has to be able to keep track of system usage by subscribers, charge appropriate amounts, print bills for each subscriber, and keep the Management team updated on information that they request.

Our Billing module will include a database that will be updated by information flowing in from Signaling team. Since it is crucial to have correct billing data, we do not want to risk having outside users sending malicious data to our Billing server. To minimize that risk, we need to implement an authentication protocol that will allow our server to recognize that the client sending us data is indeed a legitimate client running with Signaling.

Accomplishments

Pricing

Our pricing plan tries to achieve two seemingly contradictory goals. Our first goal is to charge enough so that we will make enough money to recoup our operating expenses and also generate profit. Our second goal is to charge a low enough rate to make our service attractive enough for a lot of customers to use it.

We started by trying to figure out how much money Phonetics needs to make to stay in business. This will be our bottom line, we have to be able to make at least this amount if we are to consider going into business:

Estimates:

Fixed operating costs: $80,000/month. (equipment/maintenance/salaries)

Subscriber base: 5,000 users initially

Average usage: 30 calls/month

Average call duration: 15 minutes

Voicemail users: 500 users

Average VM usage: 20 messages/month

Break even point: $0.53/call or $16/user/month

Based on these estimates, we can charge users a $10 a month subscription fee for our service. Per call charges will offset the rest of our fixed costs and also pay for variable costs such as additional bandwidth, etc.

After reviewing several ideas from Professor Hal Varian’s "Pricing the Internet" paper, we decided to adopt a strategy of billing users based on their usage of the network. Allowing light users to have less charges, and charging heavy users more as they take up more system resources.

Our final Price Schedule follows:

Per month charges:

Basic Service: $10.00

Voicemail: $2.00

(Voicemail includes 50 messages per month)

Per Call Price Schedule: (not progressive, the ENTIRE call is billed at one rate)

0 – 15 minutes: 0.02/minute

15 – 60 minutes: 0.04/minute

60+ minutes: 0.05/minute

Conferencing: 0.01/minute/user additional

Voicemail Schedule (monthly): (progressive, each message billed at different rates)

0 to 50 messages free (included in $2.00 Voicemail service charge)

50 to 100 messages 0.05/message

100 to 250 messages 0.075/message

250+ messages 0.10/message

 

By combining our pricing plan and usage estimates, we can guess at how much money we will actually make:

Revenue/Expense Monthly Cash Flow

Basic Service (5000 users x $10/month): $50,000

Average Per Call Charge (30 calls @ 15 min ea.): $45,000

Voicemail Service (500 users @ $2/month): $ 1,000

Operating Costs: ($80,000)

Gross Income: $16,000

We see that with our pricing plan, we can expect a $16,000 profit every month. This is just extra cash for the employees since employee salaries were already included in operating costs.

Interface

Our interface with signaling achieves what we had wanted it to. It allows signaling to notify us whenever a call has started or ended, and pass along all relevant information of that call to us. We have implemented a custom authorization procedure. Our server will send a random string to the client on the signaling side whenever the client makes a connection. The server will reject messages that do not include a proper response to the server’s random string. This authentication procedure is designed to increase the security of our database, so that outside users cannot pose as our clients and send false charges into our database.

Database

Our database design and data access methods provide the necessary functionality to keep secure and accurate records of telephone transactions. We used Microsoft Access as our backend database and used JDBC and a JDBC-ODBC bridge driver to execute SQL queries, inserts, and updates to access and modify data. See Figure 1 for a chart of the data flow. Security was enforced on the database through password authentication for ODBC connections and at the Access application itself.

Many SQL statements were written to support the functions we needed. SQL INSERTs handle data entry associated with the start phone call, SQL UPDATEs handle modifying the call’s status when the phone call ends, and SQL SELECT queries were written to support the management application and to print periodic bills.

Problems Encountered

Technical Problems: Internal

While testing our signaling interface, we encountered a strange error while using writeBoolean() and readBoolean() from java.io.ObjectOutputStream and java.io.ObjectInputStream. After much testing with the Signaling Team, we thought that there may be something wrong with how J++ handled these functions. We didn’t want to waste time looking into it too much, so we used a workaround of passing Strings between the client and server instead of booleans.

Also, we had problems connecting to the Microsoft Access database using standard Java classes. We found out on a Microsoft MSDN webpage that the Visual J++ 6.0 development platform that we used did not support the standard Sun Java JDBC-ODBC bridge. We had to add Microsoft’s Java SDK 2.0 in order to use Microsoft’s own JDBC-ODBC bridge driver.

Technical Problems: External

While testing the management server, we spent large amounts of time trying to figure out why a Vector of BillUser objects was crashing the management application when we passed it to them. After large amounts of time spent on this, we found that since BillUser was extending Serializable, it needed to be EXACTLY the same on both ends. The Billing end had BillUser as a public class while Management didn’t. This caused a myriad of problems that went away as soon as we made both versions non-public.

What we learned

Team Dynamics

We learned that on group projects, it’s hard to get everyone coordinated and working together. On group projects with a large number of people, it’s even harder. Communication and coordination efficiency between members degrade to such a point that a management team is required to keep everyone going.

Time Allocation

Please look at the "What we would do differently next time" section to see what we have learned about time allocation on large academic projects.

Database Programming

We learned a great deal about databases throughout this project. Having very little development experience with databases, we basically had to start from the ground up. The three database concepts we learned about was database client programming, means of accessing a database, and methods of representing data. For database client programming, we learned how to use the standard Java java.sql package that provided JDBC connectivity to databases. This package contained all the methods that we used in connecting to the Microsoft Access database, such as data type conversion and SQL formatting. We also learned how to access a database through SQL statements. We performed queries with SELECT statements, added new rows with INSERT statements, and modified data with UPDATE statements. Finally, we learned how to design and manage databases using Microsoft Access. We learned how to create and secure databases, and represent data in forms and reports.

What we would do differently next time

Time allocation

We know that it is a generally good practice to do all the major planning and design work before the coding. This way we can avoid faulty/inefficient designs and interfaces that come about when just jumping straight into coding. Thus, we allocated the entire first half of the project to planning and design.

The good news is that coding our Billing and Accounting database backend was pretty straightforward and no big surprises or detours came up. The bad news is that we had to spend a lot of time at the end making sure our code works with everyone else’s.

What went wrong? In a corporate environment, getting all the major planning and design work done beforehand is a good idea. This is because in the later stages, everyone will have time to work out kinks in code integration (they have to have time, that’s their job). However, in an academic environment, students have other classes to attend to. There isn’t enough time at the end for everyone to get together to figure out why their code isn’t fitting together well. In future large academic projects, we will try to begin code integration and testing interfaces as soon as possible, doing planning and design along the way.

Interfaces Provided

/* class BillingUpdate

* Purpose: called by signaling to provide information to

* Billing and Accounting upon each connect/disconnect of a call

*

* Current Stage: Full Interface

* -12/17/98 YAC/CKM

*/

public class BillingUpdate {

private String server; /* String: Name of B&A server resides on */

private Socket socket;

private ObjectOutputStream out;

private ObjectInputStream in;

 

/* Function BillingUpdate

*

* Purpose: Initialization function

*

* Arguments:

* String BAServer: Name of B&A server resides on

* (to be supplied by calling application)

*

* Result: Sets up server information in preparation for connection

*/

public BillingUpdate(String BAServer)

{/* cut to conserve space */

}

public BillingUpdate()

{/* cut to conserve space */

}

 

/* Function ConnectToServer

*

* Purpose: Opens socket to B&A Server

*

* Arguments:

* None

*

* Result: Connects socket to B&A Server and sets in/out info

*

* Returns: true/false on success/failure

*/

private boolean ConnectToServer()

{/* cut to conserve space */

}

 

/* Function DisconnectFromServer

*

* Purpose: closes socket to B&A Server

*

* Arguments:

* None

*

* Result: Closes socket to B&A Server and sets in/out info

*/

private void DisconnectFromServer()

{/* cut to conserve space */

}

 

/* Function SendSignalingData:

*

* Purpose: send various call informations to B&A Server

*

* Arguments:

* String Caller: Caller name or ID

* String CallerAddress: Caller phone number or IP Address

* String Target: Target name or ID

* String TargetAddress: Target number or IP Address

* String QOS: Quality of Service information on this call

* String CallType: "1" denotes beginning of call, "0" denotes

* end of call

* String Conference: "1" if call is a conference call, "0" otherwise

* String Fax: "1" if call is a fax, "0" otherwise

* String Voicemail: "1" if call is a voicemail call, "0" otherwise

*

* NOTE: arguments are all strings due to unexplainable failure

* of J++ to handle writeBoolean and readBoolean correctly.

*

* Result: Sends information to B&A server

*

* Returns: true/false on success/failure

*/

public boolean SendSignalingData (String Caller,

String CallerAddress, String Target, String TargetAddress,

String QOS, String CallType, String Conference,

String Fax, String Voicemail) {/* cut to conserve space */

}

 

/* Function BUDecode

*

* Purpose: Decodes an authentication string

*

* Arguments:

* String decodeme: string to be decoded

*

* Returns: (String) decoded string

*/

private static String BUDecode(String decodeme)

{/* cut to conserve space */

}

}

Suggestions for course staff

The overall project seemed very well designed to us. We felt that the workload was evenly distributed among the different teams. There was a clear goal for us to work towards, and we knew what was expected of us. There is nothing about the project itself that we can complain about.

We do however feel that there were some changes that could be made to the class to enable us to devote more time to this project. During the initial stages of the project, we were spending lots of time working on the Puzzles. The time spent on these puzzles were not insignificant and it detracted from our available time to work on the final project. This created some amounts of stress until we were done with the puzzles and finally had time to work on the project.

References

Budd, Timothy. An Introduction to Object-Oriented Programming. Reading: Addison-Wesley, 1996.

McCarty, Bill. SQL Database Programming with JAVA. International Thompson Publishing, 1998.

Wood, Charles A. Visual J++. Rocklin: Prima Publishing, 1996.

Borland JBuilder documentation

JDBC documentation