Stuck on Waiting for Ring.1 seconds, cannot hang up properly

[okli]

Hi,

We have :
Asterisk 1.2.24
Zaptel 1.2.21
Libpri 1.2.6
Apache 2.2.3
MySQL 5.0.32
vicidial 2.0.3
Debian 4.0, kernel 2.6.18-5-amd64 (SMP)

Agents are on Linksys PAP2T, using SIP trunk for outbound calls. No T1 cards, using ztdummy.

Everything works fine, manual, inbound and auto- dial, except when we have wrong or disconnected number in the list, on some occasions hang up doesn't work properly.
For example if I dial manually that number first 3-4 calls to it I hear busy signal and can hang up and dispo that call just fine.
Then on 5th or 6th call hitting HANG UP CUSTOMER doesn't lead to dispo screen, at the top of page ALT PHONE...FINISH LEAD links briefly show and disappear, then HANG UP and DIAL NEXT NUMBER are inactive, vicidial screen is stuck on "Waiting for Ring... 1 seconds". Attempts to make manual or fast dial lead to something like "you must be paused to make a new call".
The only solution is to log out and log in.

On campaign status screen I see the phone is in call.

screen -r output:

There are several suitable screens on:
2995.ASTfastlog (Detached)
2973.ASTupdate (Detached)
2976.ASTsend (Detached)
2979.ASTlisten (Detached)
2886.asterisk (Detached)
2982.ASTVDauto (Detached)
2985.ASTVDremote (Detached)
Type "screen [-d] -r [pid.]tty.host" to resume one of them.

This is asterisk CLI while making this call and hangup:

== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
-- Executing MeetMe("Local/8600200@default-7733,2", "8600200") in new stack
> Channel Local/8600200@default-7733,1 was answered.
-- Executing Dial("Local/8600200@default-7733,1", "SIP/7783299***/19056641373|55|tTo") in new stack
-- Called 7783299***/19056641373
-- SIP/7783299***-006a92b0 is making progress passing it to Local/8600200@default-7733,1
== Manager 'sendcron' logged off from 127.0.0.1
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'sendcron' logged on from 127.0.0.1
== Spawn extension (default, 919056641373, 1) exited non-zero on 'Local/8600200@default-7733,1'
-- Executing DeadAGI("Local/8600200@default-7733,1", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing DeadAGI("Local/8600200@default-7733,1", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
-- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcause ... ----------) completed, returning 0
== Spawn extension (default, 8600200, 1) exited non-zero on 'Local/8600200@default-7733,2'
-- Executing DeadAGI("Local/8600200@default-7733,2", "agi://127.0.0.1:4577/call_log") in new stack
-- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
-- Executing DeadAGI("Local/8600200@default-7733,2", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0---------------)") in new stack
-- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcause ... ----------) completed, returning 0
== Manager 'sendcron' logged off from 127.0.0.1
vici*CLI>

Part of extensions.conf:

