vicidial.org

Hi,

I'm having this problem that even with upgrading, reinstalling from scratch then upgrading cannot be mitigated.

The issue is sometimes 3-way transfer with customer to an internal extension hangs with a 'Waiting for dial...' and even though the agent picksup the message will stay there and can't leave the call, this doesn't always happen, just once in a while.

I had to remove hosts and IPs as I am not allowed to post them, detected as off site urls.

sip.conf

Code: Select all

[vitel-inbound3]
type=friend
dtmfmode=auto

context=trunkinbound
allow=all
insecure=port,invite
canreinvite=no

[vitel-outbound]
type=friend
dtmfmode=auto

allow=all
canreinvite=no

[vitel-inbound]
type=friend
dtmfmode=auto
context=trunkinbound
username=xxxxxxxxxxxx
secret=xxxxxxxxxxx
allow=all
insecure=port,invite
canreinvite=no


The server is setup like this:

Code: Select all

ISP1 -> ViciDial Server     ISP2
                __|_________|___
                S   W   I   T   C   H
                             |
 agents phones and computers


ISP1 is a 10 mbps dedicated line
ISP2 is a 20/5 mbps asymetric for general web use

*bump*

any help over here? Any way to have internal extensions not wait for ring? Thanks.

3way calling was designed to be external(internal transfers were supposed to be to Vicidial agents), so if you want to do a 3way call to an internal non-vicidial agent, you need to pass the call through a call_log process just like calls to a carrier go through.

Thanks for your reply Matt,

Even when dialing agent's DIDs issue still happens.

When doing 3way with another agent through dialing their DID waiting for ring still shows up.

When you are calling an agent through their DID, are you going out through the carrier to the telco?

yes, we are. When dialing out it will go through a very standard and basic dialplan that will go through telco, telco then sends the call over to us and will go through the inbound context and dialplan, where vici now handles the rest of the process.

Do all of your outbound calling processes go through the proper call_log processes as their first step?

; exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)

Looks like it wasn't. I was using the defaultlog context for the phones instead of default to have all outgoing calls logged, and that context does not have that specified line as the first step.

I will test with the original default context and check how it behaves.

*bump*

Attempted and issue seem to have been resolved but lately is back again, for the last 2-3 days the issue happens now much more less times but still happens.

I moved everybody who has on the context defautllog to default, and make sure the first thing on the dialplan is

Code: Select all

exten => _1NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)


(We do not use the 9 in front of the numbers)

However, as said, the issue persists.... when dialing out Vici keeps waiting for ring, causing calls that do not require 3way to not get recorded correctly (sometimes the next call or that call won't get recorded), or when 3 way is required it won't allow to 3way, also causes when the first call worked just fine and the call to be in a 3-way call does not, then the agent won't be able to 'leave 3way' to leave the other 2 talking to each other.