Dahdi calling problem

[rsaaris]

We are having problems with calling out from digital phone connected to MD11 switchboard that is connected to a vicidial server through E1-connection. When calling inbound the setup works great. But not when calling outbound. The error message:

Extension '0' in context 'trunkinbound' from '3741' does not exist. Rejecting call on channel 0/20, span 1

The 3741 is one of the digital phones connected to the switchboard. Same thing happens if i change the context to default, where are my dialing extensions for E1-connections. The 3741 phone uses prefix 851 to dial outbound and the '0' is the first number that goes to asterisk.

Does anybody know what could be the issue?

Edit:
When pressing '#' after the 851, asterisk gives this kind of error:
-- Accepting call from '3741' to '#' on channel 0/5, span 1
[Nov 30 15:18:02] VERBOSE[26885] logger.c: -- Executing [#@default:1] Playback("DAHDI/5-1", "invalid") in new stack
[Nov 30 15:18:02] DEBUG[26885] chan_dahdi.c: Requested indication -1 on channel DAHDI/5-1
[Nov 30 15:18:02] VERBOSE[26885] logger.c: -- <DAHDI/5-1> Playing 'invalid' (language 'en')
[Nov 30 15:18:06] VERBOSE[26885] logger.c: -- Executing [#@default:2] Hangup("DAHDI/5-1", "") in new stack
[Nov 30 15:18:06] VERBOSE[26885] logger.c: == Spawn extension (default, #, 2) exited non-zero on 'DAHDI/5-1'
[Nov 30 15:18:06] VERBOSE[26885] logger.c: -- Executing [h@default:1] DeadAGI("DAHDI/5-1", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Nov 30 15:18:06] VERBOSE[26885] logger.c: -- AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Nov 30 15:18:06] DEBUG[26885] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/5-1
[Nov 30 15:18:06] DEBUG[26885] chan_dahdi.c: Not yet hungup... Calling hangup once with icause, and clearing call
[Nov 30 15:18:06] DEBUG[26885] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/5-1
[Nov 30 15:18:06] VERBOSE[26885] logger.c: -- Hungup 'DAHDI/5-1'

Don't know if this helps...

[williamconley]

You listed several examples of "problems", but did not show a single cohesive standard "problem with debug info" (matched).

You have stated more than once that there is some form of "switchboard" connected to vicidial through an E1. But the challenge here is that Asterisk does not care how the connection has occurred physically: It cares only what number is ultimately dialed in what context.

How about this: Your agents should be dialing in "default" and the debug you show should be that of your agent attempting to dial in "default". This dialing should not include dialing a 0 in front or a # after and likely should not include your agents dialing anything else special just to make the call except a dial prefix to choose a carrier if you want to reserve that option.

So try to show a standard setup where your agent is in default and tries to dial a standard number which should go through your trunk ... and we'll help you modify the system to allow that to occur.

If that setup interferes with "other things", we can of course modify the dialplan accordingly ... but mostly we need to understand the dynamics of your present configuration. Does your "switchboard" connection via E1 provide "phones" (ie: agent phones) or "trunks" (ie: carriers) or some combination of both?

[rsaaris]

The configuration goes like this:Digital phones connects to a "Switchboard" that connects to an asterisk/Vicidial with E1 -connection. Swichboard is pri_cpe, asterisk (sangoma port 1) is pri_net with context default. Asterisk (sangoma port 2, context trunkinbound) have also an E1-connection that goes to PSTN. The PSTN->Asterisk->Swichboard->Digital phone calls works using the remote agents.

The example error came from a "standard" setup. But as I wrote or tried to wrote was that Swichboard->Asterisk->PSNT calls fail and gives the error message where extension does not exist. And I have no idea why default context doesn't recognize the '0' or any other number and gives that kind of error. The error is the same with default context. The default context works just like it should when using normal SIP phone agents. Could the problem be that the digital phone agents are not registered in any way to asterisk?

[williamconley]

I'm not entirely sure that putting quotation marks around "Switchboard" and stating that it is connected to the E1 clarified it much, LOL. But it did seam to help for some reason.

This would be a purely asterisk problem. After you have your E1 connection working with asterisk and capable of accepting call requests that contain the digits the agents have dialed, we can work out the rest. But the technical aspects of getting a workstation E1 online with asterisk are often daunting (and not something I generally handle via hit and miss without the deeper details, I don't do enough Sangoma/Digium setup to have this area memorized to that level!). If, however, you can call the agents on their E1 connected workstations, the solution is to have the agents perform all tasks within the agent interface instead of as remote agents. In this way you bypass whatever your problem is with the agents dialing through and also capture all activity with Vicidial which is a bit of a bonus.

Otherwise, you'll need to get deeper into debugging the E1 interaction with Asterisk. This is not abnormal, but it is also not something that most rooms ever deal with. If you are "stuck" with a legacy system, of course, that's what you'll need to do. dahdi debugging to see what is being received and what context it is being sent to ... could resolve your issue. Kumba, Mcargile and Gardo are all fairly adept at this, but are all time-challenged quite often for the free forum (just as we are!). Describing the equipment with model numbers may be helpful (as may a google search with that same information). Or you'll end up paying someone to get you online properly.

[rsaaris]

This is now solved.

The problem was that the physical phones could not pass more than one number at a time to asterisk and that didn't work. But when an agent from our old system called out and could pass the whole number out the calling works. Strange issue indeed...