exten => h,1,DeadAGI(agi://127.0.0.1:4577/call_log)
exten => h,2,DeadAGI(agi://127.0.0.1:4577/VD_hangup--HVcause ... EBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}))
;dial a local number
exten =>_NXXXXXXXXX,1,Dial(${TRUNK}/${EXTEN},55,tTo)
exten =>_NXXXXXXXXX,2,Hangup()

exten =>_9NXXXXXXXXX,1,Dial(${TRUNK}/${EXTEN:1},55,tTo)
exten =>_9NXXXXXXXXX,2,Hangup()

exten =>_9900XXXXXXX,1,Playback(please-contact-tech-supt)
exten =>_9900XXXXXXX,2,Hangup()

exten =>_91900XXXXXXX,1,Playback(please-contact-tech-supt)
exten =>_91900XXXXXXX,2,Hangup()

exten =>_91700XXXXXXX,1,Playback(please-contact-tech-supt)
exten =>_91700XXXXXXX,2,Hangup()

; dial an 800 outbound number
exten => _91800NXXXXXX,1,Dial(${TRUNK}/${EXTEN:1},55,tTo)
exten => _91800NXXXXXX,2,Hangup
exten => _91888NXXXXXX,1,Dial(${TRUNK}/${EXTEN:1},55,tTo)
exten => _91888NXXXXXX,2,Hangup
exten => _91877NXXXXXX,1,Dial(${TRUNK}/${EXTEN:1},55,tTo)
exten => _91877NXXXXXX,2,Hangup
exten => _91866NXXXXXX,1,Dial(${TRUNK}/${EXTEN:1},55,tTo)
exten => _91866NXXXXXX,2,Hangup

; dial a long distance outbound number
exten => _91NXXNXXXXXX,1,Dial(${TRUNK}/${EXTEN:1},55,tTo)
exten => _91NXXNXXXXXX,2,Hangup

; dial a local outbound number (modified because of only LD T1)
exten => _9NXXXXXX,1,Dial(${TRUNK}/1727${EXTEN:1},55,tTo)
exten => _9NXXXXXX,2,Hangup

Do you need any other log file or output ?

During installation I deleted by mistake 1 of the vicidial conferences in MySQL vicidial_conferences table. When I deleted that table in MySQL and recreated it, somehow all entries got sorted backwards- 200 at top, 51 at bottom. For now this seems not to be an issue as vici starts from 200, next agent gets 199 and so on. May not be relevant, but wanted to mention that too.

A few other questions about vicidial:
1. When selecting callback time, does it have to be agent's local time or the called number local time? Couldn't find the answer in both manuals.
2. When adding new leads to an existing list, new numbers go on bottom of the list. Can I change vicidial List_order to UP with immediate effect, and without having agents to log off and on, so it starts dialing new numbers right away?

Thanks in advance.

[masaboor]

That might be the problem with ur voip provider.Try using ur voip account with some other manual dialer and test it with incorrect numbers.

[okli]

The SIP trunk we are using is another Asterisk box serving also our old dialer, which we gonna shut down as soon as we move completely to vicidial.

I can get access to that box monday, but have no idea what to look for. What could be causing this hung of vicidial web page? Timeout rules in the dial plan or what? The 2 boxes are connected directly using their second network inteface.

Any idea about the other questions?

[okli]

A little update- this happens in massages file in /var/asterisk/log

I called the wrong number only once and managed to get vicidial page stuck at "waiting...."

Code: Select all

 2 22:31:08 VERBOSE[12390] logger.c:   == Parsing '/etc/asterisk/manager.conf': Dec  2 22:31:08 VERBOSE[12390] logger.c:   == Parsing '/etc/asterisk/manager.conf': Found
Dec  2 22:31:08 VERBOSE[12390] logger.c:   == Manager 'sendcron' logged on from 127.0.0.1
Dec  2 22:31:08 DEBUG[12390] manager.c: Manager received command 'Originate'
Dec  2 22:31:08 VERBOSE[12392] logger.c:     -- Executing MeetMe("Local/8600200@default-83eb,2", "8600200") in new stack
Dec  2 22:31:08 DEBUG[2892] channel.c: Avoiding initial deadlock for 'Local/8600200@default-83eb,2'
Dec  2 22:31:08 VERBOSE[12390] logger.c:        > Channel Local/8600200@default-83eb,1 was answered.
Dec  2 22:31:08 DEBUG[12392] app_meetme.c: Placed channel Local/8600200@default-83eb,2 in ZAP conf 1023
Dec  2 22:31:08 VERBOSE[12393] logger.c:     -- Executing Dial("Local/8600200@default-83eb,1", "SIP/778329****/19056641373|55|tTo") in new stack
Dec  2 22:31:08 DEBUG[12393] chan_sip.c: Setting NAT on RTP to 0
Dec  2 22:31:08 DEBUG[12393] chan_sip.c: Outgoing Call for 19056641373
Dec  2 22:31:08 VERBOSE[12393] logger.c:     -- Called 778329****/19056641373
Dec  2 22:31:08 DEBUG[2907] chan_sip.c: Acked pending invite 102
Dec  2 22:31:08 DEBUG[2907] chan_sip.c: Stopping retransmission on '39a4470406c2a33147a4e67a57865bbb@10.17.17.3' of Request 102: Match Found
Dec  2 22:31:08 DEBUG[2907] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '39a4470406c2a33147a4e67a57865bbb@10.17.17.3' Request 103: Found
Dec  2 22:31:08 DEBUG[2907] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '39a4470406c2a33147a4e67a57865bbb@10.17.17.3' Request 103: Found
Dec  2 22:31:08 VERBOSE[12393] logger.c:     -- SIP/778329****-006aa330 is making progress passing it to Local/8600200@default-83eb,1
Dec  2 22:31:08 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:09 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:09 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:10 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:10 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:10 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:11 DEBUG[2907] chan_sip.c: Stopping retransmission on '64012919061a07a07d2fa5a5557c2de8@10.17.17.3' of Request 102: Match Found
Dec  2 22:31:11 DEBUG[12390] manager.c: Manager received command 'Logoff'
Dec  2 22:31:11 VERBOSE[12390] logger.c:   == Manager 'sendcron' logged off from 127.0.0.1
Dec  2 22:31:11 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:11 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:12 DEBUG[12405] manager.c: Manager received command 'Login'
Dec  2 22:31:12 VERBOSE[12405] logger.c:   == Parsing '/etc/asterisk/manager.conf': Dec  2 22:31:12 VERBOSE[12405] logger.c:   == Parsing '/etc/asterisk/manager.conf': Found
Dec  2 22:31:12 VERBOSE[12405] logger.c:   == Manager 'sendcron' logged on from 127.0.0.1
Dec  2 22:31:12 DEBUG[12405] manager.c: Manager received command 'Hangup'
Dec  2 22:31:12 DEBUG[12393] chan_sip.c: update_call_counter(19056641373) - decrement call limit counter
Dec  2 22:31:12 DEBUG[12393] chan_sip.c: Acked pending invite 103
Dec  2 22:31:12 DEBUG[12393] chan_sip.c: Stopping retransmission on '39a4470406c2a33147a4e67a57865bbb@10.17.17.3' of Request 103: Match Found
Dec  2 22:31:12 DEBUG[12393] app_dial.c: Exiting with DIALSTATUS=CANCEL.
Dec  2 22:31:12 VERBOSE[12393] logger.c:   == Spawn extension (default, 919056641373, 1) exited non-zero on 'Local/8600200@default-83eb,1'
Dec  2 22:31:12 VERBOSE[12393] logger.c:     -- Executing DeadAGI("Local/8600200@default-83eb,1", "agi://127.0.0.1:4577/call_log") in new stack
Dec  2 22:31:12 DEBUG[2907] chan_sip.c: Stopping retransmission on '39a4470406c2a33147a4e67a57865bbb@10.17.17.3' of Request 103: Match Not Found
Dec  2 22:31:12 DEBUG[2907] chan_sip.c: Stopping retransmission on '39a4470406c2a33147a4e67a57865bbb@10.17.17.3' of Request 103: Match Found
Dec  2 22:31:12 VERBOSE[12393] logger.c:     -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
Dec  2 22:31:12 VERBOSE[12393] logger.c:     -- Executing DeadAGI("Local/8600200@default-83eb,1", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------)") in new stack
Dec  2 22:31:12 VERBOSE[12393] logger.c:     -- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0-----CANCEL----------) completed, returning 0
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '"M1202223108000002486" <0000000000>'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '0000000000'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '919056641373'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'default'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'Local/8600200@default-83eb,1'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'SIP/778329****-006aa330'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'Dial'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'SIP/778329****/19056641373|55|tTo'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '2007-12-02 22:31:08'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '(null)'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '2007-12-02 22:31:12'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '4'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '0'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'ANSWERED'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is 'DOCUMENTATION'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '(null)'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '1196663468.4465'
Dec  2 22:31:12 DEBUG[12393] pbx.c: Function result is '(null)'
Dec  2 22:31:12 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:12 VERBOSE[12392] logger.c:   == Spawn extension (default, 8600200, 1) exited non-zero on 'Local/8600200@default-83eb,2'
Dec  2 22:31:12 VERBOSE[12392] logger.c:     -- Executing DeadAGI("Local/8600200@default-83eb,2", "agi://127.0.0.1:4577/call_log") in new stack
Dec  2 22:31:12 VERBOSE[12392] logger.c:     -- AGI Script agi://127.0.0.1:4577/call_log completed, returning 0
Dec  2 22:31:12 VERBOSE[12392] logger.c:     -- Executing DeadAGI("Local/8600200@default-83eb,2", "agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0---------------)") in new stack
Dec  2 22:31:12 VERBOSE[12392] logger.c:     -- AGI Script agi://127.0.0.1:4577/VD_hangup--HVcauses--PRI-----NODEBUG-----0---------------) completed, returning 0
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '"M1202223108000002486" <0000000000>'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '0000000000'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '8600200'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is 'default'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is 'Local/8600200@default-83eb,2'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '(null)'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is 'MeetMe'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '8600200'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '2007-12-02 22:31:08'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '2007-12-02 22:31:08'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '2007-12-02 22:31:12'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '4'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '4'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is 'ANSWERED'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is 'DOCUMENTATION'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '(null)'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '1196663468.4466'
Dec  2 22:31:12 DEBUG[12392] pbx.c: Function result is '(null)'
Dec  2 22:31:12 DEBUG[4563] manager.c: Manager received command 'Command'
Dec  2 22:31:13 DEBUG[4563] manager.c: Manager received command 'Command'

[mflorell]

What is the loadavg on the server when this happens?

How many agents?

[okli]

It happens even with 1 agent only.

vici:~#cat /proc/loadavg
0.90 0.35 0.20 2/147 10360

Agents reported that this hang up problem with answering machines and live calls too, but I cannot confirm 100%, since can't reproduce the problem.

ATM we have 2 agents in one campaign, and hang up problem occurred twice in 15 minutes.

[mflorell]

Have you tried using an IAX trunk?

Did you apply the cli_concise patch before compiling Asterisk on your system>?

[okli]

I can try using IAX between the 2 boxes tomorrow. For some reason the person, who was managing the asterisk (SIP trunk) box insists on using SIP, as more standardized and tested protocol.
If you think IAX is better choice in this case I'll take it without doubts.

CLI patch was applied when compiled asterisk as far as I remember, is there a way I can reconfirm that?


Earlier today with 3 agents logged in we had like 15-20 similar freezes at random phone numbers, some of them live call

An update- I've just created a new test campaign, with only 1 repeating number, the same I use for these tests- 905 664 1373. On manual dial I couldn't freeze vicidial screen for the first 10-15 calls. Then I got a message that hopper is empty, screen froze in a similar way, need to adjust hopper?
Logged out, made hopper from 5 to 50, logged back in, another 10-15 calls- no freeze. Made a "fast dial" call to the very same number and it froze from the first time, no error messages at all, just if I try to make another fast or manual dial it says "you must be paused to be able.."
s.

In the attached file are some logs around that time, including CLI from our SIP trunk. Last call I believe was made 20:57:07, hang up at 20:57:09. After this hang up vicidial web page got stuck at "waiting for ...."
Hope it helps.
http://www.fileden.com/files/2007/1/6/6 ... _hang1.zip

Something about our setup- at the office we have PAP2T devices, behind NAT, connecting to the VICIDIAL box. Proper different SIP and RTP ports are forwarded.
We also have trixbox, which is servicing the old dialer system, this box connects to the SIP trunk using SIP. Planning to get rid of this one. Ports are forwarded and are different from PAP2T devices.
Vicidial box and Sip trunk box are connected directly with their second interfaces.
The vicidial and Sip trunk box are remotely, both on public IPs.
No issues at all with sound quality or loss of sound in any direction.

[okli]

IAX didn't make difference.
On manual dial I can make say 10-15 calls to a wrong number.
Using "fast dial" option, this turns alt. number options on. On normal call after hitting HANG UP CUSTOMER options come on top of screen- MAIN PHONE ALT PHONE ADDRESS and FINISH LEAD, the latter gives me dispo screen.
In the cases it gets stuck, after hitting HANG UP CUSTOMER that menu comes up for less than a second and disappears, no dispo screen shows. Dial next number is inactive, as is hangup customer.
I have to log out and in to be able to make new calls.
Can anyone help with this?

[mflorell]

I have tried this and I cannot duplicate the problem on a stock system install.

[okli]

I think I found the reason- shame on me , as usual the most obvious things are under our nose - in the dial plan I was missing
exten =>_NXXXXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
I fixed it yesterday and today for 4-5 hours calling no hangs have occurred, hopefully that was it.

This causes vicidial_auto_calls to get filled with the manually dialed numbers.
I looked there when switching to auto dial didn't start calling and noticed like 30-40 entries. Probably when it reaches some number (the number of available channels?) no more calls can be made.

There is also a typo in scratch_install and the conf examples, which may not be important- the h extension-

exten => h,2,DeadAGI(agi://127.0.0.1:4577/VD_hangup--HVcause ... EBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME}))

Shouldn't it be
exten => h,2,DeadAGI(agi://127.0.0.1:4577/VD_hangup--HVcause ... EBUG-----${HANGUPCAUSE}-----${DIALSTATUS}-----${DIALEDTIME}-----${ANSWEREDTIME})

?

Thanks for replying and apologies if I wasted anyone's time.

[mflorell]

Thanks for the note on the extra ). Luckily Asterisk doesn't care about matching those as long as all begins are closed

[okli]

Hi again,

It seems the problem is in our provider indeed, causing some calls to fail, luckily it doesn't happen too often to interrupt out work badly.
The problem with vicidial_auto_calls seems not to be relevant in this case.

Our setup is:

agents with PAP2T -->asterisk 1.2.26.2-->asterisk 1.4.18-->T1 to provider
------------------------- BOX1 vicidial 2.0.4-------BOX2

I was testing with a softphone, connected to BOX2. Occasionally some calls fail, here is CLI output from that box :

x*CLI>
-- Executing [1XXXXX92979@from-sip:1] Dial("SIP/999111-b7709aa0", "Zap/g2/1XXXXX92979|60") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called g2/1XXXXX92979
-- Zap/25-1 is proceeding passing it to SIP/999111-b7709aa0
-- Zap/25-1 is making progress passing it to SIP/999111-b7709aa0
-- Channel 0/1, span 2 got hangup request, cause 31
[Feb 27 20:48:44] WARNING[5420]: app_dial.c:743 wait_for_answer: Unable to forward voice or dtmf
-- Hungup 'Zap/25-1'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [1XXXXX92979@from-sip:2] NoOp("SIP/999111-b7709aa0", "HANGUPCAUSE = 31") in new stack
-- Executing [1XXXXX92979@from-sip:3] GotoIf("SIP/999111-b7709aa0", "0?99991|1") in new stack
-- Executing [1XXXXX92979@from-sip:4] GotoIf("SIP/999111-b7709aa0", "0?99992|1") in new stack
-- Executing [1XXXXX92979@from-sip:5] GotoIf("SIP/999111-b7709aa0", "0?99992|1") in new stack
-- Executing [1XXXXX92979@from-sip:6] GotoIf("SIP/999111-b7709aa0", "0?99992|1") in new stack
-- Executing [1XXXXX92979@from-sip:7] GotoIf("SIP/999111-b7709aa0", "0?99993|1") in new stack
-- Executing [1XXXXX92979@from-sip:8] GotoIf("SIP/999111-b7709aa0", "0?99993|1") in new stack
-- Executing [1XXXXX92979@from-sip:9] Hangup("SIP/999111-b7709aa0", "") in new stack
== Spawn extension (from-sip, 1XXXXX92979, 9) exited non-zero on 'SIP/999111-b7709aa0'
x*CLI>

Call doesn't get established at all and above happens in a second or two.

I have seen the similar output "Unable to forward voice or dtmf" when vicidial gets stuck at "waiting for ring...1 sec.". The button hangup becomes inactive and you have to log out and log in in order to start working again.

I am trying to get our provider to look at those failed calls, this is another story, but my question is why this affects VICIDIAL? It may be a good idea to make it more error- proof if that's the case.
What might cause this stuck at waiting for ring...?
Or the problem is in asterisk or elsewhere?

I have turned on verbose logging on both asterisk boxes, so next days I should be able to have detailed information if requested.

regards

[linuxlover]

did any one found solution of that Wwaiting for Ring.1 seconds, problem.

I am also facing the exactly same problem on manual compaigns.