* Add error handing in mod_freetdm for ftdm trace failures
* Allow freetdm signaling modules to specify a destroy function
* Added conditional forwarding to the freetdm gsm module
Just specify the conditional-forwarding-number gsm parameter in freetdm.conf.xml
* Added new 'gsm call' freetdm command for raw GSM calls which can be
used to enable/disabling network features (e.g call *93) without
having to resort to use a full originate that requires routing the
call somewhere when answered
* Miscelaneous cleanup of piggy coding style left over by one of the
previous authors -_-
Currently only enabled in the analog e&m module but any
signaling module can easily take advantage of it with a small
modification to the signaling module to set span->sig_release_guard_time_ms
Part of my ongoing effort to split ftdm_io.c into more manageable pieces.
This change (along with others in the future) allows decoupling of the
span registry and its users, in preparation of moving all span related
functions and data structures into ftdm_span.c.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
Neither of them accepts extra arguments and ftmod_sangoma_isdn is calling
ftmod_assert() with a char * msg argument.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
Some I/O implementations (e.g. mISDN) need this information to correctly
set up the port configuration. In FreeTDM, the mode of a span has been.
up until now, a part of the signalling module configuration ("node" or "mode"
for libpri and isdn spans), which is parsed _after_ the I/O part of a span
has been initialized. This limitation currently prevents us from using mISDN
in NT mode.
To work around this problem (without adding a lot of new tunk_type values like "E1_NET" etc.),
add a new "trunk_mode" parameter to the span categories in freetdm.conf, which by default
is "CPE" for all trunk types, except "FXS" (which defaults to "NET").
ftmod_misdn uses trunk_type + trunk_mode to correctly choose the d-channel protocol
for a port.
ftmod_libpri uses trunk_mode as a hint for the default "mode" setting.
(NOTE: It will print a warning if trunk_mode and signalling mode do not match.)
All other modules currently ignore the value of trunk_mode.
Example freetdm.conf snippet for a mISDN span in NET/NT mode
(using a HFC-S USB dongle):
[span misdn MBRI_1]
trunk_type => BRI_PTMP
trunk_mode => NET
b-channel => HFC-S_USB.1:1-2
d-channel => HFC-S_USB.1:3
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
Portability fix for uClibc and other (linux) environments that lack execinfo.h.
ftdm_backtrace_walk() and related return FTDM_NOTIMPL and print a message
if backtraces are not available in the current environment.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
used to clear ckt_flags, this was wrong.
if ctk_flags are blindly cleard a PAUSE might be cleared.
changed the code to clear only TX RESET and try to reset again.
Release Collision
If we get out of sync with other side we must
reset the circuit.
This condition occoured at 1+3 test box
Local Management Block
Its possible for stack to send us a BLO indicating to us
that we are local blocked. This case never worked and
we would get stuck there forever.
If we never manaully sent a LOCAL block, the BLO from
the stack will be acked and then unblocked.
This condition occoured at 1+3 test box
* FreeTDM modules using the old FTDM_SPAN_STATE_CHANGE flag should be updated *
* until then, they are still vulnerable to deadlock situations *
* Modules pending update: (ftmod_analog, ftmod_libpri, ftmod_isdn) *
* Fixes Sangoma redmine ticket #1791 0 FTDM span stop deadlock *
* FreeTDM modules using the old FTDM_SPAN_STATE_CHANGE flag should be updated *
* until then, they are still vulnerable to deadlock situations *
* Modules pending update: (ftmod_analog, ftmod_libpri, ftmod_isdn) *
* Fixes Sangoma redmine ticket #1791 0 FTDM span stop deadlock *
libteletone headers include each other, use #include ""
to look in the local dir rather than the include search path.
Unbreaking all of my (still) external FreeTDM projects.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
addressed issue with multiple GRS at the same time in a single span
revisions merged: afcc831d6fa1fccaf7ef091b8c48b905a76d834d 9c815c9ecd7102e7d30c3988cd41682b8cbade0b
Moises Silva