This FAQ lists common questions, usually about subjects that didn't
fit well in the CINEMA Technical Report for one reason or another.
Click on the question to see its answer.
CINEMA stands for Columbia InterNet Extensible Multimedia Architecture. More information can be found on the publications page.
It combines the various server software pieces into a single architecture. Various pieces of software include
CINEMA is not a protocol but an architecture to implement various IP telephony components using the protocols like SIP, RTP and RTSP.
SIP is an open standard and any one is free to implement it. CINEMA
is an instance of one such implementation for providing SIP services.
Various components in the architecture provide (1) SIP proxy, redirect and registration, (2) Interworking between SIP and H.323, (3) audio video conferencing, (4) Instant messaging and presence, (5) voice mail service, (6) interactive voice response engine (using VoiceXML), (7) device control capability by SIP for controlling X10 devices and ncast video equipment, (8) shared web browing, (9) desktop sharing using VNC, (10) interworking with regular telephone network, (11) billing and security.
Some of these services may require use of external components. For
example interworking with regular telephone requires an external
SIP/PSTN gateway.
SIP UA (UserAgent) is a component (software or hardware) that provides an user interface to make and receive SIP calls. SIP proxies are similar to routers, that forward SIP messages from source to destination. Consider a case when Alice@home.com makes a call to Bob@office.com, then the user agent of Alice sends a SIP INVITE message to the request URI sip:Bob@office.com. There may be a SIP proxy server at office.com that receives the message and routes it to Bob's current location Bob.Wilson@pc1.cs.office.com, for example. There could be any number of intermediate proxies, and the caller may not be aware of them.
A SIP stack is a library that implements the core functionality of
Session Initiation Protocol (and sometimes also the other associated
protocols like Session Description Protocol and Real-time Transport
Protocol). A SIP stack can be used by developers to build components
like SIP user agent or proxy server. We have built a variety of
applications related to conferencing, voice-mail and signaling
gateway using out SIP stack (SIP library).
Please include the following in your bug report:
Please do not send bug report to any individual. Instead send it to
CINEMA Support.
The components of CINEMA are licensed. All licensing, including educational and research licenses, is handled by SIPquest.
Only RTSP media server is Open Source under GPL terms of service.
The license string is inserted into the database specified via
the -l commandline parameter. An example of such a string
is
example.com:2001-06-30:ff4fb120281b0eb5c6d264b6896e6b6fwhich indicates that the license expires June 30, 2001 and is valid for running the server in the domain example.com.
If you get the error
check_license: ./sipd.license:1: The local hostname "bar" does not match the domain ".edu" check_license: ./sipd.license:1: The local hostname "bar" does not match the domain ".edu.au" check_license: ./sipd.license:1: The local hostname "bar" does not match the domain ".ac.uk" check_license: ./sipd.license:1: The local hostname "bar" does not match the domain ".columbia.edu" check_license: ./sipd.license:1: The local hostname "bar" does not match the domain "foo.com"where foo is the name of your organization and bar the name of the host the software is running on, it means that your local host is not configured to report its local hostname as a fully qualified domain name. The server does a forward lookup on the locally-known hostname to get an IP address; it then does a reverse lookup to obtain a publically-resolvable name. If the name resolution is mis-configured, however, it may return the short form of the name (i.e., "bar", rather than "bar.foo.com").
Make sure that you have included the complete license string during installation. You can also check the license string in the database table sipd_license, sipum_license or sipconf_license. Make sure that the encoded text does not have any extra new line at the end. Also, make sure that the license has not expired.
sip323 uses sip323.license file for licensing. sipua uses sipua.license.
If you have enabled numeric IP address instead of host name then you will need to get the license string of the IP address.
If you are using windows platform and it does not detect your host
name as a fully qualified domain name, it will automatically switch to
the numeric IP address mode.
Starting with version 1.20, we will provide license that will be valid only upto some expiration date and the upgrades will be valid only upto some update expiration date. Beyond this date your software will not work as expected or the new upgrades will not be available to you.
The license scheme was slightly changed from version 1.19 to
1.20. All users of 1.19 should upgrade and get the new license.
Every component (sipd, sipconf, etc) has its work web-page listing
the features specific to that component. Visit the CINEMA web page for
details. This FAQ provides answers to only some of the commonly asked
questions.
The SIP proxy server, sipd, supports loop detection. It also
supports the Max-Forwards header.
Sipd can be configured to support either stateful or stateless
mode. In stateless mode, the proxy server first tries to route the
message statelessly, and if it cannot then it uses stateful mode for
that transaction. Note that a stateless mode is possible only when
both upstream and downstream use UDP and there is no forking (i.e.,
only one contact location found for the user).
Our architecture uses MySQL database server for storing contact
locations and user profile among other things. See the CINEMA
technical report for details. The SQL interface can be modified with
little effort to ODBC or some others. We also use an in-memory caching
instead of per-transaction external-database-lookup for improved
performance.
We have built a voice-mail system as a first step towards
implementing our unified messaging system, sipum. We are currently
working towards providing a communication portal environment with
support for integrated conferencing, messaging, message board, etc.
The SIP proxy server can handle upto 100 register messages per second and upto 25 invite messages (call requests) per second on a standard Sun-ultra-10 box with 90% CPU utilization at 350 MHz. A higher capacity machine will do more and we should be able to scale to a higher call capacity with a little more effort.
We have tested upto 100 concurrent calls with our SIP stack as part of the conference server performance measurement. However, it should be able to support much more than this; limited only by the memory, thread and open-file descriptor operating system resources. SIP stack used in a user-agent type of application (that handles the media stream also) has most CPU cycles spent in processing the media path. Our SIP stack is independent of the media path.
The detailed SIP conference server performace is mentioned in the paper http://www.cs.columbia.edu/~kns10/publication.
More details will be available in the CINEMA technical report.
Features and performance. Features include the things that are supported by the stack and the servers. You can take a look at the features list for individual components at their web pages. Performance of servers typically has factors like throughput, turn-around time, response time, CPU and memory utilization, bandwidth usage. We plan to measure the performance of our stack soon, and will make it available in the CINEMA technical report.
See http://www.sipstone.com for details on SIP server performance measurement
Performance usually depends on the features also. For instance, stateless proxy will be faster than stateful. But stateful proxy may be more desirable at times. CPL/cgi may take more turn-around time than a pure database lookup in sipd.
People should be careful with performance numbers. Just 100
request/second or 200 simultaneous calls does not give a very clear
picture unless details like what kind of request, what response,
whether authentication was turned on, what audio codec used, which
platform, and stuff like that are mentioned. A more specific metric
like, what's the memory footprint for 150 digest authenticated calls
per second with average holding time being 3 minutes for successful
calls and 80% of the call attempts are successful.
Intel/AMD, Sun Sparc, DEC Alpha. Porting shouldnt be too hard for
the HP family. OS: Solaris, Linux, FreeBSD, OpenBSD, Tru64, Windows
NT/98/2000/XP. Please see the web page of the specific component you
are interested in to know more about this. Some applications, e.g.,
sip323, are not available on all of these platforms.
Sipd does not care about the codecs. The SIP stack can negotiate
many different codecs using SDP. Actual codec implementation is not
part of the SIP stack. The media components in our architecture have
been tested with some of the commonly available codecs, e.g., G.711 A
and mu law at 64kb/s, DVI ADPCM at 32kb/s, GSM at 13.6kb/s and (newly
added) wide band G.722 at 64kb/s.
Sipd supports forking. If a user is located at more than one locations, then the call can be forwarded to all these locations in parallel or sequencially. We assign priorities to the different contact locations. For example if user sales@company.com, has locations rep1@pc1.company.com (preference 1.0), rep2@pc2.company.com (preference 1.0), rep3@pc3.company.com (preference 0.8), senior_rep@company.com (preference 0.3) and manager@company.com (preference 0.3) then a call to sip:sales@company.com is first forwarded to both rep1 and rep2. If they do not pick up the phone or the call fails then rep3 is tried. If rep3 also does not answer the call then it is forwarded to senior_rep and manager simultaneouly.
The forking behavior with the configurable priorities for different
contact locations can achieve fine control and automatic call
distribution.
Sipd and SIP stack support TLS/SSL. IPSec can be done as add-on as this is independent of the application layer stack.
We support the basic and digest authentication mechanism in SIP.
Media encryption is not applicable to the SIP stack or sipd
server.
Yes.
Yes.
Most of the configuration can be done from web interface. Our SIP proxy server also implements the SNMP MIB based monitoring and alert.
We provide a variety of interface for accounting: sql logging, file
based accounting and RADIUS.
stress test using the sipstone tool has been partially done (in
progress). Sipd server has undergone many SIP interoperability test
events, and has been tested under a variety of torture tests. All our
applications share the same SIP code, so the test inherently applies
to all the components.
Sip323 does not support any supplementary service H.450.x. There is
no plan to support this in near future.
An IP based conference server, like sipconf, can provide more
advanced services like web based conference control, integration with
IM, message board, web, better management of auxillary things like
meeting minutes, integration of multimedia, high quality wide band
codecs (G.722) for IP users, and so on. The list is exhaustive. Even
for pure voice calls, it may turn out to be cheaper to use the IP
conference server.
There were some inconsistency in cinema version 1.20 install.tcl on Linux. It used our installation setup which had /tmp/mysql.sock as the default socket to connect to localhost instead of the the standard mysql distribution path. There are following solutions:
Installation is automated using the install.tcl script. Please make sure that you have the correct install.tcl from the Cinema support web page. We will keep this script updated whenever we find a bug and fix it.
For Solaris or Linux if you are using Package manager or RPM then please try using the distribution without the package manager and RPM.
For windows problems please see the windows troubleshooting document.
The installation script should be able to handle the
reinstallation cases. Just enter all the parameters you entered in
the first installation. For example if you had said you do not have
mysql installed and would like to install it, enter the same for the
reinstallation even if the first installation was aborted after you
already installed mysql. The installation script will detect this and
will overwrite the files for a fresh installation.
We have not thoroughly tested our script to ungrade automatically
from version 1.18 to 1.19. We recommend that you do a fresh install.
There are many changes from 1.18, e.g., all the config files are now
part of the database.
We have not thoroughly tested our script to upgrade automatically from one version to the next. However, in most cases installing the software should take care of updating any changes in the database tables or other dependencies. We do ask you to take a back-up of the old working database files before you upgrade to a new version of CINEMA.
Usually upgrading one minor version at a time should be easy to do, e.g., from 1.19 to 1.20. Upgrading two steps at a time may not work, e.g., 1.18 to 1.20
You will need the new licenses when you upgrade, if your previous
license has expired. All users of 1.19 must get a new license string
for 1.20
Version 1.19 onwards, sipd, sipconf and sipum are all bundled as
cinema. You have to install sipd if you want sipum to work. sipconf
can work independent of sipd. Get the binary (or source) distribution
of cinema and follow the installation instruction. Future version
will allow incremental changes.
We always try to make the installation as simple and straight
forward as possible. However, to automatically detect all the settings
during installation is very tough. And one or two bugs remain here or
there, primarily because we can not test installation under all
possible configurations. If you face installation difficulties, please
send a mail to CINEMA Support.
There was a bug in the script web/PersonEdit.cgi that tried to do a
query on obsolete table column in version 1.21. The correct script
can be downloaded from here. Put
this in your web directory along with other scripts, change
the .txt extension to .cgi and rename it to PersonEdit.cgi
and give approriate permission (chmod 755 PersonEdit.cgi.txt).
If you don't want to use the auto name translation using your
password file, you should remove the -n option in the canonicalize flag
in the database table sipd_config.
There were some missing files in the released version 1.20. Please
download and uncompress the patch in your web directory. The
patch is available as v1.20patch1.tar.gz. This includes the
files js/date.js, js/setcookie.js, images/notice.gif,
images/globe2b.gif, UserNew.cgi and usermenu.tcl. Last two files have
bug fixes.
There was some compatibility problem between Linux Redhat 6.2 and
7.1. We have released a patch for this. You should be able to
download it from your downloads directory at SIP Communications Inc..
Make sure that your web server has access to Tcl 8.3 shared library. We heavily depend on version 8.3. Higher versions (e.g., 8.4) will not work.
The web scripts require certain shared libraries (e.g., libtcl8.3.so and libz.so). Your web server should have access to these shared libraries.
Check your web server log (Apache puts it in logs/error_log) and see if you can figure out why it does not work.
Your webserver should be configured to take the cgi scripts and the images from any directory. A general approach for Apache server is shown in the installation manual.
If your web server's Directory index is not set to include index.cgi then you will need to specify this in your browser. e.g., <http://your-web-server:port-number/cinema/index.cgi>.
For windows users, check if you have a directory/file C:/program
created everytime you run sipd. If yes, then it means you are using
an older version. Please contact CINEMA Support for the new version.
You will need to change your webserver's configuration file to do this. If you use the installation script for installing the webserver this will automatically be done. In Apache web server you will need to add the AddHandler directive to handle .cgi extensions as cgi-scripts.
AddHandler cgi-scripts .cgiBe sure to include this line only once in httpd.conf.
MySQL requires authentication to connect to the database. If you
had used the installation script to install the database then it
should have added the required permissions (unless you changed the
password or used a different host). In that case you can GRANT the
permissions for your host again. Be sure to use the command FLUSH
PRIVILEGES to update the access permissions. See MySQL documentation
for details.
If your installation was successful, it should send mail to the
administrator's email you specfied during installation. However, if
the web cgi script fails even before it can read that email from the
database, it will try to send mail to the default value i.e., 'root'.
You can change this default value in web/cgi1.4.3/cgi.tcl
file or you can set the cgi_debug -on in
web/where.tcl file to find out why it is failing.
Some Cisco 7960 phones cannot handle DNS names in Via
headers. Use the sipd configuration option
numeric_val to enable the use of numeric IP addresses
instead. You may need to get the license string for the IP address you
will be using, if it complains of invalid license.
The Domain configuration parameter in the configuration
file determines which requests are considered to be meant for the local
domain and thus looked up in the database. For example, for a domain
example.com having a proxy server 10.1.2.3, the parameter
should be configured as
Domain ((cs.columbia.edu) |(10.1.2.3))which tells
sipd that it should accept registrations for
the request-uri sip:cs.columbia.edu or sip:10.1.2.3.
Care is needed when cutting and pasting SIP messages using telnet.
Blank lines always acquire an extra blank when cutting and pasting,
interfering with the header/body boundary detection.
If you are getting an error message such as
Error in daemon: Invalid argument (22): unable to change uid to -1 Error in daemon: Invalid argument (22): unable to set group id -1you are running
sipd as root, but have not set the 'user'
and 'group' fields in sipd configuration. Generally it
is not a good idea (or necessary) to run sipd as
root. You should set the 'user' and 'group' fields in
sipd configuration from the web page.
For Linux, it works with glibc-2.0.7-29 and later, available from http://rufus.w3.org. glibc-2.0.7-19 and glibc-2.0.7-13 cause sipd to suffer a segmentation fault due to their lack of multithreading support. For Linux kernels 2.2 and later, the standard libraries work. You can find out your current library version with
rpm -q glibc
For FreeBSD, it works with gcc and g++ 2.95.2 or higher. gcc version 2.7.2.3 is known to cause compilation problem.
Sip323 can not be compiled with gcc 3.0 because of its dependency on OpenH323 code. You must set the CC and CXX environment variable to point an earlier version of gcc. For example, if you are using version 2.95.2 the do the following before your run configure.
export CC=gcc-2.95.2 export CXX=g++-2.95.2If you are compiling OpenH323 and Pwlib yourseld then you will need to modify pwlib/make/unix.mak to use the correct gcc and g++.
If you are facing problem compiling Sip323 on windows, then
you must search for all occurances of #include<winsock2.h>
in the Sip323 code and change it to #include<winsock.h>.
This is because the SIP library includes winsock2.h whereas the
H.323 library includes winsock.h. We could not get the H.323 library
to compile with winsock2.h.
the gateway and dialmap files are stored in the database from sipd 1.21 onwardsw. A sample screen shot of how their configuration is done is at http://www.cs.columbia.edu/IRT/cinema/doc/gateway.gif, http://www.cs.columbia.edu/IRT/cinema/doc/dialplan.gif.
The system matches dialplan or gateway rules in descending order of their priority. This means when you create rules, you should give the highest priority to the rule that you want the system to try match first, next highest to the second rule and so on.
For older version 1.20 and before: You set up the dialplan file for canonicalize (-D option) to map phone numbers to their canonical form. Then, each user should be assigned a gateway class that determines his privileges. The gateway class is maintained in the primary user table and can be edited through the web interface. Finally, the gatewaymap file determines the rewriting of tel: and telephone-number SIP URLs to SIP URLs routed to one or more different PSTN gateways. The gateway chosen can depend on the PSTN (E.164) number and the caller's gateway class.
Please see the files: sipd/gateways.sample and
tools/canonicalize/dialplan.sample for an example.
If you modify any of these files you will need to restart sipd.
Make sure that you have given the correct path for sendmail tool. On windows, sendmail is not present. So the system will not send any email notification. However it should be able to store voicemails and you should be able to view them from your web page.
Check if the sip_groups for you is set to include voicemail. You can check this from your "User Edit" web page.
The notification email template given from the page is not used in this version.
Check if rtspd is running and is using the correct
port. For example if it is running on port 8554 then you should
specify this correctly in the voice mail configuration page.
Check if sipum is running and is using the correct
port. For example if it is running on port 5070 on host
"abc.example.com", then you should have a contact
"sip:yourid@abc.example.com:5070" in your User contacts page. This
contact is added automatically when a new user signs up. If it is
absent you can create a new contact entry manually for your voice mail.
Check if your user quota is not exceeded. There are two
configuration parameters: global limit per user can be set from
voicemail config page whereas per user per message size limit can be
set from your User Edit page.
The most common way of using sip323 is to run it
using -a -r option. In this mode sip323 acts as a
gatekeeper. You can configure your H.323 client (e.g., Netmeeting) to
use this as a gatekeeper. Now you should be able to dial any sip url
(yes! a SIP URL, e.g., sip:you@your-pc) from H.323 client. When the
H.323 client asks the gatekeeper for resolving the destination
address, it forwards the call to the appropriate SIP address.
For windows installation you should have a resolv.conf
file in your server root directory (or current directory, for most
installations). This file should indicate the nameserver's IP address
that should be used for DNS look up. Contact your system administrator
to know about your name server. There is no need to include multiple
lines pointing to the same name server IP address.
This page does not describe SIP or H.323. There are other places you can look for information on these protocols. http://www.cs.columbia.edu/sip, http://www.packetizer.com, http://www.cs.columbia.edu/~hgs/rtp and http://www.cs.columbia.edu/~hgs/rtsp are some of the web sites describing the various protocols used in CINEMA.
The CINEMA Support will not answer your questions about any
protocol in general, unless it is related to this architecture. There
are other mailing lists more appropriate to discuss the protocol
issues.
Not here! See the implementation section in http://www.cs.columbia.edu/sip
If you like, you can license some of the libraries or components in
CINEMA. You can read the CINEMA Technical Report to learn our
implementation experience.
Various CINEMA components are described in the CINEMA Technical Report.
Various components are also described in different papers and
technical reports. See http://www.cs.columbia.edu/~kns10/publication
API makes sense only for the SIP library component. The SIP server
supports the standard SIP APIs e.g., CPL, and SIP-CGI.
Sipd is a SIP proxy, redirect and registration server and it can
act in either proxy or redirect mode. Other special purpose servers
(e.g., SIP-PSTN gateway, SIP-conference management server, etc) can be
built on top of our SIP library, using either the C++ API or the
standard SIP API's (CPL, sip-cgi). There is no special capabilities
needed beyond what is present the SIP stack to support such services.
Multicast: Sipd can accept multicast registration. SIP stack will be able to negotiate multicast media from version 1.21 onwards. SIP conference server is a centralized conference server that uses unicast between the server and every participant.
Conference scheduling: This is done through a web interface. The sipconf server supports both pre-established conferences and ad-hoc conferences (conference names created on-the-fly).
Sipd can also act as a presence server, and it supports SUBSCRIBE and NOTIFY messages for "SIP for presence". The libsip++ SIP library does not currently have support for these methods.
DTMF: Sipd can route any method including INFO (for DTMF support). The SIP stack does not sipport INFO currently. The in-band digit collection is in media part and does not affect the SIP stack.
Caller preference: This is in progress
PSTN interworking: Sipd understands tel: URL. The stack understands
tel: URL. All other things needed for PSTN interworking are external
to the system. Our components (sipd, sipconf, sip323, sipum) interwork
with cisco SIP/PSTN gateway and can interoperate with PSTN. They
should be able to interoperate with any SIP enabled devices.
911 emergency call support cin IP telephony an be built on top of
our SIP stack. This is not a SIP stack's function, but resides in the
application level.
The RTP library supports multiple streams. the SIP library supports
multiple concurrent calls. We have built many applications (sipconf,
sipum, sip323) that can support multiple concurrent media streams. The
SIP part of these applications implement a user-agent from a SIP's
perspective.
There are three levels at which you can use/extend/deploy the
systems. At the components level, you can use the various components
of CINEMA (e.g., sipd, sipum, etc) and provide a variety of different
IP telephony environment, for instance, campus phones, corporate IP
PBX or a IP telephony portal. At the SIP API level, you can use the
CPL or SIP-CGI APIs to program the Sip proxy server. The libsip++ SIP
stack provides an easy to use user agent library interface. You can
build your own applications on top of this SIP stack. The policy
architecture provided in the core SIP stack allows a low level control
of the SIP messages. A policy is invoked for every transaction. And
modifying the policy behavior (proxy, redirect, reject, record-route,
etc), you can extend the implementation to support new scenarios in
the core SIP stack. Currently the unknown SIP headers and methods are
ignored in the SIP stack. Future version will provide an easy to use
API to implement new functionality, e.g., to handle a new method or a
new header in a message.
SDP is part of the SIP stack. RTP library is not part of the SIP
stack, but is available with the media components like sipconf, and
rtspd.
No. H.100/H.110 is described at http://www.linktionary.com/h/h100.html
See the CINEMA webpage for this information.
TCP and TLS are two important pieces for firewall/NAT
friendliness. Our stack supports both.
No. Our products run on application layer, and application layer
need not be aware of Diffserv or MPLS. Media marking, however, can be
done as most Operating Systems seem to allow us to set the DSCP byte.
Yes. ARP and DNS are supposed natively by all Operating Systems.
No. All these non-SIP interoperability can be built on top of our
SIP stack. We do, however, have a SIP-H.323 translator built using our
SIP stack.
This is independent of a SIP/SDP stack.
This is not needed in a SIP stack implementation.
Go to CINEMA home page
