[asterisk-dev] CallerID issue using DTMF on 1.2

[Will]

On Mon, Dec 28, 2009 at 2:42 AM, Stelios Koroneos <
skoroneos at digital-opsis.com> wrote:

> 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
>
> This sounds a lot like an asterisk-users list type of problem.  I find it
odd that you don't get any of the digits at all in the noop.  Make sure you
have cidsignalling set to dtmf in zapata.conf for that line.  You should
pursue this further on the asterisk-users list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20091228/b787f6d5/attachment-0001.htm