What type of equipment is used for the pots lines?
Are calls lost on outgoing only?

grandstream gateways for the SIP to POTS

UCx analog trunk card on board

and the customer believes incoming, but they have both way trunks assigned.
'Course it never happens when I am there waiting for it.

Are the pots lines copper, pri, or t1?
has telco checked the lines at the demarc?

Copper analog , no T1 or PRI
Phone company there today. No problems. Got to think it's a gateway programming issue; I checked everything on the UCx looking for some type supervision setting on the trunks. None that I can find.

Have you been able to determine whether the lost calls are on the GS gateway or the trunk card?
The gateway would be a likely cannidate due to the many configuration options

Not been able to determine; I have been watching the LEDs on the gateways but it happens so intermittently that I can't tell whether it's a dropped trunk or one that someone simply hung up.

ask your customer if they could try to make note of the time when it happens
with that you can narrow the search through call records and log files for a clue to whats going on

I would check for updates first see if that corrects the issue.

Folks it is not time sensitive; I updated the UCx just last week. I did check into any updates for the BCM and found that there have been none since 2005; I am going to try that tonite after hours. I am also going to take each trunk out of the group, one at a time and call until I get a failure. I'll let you know. Thx guys!

If the disconnects happen on the trunks connected to the SIP to FXO gateway trunks, check if you included the option
session-timers=refuse
in the corresponding SIP trunk configuration. As far as I remember, this option is required for Grandstream gateways (some others might need it, too).

If the disconnects happen on the internal card's trunks, look at Global Settings on the PSTN Cards page - specifically at the three Busy Detect related settings. If you have Busy Detect Enabled set to Yes, make sure the Busy Detect Pattern matches the cadence of the tone the CO sends when far end disconnected the call (e.g. set it to 500,500 if the tone is on for 500 msec and off for 500 msec). Also, set the Busy Detect Count to something like 10 to avoid false detection.

Hey thanks UCxGuy! The session-timers=refuse were in place. The only PSTN card page I have is for DID's. and there is nothing about Busy Detect.
I have v4.0 s/w. What am I missing please?

If your Digital Gateway Firmware is showing "2005", then you should do an update on the firmware. Here is the link for the procedure.

http://www.emetrotel.com/tsd/content/bcm-firmware-...

Also, if you can get the customer to do a "Feature 9*9" when the calls drop this will do a Log Stamp in the Support Logs that may give an indication of what's going on if you need to open a ticket with E-Metrotel.

Hope this helps and have a blessed day!

www.ucidirect.com
Stocking Distributor for E-Metrotel

I will try the F 9*9 thing but where are the busy detect settings please? I can find no "Global Settings"; I have UCx v4.0. Are the settings on it or on the BCM gateway?

Try this:

http://www.emetrotel.com/tsd/content/configure-ana...

Go down to the "Disconnect Supervision" section and then read the "On a Release 4.0 System" section. This explains how to check the settings in the chan_dahdi.conf file

www.ucidirect.com
Stocking Distributor for E-Metrotel

Thanks I did that and looks fine. I dunno.

For UCx 4.0, I would start with the following "Busy Detect" options in the chan_dahdi.conf file (if you actually need them for disconnect supervision):

busydetect=yes
busypattern=500,500
busycount=10
 

The busy pattern should be adjusted to match the cadence of the disconnect tone from the CO (i.e., the tone generated by CO after the far end disconnects).

With the options above, the call processing software will disconnect analog trunk calls (internal card only) when it detects 10 repetitions of 500 msec of tone followed by 500 msec of silence. The tone does not have to be any specific frequency. In fact, even speech could trigger the disconnect (especially with a low value used for the busycount).

If you don't need the busy detect feature (e.g., when disconnect supervision is implemented using polarity reversal), the feature should be disabled (to avoid unexpectedly terminated calls) using

busydetect=no
 

Well I checked the conf file and all I have is:
busydetect= yes
busycount=10

I do not have a busypattern=500,500 as a line
I have 4.0 sw

so just mark busydetect=no then? I do have supervision w/polarity reversal from the LEC

verify all the trunks are indeed giving supervision upon answer.
I've had a case when the telco trunk would not give supervision at times!

SOOO I should make the change busydetect=no from "yes"?