Silly Lab CO Trunk Arrangement

[trmg]

Since the Meridian 1's CO trunk do not support Caller ID, I am toying with feeding it inbound calls via a Cisco ISR. The ISR will ingest the Caller ID data and then forward the call, along with calling party info, to the Meridian over PRI.

This works great! However, I'd also like to leave the CO trunks directly connected to the Meridian so that outbound calls use them directly rather than going through the ISR.

Yes, this could possibly lead to issues with the system attempting to use a trunk that's already in use, but it's a lab environment and I'm OK with that (enabling dialtone detection might help if the analog trunk card I have will support it).

However, what I cannot figure out is how to configure the CO trunks in such a way that when a call comes in the system ignores the call. The Meridian will either 1) ring the defined ATDN on the route, or 2) ring the attendant DN which presumably is coming from NITE.

Is it possible to configure the trunk(s) so that inbound calls are ignored and not routed?

 

[KCFLHRC]

Just send the inbound trunk to an analog phone port with no set connected to it and it will just ring and ring. Or to a Dummy ACD Que with no NCFW

 

[trmg]

KCFLHRC, I was thinking something like that. Was wondering/hoping there may be a more elegant solution, but that will work. :-D Thanks!

 

[trmg]

Ok, this works pretty well. The only issue seems that the M1 is sending ringback to the trunk. So depending on when the line is answered in relation to the ringback cycle on the M1, you may hear 1 to 1.5 worth of ringback. Is there a way to tell the M1 to not play ringback to the CO trunk?

 

[KCFLHRC]

Is this configured analog phone or dummy acd? The ringback is more than likely not coming from the M1

 

[trmg]

At the moment I have it going to a SCN line appearance on a digital set. The ringback is most definitely coming from the Meridian.

 

[KCFLHRC]

I hate to ask, but how do you know the ring back is coming from the M1 ? I'm guessing it's not

 

[trmg]

Because if I unplug the analog trunk, I don't get double ringback.

 

[trmg]

Basically what's happening is this...

Call comes in, the line goes through 1 ringing cycle so the ISR can collect Caller ID data. Once the ISR collects the Caller ID data, it then answers the line and PLAR's it to the MCR I have set up for said line. At that point, you get ringback from the M1 via the PRI (expected), but you *also* still get a 1 to 1.5 of a ringing cycle from the analog trunk.

I can reproduce this very consistently. Unplug the analog trunk from the M1, problem goes away.

There is a ring detection timer that I may play with.

 

[KCFLHRC]

You may want to check the ring back fluid level in the M1, it may be overfilled. Kidding of course. Good luck with it.

 

[trmg]

I'm not exactly sure why it generates ringback on a loop start COT that it has not answered in the first place.

Here's a thread where they're experiencing the same issue:

https://www.tek-tips.com/viewthread.cfm?qid=1539064

 

[trmg]

Anyone know if thread798-1539064 or thread798-1514370 ever found a solution? :-D

 

[trmg]

Looks like adjusting NRD under LD 16 seems to help. I bumped it down to the minimum (128 ms) and now no more double ringback. This "works", but was hoping for a more elegant hack (like disabling ringback tone on COTs configured a LOP). I'm sure in my experimentation I'll find a "gotchya" with this eventually. I think the solution is to source a loop start to ground start converter. :-D


NRD 128-(10112)-32640 - No Ringing Detector change

This timer monitors disconnect on unanswered or abandoned incoming CO/FX/WATS trunk calls. On loop start trunks this is the only monitor for such calls where as for ground start trunks, it serves as a back-up mecanism.

The timer should be set for four seconds longer than the ringing period which is normally six seconds. When the period (specified by the setting) expires, the timer will trigger a trunk disconnect sequence. Too small a default value can cause disconnects. To great a value can delay release of the trunk if the ringing has stopped.

On a ground start trunk, if the call goes on-hook, the 'NRD' is overridden by the 'ICF' timer, which has recognized a valid disconnect after the specified timer value has elapsed. The call is cancelled and not presented to the console.

On a loop start trunk, the 'NRD' timer is not overridden by the 'ICF' timer. The 'ICF' does not time since the loop start trunk does not give disconnect supervision. Therefore, the timeout period is the setting of the 'NRD' timer.

(Pulled from

http://www.ghtrout.net/files/Early_LD16_NTP.zip)