From previous commit, failed to clear the done flag _DN
which cause SUSPEND to think that there was a block
pending, causing state to remain in RESTART
S UP -> relay down -> Tx AIS -> relay up -> Tx AIS off
-> confirm all back up
-> In this condition BLO will not go out due to PAUSE
S UP -> Tx AIS -> relay down -> Tx AIS off -> relay up
-> confirm all back up
-> In this condition UBL will not go out due to PAUSE
Visually status of channels will only be DOWN once all resets/blocks are cleared.
Therefore if any reset/block is active on a channel, the channel state will be in RESTART not DOWN.
Logic Change
SUSPENDED
-> Originally used as intermediate state. Purpose is to handle a condition
from any state and go back to the previous state.
Conditions: such as block/ucic.
-> Updated logic is that SUSPEND will be smart enough not to
go back to just any state. SUSPEND will only go back to
UP - if call is still up
RESTART - if for any reason singaling is not up due to
blocks/resets/etc...
DOWN - if signaling is UP - no resets/blocks
In this case we avoid infinite loops due to state jumping
from STATE->SUSPEND->STATE->SUSPEND
HANGUP_COMPLETE
-> If call is in use and a RESET comes on a call
the RESTART state will first try the HANGUP_COMPLETE state.
HANGUP_COMPLETE will Tx RSC and wait for it.
Reset Response handle was updated if current state HANGUP/HANGUP_COMPLETE
go back to RESTART state. Which will call HANGUP COMPLETE due to
channel in usage and HANDLE_COMPLETE will clear RESET condition and go back to DOWN
TERMINATING
-> This state is used to hangup a call. Sends a signal to FS.
-> Usually TERMINATING state stays in TERMINATING until FS comes back.
-> I added a condition in case of RESET on the line though TERMINATING
will go back to RESTART.
This allows us to process RESET commands even though we are
in the middle of hanging up.
Block Handler
If BLO is received on circuit is already blocked,
we failed to trasmit BLA. We should always ack the BLO
even though it was alrady in blocked state.
Fixed & Tested
S UP --> place call --> relay down --> hangup --> relay up-->
Confirm that call is hungup properly.
In this condition, on relay up the circuit is put into RESET.
Since circuit is still in use, it will HANGUP first, then RESET
then clear pending BLOCK.
S UP --> place call -> Tx RSC on call.
Used to cause infitie loop
Confirm call is cleard properly
Re-Tested
S UP --> place call -> Rx RSC on call
Confirm call is cleard properly
S UP --> place call -> Rx BLO -> hangup -> place call
Confirm call cannot be placed
Tx UBL
Confirm call can be placed
S UP --> place call -> Rx BLO -> Tx BLO -> hangup -> place call
Confirm call cannot be placed
Tx UBL
Confirm call cannot be placed
Rx UBL
Confirm call can be placed
S UP --> place call -> relay down --> Rx BLO on channel from telco
--> relay up
Confirm that relay detects the BLO channels even though relay was down
Tx AIS -> S Start -> Confirm HW block -> Tx AIS off
-> Confirm hw block clear and UP
S UP -> Tx AIS -> Confirm HW block -> Tx AIS off
-> confirm hw block clear and UP
S UP -> relay down -> Tx AIS -> relay up -> Tx AIS off
-> confirm all back up
-> In this condition BLO will not go out due to PAUSE
S UP -> Tx AIS -> relay down -> Tx AIS off -> relay up
-> confirm all back up
-> In this condition UBL will not go out due to PAUSE
M UP -> S UP
M Down -> S UP -> M UP
M UP -> S UP -> relay down -> relay up
M UP -> S UP -> Kill M -> M UP
M Up -> S UP -> relay down -> M link down -> relay up -> M link up
Redmine Bug#1966
IAM ->
<-REL
<-ACM
<-ANM
ACM sets the reset flag
ANM sets the group reset flag
when both reset flags are set we got into infinite loop
No more "invalid span", now it's either "'foo' not a libpri span" or
"'foo' span not found" which makes it a lot more useful.
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
src/ftmod/ftmod_sangoma_ss7/ftmod_sangoma_ss7_handle.c
cc1: warnings being treated as errors
src/ftmod/ftmod_sangoma_ss7/ftmod_sangoma_ss7_handle.c: In function
'handle_con_ind':
src/ftmod/ftmod_sangoma_ss7/ftmod_sangoma_ss7_handle.c:255: warning: format '%x'
expects type 'unsigned int', but argument 3 has type 'U32'
make[6]: *** [ftmod_sangoma_ss7_la-ftmod_sangoma_ss7_handle.lo] Error 1
cpg_on_progress_media is default to TRUE if not xml option exists.
transparent_iam_max_size added to ccspan. Gloal value is used
if transparent_iam_max_size is not in ccSpan.
Fixed hw alarm handling: physical ids were not used which caused alarms
read wrong.
Tested sip hold
Group blocks/unblock
Group reset
Link down-> block -> unblock
FS start with link down then link up
FS start with link up, take link down and up -> make incoming call
This fixes a "AX_COMPILER_VENDOR: command not found" error on
systems with older autotools versions (CentOS 5.x in this case).
Not a problem on newer auto* toolchains, they either ignore
acinclude.m4 completely or handle it in a different way.
(In fact, acinclude.m4 is not even needed for the one on CentOS 5,
but we'll keep it for now.)
Tested-on: CentOS 5.7 x86_64 autoconf 2.59 / automake 1.9.6 / libtool 1.5.22
Tested-on: Gentoo 20111031 x86_64 autoconf 2.68 / automake 1.11 / libtool 2.4
Signed-off-by: Stefan Knoblich <stkn@openisdn.net>
