slagburn

Great question. We're starting on a proof of concept (sorry been hanging out with data geeks too long) project to see how things are going to go with swapping our PRIs with ITG trunks...

If I understand your post correctly you're using pure ITG tunking with no Singalling Severs? If so why? Have you engaged any additional support through a vendor / Nortel to resolve these issues?

skypilot

Initially yes... It will be followed with Sig Servers. My issues are with the apparent lower reliability of the ITG cards to stay functioning as against the PRI's.

Issues I have dealt with are QOS, now ok.
Lack of volume on DDI's transfered via ITG trunks to networked sites, jury still out on that one.

What bugs me is the more frequent times an ITG card needs a "cardReset" or all channels go "sbsy" for no good reason. This has happened to me on various sites. We draw a blank on these as there is nothing on the meridian mtc records or on the OTM logfiles to give a reason.

A (not so!) funny thing is when the Meridian shows all channels idle, the ITG pack shows "disabled" and when you log into the ITG card itself the channels are idle!

If any one has any experiences themselves please post.

Skypilot


P.S. I must say we get good support both from our internal data people and our supplier.

slagburn

Oh goody!!! I was just starting to get rusty on my pad table knowledge. (Had lots of issues with echo and garbled messages when we went to centralized VM and PRI interconnect with analog DIDs)

Any quick tips and tricks on the QOS side of things?

skypilot

Ensure you have a v.good data network with no bottlenecks.

Make sure you use a Vlan for voice traffic.

Do the maths and make sure that there is zero possibilty of allocating too many itg trunks on a route where you could run into bandwidth problems e.g. you allocate 20 itg trunks, you run out of bandwidth after 15 calls are in use and Debbie starts to download her favorite Oscar movie clips = watch the rest of the ITG calls on the route drop intermittantly !

Pay particular attention to any analogue exts for volume problems.

Set up a "spare" pad table /pri route and use for testing. Have fun tuning the pad table on a test route ( you will need the practice as it can vary from sites to site! )

Skypilot

slagburn

Great info I'll add this stuff to my list of things to check out as we implement trunking with our ITG stuff.

Out of curiosity how much data bandwidth do you have between locations and what type of data traffic is being carried by the bandwidth?

Our network guys have convinced themselves that the answer to good VoIP is just more bandwidth and no consideration for designing the network to differentiate between the different applications using the bandwidth.