[asterisk-users] Asterisk 1.8.20 AGI function SAY DATETIME does not play anything when mode in say.conf is changed to "new"

[Matthew Jordan]

On Tue, Jul 2, 2013 at 11:03 AM, Amit Patkar | ATPL <amit at avhan.com> wrote:

>  Hi Matt,
>
> As required, please find DEBUG trace for datetime function. I have used
> this function in Dialplan to capture DEBUG trace. I hope, this can help us
> in resolving the issue.
>
> [Jul  2 15:54:44] DEBUG[2698] chan_sip.c: Checking device state for peer
> 1001
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: Changing state for SIP/1001 -
> state 2 (In use)
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: device 'SIP/1001' state '2'
> [Jul  2 15:54:44] DEBUG[2737] pbx.c: Launching 'Answer'
> [Jul  2 15:54:44] VERBOSE[2737] pbx.c:     -- Executing [6666 at avhan:1]
> Answer("SIP/1001-00000000", "") in new stack
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: No provider found, checking
> channel drivers for SIP - 1001
> [Jul  2 15:54:44] DEBUG[2698] chan_sip.c: Checking device state for peer
> 1001
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: Changing state for SIP/1001 -
> state 2 (In use)
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: device 'SIP/1001' state '2'
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: SIP answering channel:
> SIP/1001-00000000
> [Jul  2 15:54:44] DEBUG[2737] res_rtp_asterisk.c: Setting the marker bit
> due to a source update
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: Setting framing from config on
> incoming call
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: ** Our capability: 0x4 (ulaw)
> Video flag: True Text flag: True
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: ** Our prefcodec: 0x0 (nothing)
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: -- Done with adding codecs to SDP
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: Done building SDP. Settling with
> this capability: 0x4 (ulaw)
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: Trying to put 'SIP/2.0 200' onto
> UDP socket destined for 192.168.2.18:7490
> [Jul  2 15:54:44] DEBUG[2734] app_queue.c: Device 'SIP/1001' changed to
> state '2' (In use) but we don't care because they're not a member of any
> queue.
> [Jul  2 15:54:44] DEBUG[2734] app_queue.c: Device 'SIP/1001' changed to
> state '2' (In use) but we don't care because they're not a member of any
> queue.
> [Jul  2 15:54:44] DEBUG[2734] app_queue.c: Device 'SIP/1001' changed to
> state '2' (In use) but we don't care because they're not a member of any
> queue.
> [Jul  2 15:54:44] DEBUG[2722] chan_sip.c: = Looking for  Call ID:
> YjNlMjU5YTJlMmQ5Njc3YjQ1MDgyMDg3ZjI1ZDViMmY. (Checking From) --From tag
> 226b515a --To-tag as6e727cd7
> [Jul  2 15:54:44] DEBUG[2722] chan_sip.c: **** Received ACK (6) - Command
> in SIP ACK
> [Jul  2 15:54:44] DEBUG[2722] chan_sip.c: Stopping retransmission on
> 'YjNlMjU5YTJlMmQ5Njc3YjQ1MDgyMDg3ZjI1ZDViMmY.' of Response 2: Match Found
> [Jul  2 15:54:44] DEBUG[2737] pbx.c: Launching 'DateTime'
> [Jul  2 15:54:44] VERBOSE[2737] pbx.c:     -- Executing [6666 at avhan:2]
> DateTime("SIP/1001-00000000", "1365120000,,YBd") in new stack
> [Jul  2 15:54:44] DEBUG[2737] app_playback.c: string
> <datetime:YBd:201304050530.00-5- 94> depth <0>
> [Jul  2 15:54:44] DEBUG[2737] app_playback.c: try
> <datetime:YBd:201304050530.00-5- 94> in <en>
> [Jul  2 15:54:44] DEBUG[2737] pbx.c: Launching 'Hangup'
> [Jul  2 15:54:44] VERBOSE[2737] pbx.c:     -- Executing [6666 at avhan:3]
> Hangup("SIP/1001-00000000", "") in new stack
> [Jul  2 15:54:44] DEBUG[2737] pbx.c: Spawn extension (avhan,6666,3) exited
> non-zero on 'SIP/1001-00000000'
> [Jul  2 15:54:44] VERBOSE[2737] pbx.c:   == Spawn extension (avhan, 6666,
> 3) exited non-zero on 'SIP/1001-00000000'
> [Jul  2 15:54:44] DEBUG[2737] channel.c: Soft-Hanging up channel
> 'SIP/1001-00000000'
> [Jul  2 15:54:44] DEBUG[2737] channel.c: Hanging up channel
> 'SIP/1001-00000000'
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: Hangup call SIP/1001-00000000,
> SIP callid YjNlMjU5YTJlMmQ5Njc3YjQ1MDgyMDg3ZjI1ZDViMmY.
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: Updating call counter for
> incoming call
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: No provider found, checking
> channel drivers for SIP - 1001
> [Jul  2 15:54:44] DEBUG[2698] chan_sip.c: Checking device state for peer
> 1001
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: Changing state for SIP/1001 -
> state 1 (Not in use)
> [Jul  2 15:54:44] DEBUG[2698] devicestate.c: device 'SIP/1001' state '1'
> [Jul  2 15:54:44] DEBUG[2737] res_rtp_asterisk.c: Setting RTCP address on
> RTP instance '0x98ac7f0'
> [Jul  2 15:54:44] DEBUG[2737] netsock2.c: Splitting '192.168.2.18:7490'
> into...
> [Jul  2 15:54:44] DEBUG[2737] netsock2.c: ...host '192.168.2.18' and port
> '7490'.
> [Jul  2 15:54:44] DEBUG[2737] chan_sip.c: Trying to put 'BYE sip:100'
> onto UDP socket destined for 192.168.2.18:7490
>
>
>
So, these statements show that it is actually using the config file to try
to say the datetime:

[Jul  2 15:54:44] VERBOSE[2737] pbx.c:     -- Executing [6666 at avhan:2]
DateTime("SIP/1001-00000000", "1365120000,,YBd") in new stack
[Jul  2 15:54:44] DEBUG[2737] app_playback.c: string
<datetime:YBd:201304050530.00-5- 94> depth <0>
[Jul  2 15:54:44] DEBUG[2737] app_playback.c: try
<datetime:YBd:201304050530.00-5- 94> in <en>

The DEBUG statements in app_playback indicate the following:
 * It will use the configuration in the [en] context (no language was
specified, so it defaults to en)
 * It will use the configuration in the datetime extension
 * It will attempt a match in the datetime extension on datetime:YBd
 * It will attempt to say 201304050530.00-5- 94 based on whatever extension
pattern matches datetime:YBd

Looking at your say.conf config file, you don't have an extension that
matches "datetime". You have one that matches "date" and "time", but not
the combination of the two.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130703/a5ea94d6/attachment.htm>