I need some brain storming and confirmation on a problem with PRI and SCN.

[Z-man]

So I will try to make this post as concise as I can. I think I have figure out the issue but want to make sure about things before I start doing some changes. it is a bit complicated, but then again, so is the IP Office, LOL.

We came in a couple of years ago and took over for another vendor. We found a few issues that needed corrected, but for the most part we didn't make a lot of changes due to the fact that the customer was used to the system working a certain way and we didn't want to reinvent things for them.

UP until a few weeks ago, I had a customer who connected across the SCN on Lan2 for all 7 sites. All 7 sites were on the same subnet on LAN2, and the IP Offices connected to each other via a LAN port on the providers router. Kind of like there own little MPLS type network or private subnet. There is one main location, and all the other sites connect back to the main location via SCN. They do not connect directly to each individual site.

Each office as a local PRI and they do not route any outbound calls across the SCN. Only the main site has VM Pro, all the other sites do not use voice mail and they forward their calls at night to an answering service.

The sites used LAN 1 for local manager access.

They then changed providers, and the new provider said they could not duplicate the same settings as before, with all the systems going across LAN2 and the same subnet. So we had to change it so each system used LAN1 and their own local subnet to communicate with the local subnet of the main system. Everything seems to work fine using SCN and 4 digit dialing. All systems use unique 4 digit extension and group numbers.

The strange issue occurs when one office wants to forward its main number to another office so the second office can cover its calls. If it dials the office directly, there are no issues with the call. If it fowards the call to the other office using trunk to trunk forwarding across the PRI, it will hit the second office, and then immediately forward the call to the main office across the SCN.

I hope this is making sense. I think the issue is that none of my inbound and outbound trunk groups are unique. Most of the PRI lines are using 0 and 0. The systems seem to recoginize a call from one of the other switches on the SCN, even though it is using external PRI, and it routes it all back to the main system. I think this wasn't an issue when the were using LAN2 and all connected on one subnet, but now everything is going across LAN1 and it has changed. I suppose ideally they should be forwarding calls using the main hunt group of the destination office, instead of using the main telephone number, but they have been doing it this way so long I am afraid to implement this change.

I have 7 offices to fix, so before I start trying to reprogram everything I wanted to make sure I was at least on the right track. I planned to go to every office and assign unique inbound and outbound trunk groups to each system. Does this sound correct?

Thanks for taking the time to read. I appreciate the help.

Z

 

[Westi]

The way I would do this is to create a local group in each system and put a user of the SCN system that takes the calls into that group.
That of course only works if always the same IPO is taking over as coverage.

If you have to be flexible then it should work without any issues regardless of the IP addressing if you forward the calls to another site.
How is your network setup, star or mesh setup?

Joe
FHandw, ACSS (SME)

Remembering intrigrant 2019

 

[Z-man]

it is currently setup in a star configuration. Most of the programming is from the previous Vendor. I am going to convert it over to a mesh because I think they communicate better that way anyway.


I thought we could forward calls via huntgroups instead of using local numbers, but that scenario doesn't seem to be working.

Its just really strange that you can dial the main number from site #2 to site #3 and everything works great. But the minute you forward calls, it hits site number #3 and immediately goes across the SCN to site number #1. That part is just not making sense to me at all.

 

[Westi]

makes no sense to me either.
try forwarding to another target in the same system and see what happens.



Joe
FHandw, ACSS (SME)

Remembering intrigrant 2019

 

[Z-man]

Westi,

that was one of the very first things I did. I have them forward from site #2 to site # 4, and the results were exactly the same!

So let me explain how they are forwarding. There is just one member in the hunt. The one member uses the forward feature and makes sure that "forward hunt group calls" is enabled.

What does seem to work, is if you create a time profile, call it "TempFwd" and you make the destination the phone number of the correct office, it works without any issues.

These issues seem to have all started when we switched the SCN from WAN to LAN. I have configs from before and after and nothing is standing out to me. I even disabled "Direct Media Path" as well.

 

[derfloh]

Is the hunt group set to ring mode ‚sequential‘?

IP Office remote service
Fixed price SIP trunk configuration
CLI based call blocking
SCN fallback over PSTN

 

[Z-man]

I will remote in and check. It might be set to collective call waiting. Not sure why it would matter? The call does forward offsite from the hunt group. That part works. It just gets rerouted the instant it hits the destination switch.

Thank you all for taking some time to work this out with me. I appreciate all the input.

 

[Z-man]

just revisting this thread to see if anyone has an update. I went into two of the systems in question and made sure all the trunk groups were different at each site, and that those sites didn't have the same trunk group as the main site. Still does not work.

 

[teletechman]

What about ICRs do you have one in each system that has the same number you are forwarding?
Mike

 

[Z-man]

Originally they had duplicate trunk groups for incomning call routes, 0. I changed them to be site specific but it did not correct anything.

 

[bahmonkeys]

Hi Z-Man
I have set this all up myself on multiple sites. Just break it down..... On the secondary site which forwards calls OOH to the VM Pro located in the Primary site. Use short codes!! Test it and test it again.
If you want to get a little bit smarter program a button on the Recept phone which will put her calls into fallback and point this fallback group over the Advertised VM autoattended

 

[teletechman]

can you get a trace of a call that is affected from both sides?
Mike

 

[critchey]

I will remote in and check. It might be set to collective call waiting. Not sure why it would matter? The call does forward offsite from the hunt group. That part works. It just gets rerouted the instant it hits the destination switch.

A group set to collective or collective call waiting should NOT be forwarding to a user set to forwarding. Think about it... if you have 10 users and they are all set to forward where in the world would the call go?

Taken from manager help about "forward hunt group calls"

Hunt group calls (internal and external) are not normally presented to a user who has forward unconditional active. Instead they are presented to the next available member of the hunt group. This option, when checked, sets that hunt group calls (internal and external) are also forwarded when forward unconditional is active. The group's Ring Type must be Sequential or Rotary, not Collective or Longest Waiting. The call is forwarded for the period defined by the hunt group's No Answer Time after which it returns to the hunt group if unanswered. Note also that hunt group calls cannot be forwarded to another hunt group.


Have you tried setting the group OOS or to night service and forwarding that way instead?

The truth is just an excuse for lack of imagination.