I am a former Trixbox user. The Elastix package was so much more complete, that I built one and I am extremely happy with it. I do have a small issue:

I have a DID with Inphonex. Under Trixbox it works perfectly. However, emulating the exact same setup, Elastix can only use it for outbound, but the inbound doesn't work. If anyone has any experience, I would love your input. If you need to see config files, let me know which I need to post.

thanks in advance!

Jump into the cli, and type "asterisk -r" and then call in on your cell... Post the output here. Unless the output makes the problem painfully obvious. You may also want to obfuscate any phone numbers in the log...

Lee's advice is excellent. You might also try looking at your inbound routes.

What happens when you call the number? Do you get a recording? Ringing and ringing? Dead air?

Hello, Lee and trymes, thank you for the post. I tried your advise, but the output is a little massive. Is there I way I can save the CLI output to a file for easy copy/paste? In the meantime, let me expand on the problem, so that when you see the output, you also have an idea of the behavior it exhibits.

My Inphonex trunk setup is copied, almost letter for letter, from the configuration files posted on their website. It has Max Channels at 20 (that's how many channels I bought).

Trunk Name: ainphonex
PEER DETAILS:
host=sip.inphonex.com
disallow=all
allow=ulaw
username=XXXXXXX
secret=YYYYYYY
type=peer
fromuser=XXXXXXX
fromdomain=sip.inphonex.com
context=from-inphonex
careinvite=no

User Context: inphonex
USER DETAILS:
type=friend
context=from-trunk
disallow=all
allow=ulaw
username=XXXXXXX
user=XXXXXXX
insecure=very
host=sip.inphonex.com
fromdomain=sip.inphonex.com

And of course, a proper registration string.

I have two inbound routes pointing towards a Queue.
Route 1:
DID Number: Inphonex DID: XXXXXXXXXX
Source: Enum
Language: EN
Queues: 120 <-- that's the Queue name.

Route 2:
DID Number: WW DID: XXXXXXXXXX
Source: Enum
Language: EN
Queues: 120 <-- again, the Queue this DID should drop calls into.

When I use Route 1, FOP lights up my extension, then it lights up "ainphonex". Then it lights up "Queue 120". then it lights up the first available agent.

When I use Route 2, FOP lights up my extension, hold close to 30 minutes, then it lights up "ainphonex" which just rings and rings for about 10 or 15 seconds before it terminates the call with a busy signal.

Mind you: this setup works in Trixbox, and it is an exact duplicate. It boggles me what I might be missing. Anyhow, if there is a way to save CLI output to file, please advise to I may post that as well.

Use ssh to get into the box, and you can cut and past from the terminal window. But now I am confused. It looks like the call is coming in, and then getting lost. Try dialing 7777 from any extension to see how your internal routing is going.

All CLI output is replicated in /var/log/asterisk/full (complete with a time-stamp), that file is logrotated daily, yesterdays stuff will be in /var/log/asterisk/full.1 (etc.)

I just notice that I made a mistake in the description of my problem below.

Route 2 is the one that is working well - a generic DID that comes into a generic trunk and dumps the call in Queue 120.

Route 1 is the Inphonex trunk, the one that hangs in dead air for close to 30 seconds, before coming into ainphonex, and just staying there. In about 1.5 hours, I'll be able to test calling the inphonex number and 7777 and post the log files.

The test number I use is the DID for inphonex.

This is what I get when I dial 7777 (It says the number is not in service).
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Executing [7777@from-internal:1] Goto("SIP/156-000010b4", "from-pstn,7777,1") in new stack
-- Goto (from-pstn,7777,1)
-- Executing [7777@from-pstn:1] Set("SIP/156-000010b4", "__FROM_DID=7777") in new stack
-- Executing [7777@from-pstn:2] NoOp("SIP/156-000010b4", "Received an unknown call with DID set to 7777") in new stack
-- Executing [7777@from-pstn:3] Goto("SIP/156-000010b4", "s,a2") in new stack
-- Goto (from-pstn,s,2)
-- Executing [s@from-pstn:2] Answer("SIP/156-000010b4", "") in new stack
-- Executing [s@from-pstn:3] Wait("SIP/156-000010b4", "2") in new stack
-- Executing [s@from-pstn:4] Playback("SIP/156-000010b4", "ss-noservice") in new stack
-- <SIP/156-000010b4> Playing 'ss-noservice.gsm' (language 'en')
-- Executing [s@from-pstn:5] SayAlpha("SIP/156-000010b4", "7777") in new stack
-- <SIP/156-000010b4> Playing 'digits/7.gsm' (language 'en')
-- <SIP/156-000010b4> Playing 'digits/7.gsm' (language 'en')
-- <SIP/156-000010b4> Playing 'digits/7.gsm' (language 'en')
-- <SIP/156-000010b4> Playing 'digits/7.gsm' (language 'en')
-- Executing [s@from-pstn:6] Hangup("SIP/156-000010b4", "") in new stack
== Spawn extension (from-pstn, s, 6) exited non-zero on 'SIP/156-000010b4'
-- Executing [h@from-pstn:1] Hangup("SIP/156-000010b4", "") in new stack
== Spawn extension (from-pstn, h, 1) exited non-zero on 'SIP/156-000010b4'

The method I ended up using was "asterisk -r > Asterisk.txt" I then placed a call from ext 155 into the Generic DID. Successful connect into the queue. I then placed a call from ext 156 to the Generic DID into an empty queue. Successful Busy signal. I then placed a call from ext 155 into the Inphonex DID and it held for 28 seconds or so, then rang about 6 times, and then a voice message saying the person I was trying to reach was unavailable.

I looked at the log file but sadly, it was Mandarin to me. I went ahead and replaced all references to the DID's with either Generic DID or Inphonex DID. If Lee, Dicko or Trymes cares to look at the log file, and tell me where I failed, I would most appreciate it.

Thanks in advance...

Victor

That will be Mandarin to most everyone, it includes all the TERM formatting codes, again I suggest you use /var/log/asterisk/full as your time-stamped and authoritative source for debugging your issue. it is also conveniently in ASCII, i.e. readable by non Mandarins.

But as a pseudo-Manderin I can tell you that until 192.168.111.1 becomes at least "temporarily available" you will continue to experience this problem.