Re: Park customer dial transfer - Timeout

[JosephHajek]

Need a hand, attempted 7 transfers using the park customer dial feature... the last two failed (#1 and 2)... notice under C3HU it says DC 0 and BC 0 does this have anything to do with the error I got? Transfer # eventually times out with no ringing and says to contact system admin... leaving the hangup xfer line and park customer dial grey'd out so you cant redial to re-transfer on failed attempt. Best I found was recall customer and hope for the best on the next attempt... I dont like that solution... Any ideas Plz.???

these are my user stats from the system (Starred out transfer # and CLID):

MANUAL OUTBOUND CALLS FOR THIS TIME PERIOD: (10000 record limit)
# DATE/TIME CALL TYPE SERVER PHONE DIALED LEAD CALLERID ALIAS PRESET C3HU
1 2012-08-02 19:08:52 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1 BC 0
2 2012-08-02 19:08:39 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1 DC 0
3 2012-08-02 19:08:25 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1
4 2012-08-02 19:08:20 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1
5 2012-08-02 19:08:04 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1
6 2012-08-02 19:07:58 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1
7 2012-08-02 19:07:49 XFER_3WAY 192.168.1.2 8600059 Local/91949*******@default 683089 760******* D1


Thanks,

Joe

[williamconley]

1) Welcome aboard!

2) when you post, please post your entire configuration including (but not limited to) your installation method and vicidial version with build.

this IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "from scratch" you must post your operating system and should also post the .iso version from which you installed your original operating system. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3) Asterisk Command line output from a failure is much more helpful than ... (actually I'm not even sure where this information came from, it looks like a report ... but trying to troubleshoot from a report is like trying to fix a car using the "owners manual", LOL)

[JosephHajek]

TY

I use the Goautodial CE 2.1 from .iso | Version: 2.4b0.5 | Asterisk Version 1.4.39.1-vici | Vicidial Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel Core2Quad Q8300 @2.5GHz | 3GB RAM | 500GB HDD | I am using the Goautodial.com VOIP as Trunk...

I think it has something to do with this line as it shows up every time the dial times out on the transfer number and it tells me to contact my administrator: [Aug 1 17:50:45] DEBUG[15861] app_meetme.c: Ooh, something swapped out under us, starting over

But here is the CLI around the call just in case.

[Aug 1 17:50:41] VERBOSE[15812] logger.c: [Aug 1 17:50:41] -- Executing [919492014147@default:1] AGI("Local/919492014147@default-b2f0,2", "agi://127.0.0.1:4577/call_log") in new stack
[Aug 1 17:50:41] VERBOSE[15814] logger.c: [Aug 1 17:50:41] == Parsing '/etc/asterisk/manager.conf': [Aug 1 17:50:41] VERBOSE[15814] logger.c: [Aug 1 17:50:41] Found
[Aug 1 17:50:41] VERBOSE[15814] logger.c: [Aug 1 17:50:41] == Manager 'sendcron' logged on from 127.0.0.1
[Aug 1 17:50:41] VERBOSE[15812] logger.c: [Aug 1 17:50:41] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Aug 1 17:50:41] VERBOSE[15812] logger.c: [Aug 1 17:50:41] -- Executing [919492014147@default:2] Dial("Local/919492014147@default-b2f0,2", "SIP/19492014147@goautodial||tTo") in new stack
[Aug 1 17:50:41] VERBOSE[15812] logger.c: [Aug 1 17:50:41] -- Called 19492014147@goautodial
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] == Spawn extension (default, 8301, 0) exited non-zero on 'SIP/goautodial-0001794f'
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Executing [8301@default:1] Answer("SIP/goautodial-0001794f", "") in new stack
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Executing [8301@default:2] AGI("SIP/goautodial-0001794f", "park_CID.agi") in new stack
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Launched AGI Script /var/lib/asterisk/agi-bin/park_CID.agi
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Aug 1 17:50:41] VERBOSE[11080] logger.c: [Aug 1 17:50:41] -- Playing 'sip-silence' (escape_digits=) (sample_offset 0)
[Aug 1 17:50:41] WARNING[11080] res_musiconhold.c: Music on Hold class 'default' not found
[Aug 1 17:50:41] WARNING[11080] res_musiconhold.c: Music on Hold class 'default' not found
[Aug 1 17:50:42] VERBOSE[15717] logger.c: [Aug 1 17:50:42] -- SIP/goautodial-00017a33 is making progress passing it to Local/915596554798@default-af1d,2
[Aug 1 17:50:43] VERBOSE[15814] logger.c: [Aug 1 17:50:43] == Manager 'sendcron' logged off from 127.0.0.1
[Aug 1 17:50:43] VERBOSE[15680] logger.c: [Aug 1 17:50:43] -- SIP/goautodial-00017a30 is making progress passing it to Local/916613605712@default-cf2d,2
[Aug 1 17:50:44] VERBOSE[3109] logger.c: [Aug 1 17:50:44] -- Got SIP response 500 "Server internal failure" back from 96.31.86.214
[Aug 1 17:50:44] VERBOSE[15680] logger.c: [Aug 1 17:50:44] -- SIP/goautodial-00017a30 is circuit-busy
[Aug 1 17:50:44] VERBOSE[15680] logger.c: [Aug 1 17:50:44] == Everyone is busy/congested at this time (1:0/1/0)
[Aug 1 17:50:44] VERBOSE[15680] logger.c: [Aug 1 17:50:44] -- Executing [916613605712@default:3] Hangup("Local/916613605712@default-cf2d,2", "") in new stack
[Aug 1 17:50:44] VERBOSE[15680] logger.c: [Aug 1 17:50:44] == Spawn extension (default, 916613605712, 3) exited non-zero on 'Local/916613605712@default-cf2d,2'
[Aug 1 17:50:44] VERBOSE[15680] logger.c: [Aug 1 17:50:44] -- Executing [h@default:1] DeadAGI("Local/916613605712@default-cf2d,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----38-----CONGESTION----------") in new $
[Aug 1 17:50:45] VERBOSE[15812] logger.c: [Aug 1 17:50:45] -- SIP/goautodial-00017a37 answered Local/919492014147@default-b2f0,2
[Aug 1 17:50:45] VERBOSE[15811] logger.c: [Aug 1 17:50:45] > Channel Local/919492014147@default-b2f0,1 was answered.
[Aug 1 17:50:45] VERBOSE[15861] logger.c: [Aug 1 17:50:45] -- Executing [8600055@default:1] MeetMe("Local/919492014147@default-b2f0,1", "8600055|F") in new stack
[Aug 1 17:50:45] DEBUG[15861] app_meetme.c: Ooh, something swapped out under us, starting over
[Aug 1 17:50:45] VERBOSE[15812] logger.c: [Aug 1 17:50:45] -- Executing [h@default:1] DeadAGI("Local/919492014147@default-b2f0,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----4-----0") in new st$
[Aug 1 17:50:45] VERBOSE[15812] logger.c: [Aug 1 17:50:45] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---4-----0 completed, returning 0
[Aug 1 17:50:45] VERBOSE[15812] logger.c: [Aug 1 17:50:45] == Spawn extension (default, 919492014147, 2) exited non-zero on 'Local/919492014147@default-b2f0,2'
[Aug 1 17:50:45] VERBOSE[15680] logger.c: [Aug 1 17:50:45] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Aug 1 17:50:45] VERBOSE[15869] logger.c: [Aug 1 17:50:45] == Parsing '/etc/asterisk/manager.conf': [Aug 1 17:50:45] VERBOSE[15869] logger.c: [Aug 1 17:50:45] Found
[Aug 1 17:50:45] VERBOSE[15869] logger.c: [Aug 1 17:50:45] == Manager 'sendcron' logged on from 127.0.0.1
[Aug 1 17:50:45] VERBOSE[15870] logger.c: [Aug 1 17:50:45] -- Executing [912096327857@default:1] AGI("Local/912096327857@default-d84f,2", "agi://127.0.0.1:4577/call_log") in new stack
[Aug 1 17:50:45] VERBOSE[15870] logger.c: [Aug 1 17:50:45] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Aug 1 17:50:45] VERBOSE[15870] logger.c: [Aug 1 17:50:45] -- Executing [912096327857@default:2] Dial("Local/912096327857@default-d84f,2", "SIP/12096327857@goautodial||tTo") in new stack
[Aug 1 17:50:45] VERBOSE[15870] logger.c: [Aug 1 17:50:45] -- Called 12096327857@goautodial
[Aug 1 17:50:45] VERBOSE[15714] logger.c: [Aug 1 17:50:45] -- SIP/goautodial-00017a32 answered Local/914155738327@default-4fcc,2
[Aug 1 17:50:45] VERBOSE[15713] logger.c: [Aug 1 17:50:45] > Channel Local/914155738327@default-4fcc,1 was answered.
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- Executing [8369@default:1] Playback("Local/914155738327@default-4fcc,1", "sip-silence") in new stack
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- <Local/914155738327@default-4fcc,1> Playing 'sip-silence' (language 'en')
[Aug 1 17:50:45] WARNING[15874] file.c: Unexpected control subclass '-1'
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- Executing [8369@default:2] AGI("Local/914155738327@default-4fcc,1", "agi://127.0.0.1:4577/call_log") in new stack
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- Executing [8369@default:3] AMD("Local/914155738327@default-4fcc,1", "2000|2000|1000|5000|120|50|4|256") in new stack
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- AMD: Local/914155738327@default-4fcc,1 7608260217 (null) (Fmt: 64)
[Aug 1 17:50:45] VERBOSE[15874] logger.c: [Aug 1 17:50:45] -- AMD: initialSilence [2000] greeting [2000] afterGreetingSilence [1000] totalAnalysisTime [5000] minimumWordLength [120] betweenWordsSilence [50] maximumNumberOfWords [4$
[Aug 1 17:50:46] VERBOSE[15874] logger.c: [Aug 1 17:50:46] -- AMD: Changed state to STATE_IN_SILENCE
[Aug 1 17:50:46] VERBOSE[15714] logger.c: [Aug 1 17:50:46] -- Executing [h@default:1] DeadAGI("Local/914155738327@default-4fcc,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----11-----1") in new s$
[Aug 1 17:50:47] VERBOSE[15714] logger.c: [Aug 1 17:50:47] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... --11-----1 completed, returning 0
[Aug 1 17:50:47] VERBOSE[15714] logger.c: [Aug 1 17:50:47] == Spawn extension (default, 914155738327, 2) exited non-zero on 'Local/914155738327@default-4fcc,2'
[Aug 1 17:50:47] VERBOSE[15811] logger.c: [Aug 1 17:50:47] == Manager 'sendcron' logged off from 127.0.0.1
[Aug 1 17:50:47] VERBOSE[15679] logger.c: [Aug 1 17:50:47] == Manager 'sendcron' logged off from 127.0.0.1
[Aug 1 17:50:47] VERBOSE[15713] logger.c: [Aug 1 17:50:47] == Manager 'sendcron' logged off from 127.0.0.1
[Aug 1 17:50:48] VERBOSE[15874] logger.c: [Aug 1 17:50:48] -- AMD: ANSWERING MACHINE: silenceDuration:2000 initialSilence:2000
[Aug 1 17:50:48] VERBOSE[15874] logger.c: [Aug 1 17:50:48] -- Executing [8369@default:4] AGI("SIP/goautodial-00017a32", "VD_amd.agi|8369") in new stack

[williamconley]

Got SIP response 500 "Server internal failure" back from 96.31.86.214

I would probably ask my provider why they are having server internal failures. That's not a good thing. Get another provider if they cannot supply an explanation and stop this.

Does this also happen each time?

[JosephHajek]

It shows up now and again but that is goautodials inhouse voip for you, it doesnt show up parallel to timeouts. but I will try a new trunk and let you know if the problem presists.

[williamconley]

Well, from what I understand they are running "Virtual".

If you can get it to be predictable in any way (so you can be sure to be logging when it happens), you can try a sip debug capture and see what the difference is between these and working calls. Then we can see what to do about making the system fail them properly.

Also check your server load. If you are running on a virtual machine or an underpowered machine and using AMD ... server load could definitely spike and cause completely unpredictable results (no way to catch a "spike", they are too quick ... but they cause missed timing ticks in the cpu ... and anything can happen, LOL).