The INVALID_ELEM_CONTENT is on the N1 PRI. So that indicates the call may be going out but we don't have enough details to know much of anything. I suggest going under SYSTEM CONFIG and into the EVENT LOGGING, and set SWITCHBOARD and ISDN EVENTS to INFO. If you have a Syslog Server program you can have the ATLAS send the data to, you can also set ISDN L2 FORMATTED events to INFO, but that is very verbose and will fill the ATLAS' buffer very quickly. It may require ISDN L2 FORMATTED logging to figure out what is being rejected as "invalid" but we have no information yet.
Are you doing 7-digit or 10-digit local dialing? What is the number you are dialing? If you are sticking with the T1 in the USER TERM and the FXS ports in the DED MAP, then I suggest configuring the USER TERM entries with a "Caller ID Number" so the ATLAS will present a "Calling Party Number" when sending a call to the Telco.
I will turn on those logs and get some more information. I'm making progress. I now can get inbound calls and they are routed to the proper number. My mistake was in my dialplan. I had "$" for my incoming number accept entry for my circular group of 15 lines listed at the top of the list. I moved it down to the bottom and also filled my other incoming numbers in with the full numbers including area code. Just have to get outgoing working now. I will try the caller id field.
I removed the area code from the In#Accept Field and it still routes correctly. Also added caller id number to each user term. Still can't call out. Enabled the logs except the verbose one. Might have to do that tomorrow to see what is going on. I was trying to call 16053218162 from DS0=18.
Do you have a full PRI? The "Diagnostic" for the INVALID_ELEM_CONTENT is 18, which, if I'm reading everything correctly is the channel identifier; and the ATLAS is requesting channel 23.
So you can change the number of channels on the PRI to 10 or so, and try again. If the call goes through then work your way back up toward 23 and see where it starts failing, or you can change the channel selection to CIRCULAR and place call after call (keeping track of the channel) until one goes through.
If no calls go through, then you'll have to have the service provider monitor the call and tell you why the call is failing.
I now have incoming and outgoing working. To get outgoing working I had to change my "Outgoing Number Conversion" from "ISDN-National As Dialed" to "ISDN-National pref". The last piece I need to get working is DNIS. Currently Caller ID is working but DNIS is not being passed correctly. What log can I turn on to see what DNIS is being sent? My receiver looks like it needs 5 digits of DNIS.
Image below of Ded Map From Connects config. What does the Wink do and is it worth playing with the DNIS Delay settings?
The "DNIS Wink Timeout" does not interfere with transmitting the DNIS digits. If you move your curser to that option and hit Ctrl+a it will bring up a HELP window. This options sets a 5 second timer where the WINK will be transmitted on the T1 whether the FXS port is answered or not. If this is enabled the Wink could be sent and the DID digits transmitted before the FXS line is even answered.
For logging, I suggest setting DP OUTGOING SIGNALING to NORMAL in order to see the DID digits transmitted. Since you are doing FGD with ANI/DNIS the ATLAS should be transmitting *ANI*DNIS* but this will give you the exact digits being transmitted (in case it is less than 5 digits). If it is transmitting less than 5 digits then you may have to set up a DNIS SUBSTITUTION in order to add a digit to the number.
Disabled Dial Tone and changed DNIS Delay from 1 sec to 2 secs and it is working now. Thank you so much for everyone's help! I want to especially thank Patrick as his answers were extremely helpful!