i’m using a .call file to play a context from my extensions.conf file but when i create the call and it starts ringing, the audio is already playing so when I answer it’s midway through the audio file
my call file:
Channel: PJSIP/+12512612742@main
Context: call
Extension: s
Priority: 1
WaitTime: 20
beginning of my context:
[call]
exten => s,1,NoOp
same => n,Wait(1)
same => n,Playback(intro)
the device i’m calling is an external number
What are you calling? Do you have a log?
Which channel technology are you using? If DAHDI analogue, does the central office support answer supervision? If so, is that correctly configured.
I VoIP, are you calling to a direct line, or to a PABX, at the far end?
Are you using analogue by means other than DAHDI?
Is your A side the actual device, or are you using a local channel? If the lattter, does the dialplan contain a superfluous call to Anwer()?
Generally there is a lot of missing information in your question.
i edited my first post to include more info
This does not include a console log of a call attempt to show what actually happened. If the SIP endpoint answers immediately even if the called party hasn’t answered, then it would go into dialplan.
– PJSIP/main-00000099 answered
– Executing [s@robocall:1] NoOp(“PJSIP/main-00000099”, “Starting IVR for outgoing call”) in new stack
– Executing [s@robocall:2] Wait(“PJSIP/main-00000099”, “1”) in new stack
– Executing [s@robocall:3] Playback(“PJSIP/main-00000099”, “intro”) in new stack
– <PJSIP/main-00000099> Playing ‘intro.slin’ (language ‘en’)
– Executing [s@robocall:4] Set(“PJSIP/main-00000099”, “TIMEOUT(digit)=10”) in new stack
– Digit timeout set to 10.000
– Executing [s@robocall:5] Set(“PJSIP/main-00000099”, “TIMEOUT(response)=10”) in new stack
– Response timeout set to 10.000
– Executing [s@robocall:6] WaitExten(“PJSIP/main-00000099”, “”) in new stack
– Executing [2@robocall:1] Playback(“PJSIP/main-00000099”, “response2”) in new stack
– <PJSIP/main-00000099> Playing ‘response2.slin’ (language ‘en’)
That’s because of calling external number via SIP trunk.
External channels (like a SIP trunk to the PSTN) don’t always provide reliable call progress signaling (like “ringing” or “answered”) that Asterisk can act on, especially with Playback().
I think you should use Dial() application with ‘A’ option.
.call file:
Channel: Local/bridge@outbound
Context: dummy
Extension: s
Priority: 1
extensions.conf:
[outbound]
exten => bridge,1,NoOp(Placing external call)
same => n,Dial(PJSIP/+12512612742@main,A(callhandler^s^1))
same => n,Hangup()
[callhandler]
exten => s,1,NoOp(Call was answered)
same => n,Wait(1)
same => n,Playback(intro)
same => n,Hangup()
I wasn’t sure what to do with the dummy context but I just used exactly what you sent to test it and see what happens and I got this result in the logs and I didn’t get any call either
10716 [2025-07-20 03:43:41] WARNING[285246][C-0000007b] app_dial.c: Invalid answer timeout specified: ‘s^1)’. Setting timeout to infinite
10717 [2025-07-20 03:43:41] WARNING[285246][C-0000007b] app_dial.c: Invalid progress timeout specified: ‘s^1)’. Setting timeout to infinite
10718 [2025-07-20 03:43:42] WARNING[285245][C-0000007c] pbx.c: Channel ‘Local/bridge@outbound-00000009;1’ sent to invalid extension but no invalid handler: context,exten,priority=dummy,s,1
10719 [2025-07-20 03:43:42] NOTICE[285245][C-0000007c] pbx_spool.c: Call completed to Local/bridge@outbound
same => n,Dial(PJSIP/+12512612742@main,,A(callhandler^s^1))
Two commas. (Two is shortened as one because of markdown formatting)
Sorry.
The remote side has indicated the call has been answered, so dialplan executes. From a protocol and Asterisk perspective, it’s doing as it should. What are you actually calling?
This will behave the same way.
The problem is not Asterisk, it’s the fact that the call is basically answered, even though according to you it should not be.
There is a syntax error in the general format of the Dial parameters, and the syntax and semantics of the A option are completely wrong. In any case even if it does what I guess was intended, it still relies on answer supervision being implemented correctly.
If main represents a real provider, it is unlikely that the provider is prematurely answering, although I suppose some might do if they were never intended to be used by PABXes.. It is more likely that the callee’s PABX is doing the premature answer.
[ Note the timeout parameter issue has already been covered. ]
i’m calling my phone
You’re calling your phone THROUGH something that speaks SIP. What is that? A SIP provider? An analog adapter? A gateway?
Oh you mean what am i calling with? A sip provider
I’m using voip.ms sip and calling directly through the sip, if it’s not possible to fix the issue properly are there any workarounds i can do?