Asterisk 14.2.1 - Swift - call file - odd issue

We are migrating an old (almost 10 years old) Asterisk 1.4 server that used app_swift with a Cepstral license to a new server. I have successfully installed Asterisk 14.2.1 (built from source) on the new server and we have successfully migrated the small office (4 users) to the new server, but I am shooting a small problem and need some advice on debugging further. The Cepstral swift license was also upgraded as part of the process to their current release.

Short summary of the problem is, for one client phone device, if an outbound call to the client SIP device is placed via an Asterisk call file, then the parts of the dial plan that invoke swift are silent, but Background invocations of standard Asterisk disk sound files are heard during the call. Same call file type invocation to different phones (one to an iax2 device, and one to a DAHDI channel device) hear all parts of that dial plan for that context, both swift and Background. If the same client phone that cannot hear swift sounds makes an inbound call to the Asterisk PBX to an extension/context that includes swift invocations, the client hears everything that is spoken through calls to swift and Background in the dial plan. All human to human voice calls, inbound and outbound, work perfectly.

The SIP ATA device that exhibits the “cannot hear swift spoken text if called via Asterisk call file” problem is a Cisco SPA112 with their latest firmware flashed onto it. Prior firmware exhibited the same symptom.

The script that creates the call file looks like so:


# Now place a phone call using the asterisk switch.
# Get a unique name for the call file.
CALLFILE=/tmp/`basename $0`.$$.call
echo "Channel: sip/eheman" > $CALLFILE
echo "Callerid: FSI Weather <32>" >> $CALLFILE
echo "MaxRetries: 1" >> $CALLFILE
echo "RetryTime: 300" >> $CALLFILE
echo "WaitTime: 20" >> $CALLFILE
echo "Codecs: ulaw,alaw" >> $CALLFILE
echo "Context: freezingtemp" >> $CALLFILE
echo "Extension: s" >> $CALLFILE
echo "Priority: 1" >> $CALLFILE
# always use "mv" and not "cp" to put the call file in the call queue!
mv $CALLFILE   /var/spool/asterisk/outgoing/.

The dial plan for the freezingtemp context looks like this (The “Dave” line was added as part of debugging and is not normally in the dial plan.):
pe2950f*CLI>. dialplan show freezingtemp

[ Context 'freezingtemp' created by 'pbx_config' ]
  '1' =>            1. Goto(s,5)                                  [pbx_config]
  '2' =>            1. Goto(msgack,s,1)                           [pbx_config]
  'i' =>            1. Goto(s,5)                                  [pbx_config]
  's' =>            1. Set(TIMEOUT(digit)=5)                      [pbx_config]
                    2. Set(TIMEOUT(response)=10)                  [pbx_config]
                    3. Answer()                                   [pbx_config]
                    4. Wait(2)                                    [pbx_config]
                    5. Swift(I am sorry, Dave. I cannot do that.) [pbx_config]
                    6. Swift("This is an <break time='75ms' />alert<break time='175ms' /> from the weather station. The outside temperature has fallen to freezing.") [pbx_config]
                    7. Swift(Please take steps to protect sensitive plants from freezing.) [pbx_config]
                    8. Background(press-1)                        [pbx_config]
                    9. Background(to-hear-msg-again)              [pbx_config]
                    10. Background(press-2)                       [pbx_config]
                    11. Background(to-hang-up)                    [pbx_config]
                    12. WaitExten(TIMEOUT)                        [pbx_config]
  't' =>            1. Playback(vm-goodbye)                       [pbx_config]

-= 5 extensions (16 priorities) in 1 context. =-

The verbose trace of a call to the device looks like so. Silence is heard until it finally reaches the Background “press-1” file to be played.

