We have two PRIs that our site uses for Video Teleconferencing. They terminate in an Atlas 890. We’ve had sporadic issues in the past, but normally the issue stemmed from the TELCO. Currently, we’re unable to access more than 23 channels at once.
I’ve utilized Source IDs to force calls onto the 2nd PRI, but we still max at 23 channels. For instance, I could do 12 channels on 1, then 11 channels on 2. Attempting to make a call after that I get the NO_CIRCUIT_AVAILABLE error. It doesn’t matter how I split the channel usage (18 / 5, 16 / 7, and vice versa, etc), I receive the same error whenever I try to utilize a 24th channel.
In addition to Source IDs, I’ve utilized a spare 550 to terminate one PRI, with the other one remaining in the 890; even when split into two different termination points, the issue persists. No more than 23 channels can be accessed at once.
Also, less than a handful of times, the total number of channels I could utilize has dropped. Once a total of 17 max channels, once 11 max channels. As far as I can tell, there isn’t a way to determine what our max capacity is until we hit the limit. Typically, we connect our VTCs at 384k, but with this limitation we have had to drop it down to 256k/128k to accommodate multiple VTCs at once.
Earlier this year, we noticed an issue with incoming calls, but I believe we may have been hitting our channel limit without realizing we had a limit. I’ve worked with the TELCO a couple times since we’ve had this issue, and they believe it’s programming on our side. We do have a spare 890, but with utilizing the 550 and not isolating the issue, I don’t believe it to be our programming. Any guidance or thoughts you can provide would be greatly appreciated.
You mentioned VTCs, so you have 2 PRIs to the Telco, but what do you have on the USER TERM?
When you are testing and getting the NO_CIRCUIT_AVAILABLE error, are you testing inbound or outbound calls?
I suggest you set up Syslog Server and configure the ATLAS to send its syslog to that server. Then under SYSTEM CONFIG go into EVENT LOGGING and set SWITCHBOARD and ISDN L2 FORMATTED to INFO and run your test until you see the NO_CIRCUIT_AVAILABLE error. Then you can look to see if the ATLAS sends the SETUP and receives this message back as a response to the SETUP. This is generally a message from the service provider. The ATLAS will usually return a "USER BUSY" but the syslog will clarify exactly what happens with the call.
Thanks,
Patrick
Patrick,
Thanks for the quick response. I have yet to have a chance to use the Syslog Server, I have to work around our VTC schedules, and it's difficult to maximize bandwidth. But I'm standing by for it. I've configured the 890 to have transmission enabled, with the IP of the PC I use, and Local0. I'm not quite sure what else needs to be configured. Or if I need a different IP, or even part of the Router configuration. I've never been a network guy. Is there a guide for getting the Syslog server set up? I've opened up the Syslog client, and I'm not seeing anything.
For the USER TERM, we have Octal BRI cards. Each port configured with 2 SPIDs/LDNs. We've primarily been testing outbound calls, since that's what we typically use. I did test incoming, and I'm fairly certain we were just getting USER_BUSY, maybe the NO_CIRCUIT_AVAILABLE, but it's been a while since I've tested incoming. I'll make sure to try that once I get the log client up and running.
Thanks,
Todd
Todd,
Here is a guide for using the "Adtran Utility Syslog Server" with the ATLAS: Using the Adtran Utility Syslog with the Atlas. The ADTRAN Utility Software is no longer supported (and was written for Windows 95 computers), but the very first step in the document goes over configuring the ATLAS to transmit to the Syslog Server.
Basically you simply have to ENABLE the Transmission, put in the IP address of the Syslog Server, and set the Host Facility if you choose to change it (the default setting is "Local0").
Once this is set, anything that shows up under the SYSTEM STATUS in the EVENT LOG will be transmitted to the Syslog Server IP configured.
Hope this helps,
Patrick
Patrick,
It certainly sounds easy enough, but I may be over complicating it. Our 890 isn't on any actual network, we just have the two PRIs. We log in locally with a stand alone laptop through the Admin port. Our main laptop we use a serial to USB adapter, and I wasn't sure that was going to work, so I tried our older one that still has a serial port. No luck on either. I'm setting the IP manually on both the laptops and the 890, under the Syslog Config, with Transmission enabled. With it not being on an actual network, is this an issue?
Also, today, I'm not sure if it's related to the channel issue, but we were dialing out long distance and we got the Call Clearing: NETWORK_CONGESTION . Which is the first time I've seen that particular error. If it makes any difference we were trying to dial into a VTC bridge system. But as with the other issue (No_Circuit_Available), I expect the NETWORK_CONGESTION to be at the Telco? If not the Telco, then maybe the VTC hub? Any thoughts on that issue, and could it be related? Thank you for all your time.
v/r
Todd
As long as the Ethernet ports are up, and the ATLAS and PC(s) are on the same IP network (and can PING, etc.) then that should work fine.
And, yes. The "NETWORK_CONGESTION" is typically a Telco issue.
Patrick,
I managed to get it to work, by paying attention to what I was doing. I'm not entirely sure what I'm looking for, but I think this is the pertinent section:
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:Switchboard|Sl 7|7|XXX6170 Pri. accepted: slot Sl 1, port 1
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1|Recd = Sapi:00 C/R:C Tei:00
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| Ctl:INFO Ns:28 Nr:21
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|===================================================
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|Recd = Sapi:00 C/R:R Tei:41
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Ctl:INFO Ns:45 Nr:20
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Prot:08 CRL:1 CRV:001D
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| IE - 2C KEYPAD FACILITY Len=7
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Pref/Excl:EXCLUSIVE
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| 90 Xfer Rate:64k
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| Chan. Sel:FOLLOWS
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| 83 Numb/Map:NUMBER
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| Prot:08 CRL:2 CRV:809E
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| 83 Numb/Map:NUMBER
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| A9 Primary Rate
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| M - 02 CALL_PROC
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1|===================================================
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1|Recd = Sapi:00 C/R:C Tei:00
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| Ctl:INFO Ns:32 Nr:22
Nov 22 12:10:27 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| Prot:08 CRL:2 CRV:809F
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| M - 5A RELEASE_CMP
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| IE - 08 CAUSE Len=2
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| 80 Location:U
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 1|1| A2 Cause:NO_CIRCUIT_AVAILABLE
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:ISDN|Sl 1|1|Call clearing: NO_CIRCUIT_AVAILABLE : Loc=U
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:ISDN|Sl 1|1|Call to 'XXX6170' failed
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:ISDN|Sl 7|7|Call to 'XXX6170' busy after switchboard has connected it.
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:ISDN|Sl 7|7|Busy destination: USER_BUSY : Loc=LN
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|===================================================
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|Sent = Sapi:00 C/R:C Tei:41
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Ctl:INFO Ns:21 Nr:46
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Prot:08 CRL:1 CRV:009D
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| M - 45 DISCONNECT
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| IE - 08 CAUSE Len=2
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| 82 Location:LN
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| 91 Cause:USER_BUSY
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|===================================================
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|Recd = Sapi:00 C/R:R Tei:41
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Ctl:INFO Ns:46 Nr:22
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Prot:08 CRL:1 CRV:001D
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| M - 4D RELEASE
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|===================================================
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7|Sent = Sapi:00 C/R:C Tei:41
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Ctl:INFO Ns:22 Nr:47
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| Prot:08 CRL:1 CRV:009D
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|7| M - 5A RELEASE_CMP
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:ISDN|Sl 7|7|Call to 'XXX6170' disconnected by far end.
Nov 22 12:10:28 192.168.1.222 ATLAS 890[ADTRAN]:L2-Formatted|Sl 7|5|===================================================
After that, it just goes to NORMAL_CLEARING of the other ports. But if you'd like to see the full log from when the call was first initialized the outbound call, i pasted it to: http://dpaste.com/2NYD4RD
If you'd prefer the entire log posted here, I'm more than happy. I still just see the NO_CIRCUIT and USER_BUSY, but I'm not sure what the rest of it means. But with the above info, do you have any thoughts?
Thanks, and have a good holiday!
v/r
Todd
Ah! Thank you for the link to the full debug. I was thinking there was some information missing, but it's in the full debug. It does look like this is a BONDING call because the first SETUP goes out and connects, then there are several calls one after the other in rapid succession.
The ATLAS receives the SETUP message on the BRI slot 7 port 5 (S7.5). It's a call to the XXX-6170 number.
The ATLAS then sends the call out the PRI S1.1 on channel 11 of the PRI. This call connects normally.
Then there are additional calls to the ATLAS using S7.5, S7.6, and S7.7
These calls are sent out the PRI S1.1 until we receive back a RELEASE_CMP with a cause of NO_CIRCUIT_AVAILABLE. So this is received by the ATLAS from the Telco network.
You'll notice each message is separated with a row of equal signs ( = ). The top of each message shows whether the ATLAS SENT or RECEIVED (Sent or Recd) the messages. The NO_CIRCUIT_AVAILABLE message was received on Slot 1 Port 1, so I'm assuming that is from the Telco.
Hope this helps,
Patrick
Patrick,
That's great info! Pretty much all signs point towards the Telco, and it's kind of what I expected. I'm going to work with them, and get it escalated to a Tier 2, if necessary. Is there any suggestions on what I can try to steer them towards? If possible, I'd like to leave this thread open for a while, so I can revisit after working with them.
As always, thanks for all your help!
v/r
Todd
The only thing you can tell them is that the ATLAS is receiving the NO_CIRCUIT_AVAILABLE message, so it MUST be coming from the network. They'll have to look at the network and determine what the cause is.