Hi Oliver,
Oliver Wilcock wrote:
> To respond to my own ticket (#181), I patched dsp.c to disconnect on 1
> minute of silence.
>
> It occurs to me that the ticket is more of a discussion. So here I am in
> the dev list.
>
> The patch to disconnect on silence turned out to be relatively easy but it
> still leaves a lot to be desired. I also tried to document what I was
> learning about dsp.c while I was at it.
>
> The only thing my patch does is read the value of dsp->totalsilence and
> disconnect when > 60000. Of course it took me hours to figure this out...
> Sigh.
>
> It rests on an assumption about dsp->totalsilence. Here is the formal
> question:
>
> "What does a value in dsp->totalsilence represent?"
>
> And here is my attempt to answer it:
>
> int totalsilence /* duration of current silence in ms. 0 means the
> current frame was not silence. 20 means that the current 20ms frame was
> the first detected silence. Negative values are undefined. */
>
> To integrate this into callweaver it seems there needs to be a way to
> configure this "feature" from a configuration file such as zapata.conf.
>
> How would I make that happen? Should it piggy back on busydetect for
> example? At present my test occurs inside
> #ifdef BUSYDETECT
> int opbx_dsp_busydetect(struct opbx_dsp *dsp)
>
>
> Perhaps a new option "detectsilencedisconnectseconds=<number>", where the
> default detectsilencedisconnectseconds=0 means don't disconnect on
> silence.
>
> I also noted that opbx_dsp_silence would do real harm due to an
> unintialized value for len if the audio stream is not OPBX_FORMAT_SLINEAR
> (callweaver-RC-1.1.99.20070815).
>
> The other thing that my patch does which I don't like is test totalsilence
> every frame. What a waste of CPU time. How can I reduce the frequency?
> Surely silence detection and busy detection doesn't need to happen every
> frame. How can the granularity be adjusted? Perhaps once every 500 ms.
>
> The next thing I want to implement is long dial-tone detection disconnect,
> because this is the only option I have available with the traditional PBX
> I'm integrating with.
>
> And then from a larger perspective, isn't busy detection, silence
> detection and long dial-tone detection a sub-feature of call-progress
> detection...
>
> I found the call-progress code impenetrable - I also found that it doesn't
> work, as you can read in ticket 181. Any hints?
>
> I also wasted considerable time tinkering with busydetect options until I
> read the code and realized that the values I was using were completely
> ignored in callweaver-RC-1.1.99.20070815.
>
> I added some LOG_WARNING messages as follows in the hopes that it will
> reduce the amount of time wasted by fools like me:
> void opbx_dsp_set_busy_count(struct opbx_dsp *dsp, int cadences)
> {
> /* 2007Aug23 ojw Oliver Wilcock: increase transparency through warnings
> and debug messages
> */
> opbx_log(LOG_DEBUG, "dsp busy count requested: %d\n", cadences);
> if (cadences < 4) {
> cadences = 4;
> opbx_log(LOG_WARNING, "dsp busy count increased to hard coded
> mimimum of %d\n", cadences);
> } else if (cadences > DSP_HISTORY) {
> cadences = DSP_HISTORY; /* ojw: I wonder if this should be
> DSP_HISTORY/2 */
> opbx_log(LOG_WARNING, "dsp busy count decreased to maximum history
> window of %d\n", cadences);
> }
> dsp->busycount = cadences;
> opbx_log(LOG_DEBUG, "dsp busy count set to %d\n", cadences);
> }
>
> void opbx_dsp_set_busy_pattern(struct opbx_dsp *dsp, int tonelength, int
> quietlength)
> {
> #ifdef BUSYDETECT
> opbx_log(LOG_WARNING, "dsp busy pattern ignored when using #define
> BUSYDETECT\n");
> #else
> dsp->busy_tonelength = tonelength;
> dsp->busy_quietlength = quietlength;
> opbx_log(LOG_DEBUG, "dsp busy pattern set to %d,%d\n", tonelength,
> quietlength);
> #endif
> }
>
> You can see from my comment that I don't understand what DSP_HISTORY is.
> It affects the length of some arrays but why would the maximum value for
> cadences be DSP_HISTORY? I understand that there needs to be a
> relationship but wouldn't it be something like DSP_HISTORY*mystery
> unit/(busytone duration in ms + silence duration in ms)?
>
dsp.c is mostly pretty nasty, and is being replaced in stages.
If you get dial tone as disconnect tone it is probably going to confuse
the current code. dsp.c should report DSP_TONE_STATE_DIALTONE when that
happens, which will be out of sequence. Can't the meridian be configured
to send a disconnect tone?
Regards,
Steve
_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev