Hi
I've just commited a small patch to the bristuff-part-dahdi-all branch
that seems to fix some deadlock cases with PRI in chan_zap/chan_dahdi.
While testing it, I have encountered the following apparantly buggy
situation. I was trying to stress channel generation on a PRI link.
I had two systems connected over PRI. The system I stressed was the
network side. In one of the tests I generated pairs of calls:
asterisk -rx 'originate Zap/g1/<loopnum> application playback
call-quality-menu' &
asterisk -rx 'originate Zap/g1/<loopnum> application playback
call-quality-menu' &
Thus it generates two calls almost at the same time. the number
'<loopnum>' on the remote side goes to Dial(Zap/g1/<anothernum>) .
As you can see, both use 'g' and hence start at the bottom. I would
expect such that each call would generate a pair of b-channels. The
result, however, was that each such pair of calls seem to cancel each
other for some reason:
[Sep 8 11:47:24] WARNING[3401] chan_dahdi.c: Ring requested on channel 0/1
already in use on span 1. Hanging up owner.
Why would this happen?
--
Tzafrir Cohen
icq#16849755 jabber:[EMAIL PROTECTED]
+972-50-7952406 mailto:[EMAIL PROTECTED]
http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir
_______________________________________________
Bristuff-users mailing list
[email protected]
http://lists.three-dimensional.net/mailman/listinfo/bristuff-users
