Dear all,

I am using Asterisk version 18 and JSSIP 3.9. I am experiencing an issue with the Feature Attended Transfer (code: *402) function during a normal call. Occasionally, it seems that the function does not work properly. When I checked the logs, I noticed that the DTMF signals were sent successfully from the user, but Asterisk returned the message “DTMF feature string collection timed out.” I have attached the log for reference.

Can you please suggest any solutions to this issue? I appreciate any help or advice you can provide.

Thank you in advance.
dtmf_timedout.txt (339.8 KB)

As supplied, Asterisk does not have a feature code for attended transfer, and the (commented out) code in the sample configuration is “*2”, not “*402”.

Without details of how you have configured Asterisk, it is not possible solve your problem.

The preferred method for DTMF is RFC 4733 (previously RFC 2833), not INFO.

Thank for your response.

I change config file feature.conf (*2 to *402)

DTMF by INFO is the requirement from our customer so we must use it.

;transferretrysound = beep      ; Sound to play when a transferer fails to dial a valid extension.
;transferinvalidsound = beeperr ; Sound to play when a transferer fails to dial a valid extension and is out of retries.
atxferabort = *401               ; cancel the attended transfer
;atxfercomplete = *2            ; complete the attended transfer, dropping out of the call
atxferthreeway = *403            ; complete the attended transfer, but stay in the call. This will turn the call into a multi-party bridge
atxferswap = *404                ; swap to the other party. Once an attended transfer has begun, this options may be used multiple times

; Note that the DTMF features listed below only work when two channels have answered and are bridged together.
; They can not be used while the remote party is ringing or in progress. If you require this feature you can use
; chan_local in combination with Answer to accomplish it.

blindxfer => #1                ; Blind transfer  (default is #) -- Make sure to set the T and/or t option in the Dial() or Queue() app call!
disconnect => #000               ; Disconnect  (default is *) -- Make sure to set the H and/or h option in the Dial() or Queue() app call!
;automon => *1                  ; One Touch Record a.k.a. Touch Monitor -- Make sure to set the W and/or w option in the Dial() or Queue() app call!
atxfer => *402                   ; Attended transfer  -- Make sure to set the T and/or t option in the Dial() or Queue()  app call!
;parkcall => #72                ; Park call (one step parking)  -- Make sure to set the K and/or k option in the Dial() app call!
;automixmon => *3               ; One Touch Record a.k.a. Touch MixMonitor -- Make sure to set the X and/or x option in the Dial() or Queue() app call!

Does asterisk actually see this feature code? What is the output of features show?

Please share a full call trace with dtmf logging enabled via pastebin.com

logger set level DTMF on

The file log is attached above. Please take a look at that.
This has occurred when I use JSSIP WebPhone, but is good when I use the app Microsip.

Thanks @david551 for your reply
Actually we are using JSSIP library for our softphone which is NOT supported RFC 4733, so we must use the SIP info to send the DTMF

Dear @PitzKey ,
We enabled “logger set level DTMF on”.
Could you please help to check the log:
dtmf_timedout.txt (339.8 KB)

if we check the analysis below, it looks line Asterisk recieved the DTMF “*402” in time – See pcap
But somehow Asterisk wait until timeout, then it process next DTMF digits.

*Notes: This is an intermittent issues but it happen frequently in our lab

Any advice you could provide would be appreciated

The pcap timestamps are from when the packet gets queued, not when they are read by the application code. I’m pretty sure that even chan_pjsip has only one socket for a UDP transport, so I’d suspect something is blocking the handling of that socket, e.g. some database activity, or paging in code, if you are short on real memory.