Asterisk SIP trunk VoIPSwitch ${DIALSTATUS}=ANSWER

I’m using Asterisk 1.4.2 (but this issue is in 1.6 and 1.8 so it’s not depend on Asterisk versions).

The issue is in ${DIALSTATUS} return code from SIP trunk it is always ANSWER. So ${DIALSTATUS} from VoIPSwitch comes to Asterisk before the call actually has been made. Even if the other side is BUSY, NOANSWER, CANCEL, CONGESTION, etc it’s always return ANSWER status.

  1. SIP trunk configuration

host=*** IP Provider ***
fromuser=*** user ***
fromdomain=*** VoIP provider domain ***
username=*** user ***
authuser=*** user ***
secret=*** password ***
externip=*** My external IP ***

  1. DialPlan configuration

; England, Spain (Code number + phone number = 12 digits)
exten => _XXXXXXXXXXXX,1,Answer()
exten => _XXXXXXXXXXXX,n,Dial(SIP/${EXTEN}@WMAG006,5)
exten => _XXXXXXXXXXXX,n,Hangup()

; England 13 digits
;exten => _XXXXXXXXXXXXX,1,Dial(SIP/${EXTEN}@WMAG006-trunk,10)
;exten => _XXXXXXXXXXXXX,n,Hangup()

; USA, Australia (Code number + phone number = 11 digits)
;exten => _XXXXXXXXXXX,1,Dial(SIP/${EXTEN}@WMAG006-trunk,10)
;exten => _XXXXXXXXXXX,n,Hangup()

; Denmark (Code number + phone number = 10 digits)
;exten => _XXXXXXXXXX,1,Dial(SIP/${EXTEN}@WMAG006-trunk,10)
;exten => _XXXXXXXXXX,n,Hangup()

exten => 505,1,Answer()
exten => 505,n,Dial(SIP/505,25)
exten => 505,n,Hangup()

exten => 501,1,Answer()
exten => 501,n,Dial(SIP/501,25)
exten => 501,n,Hangup()

exten => 503,1,Answer()
exten => 503,n,Dial(SIP/503,25)
exten => 503,n,Hangup()

exten => 504,1,Answer()
exten => 504,n,Dial(SIP/504,25)
exten => 504,n,Hangup()

exten => h,1,System(/bin/sh -c “/bin/echo ${DIALSTATUS} > /usr/local/asterisk/wmag006/status”)
; exten => h,1,System(/bin/sh -c “/bin/echo ${DEVSTATE(SIP/${EXTEN}@WMAG006) > /usr/local/asterisk/wmag006/status”)
; exten => h,1,Goto(s-{DIALSTATUS},1)

exten => s-CANCEL,1,System(/bin/sh -c “/bin/echo Cancel > /usr/local/asterisk/wmag006/status”)
exten => s-ANSWER,1,System(/bin/sh -c “/bin/echo Answer > /usr/local/asterisk/wmag006/status”)
exten => s-NOANSWER,1,System(/bin/sh -c “/bin/echo NoAnswer > /usr/local/asterisk/wmag006/status”)
exten => s-BUSY,1,System(/bin/sh -c “/bin/echo Busy date +%F-%H:%M > /usr/local/asterisk/wmag006/status”)
exten => s-CONGESTION,1,System(/bin/sh -c “/bin/echo Congestion date +%F-%H:%M > /usr/local/asterisk/wmag006/status”)
exten => s-CHANUNAVAIL,1,System(/bin/sh -c “/bin/echo Chanunavail date +%F-%H:%M > /usr/local/asterisk/wmag006/status”)

  1. SIP debug output

    – Executing [380954269162@WMAG006-outbounds-calls:1] Answer(“SIP/505-00000000”, “”) in new stack
    – Executing [380954269162@WMAG006-outbounds-calls:2] Dial(“SIP/505-00000000”, “SIP/380954269162@WMAG006|5”) in new stack
    – Called 380954269162@WMAG006
    – SIP/WMAG006-00000001 answered SIP/505-00000000
    – Native bridging SIP/505-00000000 and SIP/WMAG006-00000001
    – Executing [h@WMAG006-outbounds-calls:1] System(“SIP/505-00000000”, “/bin/sh -c “/bin/echo ANSWER > /usr/local/asterisk/wmag006/status””) in new stack
    == Spawn extension (WMAG006-outbounds-calls, 380954269162, 2) exited non-zero on ‘SIP/505-00000000’
    Really destroying SIP dialog ‘3c267898dbba-gk13n2v9n3ks@snom320-0004132485B0’ Method: BYE
    Really destroying SIP dialog '’ Method: INVITE

I think maybe some patch or addons needed by Asterisk to get right ${DIALSTATUS} answer from VoIP Switch
If somebody has the same issue, please help.

I think this is one that strayed onto

The basic problem is that the downstream provider seems to answer the call, rather than using 183 Progress, and then sends in band call progress indications.

The best solution is to get the provider to fix their system, but I suspect the purpose of raising it here is to see if one can detect and handle the call progress indications in Asterisk.

I don’t know what tone detection facilities are in Asterisk and how easy it is to run them on the called channel. I’d look for suitable applications then investigate the macro, subroutine and goto actions on Dial. On 1.6, if you have to use goto on Dial, you can use Bridge() to complete the call.

My VoIP provider uses VoIP Switch where our Asterisk 1.4.2 is directly connected. They showed me VoIP traffic with help of “wireshark” and it says that DIALSTATUS on VoIP Switc is returned right, but does it not return to Asterisk from VoIP Switch?

So, even if I Dial a WRONG number through SIP trunk (1111111111 for example) it also return ANSWER status before the call has been made.

DIALSTATUS is a specifically Asterisk concept. Is VoIPSwitch a customised Asterisk system?

If so, they have something in the dialplan (Answer is often included without justification) which is causing the call to be answered before they call the Dial application, or they have a connection to the PSTN that doesn’t have answer supervision, so they have to assume that all calls are answered.

Anyone providing a paid for service for gatewaying SIP trunks to PSTN really should have a PSTN connection with answer supervision and know how to enable it.

If the service is designed solely for direct use by SIP phones, it may well not matter that answer supervision is being given prematurely in the SIP dialogue, as users will listen to the inband tones and not care whether they are being generated by the phone or the network.

The evidence in the trace that you posted to the issue tracker is that they always respond 200 OK. That means answered. If you dial an invalid number, they should return, preferably, 404 Not Found, or, at a push, 183 Progress with NU tone. If they are returning 200 OK, they are telling you that the call was answered and their system needs fixing.

Actually, if they are using ASTERISK, and getting an error DIALSTATUS, the problem isn’t answer supervision on the PSTN side, but that they are doing something that answers the call before, or at the start of the Dial application call.

My VoIP provider is using “VoIP Switch”, so my “Asterisk” is derectrly connected to it.

I don’t understand the significance of the last statement.

I already assumed that it was your direct peer. That just confirms that, either you didn’t supply a trace of a failure case, or the VoIPSwitch is broken.