CS519: FINAL REPORT
Group 3
: Keshav’s KidsMohammed Alam, Robert Sudol
Task 5: Accounting, Billing, and Pricing
1. What did you set out to do?
Our responsibility was to provide an accounting system for our Internet Telephony Group. We were required to track all calls made via the system, determine their price and bill the appropriate user. These records needed to be maintained in stable storage (in this case, an Access database) to allow recovery from host crashes. Maintaining a call log required interfacing with the signalling group to determine when a call was being placed and, indirectly, with the directory services group to ensure authenticated users were being billed for the calls. We then had to provide our company with a scheme for billing customers and the system by which we would collect payments for our services. When billing someone for a call, we had to determine a pricing strategy that would be justified for an Internet Telephony network. It could not be based entirely on the distance that calls traveled, but instead needed to cater to the costs of using the Internet. Thus, the scheme was designed to reflect the cost of creating additional congestion on the Internet, and the criterion used were those that gauged this traffic. Our duties also included generating bills for customers, and providing a protocol that provided protection against PBX imposters.
Initial goals of our project:
Try to ensure secure communication with our database (though we considered this very difficult without implementing an entire encryption scheme).
Detailed descriptions of the pieces:
Summary Stub: The call summary stub is a class that runs in the signaling application. It was designed to be called at the end of a call and provide our accounting server with a summary of the call. It would provide information on the user, the number called, length of the call, time of day, and variables that reflect the bandwidth the call required. At the initial stage we were considering charging based on some metric of the distance the call was traveling; this could be gauged by determining if the caller and recipient were on the same subnet.
Database Server: The server would be running on the CS519kk machine; it has a listening socket on port 1111 that waits for information to be passed to it. Our initial goal was just to have it receive updates from the summary stub. Later on we determined other uses, such as registration and price querying.
Pricing Methodology: Our initial plan "was to receive the IP addresses involved in the call (and number of switches (hops), if available), as well as the duration and determine the total cost of the call. If it is purely one user to another the caller will take the full cost of the call. Separate functionality will be included for conference calls and services."(Report 1) These plans changed as the project evolved and the final pricing scheme will be described below.
We planned to build an Access database that would run on CS519kk to act as the accounting database and update it using JDBC. "It will consist of at least two tables: a User Table, and a Call Log. The User Table will have a User ID (Primary Key), Name, Billing Address and E-mail. The Call Log will actively maintain all calls for one billing period. After that it will calculate the bills for that time frame and save the table in some form of permanent storage. The Call Log will contain the User ID (being billed), Cost, Call Recipient, Length, Date, and Start Time. Queries will be designed to print out bills, as well as access individual user accounts."(Report 1)
As far as additional utilities for the customers, our first thought was to design an application that a user could use to estimate the price of our call before it was made. This utility would possibly have to interface with directory services and/or signaling and then use our pricing scheme.
We initially considered security being accomplished by the format of the information passed to our server by signaling. Later thinking would reveal that this packet structure could be sniffed as it traveled on the Internet. But we never considered implementing encryption due to the scale of doing that. If this system was ever rolled out, this would have to be done, but then we could implement or purchase encryption software for the accounting packets.
2. What did you actually accomplish?
A. Call Summary Stub:
The Call Summary Stub is integrated with the signaling application to generate a record of all calls that are placed using our service. Upon the completion of a call, signaling calls our stub (a static function in a class) with information required for billing. This is passed to our accounting server, which runs on cs519kk.csuglab.cornell.edu. The stub conveys the following: the duration of the call, caller id, destination phone number, the day, month, hour, and minute the call was placed, and boolean checks on whether the call was local (within the same subnet) and included either audio or video (reflect bandwidth usage). The last three are defaulted to false as the system is not providing the services. We wanted to record additional audio and/or video charges for calls that used these, but at this point, our phone system allocates a fixed amount of bandwidth per call, regardless of services used. If these features were updated than our pricing system would be able to charge based on bandwidth used or some measure of the distance the call traversed. This and the billing server are the most integral pieces of our project, because they handle the accounting of all calls that are placed.
B. Accounting Server:
The accounting server is an application that runs on the cs519kk machine. It is the interface between the billing database, and any applications that make use of it. It is also integrated with the pricing function to determine the cost of calls when summaries arrive. It runs on port 1111 on the group machine and right now can accept three types of requests. The first is the call summary. As part of our authentication protocol, the stub first sends an initial message; the server sends back a random identifier. The stub then computes a checksum of that identifier and appends it to the information it sends. The server first parses out the information from this message, including the checksum. It compares the value of the latter with its own computation result. If authenticated, it calls the pricing function to determine the cost of the call. It then connects to the billing database, and adds the call to the log and the cost to the individual user’s balance. The second type of request is registration. This allows new users of our system to be registered in the billing database. It creates a profile for them in the database, and then uses directory services’ stub to forward information (user id and password) to their database to facilitate authentication. The third type of service is call-pricing query. This client is a GUI application that users can execute to determine the price of a call before they make it. The server calls the pricing function as before and returns the cost, but doesn’t add it to the call log. All of our updates are done using JDBC, and more specifically a JDBC:ODBC bridge. The SQL is all included inside the server code and the queries are updated for whichever values they are attempting to retrieve, insert, or update.
C. Pricing Scheme
The pricing scheme is the root issue behind the accounting problem. How do you determine what to charge for, and how much when dealing with Internet telephony. The actual implementation of this function was secondary to determining the pricing factors of Internet calls. When researching Internet pricing schemes, especially those described by Hal Varian, we determined that the majority of the costs in the Internet are fixed and in most cases have been paid (i.e. wires, routers, etc.) The main cost that should be carried over to users is the "social cost". This "social cost" is the effect that one user has on the others who use the system. These issues address quality of service on the Internet as it grows more crowded, and people hoarding more bandwidth tend to adversely affect the performance of other users. These "social costs" are what we tried to bill users for in our pricing scheme. Unfortunately some of our ideas are implemented in the function, but can’t be utilized because of a lack of information or capabilities that aren’t used in our project. The main charges we use are based on duration of the call and time of the day the call is placed (to reward users for calling during non-peak hours). Users who call for longer than 20 minutes receive a reduced rate, because it requires less cost to our system to maintain a call than to continually bring new ones up and down. There is also a check in our pricing function for whether it is a weekday call or weekend. The user is charged less for weekend calls since network traffic is lower than. Initially we expect most of our users to be in the business sector, and this would tie up the network more during weekdays. So we decided to add an additional charge for users taking up bandwidth during weekdays. We wanted to include additional costs based on the inclusion of audio or video data, due to the increased bandwidth these would require (thus causing a greater "social cost"), but couldn’t because all calls on our network are granted the same amount of bandwidth. We can describe this research in more detail during our demonstration. The pricing scheme is determined by a flat file; this allows flexibility in modifying prices without recompiling the entire server.
The diagram below serves to validate our pricing scheme. As you can see most networks experience peak traffic around 16:00EST. From 12:00-16:00 this traffic is growing. It drops off overnight reaching its lowest average point of measured traffic around 4:00 A.M. Thus, this explains our high rates for daytime traffic, when congestion is at its highest, and the lower rates we reward our users for using the system during the overnight hours. (We retrieved this figure from "Pricing the Internet" a paper written by Hal Varian and Jeffrey MacKie-Mason at the University of Michingan).
D. Billing Database
The secure billing database was created in Microsoft Access. It contains three tables: Call_Log, Latest, and User_Table. The Call_Log maintains the records of all calls placed on the network organized by the date, time, cost, user who made the call, duration, and the number that was called. Latest provides the billing information for all users. It lists their present balance, the date their next payment is due, the amount due at the next payment, the latest payment received, and the date. The User_Table provides information about the actual users, including their ID, name, e-mail address, phone number, mother’s maiden name, and social security number.
E. Generating Billing Records
Our billing records are created by an application which generates a text file of the call log. This can be done for an individual user for either their entire history of calls, or for a specified billing period. This utility would be run at the end of every billing cycle by the accounting staff to generate records to be sent to all of our customers. They include the history of the calls plus the total balance they owe. Once the bills are generated they can either be sent to each user’s e-mail or postal address, since both are available.
F. Call Pricing Query
This is a utility we wanted to provide to our customers to allow them to determine the cost of a call before they make it. They enter the time and expected duration of the call and we return the cost from our accounting server. It could also ask for audio or video information, but at this time this has no effect on the overall price since there is no variance in bandwidth granted. After taking in the information it puts it together in a string which it sends to the accounting server. It then waits for the server’s reply with the cost and writes that out to the screen (this is a GUI application).
G. Creating Secure Communications from Signaling to the Accounting Server
Our efforts at protecting the accounting process from PBX imposters is currently as follows:
Our checksum approach relies on an initial "handshaking" between our stub and the server before a summary will be accepted. The stub lets our server know of its desire to communicate by sending an initial message. The server returns a random number to it. The stub computes f(number) and appends it to the end of the summary packet it sends to the server.
This is not an optimal approach; malicious M can grab the final message from the stub and send corrupt data with the correct checksum value.
Ideally, we would have liked to use Java’s Secure Socket Layer (SSL) sockets. Our reasons for not doing so are detailed in the ‘problems’ section.
H. Registration Utility
This part of the project was an unexpected one. As none of the other teams claimed responsibility for a front end, i.e. an interface for users to register, we took this task. This GUI application queries the user for information such as name, desired password, phone number, IP address, e-mail address, mother’s maiden name, and social security number. The application conveys this information to our accounting server. The server populates the billing database with the name, e-mail address, and phone number. It also generates a unique user ID, and passes it back to the registration client. This ID, as well as the password, IP address, and phone number are passed to the directory services group to populate their database (using their API).
I. Late Additions
As a late addition, both our registration and call query utilities now have a GUI interface. They open up a Java frame in which the user can enter the necessary information and receive their response. This ended up looking a lot better than the text-driven interface.
3. Problems?
Fortunately, we were able to solve most of the problems we faced. However, some of the obstacles we faced are:
During this project we encountered both technical and non-technical problems. The main non-technical problem involved scheduling adequate time to work on the project, and determining the allocation of work among the entire group that wasn’t specifically assigned to a team. An instance of the latter problem is the responsibility for registering new users.
Our technical problems were as follows:
Our temporary implementation was discussed earlier. This can be more robust by adding a timeout on the server side; it would disregard messages from the stub after a certain period of time. A relevant problem would be determining how long it should wait.
Rob also faced a personal problem in that his apartment got burnt down. The lack of foresight (as a team) prevented an expedient resolution of certain issues such as a front end and allocation of sufficient time for integrating the individual components.
4. What you learnt:
On the technical side the main tool we worked with that we hadn’t used before was the JDBC toolkit and integrating SQL into an application. The first piece involved in this was configuring the group machine’s ODBC settings. This part actually turned out to stump us for a longer time than expected, especially as the configuration would change when we logged off our machine. It was also a challenge to learn the formatting and technique of writing the SQL statements and then extracting the data returned by the query execution.
The second technical tool we looked at was Java’s Secure Socket Layer. We wanted to use this to implement encryption security on our messages between signaling and our accounting server. Even though we were unable to locate the package, we were still able to read through the API documentation to see how to implement it. By setting up a SSLSocket to communicate with a SSLServerSocket, messages can be encrypted to allow communications at a determined security level. There is some control over the encryption strategy desired, depending on the version of the package used. RSA actually has produced software that is a developer’s kit for coding these SSL applications, but it didn’t have any free trial versions available. The level of encryption is also determined according to the type of package used; domestic version or the export-controlled version distributed to other countries.
We also attempted to add some applets that would have provided certain queries of our accounting server. During this we got to write some HTML, both manually and using FrontPage. Though ASP was not used eventually, we familiarized ourselves with it as we considered it seriously for web access to our database.
We also experienced the challenges of working in a large group situation. There were problems coordinating with the some of the other groups, despite being in a task that interfaced only with signaling and directory services. But it allowed several opportunities to work on group dynamics and develop leadership skills. When no one noticed the need to have a registration utility, our team was able to step up and voice this necessity. We also had to work closely with signaling and directory services to determine what the format would be for caller identification and authentication, as well as what was needed for billing and authentication purposes.
Lastly, we experienced the challenges of working close to a deadline, and changes desired features when we ran into problems that couldn’t be solved. This was indeed difficult at points, and we were sometimes forced to abandon certain ideas because there wasn’t enough time to complete them. This actually simulated the deadlines I have faced in real work environments quite well.
5. What would you do differently next time?
Of course, we would have liked an earlier start to the project. Rob would have liked his apartment intact as well. Other things that would have been desired were better group communication. With issues like the registration utility, we should have identified this problem much earlier, instead of stumbling on it towards the end of the semester. We started meeting a little bit later than would have been desired, and in general there was little attendance at the meetings and little was accomplished. If the whole group had been able to plot out things a little better, and keep in touch with everyone about where they stood, more problems would have been discovered during the semester instead of appearing at the end. What we did gain from this, is that planning things out beforehand helps to decrease time spent in development. This showed through in what we had to prepare for the first report, since that always served as a guide for what we should have by the end. Additionally, we would have brought up the issue of the Java package for SSL earlier, as well as try to have a web server running.
6. Interfaces that we will provide:
Call Summary Stub:
public class SecCall_Summary{
/***********************************
Declare a function that will create a socket to the server running the billing
database and send info regarding a call there.
Inputs:
duration: The length of the call in minutes (rounded to the nearest minute)
client_name: User lD of person making call
dest_name: Phone number of individual who the call was made to.
The next four variables specify the time the call was made.
int day:
int month:
int hour:
int min:
The three booleans are checks we wanted to make for pricing but right now are defaulted to false: (The information is not available in signaling)
boolean islocal: determinate of whether call was over a long distance or within some subnet
boolean audio: Whether the call included additional audio transmissions
boolean video: Whether the call included video transmissions
public static void Call_Dbase(int duration, String client_name, String dest_name, int day, int month, int hour, int min,boolean islocal,boolean audio,boolean video);
Server:
Wait for a request to the server
{
If receive summary call or price query call than {
Parse the input sting
Call the pricing function
If summary call {
Generate random number, store it and send a copy to the stub.
Get a response from the stub, compare function values. If authentic message: Update database call log and balance for user
(Ignore if imposter).
}
If price query {
Return price to application which initiated request
}
If registration call {
Update database user table, and account table
Call directory services to update their information with user ID and password
Return new user ID to application which initiated request
}
}
// Then wait for the next call to come in
Pricing:
private static double Pricing (Integer length, boolean isLocal, Integer date, Integer month, Integer hour, boolean audio, boolean video ) {
These variables are the same as those provided to the call_summary stub and price_query application. They are used in determining the cost against the flat file.
private static double Pricing (Integer length, boolean isLocal, Integer hour, boolean audio, boolean video ) {
double price;
FileInputStream pricefile = null;
try {
pricefile = new FileInputStream("pricefile.txt");
}
catch ( IOException e ) {
System.err.println( "File not opened properly\n" + e.toString() );
System.exit(1);
}
String pricing = "";
int readByte = -5;
try {
readByte = pricefile.read();
}
catch ( IOException e) {
System.err.println ("Couldn't read byte\n" + e.toString() );
System.exit(1);
}
while (readByte != -1) {
pricing = pricing + (char)readByte;
try {
readByte = pricefile.read();
}
catch ( IOException e) {
System.err.println ("Couldn't read byte\n" + e.toString() );
System.exit(1);
}
}
pricing = pricing + (char)readByte;
//Parse pricefile(day,evening,night,local, notlocal, video, audio,over20Minutes)
int[] indices = new int[8];
int index = 0;
for(int ink = 0; ink <pricing.length(); ink++){
if (pricing.charAt(ink) == '\n'){
indices[index] = ink;
index++;
}
}
String day = "", evening = "", night = "", local = "", notlocal = "", videos = "", audios = "", over = "";
day = pricing.substring(5,indices[0]);
Double dayd = new Double(day);
System.out.println("Day " + dayd.doubleValue());
evening = pricing.substring(indices[0]+9, indices[1]);
Double eveningd = new Double(evening);
night = pricing.substring(indices[1]+7,indices[2]);
Double nightd = new Double(night);
local = pricing.substring(indices[2]+15, indices[3]);
Double locald = new Double(local);
notlocal = pricing.substring(indices[3]+23,indices[4]);
Double notlocald = new Double(notlocal);
videos = pricing.substring(indices[4]+7,indices[5]);
Double videod = new Double(videos);
audios = pricing.substring(indices[5]+7,indices[6]);
Double audiod = new Double(audios);
over = pricing.substring(indices[6]+15, indices[7]);
Double overd = new Double(over);
//Compute price for call
if (hour.intValue() >= 6 && hour.intValue() < 18) {
price = length.intValue() * dayd.doubleValue();
}else if (hour.intValue() >= 18 && hour.intValue() < 23) {
price = length.intValue() * eveningd.doubleValue();
}else {
price = length.intValue() * nightd.doubleValue();
}
if (isLocal) {
price = price * locald.doubleValue();
} else {
price = price * notlocald.doubleValue();
}
if (audio) {
price = price * audiod.doubleValue();
}
if (video) {
price = price * videod.doubleValue();
}
if (length.intValue() >= 20) {
price = price * overd.doubleValue();
}
return price;
}
Price-Query Utility
Declare a function that will create a socket to the server running the billing
database and send info regarding a call's price there.
Inputs:
duration: The length of the call in minutes (rounded to the nearest p
client_name: UserID of individual who made the call
dest_name: Phone Number of individual who the call was made to.
The next four variables specify the time the call was made.
int day:
int month:
int hour:
int min:
The three booleans are checks we wanted to make for pricing but right now are defaulted to false. The information is not available in signalling
boolean islocal: determinate of whether call was over a long distance or within some subnet
boolean audio: Whether the call included additional audio transmissions
boolean video: Whether the call included video transmissions
Output: double price - the price of the call.
public static double Query_Dbase(int duration, String client_name, String dest_name, int day, int month, int hour, int min,boolean islocal,boolean audio,boolean video){
Printing Out Bills:
bill {
Request userid
Request time period for bill
Query database for call log and balance information
Create text file with bill record
}
Registration Utility:
guireg {
Open frame for user input
Receive user input
Call accounting server with information
Receive userid back from server
Display userid on screen
Exit on request
}
Pricing Utility:
guiCall_Query {
Open frame for user input
Receive user input
Call accounting server with pricing informatioin
Receive price back from server
Display price on screen
Exit on request
}
7. Advice for the course staff:
CS 519 is a great course in that we implemented many practical components in networks. The project was interesting and the ability to get everything needed was an asset. Access to the machines earlier would have been beneficial to some degree.
8. References:
The Hal Varian pages that were linked to the CS519 site
This site is the one which contains the javax.net.ssl API documentation.
http://www.javasoft.com/security/ssl/API_users_guide.html
"
Internet Telephony: Architecture and Protocols an IETF Perspective" by Schulzrinne and Rosenberg.Java Database Programming by Brian Jepson, John Wiley & Sons, Inc.
Web References:
http://www.cs.columbia.edu/~hgs/internet/internet-telephony.htmlhttp://www.vocaltec.com/
http://www.viennasys.com/Industry_spl.htm
http://info.berkeley.edu/~hal/people/hal/papers.htmlhttp://ani.cmu.edu/ http://www.netbill.com/