Page 1 of 1

transfer conf issues since upgrde

PostPosted: Wed Feb 12, 2014 1:53 pm
by bobchaos
Hello everyone, I'm having an issue with a client's system. I upgraded him to the latest trunk (VERSION: 2.8-425a BUILD: 140206-1357, still using Asterisk 1.4, orginal install done using Vicibox) using the instructions provided on the forum sticky. Since completing the upgrade, I can't seem to get 3-way conferenciong to work from the agent screen. When I try the consultative transfer, the 3rd party never rings and I get this in the console:


[Feb 12 13:24:35] -- Executing [8600054@default:1] MeetMe("Local/90009**CXFER*252894**5145555555*2006*915145555555*22*@default-4", "8600054|F") in new stack
[Feb 12 13:24:35] -- Hungup 'IAX2/127.0.0.1:40569-3459'
[Feb 12 13:24:35] == Everyone is busy/congested at this time (1:0/0/1)

Which seems to indicate something is wrong with ASTloop, but I verified and it uses default settings. These are the only symptoms as far as I can tell, all the other functions are working great. Clues anyone? Here's a sample dial extension:

exten => _91NXXNXXXXXX,1,Set(CALLERID(name)=${CALLERID(num)})
exten => _91NXXNXXXXXX,2,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,3,Dial(${TRUNKMAIN}/${EXTEN:1},,To)
exten => _91NXXNXXXXXX,4,Hangup

Re: transfer conf issues since upgrde

PostPosted: Wed Feb 12, 2014 4:20 pm
by bobchaos
So after poking around some more I realized everything works fine if I untick "consultative xfer". I bumped into a new issue, which seems to be related to something I bumped into some time ago (and never managed to fix :( ). See viewtopic.php?f=4&t=27864 for details of the other issue.

When i make a manual call and during scheduled and reserved callbacks, the system never detectes the call as being live. As a result, the transfer conf button remains grey (among other issues.). This doens't happen with any other of my clients, and I suspect it may have something to do with the fact he uses PRIs instead of a SIP trunk as it's the only major difference in the setup.

If i do a callback dial, the call goes through, but when answered vicidial.php still show Waiting for ring, and eventually the dial timeout window appears, even though the call is actually connected. This is a major issue as the agents cannot transfer to an (off-site) closer during callbacks. Clues anyone?

Re: transfer conf issues since upgrde

PostPosted: Thu Feb 13, 2014 7:17 am
by mflorell
Why are you altering the callerIDname?

That is most likely the cause of your problems.

Are you calling into Canada?

Re: transfer conf issues since upgrde

PostPosted: Thu Feb 13, 2014 10:09 am
by bobchaos
I'm altering callerID name because that appears to be the parametre transmitted to remote parties by my provider. And yes I'm in Canada, calling other canadians, and your question got me on a new research path. Apparently carriers up here don't understand the concept of global standardization :P Am I correct in assuming I need to add the special Canadian loopback context for all my outbound dialing?

I'll test this as soon as i can.

Re: transfer conf issues since upgrde

PostPosted: Thu Feb 13, 2014 12:03 pm
by mflorell
Yes, if you want to alter CIDname then you have to dial through a loopback in Vicidial if you want everything to work properly.

Re: transfer conf issues since upgrde

PostPosted: Thu Feb 13, 2014 12:32 pm
by bobchaos
I have tested a solution using the loopback and manual calls now actually show the call status :D sadly it always shows "hung up" and this shows up in the console:

[Feb 13 12:21:36] -- Called ASTloop:SuperSecretPW@127.0.0.1:40569/88818777765743
[Feb 13 12:21:36] -- Hungup 'IAX2/127.0.0.1:40569-13986'
[Feb 13 12:21:36] == Everyone is busy/congested at this time (1:0/0/1)

I verified the connection string is good and ASTloop shows as an IAX2 peer with status OK connected at 127.0.0.1. Any last piece of insight for me?

Either way, thanks a lot Matt, this is a HUGE help to me.

Re: transfer conf issues since upgrde

PostPosted: Thu Feb 13, 2014 2:30 pm
by bobchaos
So that last issue turned out to be just a faulty dialplan entry. Everything works fine now. Thanks!