...
When individual channels go down on a board, this is indicative of a problem of that of a protocol or communication error between the underlying layers. Generally these types of stuck channels / hung ports can be recovered by calling dx_resetch() API. If that does not get the channel back into an IDLE state, attempting to close and re-open the channel might work.
If an individual DSP (digital signal processor) goes down, this is indicative of a problem where the firmware was no longer operable in processing tasks from that particular DSP and affects only a subset of channels on the board in which that DSP was tied to. In this case the only option is to restart that board via DCM. An individual DSP on board cannot be restarted.
If the CP (Control processor) on the board goes down, this is indicative of a problem where the firmware was no longer operable in processing tasks from CP of the board and all channels go down at once. In this case the only option is to restart the board via DCM.
It is possible in some situations the dx_resetch() / close and re-open of the channel or even a restarting of the board via DCM does not work. This may still be indicative of protocol error between the underlying layers which needs to be re-established. This would require restart of system itself.
Sometimes in situations where the CPU load on the host system reaches a point where the dialogic stack is unable to schedule CPU time may result in stuck channels. Also if the available physical memory is depleted to an extent that the dialogic stack is unable to allocate necessary resources for continued operation, may also result in stuck channels.
Product List
Dialogic JCT series Media Boards