Voicemailmain abrubt call abort

Hello, setting up a very basic asterisk 13 server on a Debian (jessy) host. In and outgoing calls are working fine, and I can call in- and external extensions. I compiled asterisk from source. So to take it to the next level, I configured voicemail (voicemail.conf), and created one mailbox (7001) for all my internal extensions (600X) in extensions.conf. Next, I set up extension 1001 for voicemail access (VoiceMailMain()) in extensions.conf.

I dialed in, and actually was able to place a new voicemail message. However, on trying to listen back, I get just a starting message (“you have one”) and then the call gets aborted, showing:

'Spawn extension (internal, , 2) exited non-zero on ‘SIP/’.

Which, I read somewhere, actually means that the call actually ended normally (really?)

With voicemail not being particularly useful this way, can someone pass some hints on how to troubleshoot this? Have tried google, but cannot find someone that has posted similar problems as far as I can tell.

TY, Jan Vergouwe, Netherlands

Just to rule out some possibilities, I have tried to migrate my configuration from a classic ‘chan sip’ to a more modern pjsip configuration. Dialing extensions works like a charm, both internal and external. Voicemail however still gives the same problems.

Can you please provide the complete console output and not just a snippet? The problem is likely before that.

Most certainly can:

(console started with asterisk -rcvvvvvv

Using SIP RTP CoS mark 5
– Executing [1001@internal:1] Answer(“SIP/6002-0000000e”, “”) in new stack
> 0x7f80f4009820 – Probation passed - setting RTP source address to 192.168.1.117:59436
– Executing [1001@internal:2] VoiceMailMain(“SIP/6002-0000000e”, “7001”) in new stack
– <SIP/6002-0000000e> Playing ‘vm-password.gsm’ (language ‘nl’)
– <SIP/6002-0000000e> Playing ‘vm-youhave.gsm’ (language ‘nl’)
– <SIP/6002-0000000e> Playing ‘digits/1.gsm’ (language ‘nl’)
== Spawn extension (internal, 1001, 2) exited non-zero on ‘SIP/6002-0000000e’

As far as i can tell (from what i’ve read so far) it looks as though the phone hangs up… will test with another (soft) phone to confirm this behaviour.

A “sip set debug on” would confirm if it was the phone or us that hung up.

That gives me something to look at :). Nothing too obvious though… and no worries about the posted md5 password hash by the way. Can you make something out of this?

<— SIP read from UDP:192.168.1.117:57066 —>
ACK sip:1001@192.168.1.144:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.117:57066;branch=z9hG4bK-524287-1—5122ede860b625cd;rport
Max-Forwards: 70
Contact: sip:6002@192.168.1.117:57066;transport=UDP
To: sip:1001@192.168.1.144;transport=UDP;tag=as75d20db2
From: sip:6002@192.168.1.144;transport=UDP;tag=ef20c303
Call-ID: 1NBzvDjOnitpP_qSIuKL8A…
CSeq: 2 ACK
User-Agent: Zoiper rv2.8.6
Content-Length: 0

<------------->
— (10 headers 0 lines) —
– Executing [1001@internal:2] VoiceMailMain(“SIP/6002-00000014”, “7001”) in new stack
– <SIP/6002-00000014> Playing ‘vm-password.gsm’ (language ‘nl’)
– <SIP/6002-00000014> Playing ‘vm-youhave.gsm’ (language ‘nl’)
– <SIP/6002-00000014> Playing ‘digits/1.gsm’ (language ‘nl’)
== Spawn extension (internal, 1001, 2) exited non-zero on 'SIP/6002-00000014’
Scheduling destruction of SIP dialog ‘1NBzvDjOnitpP_qSIuKL8A…’ in 6400 ms (Method: ACK)

set_destination: Parsing sip:6002@192.168.1.117:57066;transport=UDP for address/port to send to
set_destination: set destination to 192.168.1.117:57066
Reliably Transmitting (no NAT) to 192.168.1.117:57066:
BYE sip:6002@192.168.1.117:57066;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.1.144:5060;branch=z9hG4bK55c95dab;rport
Max-Forwards: 70
From: sip:1001@192.168.1.144;transport=UDP;tag=as75d20db2
To: sip:6002@192.168.1.144;transport=UDP;tag=ef20c303
Call-ID: 1NBzvDjOnitpP_qSIuKL8A…
CSeq: 102 BYE
User-Agent: J.Vergouwe-PBX
Proxy-Authorization: Digest username=“6002”, realm=“asterisk”, algorithm=MD5, uri=“sip:192.168.1.144”, nonce=“6c170fb6”, response="873a6583b0d511615ca2021b23e05597"
X-Asterisk-HangupCause: Unknown
X-Asterisk-HangupCauseCode: 0
Content-Length: 0

That would be us terminating the call. Is it possible that language does not have the needed sound file, and thus the call is hung up?

