Chia-Lin
Young
Columbia University
New York, NY 10027
USA
cy167@columbia.edu
Abstract
Introduction
Background
Program Flow
Program Documentation
Reference
Extend the base SIP client with the capability of handling user control
information in REGISTER payloads, including upload CPL and XML file testing. And provide users a simple
interface to edit those calling controls.
All my work is based on Xiaotao Wu's sipc client program. And it totally follows the internet-draft: draft-lennox-sip-reg-payload-00 (March, 2000) and draft-lennox-sip-reg-payload-01 (October 2000). In the first version, there are Content-Purpose and Content-Action headers to tell the server side my uploading script type, which can be script or sip-cgi, and action, which can be add or delete. But in the later version, the headers that were mentioned above are changed to Content-Disposition and two other new headers also are added, which are Accept-Disposition and If-Unmodified-Since. So, my work is mainly to implement those headers functions in the sip client, store the exchanging information between sip client and server. And, before uploading the calling control files, it test the validation of the XML or CPL file stored in the content.
When the user wants to make a new registration, there is a register GUI window. I added a CPL frame, titled "Upload services", to this window. In the frame, there are simply two components: a textbox, "File Name", that indicate the name of the local file that is used to upload to server; and a button, "Browse", that the user can use it to select the file in open file dialog. Besides, I add a "Remove Services" button in the button frame. When pressing, it will send the REGISTER request to server with remove action for both Script and SIP-CGI controls.
Besides, I provide the simple user interface for users to edit the calling controls they want, if the user assigned no external editor or the external editor assigned can't work. When pressing "Save" button, it will show a file save dialog so that the user can choose or type the file name he/she wants to store; when pressing "Close", the modified content won't be saved and the old content will be stored as the upload content. When pressing "Cancel" button, the content won't be saved and neither will the file name.
In draft-lennox-sip-reg-payload-01, there are three new headers added to SIP. They are: Content-Disposition, Accept-Disposition, and If-Unmodified-Since.
Content-Disposition header is used to describe the intended purpose
of the uploading call controls, like the content type, to add or remove the
controls, or the time information.
As defined in the draft:
Content-Disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-param )
disposition-type = "script" | "sip-cgi" | token
disposition-param = action-param | modification-date-param | generic-param
action-param = "action" "=" action-value
action-value = "store" | "remove" | token
modification-date-param = "modification-date" "="
quoted-date-time
quoted-date-time = <"> SIP-date <">
There are three parameters in Content-Disposition that I had to set up, which
are disposition-type, action-value, and quoted-data-time.
For disposition-type, I can simply know it by the upload file's extension name,
like .pl, .xml, or .cpl. If it's .xml or .cpl file, this parameter will be
"script". Otherwise, it will be "sip-cgi". Besides, when Remove
Services button is pressed, two register requests are sent to server and their
disposition-type will be "script" and "sip-cgi". Because,
in the sipd server, script and sip-cgi controls are stored separately, we have
to request sipd to remove them separately.
For action-value, it always is "store" when REGISTER button is
pressing and there is upload file name indicated in file name textbox. It'll be
"remove" when the Remove Services button is pressed.
The SIP-date format, in quoted-date-time, is like: Sat, 29 Oct 1994 19:43:31
GMT. And all the modification-date is set to the upload file's last
modification time.
Accept-Disposition header is used to indicate what types of
disposition is acceptable on the server or the client side.
Accept-Disposition is always set to SIP-CGI right now, since we can not handle
the CPL files on the client side.
If-Unmodified-Since header is used to make a request condition. If
the control information stored in the server has not been modified since the
time specified in this header, the request will perform. Otherwise, server must
return 412 Precondition Failed responses and do nothing.
If-Unmodified-Since is set to the current time that the request is made. Since
we don't need it now, set it to the current time just makes it always ignored.
Besides those new headers, Content-Type and Content-Length headers
in SIP are also used.
Content-Length is used to present the length of the content.
Content-Type is used to present the type of the content. We tell the upload
file type by its extension file name, like .pl for perl file, .xml for XML
file.
Gui_Editor.tcl is
modified from Gui_Monitor.tcl.
I added TclXML
package to sipc in order to add the XML file check function. There are two XML
parsers in this package, which are TclExpat and TclXML. I use TclXML parser,
because it is a pure-Tcl implementation and it has some additional functions.
1. When Browse
button pressed:
if (Browse button pressed) {
open file dialog
user choose the local file to upload
if (preferred external editor works) {
open file with preferred external editor
}
else {
open file with gui_editor
}
put local file name in File Name textbox
}
2. When REGISTER
button pressed, and file name in File Name textbox exists:
if (REGISTER button pressed) {
if (File Name textbox is not empty) {
switch (local file extension name) {
case "pl":
set headers:
Content-Disposition =
Content-Disposition :
disposition-type = "sip-cgi"
action-value = "store"
modification-date-param = file modification time
Accept-Disposition = "sip-cgi"
If-Unmodified-Since = currant time
Content-Type = application/perl
case "xml":
use TclXML parser to check xml
file
if (number of error != 0) {
return error
}
set headers:
Content-Disposition =
Content-Disposition :
disposition-type =
"script"
action-value =
"store"
modification-date-param = file
modification time
Accept-Disposition = "sip-cgi"
If-Unmodified-Since = currant
time
Content-Type = application/xml
case "cpl":
if (the first two lines are not
CPL format) {
return error
}
use TclXML parser to check xml
file
if (number of error != 0) {
return error
}
set headers:
Content-Disposition = Content-Disposition :
disposition-type =
"script"
action-value =
"store"
modification-date-param = file
modification time
Accept-Disposition =
"sip-cgi"
If-Unmodified-Since = current
time
Content-Type = application/cpl+xml
case "txt":
set headers:
Content-Disposition = Content-Disposition :
disposition-type = "sip-cgi"
action-value =
"store"
modification-date-param = file
modification time
Accept-Disposition =
"sip-cgi"
If-Unmodified-Since = currant
time
Content-Type = application/text
default:
return error
}
if (no error) {
send REGISTER request
}
}
3. When Remove
Services button pressed:
if (Remove Services button pressed) {
set headers:
Content-Disposition =
Content-Disposition :
disposition-type =
"script"
action-value = "remove"
send REGISTER request
set headers:
Content-Disposition =
Content-Disposition :
disposition-type =
"sip-cgi"
action-value = "remove"
send REGISTER request
}
Gui_Editor should
add more function to be like a better editor, like undo. But since it's only a
temporary editor if the user doesn't assign the proffered external editor or
the assigned external editor doesn't work. So I think the current function is
enough, and the additional features implementation should be up to the
definition of the assigned external editor and our default editor.
There should be
more upload content check function for various files. We can only test the XML
validation for XML and CPL files, and check the first two lines in CPL files if
they are <?xml version="1.0" ?> and <!DOCTYPE cpl PUBLIC
"-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd">. But we
can not know if it is a valid perl or text files.
More error response
handling for calling controls upload should be added. We can handle 412
Precondition Failed error responses now.
Last updated: 2000-12-19