Hi,
We have now solved this problem. There was a bug in selecting codecs
when chan_unicall generates DTMF or supervisory tones. If anyone else is
having a similar problem with high CPU usage when running chan_unicall
try stable version unicall-0.0.2b, or test version unicall-0.0.3pre3.
They contain the fix.
Regards,
Steve
Andres Maduro wrote:
Hi,
I have recently found a bug when using Steve Underwood chan_unicall
with Asterisk 1.0.x (including 1.0.8RC)
When you place a call from a SIP phone with dtmfmode=rfc2833 or
dtmfmode=inband through MFCR2 via chan_unicall all goes well until you
press a dtmf key. When you do this, the other end hears a garbage
sound (not the dtmf tone) and cpu goes to 99.9% rendering almost
unusable the PBX. If there are more than 2 calls, audio start to get
choppy, more calls renders unusable the pbx.
If you hangup the calling extension, almost all the time it returns to
normality, if there is a moderate load on the * server, the only way
of shutting down * is by killing -9 it.
I have been working this with Steve and have reported this finding today.
If you have any suggestion in which things could be tweaked in
chan_sip.c, chan_zap.c or chan_unicall.c in order to see if this bug
could be solved, I will be happy to test it.
Any additional info you may require please let me know.
Regards.
AM.
_______________________________________________
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
