vicidial.org

This is a new set up. When i try to log in, phone rings, I answer and after a few seconds says 'the number you have dialed is not in service....
then says good bye.

using goautodial

Here is my cli

[Jun 22 22:29:06] > Channel SIP/111-00000011 was answered.
[Jun 22 22:29:06] -- Executing [8600051@trunkinbound:1] AGI("SIP/111-00000011", "agi-DID_route.agi") in new stack
[Jun 22 22:29:06] -- Launched AGI Script /var/lib/asterisk/agi-bin/agi-DID_route.agi
[Jun 22 22:29:06] -- AGI Script agi-DID_route.agi completed, returning 0
[Jun 22 22:29:06] -- Executing [9998811112@default:1] Wait("SIP/111-00000011", "2") in new stack
[Jun 22 22:29:06] == Parsing '/etc/asterisk/manager.conf': [Jun 22 22:29:06] Found
[Jun 22 22:29:06] == Manager 'sendcron' logged on from 127.0.0.1
[Jun 22 22:29:06] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 22 22:29:08] == Manager 'sendcron' logged off from 127.0.0.1
[Jun 22 22:29:08] -- Executing [9998811112@default:2] Answer("SIP/111-00000011", "") in new stack
[Jun 22 22:29:08] -- Executing [9998811112@default:3] Playback("SIP/111-00000011", "ss-noservice") in new stack
[Jun 22 22:29:08] -- <SIP/111-00000011> Playing 'ss-noservice' (language 'en')
[Jun 22 22:29:13] -- Executing [9998811112@default:4] Playback("SIP/111-00000011", "vm-goodbye") in new stack
[Jun 22 22:29:13] -- <SIP/111-00000011> Playing 'vm-goodbye' (language 'en')
[Jun 22 22:29:14] -- Executing [9998811112@default:5] Hangup("SIP/111-00000011", "") in new stack
[Jun 22 22:29:14] == Spawn extension (default, 9998811112, 5) exited non-zero on 'SIP/111-00000011'
[Jun 22 22:29:14] -- Executing [h@default:1] DeadAGI("SIP/111-00000011", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Jun 22 22:29:14] -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0

ANY IDEAS?

thamks in advance

VICIDIAL VERSION: 2.4-325c BUILD: 110430-1924

I don't see a dial command. You are missing part of your output or have misconfigured your carriers. Most likely the first.

thanks for your reply.

i used vitelity and authenticate using ip so no user:secret

this is my set up"
[vitelity]
type=friend
insecure=very
host=inbound24.vitelity.net
dtmfmode=auto
context=trunkinbound
canreinvite=no

this is my dial plan:
exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,2,dial(sip/${EXTEN:2}@vitelity,,tTor)
exten => _91NXXNXXXXXX,3,Hangup

Nope, try again.

Code: Select all

exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,2,Dial(sip/carriernamehere/${EXTEN:1},,To)
exten => _91NXXNXXXXXX,3,Hangup



Having "t" in the dial command is also a really bad idea.

Let me know how it works out.

cristian wrote:Having "t" in the dial command is also a really bad idea.

Not if you have blindtransfers in features.conf properly set to:

blindxfer => CC

Obscurity is not security. Next autodialer that calls me gets a free transfer to a Inmarsat test line (about $5 a minute).

Does this provide functionality to end users?

You would also have to have a wide open dial plan for that to be a problem, as well as a phone that can dial "C"...

mflorell wrote:You would also have to have a wide open dial plan for that to be a problem, as well as a phone that can dial "C"...

a) Most people posting here don't know what a dial plan is. Many internationals use "_X." or "_." like their carrier tells them to. They sure don't have a filtered LCR like they need to.

b) I have a DTMF generator (ToneDef for android) on my cell for this purpose. It also does 2600 Hz, which wasn't too secure either.

Let's roll.

Okokok ... lemme see if I'm following here.

You're saying that if one of my dialers calls me, and I dial "C" (special phones are cool) and then enter the "correct" number ... (based on an assumption of the standard 91NXXNXXXXXX or 1NXXNXXXXXX) ... interesting.

You would actually have to dial "C" twice in quick succession

Dude, interesting is an understatement; This is a bona-fide DTMF vulnerability.

That's what you get when you don't bake your own cookies, Bill, surprises.

Ah, but here's the part you didn't catch, auto-dial calls and manual dial calls get placed differently, in one the customer is the first called party, and in the other they are the second called party, so now what does that mean to you for the "T" and "t"...

Dude, that is not how that works.

Asterisk doesn't care what Vicidial is doing. It just knows that a channel was spawned by the manager interface, and the extension hits dial plan. The flags to the dial command then get applied. The called party is clearly what the instantiated channel bridges to.

The auto/manual difference is whether or not there is a user (agent) already in the conference.

Am I off here?

cristian,

vicidial is an odd puppy, as are meetme rooms. the "called party" and the "calling party" are not the same as "system which generated" and "system which received". Vicidial is quite capable of "generating" a call FROM a prospect TO an agent.

This is part of what gave me my first headache when I first began working with Vicidial. The mysterious "local call termination issue" from a few years ago caused me to "dig in" and literally watch every line of code execute to find a cure (because we were in Gentoo and we experienced the same flaw, even though others were on other operating systems, so Poundteam *HAD TO* find a cure for our clients.

I build a presentation for myself to understand the methodology in the meetme room including the masquerade moment when channels get "fuzzy" on ownership and ultimately found a solution. I also found out that there is a LOT more than meets the eye to some of the rules being broken by these apps to make Vicidial WORK (where other applications fail).

I began to understand why there is NO competition in this market from any other app (even OSdial which is arguably the closest thing to competition ... and it is a FORK of Vicidial, LOL!).

While I have not personally tested the removal of either "t" (i kinda prefer to use tTor), I would suggest you try it before making such an assumption (and remember to test every type of call and transfer after said removal ...).

Then let me ask you a question: How do you hold a call in limbo for two to five seconds after the call "answers" before choosing an agent (while waiting for one to become "available") yet allowing the agent to already be On the line for instant response when the moment arrives? Don't say "Queue", because this app works in asterisk 1.2, and Queues in 1.2 could only have ONE head call at a time (until the first caller was answered, NONE could be answered). And this app way predates asterisk 1.4

Hmm, I'll have to chew on that for a while. Good one.

You know, you could just change blindxfer to something else, like this:

blindxfer => CCCAD623*BBB


Then I don't think you would have anything to worry about.

Agreed.

I had a chance to (briefly) go through the autodial call flow. I cannot find anything that would modify the flags on the channel bridged into the meetme.

Bill, care to forward a copy of that presentation?