Issues dialing out over PRI about an hour after a reboot V2 Version 9.1.4 1

[adc110]

I have an IP Office V2 version 9.1.4 that is having issues with PRI. I recently installed a new PRI card onto a DS8 in preparation for a new PRI circuit without issue.

Couple of days ago we performed a quick PRI test (inbound/outbound) with no issue and then cut-over yesterday. I started getting calls from users stating that they could not dial out (waiting for line). I had monitor open as well as System Status. When monitoring system status I don't even see a channel being picked up at all!

It seems that after a quick reboot the system started working again. During the time that I cannot call out however - inbound calls never seem to be an issue. After about and hour to hour/half it started happening again.

My PRI is configured NI2/EFS/B8ZS through an emulated PRI (cloud). The channels are all set to ID 0 with 9N pointing to 50:Main ARS table in which all entries have ID 0.

I decided to change 9N to dial out over 0 and did not have any luck. I disabled ARS failover which stopped waiting for line essentially the call just stops.

Since this system was a migrated configuration from a V1 version 4.0 back in December I decided to default the system. I held reset button until defaulted and then "manually" built an entire new configuration on 9.1.4 and then applied the configuration. System came back online with no issues until about an hour or so and then continued to do the same thing.

The PRI channels all show idle with absolutely no alarms. I then configured users to dial out over some POTS lines I still had for the weekend and calls still come in ok over PRI until Monday when I can get back onsite as I do not have any remote access.

Just before I left for evening I was using Monitor to see if I could see anything and briefly came across an entry when attempting to dial out over PRI which stated something to the affect that Line ID:0 could not be found?? I will perform some more detailed monitoring results later but thought I would throw this issue out to see if anyone has experienced this or might have any ideas?

I am at my wits end. Could it possibly be the carrier even though I don't show any channels being accessed, and with no alarms? Maybe something I should capture in monitor? I haven't contacted carrier simply because it really looks like an IP Office issue. Thank you all in advance for any suggestions!

 

[janni78]

Please edit post and use enter.

"Trying is the first step to failure..." - Homer

 

[adc110]

What does edit and hit enter mean?

 

[amriddle01]

It puts the next sentence in a new line.
Like this, reading your post is like wading through syrup as it's just one huge paragraph

 

[adc110]

Thank you for pointing it out all! I edited it. I must find better etiquette

 

[derfloh]

Is the older PRI trunk configured with line group 0 as well?

 

[Westi]

if you start Monitor and enable only the ISDN tab entries you will see what happens on the PRI.

Is it showing in System Status that the channels are out of service or do they seem to be in service?
When you attempt a call does it use a channel and just not go through (best seen in SSA)

Enable SSA and Monitor and post the monitor trace here, you might want to change the phone numbers in the trace if you want to avoid telemarketer calls

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[adc110]

I am heading back out onsite tomorrow and will post my findings!

 

[holdmusic34]

This Sip (pri handoff) is using a "conversion box' to covert xdsl to pri?
I'd be looking at the service. I feel the 'conversion box' is dropping the registration. The carrier should trust the ip address of the service and set up peering, or static on their service. They need to turn off registration and disable reregistration.
Or, you could get the carrier to decrease the reregistration timer on the 'conversion box' or increase it on the service.



Save Ferris.

 

[adc110]

The hand-off is ethernet from carrier. Internet carrier providing 50MB synchronous circuit ether hand-off to Fortinet firewall. Fortinet has a hand-off to Cisco 2400 series IAD. Telephone service carrier has direct management of the Cisco 2400 and has many other sites already operational. Since SSA shows the channels completely idle when attempting to make phone calls I am assuming that my only lead will be within Monitor (if I can see anything at all). Just because the channels show idle with no attempt to pick up on the channel within SSA does not mean that the carrier is not blocking would you not agree? Monitor may give me more info to go on. The strangest this about all of this is that the PRI will work (it seems like after I reboot or some time of loss/connectivity with PRI) for about an hour to 1.5 hours and then fails. Since the circuit is new I have only tested twice so hopefully I will have more info.

 

[holdmusic34]

And what colour is the alarm against the trunk?
Red alarm-you unplugged it or it's their fault.
Yello alarm- look in your own backyard.
No alarm check your ars.

Save Ferris.

 

[adc110]

There aren't any alarms against any of the Trunks (at least not within SSA). ARS has been reviewed to the moon and back and not the issue. I even created Shortcode directly at a user level to force dialing directly over PRI with same issues. Hoping to get back there within the next couple of hours to use Monitor to see if I can find anything.

 

[derfloh]

Did you ever check my suggestion about double outgoing line group IDs?

 

[adc110]

derlof this was a new PRI install (never had a PRI at this site). I monitored this quite heavily yesterday and could not see any issues at all on the IP Office side. Calling outbound would actually seize a trunk and wait until we got a disconnect (ISDN Code 16) from Carrier. Unfortunately waited 5.5 hours for Carrier to look into issue at which point I needed to leave. May be going back Wed. Other strange stuff I offered to the carrier was that I could actually dial a 4 digit random number (i.e. 9 for my dial-out code and then 3456 and hit # to force it to dial out) and it would dial out properly (channel 23) and the call would come back inbound on channel 1!!! I could get this to happen multiple times (although unless the carrier dropped the call like I mentioned earlier). Again - the monitor traces did not provide much in the way of any errors or issues that I could see. Will post more as I have more! Thank you all

 

[nuklhead]

I am having the exact issue on 2 sites with 9.1.4.0 Build 137. Has there been any resolution to the issue? I have 3 sites with the same set up, but only one is connecting using EOC. The other 2 are fiber. Only 1 fiber site has the same issue. I am equally at my wits end....We cut over on 8/17. about 1/2 the calls are going out. The customer is livid.

 

[adc110]

I apologize as I never followed up on this group! We ultimately determined that it was our SIP carrier. Apparently when we provided them with (2) public IP's (we use some load balancing) our second public IP which would randomly get routed from the firewall was never registered with them so the setup of the channel was being denied. Took a long time for them to figure this one out!

 

[joe2938]

exactly as holdmusic stated already!