Hello and thanks for posting to the forum.
There are debugs we can run to see why a call failure happens, but I want to know about the circuit dropping part you mentioned. Does the T1 drop? Or just the Frame Relay portion or the PRI? I think this is an important detail.
The usual debugging for a problem that is SIP to PRI:
debug sip stack message
debug voice verbose
debug isdn l2-for
This debug shows the SIP and PRI call leg as well as the internal call routing in the ADTRAN. The problem is that a debug like this is going to severely tax the unit with 40 active calls. You may need to use the summary version of one debug to first determine the call failure origin. For example, if you did debug voice summary or debug sip stack message sum, you might get some insight into the nature of the failure - then use a full debug to get all the details.
I would like to look at the config for this unit. Another option here would be to open a ticket with Tech Support and then we can come back and post the resolution in here.
I'm not sure what you mean by "the whole circuit drops". Does the unit reboot? Do the D-channels on the PRIs drop? Does the frame-relay circuit lose connectivity? What do you do to recover it? Does it come back on its own?
Two full PRIs over a 1.5 IP circuit is pushing the limit, even with G.729. The symptom of overloading is usually poor call quality and not circuits dropping. Do you have any monitoring in place of bandwidth, CPU, memory, etc? Anything in log files?
By "whole circuit drops" I meant to say that the Adtran stopped sending traffic. Not a reboot or a physical drop of the T1. Sorry if I was not clear.
Yes, two full PRIs over a 1.5 is pushing the circuit to it's limits. We were able to resolve the issue by increasing the queue depth of the RT queue at the egress side. The provider's aggregation router.
Thanks for all the feedback