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?
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.
Well I spoke with our installer again yesterday and he thinks he recalls Samsung making some add'l firmware updates to better support our situation.
It really works quite well except for this one quirky issue in the 100. We've never had any loops that I'm aware of. We did have to tweak certain settings to make it work, adjusting the co-co timer, route optimize, etc but once we got it going ok it's been pretty decent.
One item that has been frustrating is we use digital telephone hybrids to break out the CO to separate send and receive paths for our broadcast consoles. These hybrids send a burst of white noise out to 'sample' the return audio and adjust the equalization and hybrid null with each call. The problem is the delay from when the sli line is seized on the 500 to when the 100 captures the CO line. Our digital hybrids only null the line for about 1/2 - 3/4 of second, the process takes slightly longer than this and thus we end up with some pretty bad nulls from time to time.
Well after troubleshooting the problem for a while with our vendor we finally found a problem. Samsung actually suggested we double check the dip switch settings on the network TEPRI cards. What we found was the 100 was set as the primary network card (SW4 on) and the 500 was set as the secondary card.
According to Samsung it shouldn't work at all but they had seen instances of it working even though it shouldn't.
Hopefully this should clear up a number of issues including slips and not releasing the trunks/channels across the network.
I am glad its fixed.
Edited for clarity
(desided not to rant)
One thing I failed to mention in my other post which is probably very misleading, is that our 500 receives its clock from the telco PRI, so to have the 100 act as the master of the networked switches is backwards and that is what our vendor is going to correct.
Once corrected the 500 will continue to receive the clock from the telco PRI and then it will pass it on to the 100.
Hopefully this should solve the majority of our issues and I hope haven't totally confused everyone as to what was going on.... :scratch:
Hope everyone has a good and safe holiday! :thumb: