Page 1 of 1

100% of PDROP calls

PostPosted: Thu Sep 13, 2012 1:03 pm
by marcoe
Hello guys,

I'm having some trouble setting up a carrier for the last week or so. All calls made from auto-dialer are dropped within 5 or 6 seconds after answered even with waiting users. I tested different situations and I can replicate the problem every time, here is what I did:

Made a Manual call >>> works.
Set up a different carrier and made an auto call >>> works, so it indicates a carrier problem.
Set up both carriers on different system/network/etc >>> same result as before, "trouble" carrier still drops calls.

So I decided to do a SIP debug on both carriers to find out some differences, and here it is:

"This is from the trouble carrier"
INVITE sip:01897267491@201.7.163.180;cpd=on SIP/2.0
Via: SIP/2.0/UDP 200.178.179.90:5060;branch=z9hG4bK5ffb9658;rport
From: "V9121511120000000320" <sip:0000000000@201.7.163.180>;tag=as255bbd64
To: <sip:01897267491@201.7.163.180;cpd=on>
Contact: <sip:0000000000@200.178.179.90>
Call-ID: 1a54515e077fd6a268a1486d588e21b8@201.7.163.180
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9121511120000000320" <sip:0000000000@201.7.163.180>;privacy=off;screen=no
Date: Wed, 12 Sep 2012 18:11:12 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 239


"This is the OK carrier"
INVITE sip:01897267491@sip1.tmaisngn.com.br;cpd=on SIP/2.0
Via: SIP/2.0/UDP 200.178.179.90:5060;branch=z9hG4bK0ead6441;rport
From: "V9121513400000000322" <sip:097236801@200.178.179.90>;tag=as0601becc
To: <sip:01897267491@sip1.tmaisngn.com.br;cpd=on>
Contact: <sip:097236801@200.178.179.90>
Call-ID: 46b4805824401e36100b93ac493afda4@200.178.179.90
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Remote-Party-ID: "V9121513400000000322" <sip:0000000000@200.178.179.90>;privacy=off;screen=no
Date: Wed, 12 Sep 2012 18:13:40 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 215


Notice how this headers send different information on these 2 fields, I wonder if this is what is causing the problem, my guess that AST_manager_listen can't find the call and then drops it, Or maybe this is totally out of my understanding of how Vicidial deals with auto calls.

I know the easier answer would be to use a different carrier/provider, BUT my client has very good rates on this one, and the provider is open for suggestions about their configuration.

Any thoughts ? Anybody else had something like this ?

This is my configuration: Vicibox Redux 3.1.15, Vicidial 2.4-357a BUILD: 120125-2107, on Single Server, Intel Core i5, 4GB RAM, 500GB HD.

Re: 100% of PDROP calls

PostPosted: Fri Sep 14, 2012 5:40 am
by DomeDan
That looks weird.

post the settings for both of the carriers. Registration String, Account entry, Globals String and Dialplan Entry

Re: 100% of PDROP calls

PostPosted: Fri Sep 14, 2012 8:57 am
by marcoe
Both don't register, there is only the account info and dialplan.

Trouble carrier, no user/password, they restrict IP's
Code: Select all
[primacom]
type=peer
nat=no
context=trunkinbound
host=201.7.163.180
fromdomain=201.7.163.180
dtmfmode=rfc2833
canreinvite=no
insecure=invite,port
qualify=yes
disallow=all
allow=ulaw,alaw

Code: Select all
exten => _ZZ[2-9]XXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _ZZ[2-9]XXXXXXX,2,Dial(SIP/primacom/0${EXTEN},40,tTor)
exten => _ZZ[2-9]XXXXXXX,3,Hangup




OK Carrier
Code: Select all
[tmais_sp]
type = friend
username = 097236801
secret = Qjf8woueou
fromuser = 097236801
host = sip1.tmaisngn.com.br
callerid = "tmais" <1126269734>
context = trunkinbound
disallow = all
allow = ulaw
dtmfmode = rfc2833
canreinvite = no
insecure = very
qualify = yes
nat = no
reinvite = no
canreinvite = no

Code: Select all
exten => _1N[2-9]XXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _1N[2-9]XXXXXXX,2,Dial(SIP/tmais_sp/0${EXTEN},30,tTor)
exten => _1N[2-9]XXXXXXX,3,Hangup


Re: 100% of PDROP calls

PostPosted: Fri Sep 14, 2012 1:51 pm
by marcoe
So I did some more traces and I think I found some important stuff, but this is probably one of those thinks that just Matt may understand the reason why is happening.

Comparing the output of agi-VDAD_ALL_outbound.agi on both carriers, I notice that the channel field stays Local/xxxxx and it was supposed to be SIP/primacom/xxx, and the agi exits because it is in that way.

I've tried adding more lines to dialplan to call this agi script up to 5 times and it did nothing.

Any guesses ?


trouble carrier
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- channel = Local/1897267490@default-e348,1
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- context = default
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- dnid = unknown
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- enhanced = 0.0
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- extension = 8368
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- language = en
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- priority = 4
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- rdnis = unknown
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- request = agi-VDAD_ALL_outbound.agi
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- type = Local
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi| -- uniqueid = 1347646064.291
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi|AGI Variables: |1347646064.291|Local/1897267490@default-e348,1|8368|Local|V9141507430000000326|V9141507430000000326|4|
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi|+++++ VDAD START : |326|2012-09-14 15:08:03|1.4.38-vici|4|
2012-09-14 15:08:03|agi-VDAD_ALL_outbound.agi|+++++ VDAD START LOCAL CHANNEL: EXITING- 4


OK carrier
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- channel = SIP/tmais_sp-00000047
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- context = default
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- dnid = unknown
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- enhanced = 0.0
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- extension = 8368
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- language = en
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- priority = 4
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- rdnis = unknown
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- request = agi-VDAD_ALL_outbound.agi
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- type = SIP
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi| -- uniqueid = 1347646357.297
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi|AGI Variables: |1347646357.297|SIP/tmais_sp-00000047|8368|SIP|V9141512370000000328|V9141512370000000328|4|
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi|+++++ VDAD START : |328|2012-09-14 15:12:46|1.4.38-vici|4|
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi|0|SELECT count(*) FROM vicidial_live_agents where callerid='V9141512370000000328';|
2012-09-14 15:12:46|agi-VDAD_ALL_outbound.agi|0|SELECT count(*) FROM vicidial_auto_calls where callerid='V9141512370000000328' and status IN('LIVE','XFER');|

Re: 100% of PDROP calls

PostPosted: Fri Sep 14, 2012 3:47 pm
by marcoe
well, I just found this:
http://www.eflo.net/VICIDIALforum/viewtopic.php?t=6583

williamconley did you find out why this happens ?

Re: 100% of PDROP calls

PostPosted: Mon Sep 17, 2012 2:42 am
by DomeDan
Dont forget the weird asterisk output

"fromdomain" should not be the carrier ip.
set your domain-name or ip there, or remove that line
fromdomain=200.178.179.90

and play around with insecure and type

btw what sip response did you get from the carrier when trying to make a call with the troublesome config?

Re: 100% of PDROP calls

PostPosted: Mon Mar 18, 2013 3:22 pm
by williamconley
marcoe wrote:well, I just found this:
http://www.eflo.net/VICIDIALforum/viewtopic.php?t=6583

williamconley did you find out why this happens ?

In "lucky" cases it is because there is a firewall blocking the rdp port and sound never starts. No sound = no call = vicidial terminates the "local" call because it would be a waste of the Agent's time to listen to a channel with no sound on it.

In the "not so lucky" cases, it was an old spectre of a bug that we wrote a workaround for (thus my request for help, which is unusual, LOL). But we have not had to install that fix in any servers since version 2.0.5. And then only a marked few were affected.

Essentially, if the channel is still "local", it is not "real". So Vicidial terminates it. Vicidial will attempt to link three times, then dump the call if still "local".