From b7f198ba18e877c2f47c028092118ee2076c4179 Mon Sep 17 00:00:00 2001 From: Moises Silva Date: Sat, 27 Feb 2010 18:47:19 +0000 Subject: [PATCH] added boost-tasks.txt old doc, it might be useful later git-svn-id: http://svn.openzap.org/svn/openzap/branches/sangoma_boost@1043 a93c3328-9c30-0410-af19-c9cd2b2d52af --- .../ftmod/ftmod_sangoma_boost/boost-tasks.txt | 146 ++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 libs/freetdm/src/ftmod/ftmod_sangoma_boost/boost-tasks.txt diff --git a/libs/freetdm/src/ftmod/ftmod_sangoma_boost/boost-tasks.txt b/libs/freetdm/src/ftmod/ftmod_sangoma_boost/boost-tasks.txt new file mode 100644 index 0000000000..f0eab3a277 --- /dev/null +++ b/libs/freetdm/src/ftmod/ftmod_sangoma_boost/boost-tasks.txt @@ -0,0 +1,146 @@ +== General Design == + +NBE will do its current loading of spans and configuration process through Sangoma Board Manager (SBM). +After doing SangomaBoardManager::getInstance().configure -> start. It will proceed to initalize +the openzap stack (just as the TelesoftStack is loaded after starting SMB. The procedure will be: + +- create a static or malloced zap_io_interface_t +- call zap_global_set_logger with the logging hooks. +- call zap_global_set_memhandler() with the memory hooks. +- call zap_global_init() to initialize the stack +- call zap_add_io_iface() to add the I/O iface. +- iterate over all SBM spans configured for BRI or any boost-managed signaling and: + * call zap_span_create(NBE I/O mod, in_ptrSpan, SMB span name) + * Fill in some members like: + span->trunk_type = E1/T1/J1/FXO/FXS etc ... + * iterate over all channels in SMB span and: + * zap_span_add_channel(zap_span, sock, type:CAS|BCHAN|DCHAN|ETC) + * call zap_configure_span("sangoma_boost", span, sigmsg_callback, "param1", value1, "param2", value1 ...) + * zap_span_start(span); + + +At this point, NBE would receive signaling msgs via sigmsg_callback registered when configuring +and NBE would request hangup or making calls throug openzap API, like zap_set_state_* and zap_channel_outgoing_call() to place calls. + +When NBE wants to check for link status. + + zap_get_siglink_state() which would return + ZAP_SIG_STATE_UP (D-chan UP, R2 bits in IDLE, ss7?) + ZAP_SIG_STATE_SUSPENDED (D-chan in power saving mode?) + ZAP_SIG_STATE_DOWN (D-chan down, R2 bits in blocked, ss7?) + + Whenever a state in sig link changes, the sigmsg_callback will be used to notify NBE or any other user. + +NOTE: right now hardware alarms notification in openzap is seriously broken, +see ozmod_libpri.c process_event ... reads an event from hardware (zap_event_t *), +then checks the event type, if its ZAP_OOB_ALARM_TRAP prepares a zap_sigmsg_t +(signaling event) setting its event_id to ZAP_OOB_ALARM_TRAP, which is *WRONG* +because event_id is of type zap_signal_event_t and not zap_oob_event_t! +this means on alarm the user will get ZAP_SIGEVENT_PROGRESS_MEDIA!! which is +value 7 that is in conflict with ZAP_OOB_ALARM_TRAP, I think a separate +callback should be used if the outside user wants to be notified about +hardware events like HW DTMF or so. Currently there is alreadya generic DTMF +listener. + +== Tasks Stage 1 / OpenZAP and Boost changes (To be tested with FreeSWITCH) == + +- Change malloc and other mem functions in openzap + to use internal hooks provided via zap_global_set_memhandler() + which would be called before zap_global_init(), this is + already done for the logger via zap_global_set_logger() + + question: should the mem routines allow for memory pool ptr? + this could be useful to provide a memory pool to + the whole module. + + question: should we allow hooks for threads and locking? + I think we can skip this one unless needed. They already + use their own threading abstraction which is working for + Linux and Windows. If we ever need to profile threading + we can add profiling hooks. + + question: I had to add openzap calls to the hash table and libteletone implementations, is that acceptable? + +- Modify zap_global_init() API + + This API must just initialize vars, mutexes etc. + and NOT DO ANY CONFIGURATION LOADING, PARSING, SPAN CREATION and I/O + configuration, which is what is currently doing. + We don't want zap_global_init() to create the spans based on that configuration + since NBE will have its own configuration and will take care of creating + the needed data structures on its own. + +- Add new zap_std_io_config() API + + This API will parse the standard openzap.conf module and create the spans. + This will be used by FS but not by NBE, which will create the openzap spans by itself. + The NBE flow to initialize openzap will be: + +- Add new API zap_global_add_io_iface(), + + This API will add a new I/O interface structure to the internal openzap hash of I/O structs. + This is needed because NBE I/O structure will NOT be loaded from an openzap module (.so/.dll) + but rather just registered on runtime (probably from a static structure in NBE code). + This openzap hash is used by zap_api_execute() for example, to find the module that can + handle a given API, ie (oz libpri status). This is an example of how an openzap I/O interface + can decide to implement just the ->api() member to handle commands and NOTHING else, + so I/O interfaces not necessary are hardware-related. + +- Add new zap_channel_get_siglink_state(zap_channel, zap_siglink_status_t &status) + +- Modify mod_openzap.c to read proto= setting in boost spans, this will determine wich boost sig + module will handle the configuration and those channels. + + + + Then as first config arg to zap_config_span() the boost proto module name would be included as "sigmod" which will be used + by ozmod_sangoma_boost to decide which sig module must handle that span configuration + +- Create minimal boost mod interface. + + ozmod_boost_ss7 should load sig boost mods and get interface via dlsym(boost_get_interface) boost_get_interface(boost_iface); + The boost interface will have + * const char *name // boost sigmod name (brid,ss7d) + * set_write_boost_msg_cb(callback) // tell the stack how to send us boost messages + * set_sig_status_cb(callback); // tell the stack how to notify us about link status changes + * write_boost_msg(struct boost_msg) // send a boost msg to the stack + * configure_span(zap_span_t span, "configuration", value, "configuration", value) // configure a given span + * get_sig_status(openzap_sigstatus_t status) + * start(span) // to start a given openzap span + * stop(span) // to stop the stack on a given openzap span + +- Migrate current sangoma_brid sig module to openzap + * Make sangoma_brid a library + * Move from using malloc, threading, locking, logging and I/O to openzap functions. Export the boost sigmod interface and its supporting code. + +== State 2 Tasks == + +- Create the I/O NBE interface and supporting functions. It must be possible to poll over the span + given that ozmod_sangoma_boost BRI module and others may need to *wait* for data. The poll() + function in I/O NBE interface would wait on a pthread condition or Windows event, which would + be triggered by some external NBE component registered with Sangoma Board Manager (SMB) for d-chan + data, whenever d-chan data arrives, saves the data in a buffer and triggers the condition to wakeup + any waiter, then the waiter (sangoma_brid or any other boost client) calls zap_channel_read which calls + our own I/O NBE interface read method and retrieves the data from the buffer. + + Dropped alternative design: + Another option is to add a new API zap_span_push_incoming_data(span/chan, data); However this changes + the model openzap has followed and I don't think fits that well, since now we have 2 different models + to support in openzap. + +== TODO == + +- how about logging specific modules, like, just ozmod_boost, or just the BRI stack? + more work to be done so the BRI module uses zap_log instead of current syslog + then work to be done to be able to filter logs from specific openzap code? is it worth it? + +- remove FORCE_SEGFAULT from sprid + + +=== Shortcomings == + +- we had to drop smg support in the branch where we work on sangoma prid. + After all, most people using sangoma_prid is using freeswitch/openzap and not Sangoma Media Gateway + The problem is in freeswitch/openzap mode, sangoma_boost ozmod takes care of span events (POLLPRI) + where in SMG and Netborder POLLPRI is done typically by sangoma board manager. +