I have these from the log. I'm not doing any of the things happening there.
There is no extension called 1697 on my system.
Can anyone please help with this?

[Mar 6 12:45:49] VERBOSE[4382] logger.c: -- Accepting call from '' to '1697' on channel 0/1, span 1
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [1697@from-zaptel:1] Set("DAHDI/1-1", "DID=1697") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [1697@from-zaptel:2] Goto("DAHDI/1-1", "s|1") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Goto (from-zaptel,s,1)
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:1] NoOp("DAHDI/1-1", "Entering from-zaptel with DID == 1697") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:2] Ringing("DAHDI/1-1", "") in new stack
[Mar 6 12:45:49] DEBUG[16219] chan_dahdi.c: Requested indication 3 on channel DAHDI/1-1
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:3] Set("DAHDI/1-1", "DID=1697") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:4] NoOp("DAHDI/1-1", "DID is now 1697") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:5] GotoIf("DAHDI/1-1", "1?zapok:notzap") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Goto (from-zaptel,s,8)
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:8] NoOp("DAHDI/1-1", "Is a Zaptel Channel") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:9] Set("DAHDI/1-1", "CHAN=1-1") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:10] Set("DAHDI/1-1", "CHAN=1") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:11] Macro("DAHDI/1-1", "from-zaptel-1|1697|1") in new stack
[Mar 6 12:45:49] WARNING[16219] app_macro.c: No such context 'macro-from-zaptel-1' for macro 'from-zaptel-1'
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:12] NoOp("DAHDI/1-1", "Returned from Macro from-zaptel-1") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-zaptel:13] Goto("DAHDI/1-1", "from-pstn|1697|1") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Goto (from-pstn,1697,1)
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [1697@from-pstn:1] Set("DAHDI/1-1", "__FROM_DID=1697") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [1697@from-pstn:2] NoOp("DAHDI/1-1", "Received an unknown call with DID set to 1697") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [1697@from-pstn:3] Goto("DAHDI/1-1", "s|a2") in new stack
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Goto (from-pstn,s,2)
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-pstn:2] Answer("DAHDI/1-1", "") in new stack
[Mar 6 12:45:49] DEBUG[16219] chan_dahdi.c: Requested indication -1 on channel DAHDI/1-1
[Mar 6 12:45:49] VERBOSE[16219] logger.c: -- Executing [s@from-pstn:3] Wait("DAHDI/1-1", "2") in new stack
[Mar 6 12:45:51] VERBOSE[16219] logger.c: -- Executing [s@from-pstn:4] Playback("DAHDI/1-1", "ss-noservice") in new stack
[Mar 6 12:45:51] VERBOSE[16219] logger.c: -- <DAHDI/1-1> Playing 'ss-noservice' (language 'en')
[Mar 6 12:45:53] VERBOSE[4382] logger.c: -- Channel 0/1, span 1 got hangup request, cause 16
[Mar 6 12:45:53] VERBOSE[16219] logger.c: == Spawn extension (from-pstn, s, 4) exited non-zero on 'DAHDI/1-1'
[Mar 6 12:45:53] VERBOSE[16219] logger.c: -- Executing [h@from-pstn:1] Hangup("DAHDI/1-1", "") in new stack
[Mar 6 12:45:53] VERBOSE[16219] logger.c: == Spawn extension (from-pstn, h, 1) exited non-zero on 'DAHDI/1-1'
[Mar 6 12:45:53] DEBUG[16219] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/1-1
[Mar 6 12:45:53] DEBUG[16219] chan_dahdi.c: Not yet hungup... Calling hangup once with icause, and clearing call
[Mar 6 12:45:53] DEBUG[16219] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/1-1
[Mar 6 12:45:53] VERBOSE[16219] logger.c: -- Hungup 'DAHDI/1-1'
[Mar 6 12:48:55] VERBOSE[16220] logger.c: == Parsing '/etc/asterisk/manager.conf': [Mar 6 12:48:55] VERBOSE[16220] logger.c: Found
[Mar 6 12:48:55] VERBOSE[16220] logger.c: == Parsing '/etc/asterisk/manager_additional.conf': [Mar 6 12:48:55] VERBOSE[16220] logger.c: Found
[Mar 6 12:48:55] VERBOSE[16220] logger.c: == Parsing '/etc/asterisk/manager_custom.conf': [Mar 6 12:48:55] VERBOSE[16220] logger.c: Found
[Mar 6 12:48:55] VERBOSE[16220] logger.c: == Manager 'admin' logged on from 127.0.0.1
[Mar 6 12:48:57] VERBOSE[16220] logger.c: == Manager 'admin' logged off from 127.0.0.1
[Mar 6 12:50:01] VERBOSE[4335] logger.c: -- Remote UNIX connection
[Mar 6 12:50:02] VERBOSE[16228] logger.c: -- Remote UNIX connection disconnected
[Mar 6 12:55:01] VERBOSE[4335] logger.c: -- Remote UNIX connection
[Mar 6 12:55:02] VERBOSE[16236] logger.c: -- Remote UNIX connection disconnected
[Mar 6 12:59:50] VERBOSE[16240] logger.c: == Parsing '/etc/asterisk/manager.conf': [Mar 6 12:59:50] VERBOSE[16240] logger.c: Found
[Mar 6 12:59:50] VERBOSE[16240] logger.c: == Parsing '/etc/asterisk/manager_additional.conf': [Mar 6 12:59:50] VERBOSE[16240] logger.c: Found
[Mar 6 12:59:50] VERBOSE[16240] logger.c: == Parsing '/etc/asterisk/manager_custom.conf': [Mar 6 12:59:50] VERBOSE[16240] logger.c: Found
[Mar 6 12:59:50] VERBOSE[16240] logger.c: == Manager 'admin' logged on from 127.0.0.1

