文件列表:

newprov\cpp\cacheLibrary\Cache.cxx (17406, 2003-05-07)
newprov\cpp\cacheLibrary\Cache.hxx (8103, 2003-05-07)
newprov\cpp\cacheLibrary\CacheListener.cxx (5450, 2003-05-07)
newprov\cpp\cacheLibrary\CacheListener.hxx (4091, 2003-05-07)
newprov\cpp\cacheLibrary\CacheManager.cxx (3823, 2003-05-07)
newprov\cpp\cacheLibrary\CacheManager.hxx (3440, 2003-05-07)
newprov\cpp\cacheLibrary\CacheStorage.cxx (9003, 2003-05-07)
newprov\cpp\cacheLibrary\CacheStorage.hxx (4395, 2003-05-07)
newprov\cpp\cacheLibrary\CVS\Entries (423, 2004-06-08)
newprov\cpp\cacheLibrary\CVS\Entries.Log (13, 2004-06-08)
newprov\cpp\cacheLibrary\CVS\Repository (39, 2004-06-08)
newprov\cpp\cacheLibrary\CVS\Root (43, 2004-06-08)
newprov\cpp\cacheLibrary\CVS (0, 2004-07-21)
newprov\cpp\cacheLibrary\Makefile (1280, 2003-05-07)
newprov\cpp\cacheLibrary\test\CVS\Entries (94, 2004-06-08)
newprov\cpp\cacheLibrary\test\CVS\Repository (44, 2004-06-08)
newprov\cpp\cacheLibrary\test\CVS\Root (43, 2004-06-08)
newprov\cpp\cacheLibrary\test\CVS (0, 2004-07-21)
newprov\cpp\cacheLibrary\test\testCache.cxx (9832, 2003-05-07)
newprov\cpp\cacheLibrary\test\testCache.log (26549, 2003-05-07)
newprov\cpp\cacheLibrary\test (0, 2004-07-21)
newprov\cpp\cacheLibrary (0, 2004-07-21)
newprov\cpp\CVS\Entries (2, 2004-06-08)
newprov\cpp\CVS\Entries.Log (59, 2004-06-08)
newprov\cpp\CVS\Repository (26, 2004-06-08)
newprov\cpp\CVS\Root (43, 2004-06-08)
newprov\cpp\CVS (0, 2004-07-21)
newprov\cpp\dataObjects\AccountRecord.cxx (12233, 2003-05-07)
newprov\cpp\dataObjects\AccountRecord.hxx (6789, 2003-05-07)
newprov\cpp\dataObjects\AliasRecord.cxx (3056, 2003-05-07)
newprov\cpp\dataObjects\AliasRecord.hxx (2020, 2003-05-07)
newprov\cpp\dataObjects\CVS\Entries (849, 2004-06-08)
newprov\cpp\dataObjects\CVS\Entries.Log (50, 2004-06-08)
newprov\cpp\dataObjects\CVS\Repository (38, 2004-06-08)
newprov\cpp\dataObjects\CVS\Root (43, 2004-06-08)
newprov\cpp\dataObjects\CVS (0, 2004-07-21)
newprov\cpp\dataObjects\FeatureRecord.cxx (6188, 2003-05-07)
newprov\cpp\dataObjects\FeatureRecord.hxx (4669, 2003-05-07)
newprov\cpp\dataObjects\Makefile (1537, 2003-06-05)
newprov\cpp\dataObjects\oldRecords\CVS\Entries (426, 2004-06-08)
... ...

