[Home]

Summary:ASTERISK-04511: DTMF Registering in IAX Debug output but ignored for IVR purposes
Reporter:Mark Edwards (edwar64896)Labels:
Date Opened:2005-07-02 08:23:57Date Closed:2011-06-07 14:03:11
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dialplan-from-external.conf
( 1) iax.conf
( 2) messages.debug.gz
Description:I have a very simple 3 button IVR application into which I am dialling from my IAX provider. I am using ilbc codec. 9 calls out of 10 the DTMF codes just get ignored by *. They are showing up happily in IAX2 debug logs. Every now and again, I dial in and it works OK, but the next time it won't. I have tried to consistently reproduce it, but cannot get 100% consistency. Every now and again, the d**n thing will actually work once - just to frustrate me! ;-) For sure, the next time after - it won't.

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

It seems to work more often when debug isn't running. Additionally, I am seeing some odd timestamp data in the debug log (notice line 8)

Tx-Frame Retry[000] -- OSeqno: 002 ISeqno: 002 Type: CONTROL Subclass: RINGING
  Timestamp: 00045ms  SCall: 00003  DCall: 00044 [210.80.176.12:4569]
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: IAX     Subclass: ACK
  Timestamp: 00042ms  SCall: 00044  DCall: 00003 [210.80.176.12:4569]
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 003 Type: IAX     Subclass: ACK
  Timestamp: 00045ms  SCall: 00044  DCall: 00003 [210.80.176.12:4569]
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 003 Type: VOICE   Subclass: 136
  Timestamp: 4294967280ms  SCall: 00044  DCall: 00003 [210.80.176.12:4569]
Tx-Frame Retry[-01] -- OSeqno: 003 ISeqno: 003 Type: IAX     Subclass: ACK
  Timestamp: 4294967280ms  SCall: 00003  DCall: 00044 [210.80.176.12:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 003 Type: VOICE   Subclass: 136
  Timestamp: 00014ms  SCall: 00044  DCall: 00003 [210.80.176.12:4569]
Tx-Frame Retry[-01] -- OSeqno: 003 ISeqno: 004 Type: IAX     Subclass: ACK
  Timestamp: 00014ms  SCall: 00003  DCall: 00044 [210.80.176.12:4569]
Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 004 Type: CONTROL Subclass: ANSWER
  Timestamp: 05046ms  SCall: 00003  DCall: 00044 [210.80.176.12:4569]
Tx-Frame Retry[000] -- OSeqno: 004 ISeqno: 004 Type: VOICE   Subclass: 136
  Timestamp: 05060ms  SCall: 00003  DCall: 00044 [210.80.176.12:4569]
Rx-Frame Retry[ No] -- OSeqno: 004 ISeqno: 004 Type: IAX     Subclass: ACK
Comments:By: Kevin P. Fleming (kpfleming) 2005-07-05 16:04:43

We will need some actual debugging information before we can even hope to help you. At the least we will need the section of your dialplan that is being used, the IAX user definition involved, and a 'set verbose 255'/'set debug 255'/'iax2 debug' trace during a failing call.
By: Mark Edwards (edwar64896) 2005-07-06 06:28:40

gets interesting around lines 2800 of the debug log when the log mentions out of order packets. Seemed to be working better tonight but still got the one failure out of a sequence of call attempts.
By: Mark Edwards (edwar64896) 2005-07-06 06:29:48

updated bug with some log and conf files.
regards,
Mark
By: Brian West (bkw918) 2005-07-07 10:07:13

Also are you using cvs-head to stable? or any combo of head to stable? (ie is the provider using stable?)
By: Mark Edwards (edwar64896) 2005-07-09 06:21:00

Have contacted Oztell for the information regarding their use of IAX. Reckon there might be some incompatibility within the RFC2833 message that is being sent?
By: Russell Bryant (russell) 2005-07-11 20:47:38

well ... RFC2833 is a standard for sending dtmf within RTP.  IAX doesn't use RTP, so I don't think this is the case.  :)

Unlike SIP, IAX only has one way to send DTMF, and that is using out of band signalling.
By: Mark Edwards (edwar64896) 2005-07-11 20:59:12

call it a newbie-lack-of-understanding then... there is some out of band DTMF data being sent with the IAX stream that I can see when setting iax2 debug. * is ignoring it completely. Forget I ever mentioned RFC2833.
By: Michael Jerris (mikej) 2005-07-12 17:48:37

Any word from provider about what version they are using?
By: Mark Edwards (edwar64896) 2005-07-13 07:44:14

Not only is the provider (oztell) being quite silent on this issue, my incoming DID is now just as silent as their response to my question. I will keep pinging the number and their support desk - hopefully I will be able to post some sort of tcpdump trace that might be able to shed some light on the problem - as soon as the DID starts working again!
By: Michael Jerris (mikej) 2005-07-20 22:45:26

unfortunately we are unable to address this bug report any further without additional information.  I am suspending this bug, please re-open when you are able to provide the requested information.