[Asterisk-Dev] UK BT Caller ID - work on new patch

[Steve Underwood]

Marc McLaughlin (LUSYN) wrote:

>Hi all,
>
>The original patch developed by Tony Hoyle was reported in Bug ID 1719.
>Modified versions of these are now available which work with v1 of *
>(download from www.lusyn.com/asterisk/patches.html).  I'm trying to come up
>with a new patch for UK BT Caller ID on X100P with the aim of it being
>accepted into CVS as a permanent fix.  
>
>Since v1 of *, which now incorporates a UK Caller ID fix which I believe was
>done by dant, I thought it would be easiest to monitor for a sample above a
>certain threshold (as Mark suggested in the bugnotes) but to then signal
>ZT_EVENT_POLARITY.  That would fire off to chan_zap.c which should extract
>the Caller ID info and then carry on with distinctive ring checks, etc.  I
>set a flag to indicate a signal has been sent, which gets cleared when
>wc->off_hook is set to 0.
>
>At the moment my modified wcfxo.c results in the following :
>
>1) Samples detected on line, ZT_EVENT_POLARITY signalled
>2) Caller ID info extracted correctly by chan_zap.c
>3) Distinctive ring checks fail
>4) Call forwarded as expected to SIP phone
>5) When hanging up and wc->off_hook set to 0, extra samples are detected
>which fires off ZT_EVENT_POLARITY again
>
>The first problem is that distinctive ring checks fail.  I remember dant
>saying in the bugnotes that he couldn't test distinctive ring with his
>Caller ID patch (which has been incorporated into CVS head).  I've found a
>simple test whether or not you have BT Call Sign (distinctive ring product).
>First of all make sure you have set "usedistinctiveringdetection=yes" in
>/etc/asterisk/zapata.conf.  If the line gets answered after the first ring
>and distinctive ring is detected as 0,0,0 then the distinctive ring
>detection is not working.  If the line gets answered after a couple of rings
>and distinctive ring is not detected as 0,0,0 (I normally get 367,*,* for
>normal ring), then distinctive ring detection is probably working.
>
>The second problem is with samples generated which are nothing to do with
>Caller ID info being sent before a call.  I can ignore the start-up samples
>which appear when wcfxo is loaded and then ztcfg'd, but the difficult bit is
>knowing when a call has closed down properly and it's safe to start
>monitoring for Caller ID info again.  Unfortunately the close-down samples
>are similar in value to the samples generated just before Caller ID.
>Thinking perhaps of checking the actual values against the Channel Seizure
>Signal (01010101 x 30).
>
>Anyone got any ideas?
>
>Rgds,
>
>Marc
>  
>
I certainly wouldn't accept your strategy if it were my CVS. Detect the 
short term energy, not just a single large sample. It will be much more 
reliable. Just use something like:

   energy += ((amplitude*amplitude - energy) >> 5);

for each sample. Its what I have been telling people to do for the last 
year. If someone had done something clean and simple like that I'm sure 
it  would have gone into CVS ages ago.

Of course, you also have some other bug as well. :-)

Steve