==================================================================== New provisiong system README ==================================================================== Newprov Release 1.0.0 April 16th 2003 Authors: Suha Cubukcuoglu [ suhac@nplusone.net ] Colin Cameron [ colinc@nplusone.net ] nplusone [ http://www.nplusone.net ] License as below ==================================================================== LICENSE AND COPYRIGHT ==================================================================== The license applies to all software incorporated in the "Vovida Open Communication Application Library" except for those portions incorporating third party software specifically identified as being licensed under separate license. The Vovida Software License, Version 1.0 Copyright (c) 2000 Vovida Networks, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The names "VOCAL", "Vovida Open Communication Application Library", and "Vovida Open Communication Application Library (VOCAL)" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact vocal@vovida.org. 4. Products derived from this software may not be called "VOCAL", nor may "VOCAL" appear in their name, without prior written permission of Vovida Networks, Inc. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT ARE DISCLAIMED. IN NO EVENT SHALL VOVIDA NETWORKS, INC. OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT DAMAGES IN EXCESS OF $1,000, NOR FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ------------------------------------------------------------------------- This software consists of voluntary contributions made by Vovida Networks, Inc. and many individuals on behalf of Vovida Networks, Inc. For more information on Vovida Networks, Inc., please see http://www.vovida.org/. All third party licenses and copyright notices and other required legends also need to be complied with as well. ==================================================================== INTRODUCTION ==================================================================== The files in the directories under this one contain the implementation of the new provisioning system. Briefly, the system works using a SQL database backend, an interface system that allows clients to retrieve the information from the database and a generic caching system that stores accessed information locally. Updates to the database for provisioning will be done directly, using an interface to the database itself. In order to ensure that the clients caches are updated each client registers with the database to say what information is being cached. When the database changes internal database triggers are activated that send information (via a socket) to any client registered for updates to that information. As this is done as part of the database itself it means that it is safe to alter the database from any external source. Each client has a separate cache and each client also retrieves information relevant to itself. The information is retrieved as C++ objects which can then be queried in the normal way. Each of the information objects contains internally the SQL queries required to retrieve and alter that record therefore the queries (and database implementation) is hidden from the client. The client has no knowledge of the actions taken inside the caching system, and the caching system has no knowledge of the contents of the data (aside from a unique key used for indexing). Several manager threads periodically remove old cache data and ensure that the database connections are fresh. We have a test of this system running but have still to define our database structure and therefore the contents of the data objects used by each client. We also have to add code to the clients so that they use the new data objects. Our current plan is to not remove the old client code for the previous system, this will allow the clients to be compiled to work with either system -- since the data they are retrieving is essentially the same it's just the design and implementation of the database that varies. ==================================================================== NEW FEATURES IN THIS RELEASE ==================================================================== This is the first release, supported features : +) Accounts/Alias provisioning +) Support for IP Centrex functionality +) Feature provisioning (feature information such as forward-to number still read from old provisioning.) +) G729 shell for VoiceAge codec +) Hunt groups ==================================================================== BUG FIXES ==================================================================== None. ==================================================================== KNOWN LIMITATIONS ==================================================================== This implementation doesn't provision everything that vocal requires, therefore several key areas are not covered. +) No server provisioning, the location and details of each server is stored in the old provisioning system +) Limited feature support, the system still uses CPL scripts for features meaning that users will need to be provisioned in both systems (to add the CPL script). See media server info below. +) Only postgres functionality implemented. +) Assumes database is on the same machine +) Cache size limites / record exipiry time are hardcoded in CacheManager.hxx ==================================================================== TO DO / FUTURE ==================================================================== +) Fix known limitations above +) Move vocal to use media-server system, rather than feature servers. Current idea is to use the 'URL' in the database to provide the location of a PHP script that will provide the required feature interaction. This PHP script will access the other parts of the database. +) Better error handling ? Throw exceptions ? +) Allow emergency command to CacheListeners to tell them to ditch all cached information and reload it. (I.e. in the case of a network outage). +) Support for other databases, support for different database formats (i.e. having sub-classes of accounts that talk to different (non-SQL) databases). ==================================================================== GETTING STARTED ==================================================================== Other Required software ----------------------- Vocal, with the modified RS and Marshall files so they use the new provisioning system. PostgreSQL. Build / Compile --------------- Vocal parts: ------------------------- To build just the newprov cd /newprov/cpp/DBManager make; make install; cd ../dataObjects make; make install; cd ../cacheLibrary make; make install; now rebuild the RS and Marshall code ensuring that the makefile does not define OLD_PROV (which forces the use of the old system). the best way to do this is to do ./configure --with-newprov when building. ----------------------- To rebuild all of vocal Rebuild the 1.5.0 vocal as normal. -------------- Postgres parts Create a postgres user called 'vocal' and a database called 'vocal'. Ensure that the postgres user 'vocal' can connect to the database correctly and that it has the password vocal. cd /newprov/postgresTriggers make ut.so You may have to edit the Makefile to change the include directories. Now edit initTriggers.pgsql to change the path to ut.so to agree with your installation directory of vocal. Then, in postgres (i.e. psql) run the two files initTables.sql and initTriggers.pgsql. Make sure you run the initTables file as the vocal user (otherwise vocal doesn't have permission to change the files). The file populateTest.sql creates a small amount of test data. You may need to do the command 'createlang -d vocal plpgsql' in the shell first. Using the code -------------- The Cache and Record class provide the main interface to the database, the various subclasses of record provide access to different types of information. End user programs should be able to either use an existing subclass of Record or write their own. Programs using the class shouldn't really require to access the database directly. This is a rough sketch of the design we'll be using to access the database from the various clients. ==================================================================== DIRECTORY STRUCTURE ==================================================================== The Cache code lives in ./vocal/newprov/cpp/cacheLibrary Cache.cxx, Cache.hxx Singleton class that provides the main point of contact to the cache, and from there to the database. CacheManager.cxx, CacheManager.hxx A seperate thread that monitors the contents of the cache removing old data if a) the cache is too large, or b) a Record's timestamp has expired. CacheListener.cxx, CacheListener.hxx A seperate thread that is invoked whenever a client registers to listen for updates to the database. The listener removes any updated records from the cache and calls an optional call-back function in the client code. CacheStorage.cxx, CacheStorage.hxx The cache system itself. Essentally a two-dimensional hashmap. testCache.cxx A quick-n-dirty test program, usage testCache [num] where num is between 1 and 6. The data objects stored in the cache live in ./vocal/newprov/cpp/dataObjects Record.hxx, Record.cxx Abstract class that defines the basic qualities of a data record. RecordTypes.h Defines the valid record types and some typedefs. AccountRecord.cxx, AccountRecord.hxx, FeatureRecord.cxx, FeatureRecord.hxx, UpdateRegInfoRec.cxx, UpdateRegInfoRec.hxx These are the concrete implementations of the Record class, each storing a different subset of information from the database. Note: AccountRecord automatically retrieves and caches FeatureRecord objects, account record can also order feature records and return the correct list of URLs for the features. Therefore FeatureRecord may not be required in client code. Note: UpdateRegInfoRec is used internally to store the details of the clients that have registered for updates. The database management stuff lives in ./vocal/newprov/cpp/DBManager DBInfo.h, DBInfo.cxx Defines structures for storing basic information about the database DBConnection.hxx Abstract class defines the basic properties of a database connection. (In this case simple SQL queries) PGSQLConnection.cxx, PGSQLConnection.hxx, PGSQLResultset.cxx. PGSQLResultset.hxx Concrete implementation of DBConnection and DBResultSet for a postgreSQL database backend. ConnectionManager.cxx, ConnectionManager.hxx Keeps track of connections, marking which are used or not and suppling new ones on demand DBConnThread.cxx, DBConnThread.hxx Seperate thread that monitors the connections to ensure that they are all still valid and working. Postgres database setup files are in ./vocal/newprov/postgresTriggers updateTrigger.c A simple C socket implementation, this file is loaded into the database as a postgres trigger. It compiles to ut.so initTables.sql Creates the required tables in the database, except feature tables or server tables initFeatureTables.sql -- Not Complete initServerTables.sql -- Not Complete Creates tables in the database to store feature specific information and information regarding the different servers avalible. initTriggers.plsql Creates the required triggers to do the database update, contains pgsql code that is used as the main trigger. This code calls the C function in the ut.so library. dropTables.sql dropTriggers.sql Removes the tables and triggers from the sql database. Note: This is not complete as it doesn't remove sequences and other auto-generated stuff. It is useful to recreate the triggers however. ==================================================================== SOURCE CODE INFORMATION ==================================================================== You may get useful information out of Doc++, but it's probably covered equally well by the text above. G729 ---- In libmedia there are is now a CodecG729C class (and a slightly amended CodecAdaptor class). If you have VoiceAge's G729C library then place it in the libmedia directory and alter the following Makefiles libmedia\Makefile sip\gua\Makefile uncommenting the marked lines. If you have any other systems using libmedia and requiring 729 support then add similar lines to their makefiles as well. Recompile and install and restart vocal and it should all work. Hunt Groups ----------- Changes in SubscriberContainer.cxx ( proxies/rs ) enables hunt groups based on account information in the database. NOTE : the actual hunt group used is still based on CPL scripts, the hunt_* tables in the database are not currently accessed for hunt groups, they merely reflect the information coded in the CPL scripts. Database provisioning --------------------- In order for each client (RS, proxy, etc) to access data in the database we defined a set of objects. Each of these objects will encapsulate a subset of the data in the database as required by that particular client. For instance a media server would require account information and so may have a AccountRecord Object, a redirect server may have a PlanRecord Object for (Dial Plans). These objects encapsulate the information required by that aspect of the client. Each of these objects also contains the knowledge to query the database. So a AccountRecord would contain the logic required to fetch the account information from the database and also amend the information in the database. The clients access the database through an interface (Cache) that allows the following functionality. The client can request information by specifying the type of information required (i.e. the type of record object) and providing a key value (which is used to access that object). The client can amend, insert or delete records by creating a record object with the relevant information and then passing it to the amend, insert or delete method of the interface. The Cache itself simply calls the methods internal to the record objects passing them a database connection. The record objects themselves interact with the database via this connection. In the case of a client requesting a record the cache will first check its cache to see if that object exists in it. The cache itself is a hashmap using object types as its key, the data for each key being another hashmap containing the valid objects of that type (using the key provided for the object lookup). If the object is not present in the cache then a new a new object of that type will be created (using a factory class by passing the type to it) and then get that object to populate itself from the database. The Cache only deals in a Record superclass and doesn't need to know about the individual details of different records as each specific Record class implements it's own logic to communicate with the database. The Cache can also retrieve objects from the database bypassing the cache storage itself (for one-off queries) The database connections are controlled by a database manager which will maintain connections and provide them on request. It will periodically check that the connections are still active. The record object will also have a timestamp indicating when it was last used (retrieve from the cache or the database). A cache manager thread will periodically remove old cached records as the cache fills up. =================================================================== CONTACT INFORMATION AND WEBSITE ==================================================================== We welcome your feedback, suggestions and contributions. Contact us via email if you have questions, feedback, code submissions, and bug reports. For general inquiries - info@vovida.org We have mailing lists for the VOCAL applications and proctocol stacks: VOCAL - vocal@vovida.org COPS - cops@vovida.org MGCP - mgcp@vovida.org RADIUS - radius@vovida.org RTP - rtp@vovida.org SIP - sip@vovida.org TRIP - trip@vovida.org You can subscribe to the mailing lists on www.vovida.org. You can submit bug, patches, software contributions, and feature requests using Bugzilla. Access Bugzilla from www.vovida.org. ==================================================================== ======================================================================

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：