[Home]

Summary:ASTERISK-11561: [patch] Sending DTMF when receiving the PROGRESS status
Reporter:VoipForces (voipforces)Labels:
Date Opened:2008-03-03 09:18:55.000-0600Date Closed:2010-12-06 13:29:09.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) app_dial.c_patch_trunk_valid
( 1) dtmf_progress.patch
Description:Some telco account code services (like Allstream here in Canada) required that the account code DTMF be send as soon as the PROGRESS status is received but before the channel is considered "Answered" by Asterisk.

When dialing manually this is not an issue as the user hears the beeeep and punch in the correct DTMF account code.

However when using call files or AMI to initiate the call, the D() flag in app_dial does not work as D() only sends the DTMF when the channel is answered.

****** ADDITIONAL INFORMATION ******

Attached is a patch against 1.4.18 that gives a new parameter to the D() flag where:

   D([called][:calling][:progress]) - Send the specified DTMF strings *after* the called
          party has answered, but before the call gets bridged. The 'called'
          DTMF string is sent to the called party, and the 'calling' DTMF
          string is sent to the calling party. Both parameters can be used
          alone.
          If progress specified, it's DTMF will be send as soon as PROGRESS message is received.


Comments:By: Joshua C. Colp (jcolp) 2008-03-03 09:28:06.000-0600

All patches must have a license on record in order to be looked at. As well new features need to be made against trunk.
By: VoipForces (voipforces) 2008-03-03 09:32:35.000-0600

Yup, filled-up the license after. Will provide patch against trunk in a few minutes.
By: VoipForces (voipforces) 2008-03-03 10:16:44.000-0600

Ok, app_dial.c_patch_trunk is the patch against trunk downloaded a few minutes ago.
By: VoipForces (voipforces) 2008-03-04 09:51:21.000-0600

Ok, sorry about the fuzz, last attached file is a valid one with the license.
By: VoipForces (voipforces) 2008-03-20 11:06:04

Further on this, I am hitting the same problem using call files.

I don't have a patch for this yet and would appreciate hints on how to implement the same on the call file code which is very much different.
By: Donny Kavanagh (donnyk) 2008-03-20 14:20:15

A workaround for the .call files or Manager Action Originate would be to place your call on a local channel eg, Local/12345@mycoolcontext

then in [mycoolcontext] you pattern match your number your dialing and do your Dial(Zap/g1/${EXTEN},...,D()) etc.
By: VoipForces (voipforces) 2008-04-24 09:37:03

Thanks juggie.

Problem I found with that is that as soon as I send the "progress" dtmf, the channel is considered "answered" and branches of to my answered context which is using AMD to detect human/answering machine,... At this point the channel is still ringing and AMD is fooled in thinking it's an answering machine.

Off course adding wait before the amd kinda work, but it's not stable as the timeout is variable and you end-up having peoples saying "hello" multiple times till the timeout is ended and branches off to the AMD line.

BackgroundDetect can not also be used since the channel is not silent as it rings...

I know this is out of the scope of a bug track, but any bright ideas welcome.
By: VoipForces (voipforces) 2008-04-30 09:17:59

Corydon76-dig on #asterisk-dev suggested using ast_senddigit to send the individual digits instead of using ast_dtmf_stream. Will try that tonight when the system is free.
By: VoipForces (voipforces) 2008-04-30 22:10:11

Well, unfortunatly sending discrete dtmf digits did not work. Here is the output with pri debug enabled:

   -- Executing NoOp("Local/s@cwdial-with-telco-code-1-5826,1", "Going to dial 15146678448 on line 91") in new stack
   -- Executing Dial("Local/s@cwdial-with-telco-code-1-5826,1", "Zap/91/15146678448|300|D(::1444)G(ek_ekivrtest3_e^s^1)") in new stack
-- Making new call for cr 32771
   -- Requested transfer capability: 0x00 - SPEECH
> Protocol Discriminator: Q.931 (8)  len=61
> Call Ref: len= 2 (reference 3/0x3) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a2]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: u-Law (34)
> [18 03 a9 83 93]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 19 ]
> [1e 02 80 83]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: User (0)
>                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
> [28 0c b1 31 37 38 30 34 30 38 35 32 31 36]
> Display (len=12) Charset: 31 [ 17804085216 ]
> [6c 0c 21 80 38 30 30 33 38 38 32 38 37 33]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number not screened (0) '8003882873' ]
> [70 0c a1 31 35 31 34 36 36 37 38 34 34 38]
> Called Number (len=14) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '15146678448' ]
   -- Called 91/15146678448
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 3/0x3) (Terminator)
< Message type: CALL PROCEEDING (2)
< [18 03 a9 83 93]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 19 ]
-- Processing IE 24 (cs0, Channel Identification)
   -- Zap/91-1 is proceeding passing it to Local/s@cwdial-with-telco-code-1-5826,1
