[Home]

Summary:ASTERISK-08759: DTMF not registered from called party to 3rd call party in 3-way call
Reporter:Chris C. (voipman)Labels:
Date Opened:2007-02-08 23:39:00.000-0600Date Closed:2007-04-02 14:31:18
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:In any channel (SIP and ZAP confirmed) when a call 3-way call is made the called party can not register the DTMF with the 3rd/conferenced party.

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

1. Party A calls Party B
2. Party A conferences (3-way calls) party C
(Party C is a Credit card verification IVR- non-asterisk)
3. Party C plays IVR "enter credit card number"
4. Party B enters DTMF which the asterisk application registered but does not mix and forward to party C.
5. Party C does not recognize DTMF entered by party A for credit card validation.

This can be reproduced with 3-way'ing into the echo() application, and the read application from SIP-SIP and ZAP-SIP and ZAP-ZAP call flows on the same asterisk server.
Comments:By: Serge Vecher (serge-v) 2007-02-09 12:18:25.000-0600

I assume you use a "native conferencing" feature, like "Confrn" button on Cisco IP phones. In that case, the phone, or Party A, acts like a "mixer", not Asterisk.
By: Chris C. (voipman) 2007-02-09 21:33:47.000-0600

This was my first assumption as well. But party A can be any technology, and the "mixing" can be done on the asterisk or not and the problem still exists. Here are some call examples that i think illustrate the issue:

Example 1:

Party A = Zap (analog port)
Party B = SIP (cisco 7940)
Party C = Read application
DTMF entered by: Party B

   -- Executing Dial("Zap/21-1", "SIP/6005") in new stack
   -- Called 6005
   -- SIP/6005-09e8c398 is ringing
   -- Started music on hold, class 'default', on channel 'SIP/0093-09ee3c28'
   -- SIP/6005-09e8c398 answered Zap/21-1
   -- Stopped music on hold on SIP/0093-09ee3c28
   -- Started three way call on channel 21
   -- Started music on hold, class 'default', on channel 'SIP/6005-09e8c398'
   -- Starting simple switch on 'Zap/21-2'
   -- Stopped music on hold on SIP/6005-09e8c398
   -- Executing Answer("Zap/21-2", "") in new stack
   -- Executing Read("Zap/21-2", "test|beep|5") in new stack
   -- Accepting a maximum of 5 digits.
   -- Playing 'beep' (language 'en')
   -- Building conference on call on Zap/21-1 and Zap/21-2
Feb 10 03:13:20 DTMF[23661]: channel.c:2345 ast_write: Zap/21-1 : 1
Feb 10 03:13:20 DTMF[23661]: channel.c:2345 ast_write: Zap/21-1 : 2
Feb 10 03:13:21 DTMF[23661]: channel.c:2345 ast_write: Zap/21-1 : 3
Feb 10 03:13:22 DTMF[23661]: channel.c:2345 ast_write: Zap/21-1 : 4
Feb 10 03:13:23 DTMF[23661]: channel.c:2345 ast_write: Zap/21-1 : 5
Feb 10 03:13:24 DTMF[23661]: channel.c:2345 ast_write: Zap/21-1 : #
   -- User entered nothing.
   -- Executing NoOp("Zap/21-2", "{$TEST}") in new stack
 == Auto fallthrough, channel 'Zap/21-2' status is 'UNKNOWN'
   -- Hungup 'Zap/21-2'

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

Note that you do not see channel.c:2345 ast_write write to the channel where party C is connected.

Example 2:

Party A = Zap (analog port)
Party B = SIP (cisco 7940)
Party C = Read application
DTMF entered by: Party A


   -- Executing Dial("Zap/21-1", "SIP/6005") in new stack
   -- Called 6005
   -- SIP/6005-09e8c398 is ringing
   -- Started music on hold, class 'default', on channel 'SIP/0093-09ee3c28'
   -- SIP/6005-09e8c398 answered Zap/21-1
   -- Stopped music on hold on SIP/0093-09ee3c28
   -- Started three way call on channel 21
   -- Started music on hold, class 'default', on channel 'SIP/6005-09e8c398'
   -- Starting simple switch on 'Zap/21-2'
   -- Stopped music on hold on SIP/6005-09e8c398
   -- Executing Answer("Zap/21-2", "") in new stack
   -- Executing Read("Zap/21-2", "test|beep|5") in new stack
   -- Accepting a maximum of 5 digits.
   -- Playing 'beep' (language 'en')
   -- Building conference on call on Zap/21-1 and Zap/21-2
Feb 10 03:21:29 DTMF[23679]: channel.c:2345 ast_write: SIP/6005-09e8c398 : 1
Feb 10 03:21:29 DTMF[23679]: channel.c:2345 ast_write: SIP/6005-09e8c398 : 2
Feb 10 03:21:30 DTMF[23679]: channel.c:2345 ast_write: SIP/6005-09e8c398 : 3
Feb 10 03:21:30 DTMF[23679]: channel.c:2345 ast_write: SIP/6005-09e8c398 : 4
Feb 10 03:21:31 DTMF[23679]: channel.c:2345 ast_write: SIP/6005-09e8c398 : 5
   -- User entered nothing.
   -- Executing NoOp("Zap/21-2", "{$TEST}") in new stack
 == Auto fallthrough, channel 'Zap/21-2' status is 'UNKNOWN'
   -- Hungup 'Zap/21-2'

Example 3: (no 3-way call)

Party A = Zap (analog port)
Party B = Read application
DTMF entered by: Party A

   -- Starting simple switch on 'Zap/21-1'
   -- Executing Answer("Zap/21-1", "") in new stack
   -- Executing Read("Zap/21-1", "test|beep|5") in new stack
   -- Accepting a maximum of 5 digits.
   -- Playing 'beep' (language 'en')
   -- User entered '12345'
   -- Executing NoOp("Zap/21-1", "{$TEST}") in new stack
 == Auto fallthrough, channel 'Zap/21-1' status is 'UNKNOWN'
   -- Hungup 'Zap/21-1'



Note that the read application picked up DTMF only when a direct call was established (last example.)
By: Serge Vecher (serge-v) 2007-02-10 18:22:38.000-0600

voipman: can you please provide the respective dialplan entries for those examples? Also, in r.53840 of the 1.4 branch has seen an addition of 'F' option which allows DTMF frame passthrough in Meetme.
By: Joshua C. Colp (jcolp) 2007-02-15 19:59:50.000-0600

In the case of zaptel DTMF is purposely muted on conferences. As for mixing on SIP phones it's up to them to do it and handle things. It might be interesting to see if it would be possible to get DTMF through a zaptel conference but I don't know how reliable it would be.
By: Serge Vecher (serge-v) 2007-03-30 09:36:19

file: can you think of the next action here? Methinks it's time to close the issue
By: Joshua C. Colp (jcolp) 2007-04-02 14:31:17

I agree. Things are purposely done like this, if you would like to see it changed it would be a feature request in my eyes and who knows how reliable it would be.