[asterisk-dev] Q.921 strange behaviour

[Tony Mountifield]

While doing some testing of a PRI-sniffer I am working on, I discovered
some strange operation at the Q.921 level that didn't seem right.

Just a bit of background first:

My test setup is a PC containing a TE405P, currently running
zaptel-1.2.21, libpri-1.2.5 and asterisk-1.2.24.  I am running E1
EuroISDN with spans 1/2 set to CPE and spans 3/4 set to NET. Using E1/T1
crossover cables, span 1 is connected to span 3 and span 2 to span 4. I
can make calls from one span to another with no problems.

The span 1 to 3 connection goes via a breakout box which in turn is
connected to a Sangoma A102 (2-port E1) in high-impedance mode, enabling
both directions of the link to be sniffed. The sniffer system with the
Sangoma card is not running asterisk, but a custom app, which uses parts
of libpri to understand the D-channel traffic received from the wanpipe
sockets.

Now to the observed behaviour:

Today, the Asterisk system appears to be running normally. When idle,
every 10 seconds the CPU port sends an RR, and in response receives
an RR from the NET port.

However, yesterday, the Q.921 layer appeared to have got into a strange
state where both sides were sending and receiving RR frames every few
milliseconds.

This did not seem to stop the signalling of actual calls, which could
still be made, but it certainly made the logger work hard!

Looking at one of the log files from the passive monitor, it appears
that it got into this state after being required to do Q921
retransmissions in response to a REJ packet. The asterisk box is rather
under-powered (533MHz celeron), and when the D-channel decided to send
a burst of RESTART messages, the receiving process seemed to miss the
occasional frame, and so sent a REJ when it got the I-frame after the
one it was expecting. Even though the wanted frame was correctly
retransmitted, the RR-storm continued for ever.

All the above was observed by the passive monitor, not by using pri
debug on the Asterisk.

Has this behaviour been observed before, and perhaps fixed in later
versions of asterisk and/or libpri? I can try testing later versions,
but was wondering if such an issue had been knowingly corrected.

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org