Q.921 just says to log the condition and carry on as if it did not happen.
I guess you mean: carry on if it happened (and don't care any more).
It does not say what to do
about it.
It seems that making some calls makes these error messages go away. I am going to write a test
script that monitors the log file for the message and triggers a call if one occurs. Then I'll
see whether my hypothesis is correct.
The condition is likely to happen when the Q.921 peers are out of sync with
each other. When
you reboot your machines, they will be out of sync with each other for awhile.
It doesn't happen all the time, though. I have skimmed, but not studied, the Q.921 ITU specs
already, and for synchronization it may be necessary that libpri is active (essentially getting
* to run ASAP after starting the machine) and that just starting the driver (wanrouter in my
case) is not sufficient to sync the cards. I have to test this, but the idea is that letting the
cards communicate without some higher level support from libpri may be responsible for the error
condition.
I cannot think of a
particular sequence of events off-hand where it would happen though.
I'll keep watching for whatever might trigger the error condition.
jg
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
