IPO R9.1 and R8.1 Trunk Drops every couple hours

[bbaits25]

Afternoon,

I have an IPO R9.1 and R8.1 on the remote end, the trunk works great for half of the day then we cant dial to them and vice-versa. I tore down the trunk and re-added on our R9.1 IPO Office and comes backup. The networking on the VPN tunnel is up and can ping both IPO's. On the R9.1 I delete and Re-Add the trunk, it comes backup and able to inter-dial between them. When i looked at system status it says "Out of Service" when issue arise. When it comes back up its idle like what it should be.

On R8.1 you can only configure h.323 and R9.1 you can configure a IP Office Line or h.323. I have configured R9.1 an IP Office line, has other people have had issues?

The weird thing is, I have R8.1 at a couple stores that have h.323 only and R9.1 IPO I have an IPO Office line, there inter dialing works. I would think I would run into issues there.

There is more call volume that goes through our R8.1 and R9.1 through inter-department transfers, R9.1 calling out of R8.1 phone system etc.

 

[Andhee]

How many network channel licenses do you have for each system?
Each site should be licensed for the same amount of channels.

If vegetarians love animals so much, why are they eating all of their food?

 

[amriddle01]

This is classic firewall/router interference, had similar issues that we proved was the router by building our own VPN and it worked flawlessly.... back to IT thanks

 

[intrigrant]

Each site should be licensed for the same amount of channels.

Non true.... and it has nothing to do with the problem. Only outgoing SCN channels are licensed, incoming is limited to the number of available VCM channels.
Of course you need to have suffcient VCM resources.

use monitor and look for error messages in the trace.

 

[bbaits25]

Ok when it happens again I will update. I have VPN connections to all the remote branches and those don't go down, including the location with the issue. We are using Sonicwall's of mixed series, TZ200 series, NSA2400 and NSA 3600 at HQ. The only difference between the remote locations and the R8.1 and R9.1, is that there is a direct fiber connection to the building which i built a VPN tunnel just like our remote locations over MPLS (they dont have issues calling us or vice-versa). For the VCM channels, we have VMC64, so that is more then efficient, I have seen at the most 8 calls going at once on the system status. For the licenses, We have 16 at the R8.1 and 12 at the R9.1, So we have sufficient resources for that as well. I changed the trunk to h.323 to R9.1 instead of the IP Office Trunk. I'll see how that goes and look at system status.

 

[amriddle01]

The VPNs never went down in my case, they simply stopped routing some traffic, the VPN doesn't have to go down to have issues

 

[bbaits25]

So I got more info, i just noticed this in the system status which i totally overlooked. Our Corporate (R9.1) internal calls are going to one of our Branch locations trunk then to Branch (8.1), which isnt correct, they should be going out the designated correct trunk. Calls from the branch (8.1) to Corporate (9.1) are going to another locations then to us....so theres a problem with the SCN not going out the right trunk? I tried to force an example extension out the trunk and still goes to the wrong one.

So what's happening is Corporate calls are getting transferred incorrectly over the trunk to another branch locations and we dont have enough licenses for it on the small branch end (4) so it gets overloaded then drops the calls.

Any suggestions on correcting this issue on the calls going out the wrong trunk?

 

[amriddle01]

Your SCN trunk programming dictates how it works, if calls can go direct they will, if their is no direct trunk to that site but there is through another system then that's what will happen

 

[bbaits25]

There is a direct trunk to that site, but it chooses to go out another branch's trunk to get to it unfortunately. The systems that are being affected are preferred edition as well. How does the IPO determine which trunk to go out of first if both are accessible from another remote ends trunk? I would think it would go directly to the first direct trunk then another branch trunk (which are perferreed license which its the one its choosing) By least cost routing? Or just picks one randomly? Thanks!

 

[amriddle01]

Did you follow the golden rule that they all need to have their own outgoing line group?

 

[bbaits25]

Yes. They have all have there own Outgoing Group ID and Line

 

[amriddle01]

Watch the call in monitor, I imagine you'll find the direct trunk is OOS

 

[derfloh]

Sound that the direct trunk (or SCN status) is inactive and IPO decides to take an alternative route. Did you check the trunk status in SSA and messages in SysMon when dialling?

 

[bbaits25]

R9.1 it shows SCN down, i believe after i switched it from IPO Office to h323 with supplementary services to h450 it went to that. Before I had an IP Office line and the SCN was up before. in SSA, it shows idle for 20 channels like the others .

 

[Jerrberr]

looking at it from a quick glance, does the extensions mis-routing have a "9N" programmed with a different line group? That could override the system line group and sling a call elsewhere.

- first always eliminate the obvious

Jerrberr

 

[bbaits25]

9N is going out our 50:Main ARS which is our PRI.

 

[Jerrberr]

Also are you resetting your system every time your trunk drops? As most of us have seen licensing can allow a two hour window to get things programmed and then it expires it locks down the feature. Licensing may be an issue( verify that status). If its up, then down, then back up, I would be looking at call volume(sys monitor=> lines=status) and when it exactly when the trunk drops. That could give you more information to help diagnose the cause.
-Just keep adding up the symptoms they are going to point you to the reason.

Jerrberr

 

[bbaits25]

The routing is the issue to the wrong branch which only has 4 channels, R9.1 (16 channels) and R8.1 (12 channels), R8.1 gets a call then transfers to R9.1, but it goes to the wrong branch which only has 4 channels, it gets overloaded and calls cant get transferred or dropped. So thats the issue, its routing out the wrong trunk.

 

[amriddle01]

You have unsupported systems in the mix, even when they're supported your lucky if it works, you not have that, enough said