Console verbose was OFF and is now 7.
    -- Attempting call on sip/eheman for s@freezingtemp:1 (Retry 1)
  == Using SIP RTP CoS mark 5
    -- Called eheman
    -- SIP/eheman-00000005 is ringing
    -- SIP/eheman-00000005 answered
    -- Executing [s@freezingtemp:1] Set("SIP/eheman-00000005", "TIMEOUT(digit)=5") in new stack
    -- Digit timeout set to 5.000
    -- Executing [s@freezingtemp:2] Set("SIP/eheman-00000005", "TIMEOUT(response)=10") in new stack
    -- Response timeout set to 10.000
    -- Executing [s@freezingtemp:3] Answer("SIP/eheman-00000005", "") in new stack
    -- Executing [s@freezingtemp:4] Wait("SIP/eheman-00000005", "2") in new stack
       > 0x7f0f4c004f20 -- Probation passed - setting RTP source address to 192.168.249.120:16418
    -- Executing [s@freezingtemp:5] Swift("SIP/eheman-00000005", "I am sorry, Dave. I cannot do that.") in new stack
    -- Executing [s@freezingtemp:6] Swift("SIP/eheman-00000005", ""This is an <break time='75ms' />alert<break time='175ms' /> from the weather station. The outside temperature has fallen to freezing."") in new stack
    -- Executing [s@freezingtemp:7] Swift("SIP/eheman-00000005", "Please take steps to protect sensitive plants from freezing.") in new stack
    -- Executing [s@freezingtemp:8] BackGround("SIP/eheman-00000005", "press-1") in new stack
    -- <SIP/eheman-00000005> Playing 'press-1.ulaw' (language 'en')
    -- Executing [s@freezingtemp:9] BackGround("SIP/eheman-00000005", "to-hear-msg-again") in new stack
    -- <SIP/eheman-00000005> Playing 'to-hear-msg-again.ulaw' (language 'en')
    -- Executing [s@freezingtemp:10] BackGround("SIP/eheman-00000005", "press-2") in new stack
    -- <SIP/eheman-00000005> Playing 'press-2.ulaw' (language 'en')
    -- Executing [s@freezingtemp:11] BackGround("SIP/eheman-00000005", "to-hang-up") in new stack
    -- <SIP/eheman-00000005> Playing 'to-hang-up.ulaw' (language 'en')
    -- Executing [s@freezingtemp:12] WaitExten("SIP/eheman-00000005", "TIMEOUT") in new stack
    -- Executing [2@freezingtemp:1] Goto("SIP/eheman-00000005", "msgack,s,1") in new stack
    -- Goto (msgack,s,1)
    -- Executing [s@msgack:1] Playback("SIP/eheman-00000005", "thank-you-cooperation") in new stack
    -- <SIP/eheman-00000005> Playing 'thank-you-cooperation.ulaw' (language 'en')
    -- Executing [s@msgack:2] Playback("SIP/eheman-00000005", "vm-goodbye") in new stack
    -- <SIP/eheman-00000005> Playing 'vm-goodbye.ulaw' (language 'en')
    -- Executing [s@msgack:3] Hangup("SIP/eheman-00000005", "") in new stack
  == Spawn extension (msgack, s, 3) exited non-zero on 'SIP/eheman-00000005'
[Mar  3 06:23:54] NOTICE[10544]: pbx_spool.c:426 attempt_thread: Call completed to sip/eheman

To reiterate, in the above received call, silence is heard where swift spoken word should have been heard.

For an inbound call from the device to an extension context that begins with a swift invocation, everything is heard normally.

I noted on the inbound call to the switch placed from the Cisco SPA112 that I traced to a context where swift calls are heard correctly that the verbose console information for that call starts with this:

== Using SIP RTP CoS mark 5

Not sure if that is significant or not.

The device is on a different LAN network connected via VPN.

Any guidance on further debugging traces that I can take or do is appreciated.

Have you added the IP range of the remote lan to your localnets for chan_sip or local_net lines if you are using chan_pjsip?

[quote=“johnkiniston, post:2, topic:69929, full:true”]
Have you added the IP range of the remote lan to your localnets for chan_sip or local_net lines if you are using chan_pjsip?
[/quote] No, I have not tried that. I’ll give it try and report back. I am not understanding why that might make a difference given that the call is made, answered, and sound files from Background are heard ok.

I added
localnet=192.168.0.0/255.255.0.0
to the sip.conf and reloaded sip. No change in symptoms.

I also added a “Background” invocation to the dialplan context preceding the first invocation of Swift. After answering, I could hear it play the specified file (happened to be “good-morning”), and then silence again when the Swift sounds should have been heard, followed again by being able to hear the subsequent Background files being played.

I reckon at this point, I should be suspicious of Swift, but I sure don’t understand why I can hear Swift calls if the call is initiated from the sip phone to the pbx, but not when the pbx initiates the call via a call file.

Ah my bad, I thought you were not getting any audio on your wan connected phones I misread your initial post.

hello, did you find any solution to this ? im suffering the same issue :frowning: