I misdiagnosed the code, but i is a rare option. and you appear to be misusing it, anyway, as your parameter 1 is not a tone name.
Using i effectively makes use of a completely different way of doing the actual read.
Actually, there may be a bug in the i handling, but the result would be gibberish after the 8th digit, not a failure to return the number. (It doesn’t seem to be setting a terminating NUL on the string if the loop ends due to a maximum length read. On the other hand, it looks like the effect of the invalid
tone name may be to cause the i option to be ignored, anyway.)
What do you mean by invalid tone name, do you mean the enter_destination IVR?
enter_destination is not a name that appears in the off the shelf indications.conf and sounds more like the name of a voice announcement file than that of a replacement dial tone.
Cos I recorded the IVR and save it in the /var/lib/asterisk/sounds/es/ and it has been saying the IVR anytime I am to enter the digits. Do you think I am doing it wrong?
In that case it ignoring the i option, or rather it uses the i option to attempt to open the tone, but subsequently tests the existence of the tone, rather than the I option, with the result that the error causes it to behave as though i had never been used, except for several thousand wasted machine instructions.
sorry this is the statement
same => n,Read(phonenumber,/var/lib/asterisk/sounds/es/enter_destination_pound,8,i,1,3)
Definitely misusing i, then.
Then maybe I should try this statement then
same => n,Read(phonenumber,/var/lib/asterisk/sounds/es/enter_destination_pound,8,1,3)
That would be more correct, although I don’t think it will make a difference as the code falls back to that interpretation, anyway. All it really does is save about a thousand instructions searching for a tone name that it will never find.
I think you need to enable the DTMF log, with millisecond timings, and see whether the digits are arriving a keyed, or, only in a burst, with the #. If the latter, we go back to the phone dialplan, or something similar, upstream of Asterisk.
How do I enable DTMF log. Also when testing whether the digits are arriving a keyed or only in burst. Do I have to still enable it in the dialplan same => n,SIPDtmfMode(RFC2833)
The same way as you enable any other log (logger.conf).
Asterisk still has to decode the DTMF for it to be logged.
console => notice,warning,error,dtmf. DONE
Please log to a file, as the console log doesn’t include timestamps, which are important, here.
This is what I added to the logger.conf
dtmflog => notice,warning,error,debug,dtmf
When I checked the log file after trying the DTMF without SIPDtmfMode() I get the following
[2017-02-24 08:54:17] WARNING[15577] chan_sip.c: Retransmission timeout reached on transmission d136005eb14d6045898051c401d0ec8f for seqno 1 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[2017-02-24 08:54:20] WARNING[15577] chan_sip.c: Retransmission timeout reached on transmission af1f418a901efe13275af7c9ed86c211 for seqno 1 (Critical Response) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
[2017-02-24 08:54:39] WARNING[22252][C-00002878] translate.c: no samples for ulawtolin
[2017-02-24 08:54:39] WARNING[22252][C-00002878] translate.c: no samples for ulawtolin
[2017-02-24 08:54:40] WARNING[22253][C-00002879] translate.c: no samples for ulawtolin
[2017-02-24 08:54:40] WARNING[22253][C-00002879] translate.c: no samples for ulawtolin