atcomsystems.ca/forum Forums TDM Business Telephone Systems Samsung Telephones & Systems iDCS100 not releasing PRI trunks on network

I have an iDCS500 & iDCS100 networked together that I administer. They are located in two different locations and are networked together via a dedicated T1 using PRI/T1 cards in each switch. (no MGI in use)

Outside lines on the 100 come in via POTS trunk connections and some calls are directly routed to the other location using the PRI/T1 card via the T1 connection.

The 500 always releases the trunks on the T1/PRI card correctly. However, the 100 is occasionally not dropping the networked call between the two switches.

If I got into Connection Status I see the CO trunk and PRI trunk are still connected to each other. The only way to drop the call is to do a Forced Trunk Release or System Reset.

My first thought is why isn't the CO to CO transfer timer eventually dropping the call (we've had it do it in the middle of a legitimate call before we lengthened it past the system default!)

But is this some kind of firmware issue? Like I said the 500 always releases the trunks and is perfect, I've never seen a hung trunk on it.

The 100R2 is running 2.44 3-22-2005, PRI 1.05 8-20-2002. I know the PRI firmware is a little dated but I was told the updates only deal with CID information which I wouldn't think is used in a networking mode.

Any ideas? MCP or PRI update in order?

Yes is good idea to update this MCP 2.44 IDS100 and the PRI but first check if you have a correct disconnect on the POTS lines.

Hmm, well CO Supv TM is set to 40ms. They are all loop disconnect lines. It works 99% of the time just every now and then it doesn't.

Would I dare enable Loop Trk Tone Disc? Could it easily be falsed by certain audio?

I'm also going to look into shortening my co-co timer

Okay, I just wandering if POTS disconnect OK!!!, I’ don’t know what this 99% really men. Sorter, if CPC disconnect works forget about Tone disconnect or audio interfering and for the last patch Co-Co timer disconnect ??? .Who are you ???.Just PM for more. :bang:

U have said the the 500 is working perfect. So let's look at the 100. Does the same problem happen when you to an co trunk to co trunk conferene call or call someone the hang-up. If you make several calls (i mean ten to twenty call) does the problem happen. Does it happen using on one trunk card or is it random?
Are all trunk set to sent disconnect signal(or the correct timed signal) from telco carrier. They all should be the same. Yeah right! These are just things to narrow down the problem. I hope they help!

Sorry to be confusing, the calls that come in on this trunk line are directly routed back out through the T1 to the 500 so they fall under the co-co disconnect timer. At one time we set the co-co timer at 250 (max) to make sure long calls never got dropped in mid conversation.

Here is the quirky thing we're doing, we're basically extending the CO Trunks in the 100 to dedicated extensions in the 500. When a CO calls comes in on the 100 it rings an extension on the 500, and only that extension. When that extension is picked up on the 500 it grabs that same trunk on the 100.

This is where the problem gets tough to trace, is the call coming in on the 100 going to the 500 and the co to co connection not being dropped OR is the extension going off hook on the 500 and when the call is completed it's not being released?

I have no way to know for certain.

Hope this makes more senses

are U call forwarding the co trunk from the 100 to the 500?

Are U using Network LCR?

No and Yes.

The incoming CO calls are simple on the 100. We use trunk ring assignments direct to the extensions in the 500 using LCR on the 100 to route the incoming trunk calls to the extensions in the 500.

In the 500 it's more complicated, me, the installer, and Samsung worked to get it going and maybe there is a simpler solution but this is what we currently do:

Extension in 500 hotlines to a v-ext, the v-ext call forwards to a v-ext in the 100 via LCR, but the DID translation in the 100 actually re-directs the call to the same incoming trunk explained in the first paragraph.

WOW! I bet this took some time to setup and test!
I see that you have recreated an Loop! I maybe wrong but I think this should be giving you problem from day one. But knock on WOOD! It doesn't. I am think that it's( the problem) in that loop. If what i understand is right you have setup a virtual extension intercom call with a co line. or maybe we should it a conference call setup? What does tech support say? Or can someone else on this site give LightGuy48 some more input? Please keep us updated on the solution.