Unable to receive calls on Atlas 550.

[tnewell]

We currently cannot receive incoming calls on our Atlas 550.  We use both a 550 & 890 for Video Teleconferencing, with 2 PRIs that are broken out into BRIs.  Our primary is the 890, but we utilize the 550 for testing or backup purposes.  We're currently unable to receive calls on the system, but make out bound calls with no issue.  We've checked settings of the 550 versus the 890, there were a couple minor differences, but even when they were mirrored, still no luck.

We've tried a couple different VTC systems to rule out that out.  We've swapped the systems back to the 890 and all was well there.  We have had both the $ and the phone numbers individually assigned in the In#Accept on the user terminal for the BRI card, with no luck.  We have firmware C0904 and haven't had any luck find info elsewhere.  Do you have any ideas or suggestions we could try to remedy the issue?  Thank you for your time and assistance.

[Anonymous]

With PRI to BRI, and with outbound calls working - it is an issue with either the numbers in the IN#ACCEPT list, & the SPID list... Or with the SPID registration. If the SPIDs are not registered the ATLAS cannot send a call out the BRI but will accept a call FROM the BRI.

Under SYSTEM CONFIG and EVENT LOGGING, you can set "ISDN EVENTS" to INFO, then back out to the main menu, and go into SYSTEM STATUS into the EVENT LOG to view ISDN Events. You will probably need to either reboot the video codec, or unplug the BRI lines, but you want the Codec to send the SPID registration. You should see that in the event log and it will either be rejected, (NOT IN LIST) or accepted with ALL SPIDS REGISTERED. If they register, then the SPIDS are good.

The IN#ACCEPT should be however many digits the ATLAS receives on the inbound call on the PRI. If it is 10 digits, than the IN#ACCEPT will be all 10 digits, however the PHONE # under the SPID LIST will never be more than 7 digits. So the PHONE # should match the IN#ACCEPT up to 7 digits.

Also, under DIAL PLAN and GLOBAL PARAM, make sure the AREA OR CITY CODE is either blank or "000", as this can cause issues with inbound calls when 10 digits are recieved.

Again, with ISDN EVENTS set to INFO, you can monitor the inbound call and see how many digits (and what digits) the ATLAS receives -- it should show "Call to ATLAS XXXXX" where XXXXX is the number received.

Hope this helps,

Patrick

[tnewell]

Patrick,

Thank you for the quick response.  The SPIDS did register, I cycled the power on our NT1 device.  Previously, we did have just 7 digits in the In#Accept, I switched them out for the 10 digit version and was unable to make or receive a call.  I take that to mean that it needs to be 7 digits in that column?

I also removed our area code and left it blank, then tried 3 zeroes, again with no success.  I'm not sure where the answer lies.  When we try to make a system to system call from our functional 890 to the problem 550, it never even hits the 550.  Nothing in the event log, at all.  Grasping at straws, I reached out and had a different location (local & long distance) try with the same lack-of-indicator.  When you dial the VTC system's number from a standard phone there is about a half a second normal ring, which shifts immediately over to the busy signal.  Still no indication in the event log.

I do see all the standard INFO during outbound calls, or when the SPIDS were re-registering.  Not really thinking it was a problem, we swapped out to a different BRI card with no joy.  I'm fairly sure we have another PRI card we can add in to see if that may be the culprit, but I don't really expect it to be a hardware issue.  Is there anything else that we can maybe try?  Thank you again.

v/r

Todd

[Anonymous]

If outbound calls work, then I don't believe the card is bad. If nothing shows up in the event log on an inbound call, then you may need to try more detailed logging, and set "ISDN L2 FORMAT" to INFO. If nothing shows up with that, then the call is not being sent down that PRI. You may also need to set SWITCHBOARD to INFO to confirm the call routing.

The IN#ACCEPT only affects routing calls TO that interface, so it shouldn't change outbound calls at all, unless the call is being routed out another BRI port, and not out the PRI in the NETWORK TERM (with a "$" as the OUT#ACCEPT). If it's a PRI to another ATLAS, then it needs to be appropriate for what needs to be routed out to the other ATLAS (it can still be "$" for accept anything).

[tnewell · Accepted solution]

Patrick,

I appreciate all the support.  With all that tweaking and configuring it turned out to be at the Telco's side.  For whatever reason they had our PRI 2 not set up to receive incoming calls.  Changing the ISDN L2 FORMAT to INFO did help in pinning down the exact problem.  Thank you for all the help!

v/r

Todd