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

Reply via email to