< Protocol Discriminator: Q.931 (8)  len=13
< Call Ref: len= 2 (reference 3/0x3) (Terminator)
< Message type: PROGRESS (3)
< [08 02 82 ff]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Interworking, unspecified (127), class = Interworking (7) ]
< [1e 02 82 81]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Call is not end-to-end ISDN; further call progress information may be available inband. (1) ]
-- Processing IE 8 (cs0, Cause)
-- Processing IE 30 (cs0, Progress Indicator)
   -- PROGRESS with cause code 127 received
   -- Zap/91-1 is making progress passing it to Local/s@cwdial-with-telco-code-1-5826,1
   -- Zap/91-1 is sending dtmf [1] to Local/s@cwdial-with-telco-code-1-5826,1
   -- Zap/91-1 is sending dtmf [4] to Local/s@cwdial-with-telco-code-1-5826,1
   -- Zap/91-1 is sending dtmf [4] to Local/s@cwdial-with-telco-code-1-5826,1
   -- Zap/91-1 is sending dtmf [4] to Local/s@cwdial-with-telco-code-1-5826,1
   -- Zap/91-1 answered Local/s@cwdial-with-telco-code-1-5826,1
   -- Executing Answer("Local/s@cwdial-with-telco-code-1-5826,1", "") in new stack
   -- Executing AMD("Local/s@cwdial-with-telco-code-1-5826,1", "3500|1500|300|5000|120|50|5|256") in new stack
   -- AMD: Local/s@cwdial-with-telco-code-1-5826,1 8003882873 (null) (Fmt: 64)
   -- AMD: initialSilence [3500] greeting [1500] afterGreetingSilence [300] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [5] silenceThreshold [256]
   -- Executing AMD("Zap/91-1", "3500|1500|300|5000|120|50|5|256") in new stack
   -- AMD: Zap/91-1 8003882873 (null) (Fmt: 64)
   -- AMD: initialSilence [3500] greeting [1500] afterGreetingSilence [300] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [5] silenceThreshold [256]
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 3/0x3) (Terminator)
< Message type: CONNECT (7)
> Protocol Discriminator: Q.931 (8)  len=5
> Call Ref: len= 2 (reference 3/0x3) (Originator)
> Message type: CONNECT ACKNOWLEDGE (15)
   -- AMD: Word detected. iWordsCount:1
   -- AMD: Channel [Zap/91-1]. Too long...
   -- Executing GotoIf("Zap/91-1", "0?machine|1") in new stack
   -- Executing GotoIf("Zap/91-1", "0?talk|1") in new stack
   -- Executing GotoIf("Zap/91-1", "1?uncertain|1") in new stack
   -- Goto (ek_ekivrtest3_e,uncertain,1)
   -- Executing System("Zap/91-1", "/usr/bin/cwASTstocke.sh      "uncertain"") in new stack
   -- Executing Goto("Zap/91-1", "ek_ekivrtest3_hangup_e|s|1") in new stack
   -- Goto (ek_ekivrtest3_hangup_e,s,1)
   -- Executing Hangup("Zap/91-1", "") in new stack
 == Spawn extension (ek_ekivrtest3_hangup_e, s, 1) exited non-zero on 'Zap/91-1'
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Connect Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 3/0x3) (Originator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
   -- Hungup 'Zap/91-1'
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 3/0x3) (Terminator)
< Message type: RELEASE (77)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 3/0x3) (Originator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
   -- Executing Hangup("Local/s@cwdial-with-telco-code-1-5826,2", "") in new stack
By: John Covert (jcovert) 2008-08-15 17:00:29

I would like to mention that this feature has been asked for by several different students in the Asterisk Bootcamp, so I hope that "Progress" can be made on it.  It needs to work both on Zap channels (PRI or CAS) and VoIP channels (SIP and IAX), so that it can be used to send account codes or other charge information to providers before they answer.

The "w" needs to be supported to allow delays required by the remote equipment.
By: Leif Madsen (lmadsen) 2008-12-05 10:52:13.000-0600

I'm going to confirm this issue for now since there is a patch associated with the bug. Can the original reporter comment on the issues raised by jcovert? Can we move this issue forward?
By: Digium Subversion (svnbot) 2009-03-17 12:17:51

Repository: asterisk
Revision: 182596

U   trunk/CHANGES
U   trunk/apps/app_dial.c

------------------------------------------------------------------------
r182596 | dvossel | 2009-03-17 12:17:51 -0500 (Tue, 17 Mar 2009) | 12 lines

Option to send DTMF when receiving PROGRESS status

The D() option in app_dial is only able to send DTMF after the call has been answered.  A progress option has been added to D() to allow DTMF to be sent upon receiving PROGRESS.  This allows DTMF to be sent before the call is answered.

(closes issue ASTERISK-11561)
Reported by: VoipForces
Patches:
app_dial.c_patch_trunk_valid uploaded by VoipForces (license 419)
dtmf_progress.patch uploaded by dvossel (license 671)
Tested by: VoipForces, dvossel


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=182596