Pots line to Trunk Line between two IPO's

[clayfoxmvp]

I am setting up an SOE to be a subsystem on a 403. I have four analog lines in a huntgroup that are attached to the Trunk ports on the SOE.

I have turned call display on for the extensions but I do not get any caller ID on the SOE.

I also have an IP trunk setup between them and I get caller ID and everything on calls over the IP trunk.

I am sure someone else has done this and can help me with what I am missing here.

Both systems are 3.0(44). I assume I want Loop Start ICLID but right now I am getting the delay as it waits for ICLID.

Any help would be great.

ALso any recomendations on how to speed up the delay dialing from the SOE through the 403? Right now I get dial delay on both switches. Is there a way to bypass the dial delay on the 403 for calls originating from the analog ports or is there a short code?

Thanks
Clay

 

[IPGuru]

Piggy backing using analog trunks is always going to be a poor compromise.
I suspect your CLI problem is because the IPO sends lots of additional info to its analog exts (Source & destination ID's)

With an IP trunk setup between the 2 systems why are you even bothering with the pot-alog trunk setup?
get the SOE to pass outbound call requests to the 403 Via the IP trunk.

 

[clayfoxmvp]

Some of the reason is political and some is that the network is not always as realiable as they would like so this way they have a hardwired connection through to a PRI.

Is there a way to limit the information output from the 403 to make it more friendly to the trunk loop start ICLID port?

From other posts I do not think I can have the POTS group backup the IP trunk because of IPO's ability to detect problems with the IP trunk. Is this correct?

What is my best practice for redundancy?

Thanks
Clay

 

[JeSTeROCK]

The IPO doesn't fallback well when IP trunks go down

Program a # to overide and use another route, not very nice or automatic... waiting for the IPO to catch up to the rest of the voip world

 

[IPGuru]

There is no automatic fall back on IP trunks (yet) but personaly I am not 100% keen on automatic fall back any way. If it works as intended your customer does not become aware of problems untill the backup fails as well & if you dont know that something is broken you cant take steps to fix it.

If the customerts network is as unreliable as you imply then I would be concentrating on finding the cause.

My final recomendation would be Voip Networking (after locating the cause of network instability) with 1 or to direct analog exchange lines to the IPO as backup incase of failure.