Will check on that… funny that a misplaced or missing file would break stuff. Tried some more (different) softphones, but all misbehave in the same way. So far; zoiper, xlite, 3cx. File hunting it is :).

Thx for the quick replies btw… its like a chat session :).

The users of file playback can be a bit harsh in how they handle the specific scenario where the file doesn’t exist. Some tolerate it a bit better. You’re welcome for the replies!

As I am probably gonna be blacklisted for posting ridiculously long posts anyways, here’s my sound file list for vm- files. Havent the faintest which file should be next, so I’ll slap my list here (all gathered in /var/lib/asterisk/sounds/en/):

vm-advopts.gsm vm-login.gsm vm-reenterpassword.gsm
vm-and.gsm vm-mailboxfull.gsm vm-repeat.gsm
vm-calldiffnum.gsm vm-marked-nonurgent.gsm vm-review.gsm
vm-changeto.gsm vm-marked-urgent.gsm vm-review-nonurgent.gsm
vm-Cust1.gsm vm-message.gsm vm-review-urgent.gsm
vm-Cust2.gsm vm-messages.gsm vm-saved.gsm
vm-Cust3.gsm vm-minutes.gsm vm-savedto.gsm
vm-Cust4.gsm vm-mismatch.gsm vm-savefolder.gsm
vm-Cust5.gsm vm-msgforwarded.gsm vm-savemessage.gsm
vm-deleted.gsm vm-msginstruct.gsm vm-saveoper.gsm
vm-delete.gsm vm-msgsaved.gsm vm-sorry.gsm
vm-dialout.gsm vm-newpassword.gsm vm-star-cancel.gsm
vm-duration.gsm vm-newuser.gsm vm-starmain.gsm
vm-enter-num-to-call.gsm vm-next.gsm vm-tempgreetactive.gsm
vm-extension.gsm vm-nobodyavail.gsm vm-tempgreeting2.gsm
vm-Family.gsm vm-nobox.gsm vm-tempgreeting.gsm
vm-first.gsm vm-no.gsm vm-tempremoved.gsm
vm-for.gsm vm-nomore.gsm vm-then-pound.gsm
vm-forward.gsm vm-nonumber.gsm vm-theperson.gsm
vm-forward-multiple.gsm vm-num-i-have.gsm vm-tmpexists.gsm
vm-forwardoptions.gsm vm-Old.gsm vm-tocallback.gsm
vm-Friends.gsm vm-onefor-full.gsm vm-tocallnum.gsm
vm-from-extension.gsm vm-onefor.gsm vm-tocancel.gsm
vm-from.gsm vm-options.gsm vm-tocancelmsg.gsm
vm-from-phonenumber.gsm vm-opts-full.gsm vm-toenternumber.gsm
vm-goodbye.gsm vm-opts.gsm vm-toforward.gsm
vm-helpexit.gsm vm-passchanged.gsm vm-tohearenv.gsm
vm-INBOX.gsm vm-password.gsm vm-tomakecall.gsm
vm-incorrect.gsm vm-pls-try-again.gsm vm-tooshort.gsm
vm-incorrect-mailbox.gsm vm-press.gsm vm-toreply.gsm
vm-instructions.gsm vm-prev.gsm vm-torerecord.gsm
vm-intro.gsm vm-reachoper.gsm vm-undeleted.gsm
vm-invalid-password.gsm vm-rec-busy.gsm vm-undelete.gsm
vm-invalidpassword.gsm vm-received.gsm vm-unknown-caller.gsm
vm-isonphone.gsm vm-rec-name.gsm vm-Urgent.gsm
vm-isunavail.gsm vm-record-prepend.gsm vm-whichbox.gsm
vm-last.gsm vm-rec-temp.gsm vm-Work.gsm
vm-leavemsg.gsm vm-rec-unv.gsm vm-youhave.gsm

This challenge would net you the achievement ‘eagle-eye’ probably :).

Your language is set to ‘nl’ and not ‘en’. Are you using a different sound pack?

Nope… I could switch the language, but i just tried attaching the vm-messages.gsm to an extension (PlayBack) and that goes awry… suspecting a corrupt file now… gonna replace the sound files with a fresh download and set the language to ‘en’ to see how that goes. Ty sir… this looks like the right track, much obliged. Will reply when it is solved.

Good luck! If you find anything of note from that don’t hesitate to pop back.

POP<<

Been quiet a bit, but busy. In short, the refresh of the audio files did not do much good. So I went the extra mile, and rebuilt my whole config from scratch (about 30 mins work, no worries). Short story: the problem remained. And thickened:

Apparently, if I have 1 voicemail message waiting, the reported problem occurs. If I have 2 messages waiting, everything falls through and works like a charm. Its black magic all over. I really have a hard time getting my head around this one.

Would be nice if someone could confirm on a fresh config based on debian jessie, asterisk-13.11.2 (13 current) from source. Or call me bonkers, that would be the other option of course.