Three way call gets dropped ALOT

[udfxrookie]

Still not having any resolution and not sure what the problem is. We make a call connecting customer B to agent A, then the agent dials (from 2143965565) to an automated verification recording (7868660355) C. Completing the three way call with Agent A, Customer B, Verification C.

Perfect scenario: A,B are good and when C joins it asks for agent ID, cust phone#, cust utility acct#, and then proceeds to ask the customer B questions to which after the response you must press the # button to continue on to the next question.

Here's our problems:
Biggest issue 1) A,B connect with C and it makes it past the first three questions and then hangs up the customer and keeps A,C connected. When B is questioned they say it sounds like dead air then they hear if you'd like to place a call type of sound.
2) A,B connect with C and it makes it past the first two questions (sometimes this happens on the first question) but will not proceed with prompts because failure to receive correct DTMF amount of tones to continue and replays the question.
3)A,B try to connect with C and it either doesn't connect and results in failure or is delayed in connecting sometimes up to 90 seconds.

In our company we have 5-15 Agents trying to connect with Verification and their Customer simultaneously all day long. We need help with this as quickly as possible.

My carrier is telling me that in Scenario 1 that they are recieving a by signal from my dial.... how and why?

Code: Select all

[ SIP ] 10:20:58.529133 <==== 108.9.164.50:5060
BYE sip:12155910750@38.102.250.161:5060 SIP/2.0
Via: SIP/2.0/UDP 108.9.164.50:5060;branch=z9hG4bK11c76194;rport
Route: <sip:38.102.250.50:5060;lr>
From: "M5241317210001839387" <sip:2143965565@108.9.164.50>;tag=as4df6065e
To: <sip:12155910750@38.102.250.50:5060;cpd=on>;tag=xtg-40495-18446744073676512385
Call-ID: 062c665c15c51539792d387c78c5c592@108.9.164.50
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "M5241317210001839387" <sip:2143965565@108.9.164.50>;privacy=off;screen=no
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0

Vicibox 3.10 from ViciBox_Redux.x86_64-3.1.10.iso | Vicidial 2.4-350a Build 111201-0939 | Asterisk 1.4 | Single All-in-one Server | No Digium/Sangoma Hardware | No Extra Software After Installation

[Staydog]

Are you using a direct SIP connection to your TPV? DTMF issues are common with a few of them and this is the way we fix it, normally.

[udfxrookie]

If I get a direct ip to dial into, which I'm sure they'll provide, I'm not to good with dial plans, how would I set that up?

[Staydog]

Unfortunately it is a little complicated. Here is how I would proceed:
1. Verify that your TPV supports Direct SIP Cross Connect
2. Contact your carrier and see if they will be able to set this up for you.
3. If that fails, you will have to set this up directly in Asterisk. If you are not good with dial plans, this will be difficult. I could not really walk you through this here and would advise getting some support time with VICIdial.

As long as your TPV supports Direct SIP Cross Connect, a VICIdial engineer will be able to set this up for you. Otherwise, you need to play hardball with your carrier to have them fix this issue.

[udfxrookie]

Ok, the TPV company does work with Vici and does offer Direct SIP Cross Connect.... they sent this to me:

voip-pos-e.samasher.com, port 5070

How do I use this so my verifiers click Transf-Conf and then ??? to connect to this (normally we do dial with customer and it dials the preset number)

[Staydog]

I cannot access that link, so I am not sure what they advised you to do. However, the way this works is when the call is being placed. That specific dial plan entry determines how the call is routed, so the change is happening on the back-end and your reps will have no knowledge. However they did this before, it will be the same. I suggest:
Consultative: the Agent & Customer are on the line together when the call is sent to a DID
1. Click the “TRANSFER-CONF” button on the left side agent screen
2. Enter the DID in the “NUMBER TO CALL” field
3. Press the “DIAL WITH CUSTOMER” button directly below.
4. After the 3rd party answers, the agent can then drop off the call by clicking the “LEAVE 3-WAY
CALL” button on the right (they can also use either the “HANGUP XFER LINE” or
“HANGUP BOTH LINES” buttons).

[udfxrookie]

That's the way we work it now and miss DTMF tones etc.
Getting the direct link to them I was assuming I'd come up with something like:

