[asterisk-dev] CallerID issue using DTMF on 1.2

[Stelios Koroneos]

First of all, Merry Christmas and happy holidays !

I am facing a rather strange issue with the CallerID generated by an FCT
device (GSM gateway) that is connected to zap channel (Digium 4 port )
on * using 1.2.31 and zaptel 1.2.27
The device is sending the callerid as dtmf between the 1st and 2nd ring
but i get the following error

    -- Starting simple switch on 'Zap/1-1'
Dec 28 00:07:29 ERROR[3896]: callerid.c:276 callerid_feed: fsk_serie
made mylen < 0 (-1)
Dec 28 00:07:29 WARNING[3896]: chan_zap.c:6627 ss_thread: CallerID feed
failed: Success
Dec 28 00:07:29 WARNING[3896]: chan_zap.c:6671 ss_thread: CallerID
returned with error on channel 'Zap/1-1'
    -- Executing Wait("Zap/1-1", "5") in new stack
Dec 28 00:07:29 DEBUG[3896]: chan_zap.c:4001 zt_handle_dtmfup: DTMF
digit: 9 on Zap/1-1
Dec 28 00:07:29 DEBUG[3896]: chan_zap.c:4001 zt_handle_dtmfup: DTMF
digit: 1 on Zap/1-1
Dec 28 00:07:29 DEBUG[3896]: chan_zap.c:4001 zt_handle_dtmfup: DTMF
digit: 0 on Zap/1-1
Dec 28 00:07:29 DEBUG[3896]: chan_zap.c:4001 zt_handle_dtmfup: DTMF
digit: 5 on Zap/1-1
Dec 28 00:07:31 DEBUG[3896]: chan_zap.c:4907 __zt_exception: Exception
on 14, channel 1
Dec 28 00:07:31 DEBUG[3896]: chan_zap.c:4092 zt_handle_event: Got event
Ring Begin(18) on channel 1 (index 0)
Dec 28 00:07:32 DEBUG[3896]: chan_zap.c:4907 __zt_exception: Exception
on 14, channel 1
Dec 28 00:07:32 DEBUG[3896]: chan_zap.c:4092 zt_handle_event: Got event
Ring/Answered(2) on channel 1 (index 0)
Dec 28 00:07:32 DEBUG[3896]: chan_zap.c:4441 zt_handle_event: Setting
IDLE polarity due to ring. Old polarity was 0
Dec 28 00:07:34 DEBUG[3896]: pbx.c:1548
pbx_substitute_variables_helper_full: Function result is '"" <>'
    -- Executing NoOp("Zap/1-1", "CALLERID="" <>") in new stack
Dec 28 00:07:36 DEBUG[3896]: chan_zap.c:4907 __zt_exception: Exception
on 14, channel 1
Dec 28 00:07:36 DEBUG[3896]: chan_zap.c:4092 zt_handle_event: Got event
Ring Begin(18) on channel 1 (index 0)


As you can see * does capture part of the callerid (which is 2114019105
in this case) but misses the rest of it (last 4 digits in this case).
I captured (using ztmonitor) the stream and got a better view of what is
send as caller id.

After the 1st ring ends, there is a 640ms delay before the dtmf starts.
Dtmf pulses have a length of 84ms and there is inter-digit delay of
120ms

Some screen captures are here
http://twitxl.com/storage/aaaato/full-15304865542172019340.png
http://twitxl.com/storage/aaaatp/full-392697349669633878.png
http://twitxl.com/storage/aaaatq/full-33874008803478352278.png

(The actual stream is available if someone wants is also)

The same device if connected to a classical pbx gets the callerid
correctly but if connected to normal analog phones, there is a 50-50
chance the callerid would work,depending on the maker of the phone. 

My first take on this, is that the device takes too long to send the
caller id and * callerid routine "times out".
(That would also explain why the clasic pbx that uses hardware dtmf
detection gets the callerid right)

The question is, if there is a way to extend the time asterisk waits for
the callerid without effecting the other zap lines that are using fsk?

Also is there a standard for dtmf callerid ?
>From what i have read, there are several standards regarding dtmf
callerid depending on country, so what's the most common one ?

If something like that exists i can send it to the device maker and ask
them to comply with it


Thanks for your time.

-- 
Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence

Tel +30 210 9858296 Ext 100
Fax +30 210 9858298
http://www.digital-opsis.com