[Home]

Summary:ASTERISK-09947: dtmf_end_only test failing on sip-iax bridge
Reporter:Stanislaw Pitucha (viraptor)Labels:
Date Opened:2007-07-24 10:59:10Date Closed:2011-06-07 14:03:16
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Addons/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:SIP->IAX bridge doesn't send correct DTMF.
Even though _FLAG_DTMF_END_ONLY is set when bridge is set up (checked by debug), it's lost somewhere on the way.
I'm bridging sip->iax. Sending dtmf from sip fails (only BEGIN is sent, not END). I've tracked it to channel.c:2390 in *-2.4.8, but can't find any cause for test failing (END_ONLY not being set):

if ( ast_test_flag(chan, AST_FLAG_DEFER_DTMF | AST_FLAG_END_DTMF_ONLY) ||
   (!ast_tvzero(chan->dtmf_tv) &&
     ast_tvdiff_ms(ast_tvnow(), chan->dtmf_tv) < AST_MIN_DTMF_GAP) ) {

gdb shows, that chan->flags == 512 in that moment.
Any other info needed?
Comments:By: Joshua C. Colp (jcolp) 2007-07-25 17:08:50

We need much more information to look at this. Complete console output with debug enabled, plus a general idea of channels involved and their DTMF methods in use, sip debug, and iax2 debug.
By: Stanislaw Pitucha (viraptor) 2007-07-26 11:24:35

debug on receiving end:

   -- Executing [s@menu:3] Read("IAX2/192.168.1.98:59976-1", "digit") in new stack
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 003 Type: IAX     Subclass: LAGRQ  
  Timestamp: 10007ms  SCall: 32767  DCall: 00001 [192.168.1.98:59976]
Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 003 Type: IAX     Subclass: LAGRP  
  Timestamp: 10007ms  SCall: 00001  DCall: 32767 [192.168.1.98:59976]
Tx-Frame Retry[000] -- OSeqno: 004 ISeqno: 003 Type: IAX     Subclass: LAGRQ  
  Timestamp: 10018ms  SCall: 00001  DCall: 32767 [192.168.1.98:59976]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 004 Type: IAX     Subclass: ACK    
  Timestamp: 10007ms  SCall: 32767  DCall: 00001 [192.168.1.98:59976]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 005 Type: IAX     Subclass: LAGRP  
  Timestamp: 10018ms  SCall: 32767  DCall: 00001 [192.168.1.98:59976]
Tx-Frame Retry[-01] -- OSeqno: 005 ISeqno: 004 Type: IAX     Subclass: ACK    
  Timestamp: 10018ms  SCall: 00001  DCall: 32767 [192.168.1.98:59976]
Rx-Frame Retry[ No] -- OSeqno: 004 ISeqno: 005 Type: DTMF_B  Subclass: 2
  Timestamp: 11633ms  SCall: 32767  DCall: 00001 [192.168.1.98:59976]
Tx-Frame Retry[-01] -- OSeqno: 005 ISeqno: 005 Type: IAX     Subclass: ACK    
  Timestamp: 11633ms  SCall: 00001  DCall: 32767 [192.168.1.98:59976]
Rx-Frame Retry[ No] -- OSeqno: 005 ISeqno: 005 Type: DTMF_B  Subclass: #
  Timestamp: 12756ms  SCall: 32767  DCall: 00001 [192.168.1.98:59976]
Tx-Frame Retry[-01] -- OSeqno: 005 ISeqno: 006 Type: IAX     Subclass: ACK    
  Timestamp: 12756ms  SCall: 00001  DCall: 32767 [192.168.1.98:59976]
   -- User entered nothing.
   -- Executing [s@menu:4] SayDigits("IAX2/192.168.1.98:59976-1", "") in new stack
   -- Executing [s@menu:5] GotoIf("IAX2/192.168.1.98:59976-1", "0?2") in new stack
   -- Executing [s@menu:6] Hangup("IAX2/192.168.1.98:59976-1", "") in new stack


------>8------

dialplan:

 's' =>            1. Answer()                                   [pbx_config]
                   2. Datetime()                                 [pbx_config]
                   3. Read(digit)                                [pbx_config]
                   4. SayDigits(${digit})                        [pbx_config]
                   5. Gotoif($["${digit}"!=""]?2)                [pbx_config]
                   6. Hangup()                                   [pbx_config]

------>8------

traffic goes: ekiga -> [sip-asterisk-iax] -> [iax-asterisk]
ekiga claims to send RFC2833 DTMF sending
debug log on sip->iax translating server shows same iax frames as other server is getting and doesn't show any special sip packets
configs are default - nothing was changed in sip & iax apart from adding accounts
By: Joshua C. Colp (jcolp) 2007-07-27 12:20:32

We need the debug from the machine sending these DTMF begin frames, not the machine receiving them.
By: Joshua C. Colp (jcolp) 2007-08-16 19:56:28

Suspended due to lack of feedback. If you can get the needed information please reopen and attach. Thanks.