exten => q,1,answer
exten => q,2,sayalpha(voip-pos-e.samasher.com:5070)
sxten => q,3,hangup
and in Preset put "q" so when the closer goes to bring the TPV recording on the line with themselves and the customer they would click:
Transfer-Conf, and Dial With Customer with the preset of "q" in the number to dial field....
am I on the right path? lol

[udfxrookie]

I also so this bit:

Code: Select all

Here is a copy of the extensions.conf logic I use to accomplish this.

exten => 300,1,Playback,sipextn
exten => 300,2,Read(DSTNE||8)
exten => 300,3,Playback,sipip
exten => 300,4,Read(DSTNI||15)
exten => 300,5,Playback,sipport
exten => 300,6,Read(DSTNP||4)
exten => 300,7,Cut(DSTNI1=DSTNI,*,1)
exten => 300,8,Cut(DSTNI2=DSTNI,*,2)
exten => 300,9,Cut(DSTNI3=DSTNI,*,3)
exten => 300,10,Cut(DSTNI4=DSTNI,*,4)
exten => 300,11,Dial,SIP/${DSTNE}@${DSTNI1}.${DSTNI2}.${DSTNI3}.${DSTNI4}:${DSTNP}

sipextn.gsm says "Please enter the SIP extension you wish to dial"
sipip.gsm says "Enter the SIP IP seperated by stars"
sipport.gsm says "Enter the SIP Port Number"

User dials in and types
102#
192*168*0*6#
5060

and is connected with SIP/102 at 192.168.0.6:5060
from http://lists.digium.com/pipermail/asterisk-users/2004-May/040436.html

Making me think I can create within extensions.conf the dial plan they show, just inserting what I already have as a known value:

Code: Select all

exten => 300,1,Dial,SIP/208.49.156.130:5070

[udfxrookie]

After using xlite to simply dial 300 and connect to verification I get this for results:

Code: Select all