Probably not,

I notice you have both FXO and PRI analog trunks to which one does DAHDI/1 refer to? ( I guess the FXO's, if so investigate your from-zaptel contexts for 1697 as an entity, or possible your spans are a little confused and your isdn is leaking to the wrong context, on a reboot the channels will reassign themselves with the order in which the spans are recognized, so make sure the drivers are loaded in the correct order)

Hi Dicko
The number "1697" is not mine. It, and other 4 digit numbers are 'generated' randomly.
"Spans confused" - I have no idea what you're saying. This is my first system. Still learning. I got two Dell servers with DRBD to fail-over. I am using Xorcom Twinstar, and got that working as well (after Xorcom supplied the files needed). I can receive incoming calls, but can not make calls at this point.
However, I stopped working on that since the "auto-pilot" actions of the system. I'm freaked out.
Here is some more stuff it does;

[Mar 7 22:42:35] VERBOSE[18349] logger.c: == Manager 'admin' logged on from 127.0.0.1
[Mar 7 22:42:35] VERBOSE[18349] logger.c: == Manager 'admin' logged off from 127.0.0.1
[Mar 7 22:42:35] VERBOSE[18347] logger.c: == Manager 'admin' logged off from 127.0.0.1
[Mar 7 22:45:01] VERBOSE[9052] logger.c: -- Remote UNIX connection
[Mar 7 22:45:01] VERBOSE[18353] logger.c: -- Remote UNIX connection disconnected
[Mar 7 22:50:01] VERBOSE[9052] logger.c: -- Remote UNIX connection
[Mar 7 22:50:02] VERBOSE[18359] logger.c: -- Remote UNIX connection disconnected
[Mar 7 22:55:01] VERBOSE[9052] logger.c: -- Remote UNIX connection
[Mar 7 22:55:01] VERBOSE[18368] logger.c: -- Remote UNIX connection disconnected
[Mar 7 23:00:02] VERBOSE[9052] logger.c: -- Remote UNIX connection
[Mar 7 23:00:02] VERBOSE[18375] logger.c: -- Remote UNIX connection disconnected
[Mar 7 23:05:01] VERBOSE[9052] logger.c: -- Remote UNIX connection
[Mar 7 23:05:02] VERBOSE[18386] logger.c: -- Remote UNIX connection disconnected
[Mar 7 23:08:03] VERBOSE[9068] logger.c: -- B-channel 0/1 successfully restarted on span 1
[Mar 7 23:08:08] VERBOSE[9068] logger.c: -- B-channel 0/2 successfully restarted on span 1
[Mar 7 23:08:08] VERBOSE[9069] logger.c: -- B-channel 0/1 successfully restarted on span 2
[Mar 7 23:08:13] VERBOSE[9068] logger.c: -- B-channel 0/3 successfully restarted on span 1
[Mar 7 23:08:13] VERBOSE[9069] logger.c: -- B-channel 0/2 successfully restarted on span 2
[Mar 7 23:08:18] VERBOSE[9068] logger.c: -- B-channel 0/4 successfully restarted on span 1
[Mar 7 23:08:18] VERBOSE[9069] logger.c: -- B-channel 0/3 successfully restarted on span 2
[Mar 7 23:08:23] VERBOSE[9068] logger.c: -- B-channel 0/5 successfully restarted on span 1
[Mar 7 23:08:23] VERBOSE[9069] logger.c: -- B-channel 0/4 successfully restarted on span 2
[Mar 7 23:08:28] VERBOSE[9068] logger.c: -- B-channel 0/6 successfully restarted on span 1
[Mar 7 23:08:28] VERBOSE[9069] logger.c: -- B-channel 0/5 successfully restarted on span 2
[Mar 7 23:08:33] VERBOSE[9068] logger.c: -- B-channel 0/7 successfully restarted on span 1
[Mar 7 23:08:33] VERBOSE[9069] logger.c: -- B-channel 0/6 successfully restarted on span 2
[Mar 7 23:08:38] VERBOSE[9068] logger.c: -- B-channel 0/8 successfully restarted on span 1
[Mar 7 23:08:38] VERBOSE[9069] logger.c: -- B-channel 0/7 successfully restarted on span 2
[Mar 7 23:08:43] VERBOSE[9068] logger.c: -- B-channel 0/9 successfully restarted on span 1
[Mar 7 23:08:43] VERBOSE[9069] logger.c: -- B-channel 0/8 successfully restarted on span 2
[Mar 7 23:08:48] VERBOSE[9068] logger.c: -- B-channel 0/10 successfully restarted on span 1
[Mar 7 23:08:48] VERBOSE[9069] logger.c: -- B-channel 0/9 successfully restarted on span 2
[Mar 7 23:08:53] VERBOSE[9068] logger.c: -- B-channel 0/11 successfully restarted on span 1
[Mar 7 23:08:53] VERBOSE[9069] logger.c: -- B-channel 0/10 successfully restarted on span 2
[Mar 7 23:08:58] VERBOSE[9068] logger.c: -- B-channel 0/12 successfully restarted on span 1
[Mar 7 23:08:58] VERBOSE[9069] logger.c: -- B-channel 0/11 successfully restarted on span 2
[Mar 7 23:09:03] VERBOSE[9068] logger.c: -- B-channel 0/13 successfully restarted on span 1

What is "UNIX connection" and who is the manager that logs in-and-out all the time?
Please help. I'm completely lost on the security thing.
Thx for taking the time to read and reply to this.
It is highly appreciated.
Jan

You didn't say whether dahdi/1 was supposed to be an FXO or ISDN,

FXO channels with some very few and esoteric exceptions do not present DID information, the DID is intrinsic in the Line itself (it's phone number so the from-zaptel context is to synthesize DID thingy) that you are getting spurious DID information on an analog trunk (from-zaptel so I assume an FXO) perhaps indicates that possibly the dadhdi modules are loading in a different order than when you had it working. The drivers will load and set the channels in the order of first to last, if the ISDN is loading before the analog stuff now then your channels will be mis-numbered, and so misbehave. I'm not saying this is the case but it's certainty something to verify.

dicko

p.s.

don't sweat the noisy connection messages, they are quite normal and come from the box itself.

Dicko.
In my home language, we have a saying that roughly translates to this: If someone is REALLY confused, we say "He is so confused like puke in a tumble dryer". I once read a book by an American fighter pilot instructor, referring
to "cranium melt-down" as a state where the events run away from the person.
I am now officially the international PRIME example of both these scenarios.

And the more I read, the more confused I get.

So I think it's time I just stop thinking for a moment and ask questions, some of which may sound utterly stupid to the informed. Nevertheless, I'll ask.

Some background on my system, and thank you for taking the time to read. The company I work for (Primarily a Wireless Internet supplier) has been approached by our local Telecoms to supply "last mile Telco services" to the
public, obviously over wireless. (Just to be clear, this entailed installing an E1-type ISDN service at our premises, of which individual service would then be transmitted to client).

After reading a lot about "provisioning" and some info on the forums, I decided to opt for the following;
An Elastix system, on 2X Dell 1850 servers, each with 2X hard drives,
mirrored. The 2 machines are set to fail-over to give continuity. DRBD is used for this. On the hardware side, I was advised by Romano on the forum to go for Astribank from Xorcom. I took his advice and bought an Astribank with 4X PRI and 24X FXO ports. (We were told that the ISDN installation was going to take a long time, so we thought, at the time, that we could use the FXO's in the meantime as a tie-over. This was not necessary, so the FXO's are not used at all).

Currently, we therefore have 2X E1 ISDN installed on the Astribank (When needed, we'll add 2 more). We get a batch of telephone numbers from the local Telco which are assigned to the ISDN lines. We use A2Billing for accounting.

The actual business-side of events are now to assign one Telco number from the batch we received to a customer. His "own" number now becomes his DID (or DDI in our Telco's parlance". An extension is created for the client, his DID
is assigned to his extension. The "context" in the extension set-up is A2Billing, and the A2B account number is entered into the extension section.

In the perfect world, this will result in incoming calls to the customer via his DID ringing to his extension. Outgoing calls will be made through A2B on a pre-paid system (not cards, no voice prompts, no balances, no "please enter the number scenes"). Straight forward dialing/authentication via his caller ID.

What I did: (Reading from forums, manuals, etc)
How to set up Elastix with fail-over. Difficult, but got it working.
How to set up Xorcom Astribank/Twinstar. Very difficult, but after Xorcom supplied the MUCH needed files, it was a breeze. (There is still issues with fail-back. Xorcom triggers from watchdog a fail-over. On fail-back, none of
the conditions that triggered the fail-over are present. So fail-back is done manually). Anyway, my Elastix system with Astribank/Twinstar can now fail-over
automatically.

I've not changed many files. Mostly everything seemed to be working "Plug-n-play", which was more or less what I was after.

Now we arrive at the point of the previous message of this topic.

Questions:
I'm completely confused regarding Zaptel and Dahdi. I've read somewhere that dahdi is the new replacement for zaptel. Now, in my mind, replacement means just that-replacement. IOW, zaptel is no more? But I keep running into zaptel everywhere I read about "how to .. on dahdi"? There are context's "from zaptel", in the system logs I see zaptel channels. So, I'm lost - in the tumble dryer.

All the files that people change seem to be "auto-generated" files? So what good is it to change them, like the dahdi channels.conf and others?

I don't know what dahdi1/1 means. Does dahdi do both ISDN and FXO? My Astribank only has the 2 ISDN E1's connected.

In the set-up scenario as described above, I could receive a call on an extension I tested, but the phone can not dial out. I have the trunk as g12, but the system says "...outgoing...busy". (I'm trying to get a direct call-out, not through A2B, to see where the faults are).

Contexts issues put me in a "I'm a drooling idiot" mode. I have no idea what to use them for. From-internal; from-pstn; from-zaptel; They may all have been "from-MARS" - I could never find a clear concise write-up on exactly what they mean and what they do. Like, in my own scenario, why is there not a "from-dahdi" context? In the chan_dahdi.cong file, it says context=from-pstn. In the dahdi-channels.conf it says context=from-zaptel for the ISDN Span(s). ????? In Elastix extensions we have "from-internal"; then there's "a2billing" and in my dreams, "from-HELL".

For the system to work through A2B on outgoing, I had to create a special trunk A2B/1. But also a normal trunk g11/g12 or even g63 (Jeez! I'm not sure) (as far as I could establish). A2B now uses the g12 as a "ZAP" trunk. But
clients are going out via the A2b/1 trunk into A2B, then back to Elastix via the g12 trunk. Is this normal?

I'm sure the people who designed this ALL work for NASA? Because to me it's much more complicated than rocket science.

I am SO lost - I think through too much reading. 1001 opinions about the same subject just adds to all the confusion. Differentiating between different versions of Elastix, write-ups on a subject from Elastix, Trixbox, Ast.Now, etc adds some more confusion. And in the end, you have .... ME! (A very unintelligent "Duh" from me).

Dicko. I wonder if it's possible to help me? I'm at earth's end right now and balancing between asking for help or just asking you to fix our system (with payment, of course). The latter would be the easiest (for me), but to quote
you while talking to someone else - the purpose is to do my own trouble-shooting, and fixing my own problems. So, if you fixed it, I'd have a working system, but I would not be able to fix it afterwards.....

What do you suggest?
Jan

Added:
I get this when attempting a call.
[Mar 8 15:07:33] NOTICE[21009] app_dial.c: Hey! chan SIP/1306-00000009's context='macro-dialout-trunk', and exten='s'
[Mar 8 15:07:33] VERBOSE[21009] logger.c: -- Requested transfer capability: 0x00 - SPEECH
[Mar 8 15:07:33] VERBOSE[21009] logger.c: -- Called 11/5555555555 (Real number hidden)
[Mar 8 15:07:33] DEBUG[9068] chan_dahdi.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/11 span 1
[Mar 8 15:07:33] VERBOSE[21009] logger.c: -- DAHDI/11-1 is proceeding passing it to SIP/1306-00000009
[Mar 8 15:07:33] VERBOSE[9068] logger.c: -- Channel 0/11, span 1 got hangup request, cause 3
[Mar 8 15:07:33] WARNING[21009] app_dial.c: Unable to forward voice or dtmf
[Mar 8 15:07:33] DEBUG[21009] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/11-1
[Mar 8 15:07:33] DEBUG[21009] chan_dahdi.c: Not yet hungup... Calling hangup once with icause, and clearing call
[Mar 8 15:07:33] DEBUG[21009] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/11-1
[Mar 8 15:07:33] VERBOSE[21009] logger.c: -- Hungup 'DAHDI/11-1'
[Mar 8 15:07:33] VERBOSE[21009] logger.c: == Everyone is busy/congested at this time (1:0/0/1)

???
Jan

Oh my word. Look at this:

hi there.

I'm having big big problems with my elastix box.

We're from spain and we have our elastix behind a firewall, allowing connection to elastix only from our office. What happens is that someone is connection and making calls from and extension. How is this possible? we're using version 1.5-9.

This guy just confirmed my suspicions. Can this be scripts? Cause I've locked out our box completely?

Hi JanKoster,

Maybe you got more than you could chew with your installation.

To get some asterisk basics read through this page:

www.the-asterisk-book.com/unstable/

There you will learn about extensions, dialplans, applications, channels, etc.
This is for pure asterisk from console, but you can learn how things work in the background.

You should also learn about freepbx and Elastix way of interacting with asterisk, for example, usually you can only change the *_custom.conf files using them. Read a little about freepbx modules, and Elastix Without tears too.

Maybe you should do a ECT or ECE course. Or get someone to fix your problems right away and learn as much as you can from him.

Thx Ramoncio. I'll read some more.... and get more confused.
I do have a perfctly working SIP system, with extensions-n-all, remote extensions, mobile phones, etc etc. All calling world-wide through A2B, no problems, no hick-ups. So I do have a wee bit of understanding re the basics.

It's the different Telco issues I don't understand. Actual landlines. The main difference being (on my working system) I have one main SIP trunk to my VSP. And it's easy, cause it's a SIP trunk.

Now the new ISDN landline thingy is either dahdi/zaptel/pstn/custom/moonraker/canonballs. At "this" place in the system. On "another" place it changes into something else, and in the logs it's something else again.

Straight-forward Q: WHY the difference below?
In the chan_dahdi.cong file, it says context=from-pstn. In the dahdi-channels.conf it says context=from-zaptel for the ISDN Span(s).

So, should the extension's context now be from "pstn" or "zaptel". Or something else?
Jan

Oh. One thing I did pick up. Under Admin;Hardware detection-tab, it shows the first two spans (green) but showing "In Use". Is this not maybe why I get "busy"?

Jan Koster:

With respect the complications are largely of your own doing, You say you are not using the FXO's yet you at one time so set up the from-zaptel contexts, ISDN does not need or use this context the DID/CID etc. information is all present in the common D channel and belong in the from-pstn context. Basically the trunks will be enumerated in the order that Xorcom documents that they will, they will then be known as dadhdi/1 dahdi/2 etc. It is up to you to "group" them as appropriate so you can use the groups appropriately dahdi/G0 or dahdi/g1 etc. As you only use the isdn interfaces I suggest you leave the FXO's in group 0 and add all 62 usable B channels into group 1 and just use that group. (Ramoncio's suggested reading will give you the basics here, a further resource is voip-info.org).


You further complicate matters by using a2billing on top of Elastix , from my reading of your deployment perhaps you do not need Elastix at all as all your described functionality is within a2billing and it's somewhat oblique documentation, The do have a commercial department (star2billing I believe) that offer paid installation and consulting.

Consider dahdi as largely just a replacement by Digium of the old Zaptel for somewhat arcane licensing/branding reasons, any residual Zaptel references are just legacy, as Ramoncio says differentiating between technology (the physical trunks) and contexts (pure Asterisk) is kind of critical for you. As is understanding the "inclusion" methodology of configuration files (basically last mention wins).

If your outbound calls are indeed coming back into the system via the ISDN trunks and that's not what you want then you will have to study your outbound routes and how they are handled, again from my reading of your post you probably should not have them anywhere in your outbound routes as I believe you want to use these just for incoming calls.


You are obviously quite competemnt as you got the drdb and a2billing stuff largely working, Just slow down , pop down to the local cafe and spend a couple of euros on whatever reduces stress for you catch up on your reading (Xorcom/A2billing/Asterisk/Elastix) I'm sure the light in your drier will eventually go on and dry up that puke.

From the very first post I really don't think that spurious inbound calls on landlines is in any form a security breach that would take a digital bridge tap somewhere on the physical line, you would probably notice that additional equipment in your phone closet, The post that freaked you out is nothing to do with your set of problems.

Any way, slow down, remember rule number 42 (Don't Panic) and good luck

dicko