[May 29 19:26:13]     -- Executing [300@default:1] Dial("SIP/7012-0000a1a4", "SIP/208.49.156.130:5070") in new stack
[May 29 19:26:13]     -- Called 208.49.156.130:5070
[May 29 19:26:13]     -- SIP/208.49.156.130:5070-0000a1a5 is circuit-busy
[May 29 19:26:13]   == Everyone is busy/congested at this time (1:0/1/0)
[May 29 19:26:13]   == Auto fallthrough, channel 'SIP/7012-0000a1a4' status is 'CONGESTION'
[May 29 19:26:13]     -- Executing [h@default:1] DeadAGI("SIP/7012-0000a1a4", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----1-----CONGESTION----------") in new stack
[May 29 19:26:13]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----1-----CONGESTION---------- completed, returning 0
[May 29 19:26:14]   == Parsing '/etc/asterisk/manager.conf': [May 29 19:26:14] Found


[udfxrookie]

Aside from all the direct sip connection. I use the regular 3 way calling method to dial in three way and my dialer hangs up on the call, this is from the carrier:

Code: Select all

Call Date Source Destination Customer Duration Billing Disp
May 24, 2012 10:17:21 AM 2143965565 2155910750 American Alar 03m 37s 03m 33s Answer

Again, our switch got BYE from your side.

[ SIP ] 10:20:58.529133 <==== 108.9.164.50:5060
BYE sip:12155910750@38.102.250.161:5060 SIP/2.0
Via: SIP/2.0/UDP 108.9.164.50:5060;branch=z9hG4bK11c76194;rport
Route: <sip:38.102.250.50:5060;lr>
From: "M5241317210001839387" <sip:2143965565@108.9.164.50>;tag=as4df6065e
To: <sip:12155910750@38.102.250.50:5060;cpd=on>;tag=xtg-40495-18446744073676512385
Call-ID: 062c665c15c51539792d387c78c5c592@108.9.164.50
CSeq: 103 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "M5241317210001839387" <sip:2143965565@108.9.164.50>;privacy=off;screen=no
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


how do I figure out what's wrong and fix it, this issue causes a lot of lost calls.

[udfxrookie]

Here's the errors I get in the Asterisk log:

Code: Select all

I get these errors:
[Jun  5 10:50:36] WARNING[13341] res_agi.c: Running DeadAGI on a live channel will cause problems, please use AGI

[Jun  5 10:50:47] WARNING[2912] chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '24cacabf32c7ec0b40cc66c712dd9c88@108.9.164.50'. Giving up.

[Jun  5 10:50:54] WARNING[19115] app_meetme.c: Conference number '8600065' not found!

[Jun  5 10:52:15] WARNING[2912] chan_sip.c: Unsupported SDP media type in offer: image 41696 udptl t38
[


[udfxrookie]

To revisit this... an even that still happens. Today it happened and I saw this:

Code: Select all

[Oct  1 17:23:01] VERBOSE[15288] logger.c: [Oct  1 17:23:01]     -- SIP/xcast-0000eb36 answered Local/617868664922@default-4bd0,2
[Oct  1 17:23:01] VERBOSE[15287] logger.c: [Oct  1 17:23:01]        > Channel Local/617868664922@default-4bd0,1 was answered.
[Oct  1 17:23:01] VERBOSE[15329] logger.c: [Oct  1 17:23:01]     -- Executing [8600064@default:1] MeetMe("Local/617868664922@default-4bd0,1", "8600064|F") in new stack
[Oct  1 17:23:01] DEBUG[15329] app_meetme.c: Ooh, something swapped out under us, starting over
[Oct  1 17:23:01] VERBOSE[15288] logger.c: [Oct  1 17:23:01]     -- Executing [h@default:1] DeadAGI("Local/617868664922@default-4bd0,2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----2-----0") in new stack
[Oct  1 17:23:01] VERBOSE[15288] logger.c: [Oct  1 17:23:01]     -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16-----ANSWER-----2-----0 completed, returning 0
[Oct  1 17:23:01] VERBOSE[15272] logger.c: [Oct  1 17:23:01]     -- AMD: HUMAN: silenceDuration:1000 afterGreetingSilence:1000
[Oct  1 17:23:01] VERBOSE[15288] logger.c: [Oct  1 17:23:01]   == Spawn extension (default, 617868660355, 2) exited non-zero on 'Local/617868664922@default-4bd0,2'


Here's the users log:

Code: Select all


#   DATE/TIME         LENGTH   STATUS          PHONE    CAMPAIGN     GROUP           LIST        LEAD     HANGUP REASON
3   2012-10-01 17:24:55    241     SALE        6102792395    VERIFY    Verification    2801    93320    CALLER
4   2012-10-01 17:22:36    96       B            6102792395    VERIFY    Verification    2801    93320    AGENT
5   2012-10-01 17:22:24    0        B            6102792395    VERIFY    Verification    2801    93320    AGENT

The "happening", the call gets transferred from the front to the verification, verification takes the customer and dials in a three way TPV. When the agents begins to dial in certain DTMF tones the get disconnected (certain as in customers phone number, etc)

Now I did see a cool little reference to this problem here:
http://www.eflo.net/VICIDIALforum/viewtopic.php?p=78251
but it never got resolved....
So to prep... Agent transfers to the verification in different campaign via Tansf-Conf, Local Closer
Local Closer takes call, click Transfer-Conf, Presets, The number to dial (in this case: 7868660355)... we use the same dialplan for entire dialer:

Code: Select all

exten => _61NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _61NXXNXXXXXX,n,Dial(${DIAL6TRUNK}/${EXTEN:1},,Ttor)
exten => _61NXXNXXXXXX,n,Dial(${DIAL8TRUNK}/${EXTEN:1},,Ttor)
exten => _61NXXNXXXXXX,n,Hangup

Failover from one carrier to a backup... ideas?

[mcargile]

Try removing the 't' and the 'r' options from your dial commands. I have seen this cause issues before.

[udfxrookie]

So try:

Code: Select all

exten => _61NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _61NXXNXXXXXX,n,Dial(${DIAL6TRUNK}/${EXTEN:1},,To)
exten => _61NXXNXXXXXX,n,Dial(${DIAL8TRUNK}/${EXTEN:1},,To)
exten => _61NXXNXXXXXX,n,Hangup

?

[williamconley]

And to be clear: How is this closer entering the information at the TPV? Keypad on phone or DTMF field on agent screen?

[Janky]

I am experiencing the same issue I currently do have a direct sip connection configured. The agents are entering the information from the keypad on softphone. Any advice is much appreciated

This occurs intermittently most 3 way tpv calls go with out issue. I have been reviewing the systems logs for any reason or cause for this issue but am coming up empty handed. Is there any specific log i should be checking?

VERSION: 2.4-363a
BUILD: 120402-2111
ViciBox

[williamconley]

the same issue

Please actually describe your issue in detail. This is a very long thread and making assumptions is a waste of time. Are you saying your TPV calls fail, or drop, or have no sound ... how do your agents initiate these TPV calls (button by button)? are the calls initially inbound or outbound? How are you routing the calls? What is your load when "the same issue" occurs? Can you show Asterisk Command line output from a single occurrence? (not 3000 lines of unrelated code, just CLI during a single occurrence, hopefully with some form of "error" on it).

[Janky]

the same issue

Please actually describe your issue in detail. This is a very long thread and making assumptions is a waste of time. Are you saying your TPV calls fail, or drop, or have no sound ... how do your agents initiate these TPV calls (button by button)? are the calls initially inbound or outbound? How are you routing the calls? What is your load when "the same issue" occurs? Can you show Asterisk Command line output from a single occurrence? (not 3000 lines of unrelated code, just CLI during a single occurrence, hopefully with some form of "error" on it).

The calls are initially outbound. Agent dials to TPV with customer on call via transfer and dial with customer option and enters the specific dialplan number for the tpv. I have a dial plan setup for direct sip connection to the tpv. Agent enters first couple TPV options then issue occurs customer cannot hear TPV or agent, It seems the agent is still on call with both parties but there is no audio being received by customer I am not 100% sure if the call is staying connected or a portion is being dropped this is one of the things i have been trying to determine.

Load on the server is fairly consistent.
load average: 0.27, 0.28, 0.20
214 active channels
103 active calls

I have been reviewing the logs to find an error but i have not found anything pertinent to the issue. I am checking further on the routing methods to ensure it is using the SIP connection. I will update further.

[williamconley]

It seems the agent is still on call with both parties but there is no audio being received by customer I am not 100% sure if the call is staying connected or a portion is being dropped this is one of the things i have been trying to determine.

So ... agent can hear TPV and customer ... TPV can hear customer and agent, but customer cannot hear anything? Never heard that one before.

Check the conference channels (at the bottom of the agent screen or at the command line) to see which leg or legs of the call are live.

Also test when there are NO live channels. You may be (with 103 calls) at a limit of some sort. Although 0.27 is not too loaded, I wonder if that was the load when the problem occurred or "just when you looked". Obviously the load at the moment of a failure is quite important.

Ordinarily, sound in one direction is a firewall issue. If you have a sip connection, that could be related .. but if the customer had sound until the TPV connected (and then lost sound), something else is afoot.

[Janky]

Thank you for the info.

I have checked my providers limits and from what they tell me I have more than enough available channels etc and I am not seeing any reports of congestion the available channel/call limits in vici are also configured higher than this number. I will try to catch the resource load at the time of an issue. Also i do not believe the TPV can hear the customer either. I also suspected a possible firewall issue and have found this to be the cause of other sound related issues in the past, Although I had somewhat the assumption that if it was only happening intermittently that firewall most likely is not the issue. I will check the other things you suggested, seeing that this happens randomly it is somewhat hard to duplicate.

[williamconley]

happens randomly is ordinarily load related.

Also: I was not questioning the number of channels at the carrier, I suggested you check the live channels in the agent conference. To see if the agent channel is terminated. These channels can be viewed on the agent screen (hyperlink near the bottom) or in asterisk with the meetme request for that conference.

[Janky]

I have been monitoring resources and there has been times where load was even higher than what i previously posted and there was no issues in TPV. Checking the live channels during the tpv so far it seems that all 3 are still connected I am still reviewing this to be sure. I am beginning to wonder if this may just be an issue unrelated to our systems and an issue at the TPV or possibly some type of connection latency between the agents workstation and phone system.

[williamconley]

Both are entirely possible. Wireshark will show dropping packets. SIP debugging will show disconnect requests and may even show "no response" moments. Try using another carrier for the TPV calls. Even if this does not resolve the issue, it gives you an IP address you can use with SIP debug that has only this traffic on it ... so instead of 150,000 lines of debug to sift through, your next occurrence may require only 5,000 lines of code to sift through. Then a bit of searching may find your problem.