Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Inbound PRI calls not hitting switch, wrong "DDI" number showing up in System Status alarm 3

Status
Not open for further replies.

Straggle

Technical User
Jan 22, 2009
68
US
I have an IP 500V2 that was on 8.1.69, with a UC module, and PRI phone service from TelePacific.
2 days ago I remotely upgraded it to 9.0.8 and had inbound/outbound calls working, the Voicemail Pro was answering calls, and users could check their VM.

Last night I upgraded them to 9.1.4, and that's when the stuff hit the fan. The VM Pro would not link up (I did not update the UC module to 9.0 or 9.1). I then decided to roll back to 9.0.8, which I did successfully.

The customer then informed me that they're not able to receive inbound calls, and could not make outbound calls. The phones say Waiting for Line. The trunk status shows no alarms, and the carrier says "No issues."

I did notice that when a call comes in on any of the DIDs a "Configuration" alarm says: "The following line had no incoming call route for a call. Line 5, Line Group ID: 131072, DDI: 06522" (I have a Monitor trace text doc attached)

What strikes me about that is the "DDI" of 06522. The actual main inbound number (omitting the area code) is 642-6522. Where does the 0 come from on that DDI? Why does that same DDI show up no matter what DID is called?

I have deleted the formerly working incoming call route, (both the correct route, and the "catch all" route with no actual incoming number listed in that field), rebuilt the route, rebooted the switch, powered the switch down for 20 minutes, and changed the destination for both routes to known working extensions.

Thoughts?

I'm going to site tomorrow to upgrade the UC module with the USB boot upgrade tool to 9.1, will bring the switch back to 9.1.4, and I'm sure that'll fix the VM link issue, but this DID one is weird.

All help is appreciated. I'll be monitoring this feed tonight to be ready for tomorrow. Thanks all!
 
 http://files.engineering.com/getfile.aspx?folder=ca748797-9071-47b0-bff5-02afd2681059&file=Called_DID_4626522.txt
I have done it myself once and all kind of things stopped working, the system was really messed up and to get it working again i had to do the following:
- factory default the IP Office
- clear security settings
- reload 9.0
- reload a backup of a 9.0 config
 
I have found 9.1 manager will append spaces after numbers entered in the Incoming number field, it may have also added a space in the apparently blank default route, as you can't see a space you can't tell but it stops it matching.

Try clicking into those fields and make sure there are no hidden spaces :)

 
See
Called number is being presented as 6 digits and number format as national.
Pbx is pre fixing a 0 to called number.

Calls number no longer matches icr if programmed for more than 6 digits

Reduce icr to 6 digits or get telco to send called number as unknown number type.

Daken
Ps I'm still trying to get the telco to fix this for me
 
So here's what it was: my "line 5" (the PRI) settings had been corrupted in my config, and the "Line Sub Type" box was blank. When I clicked the box to select PRI, I could select PRI, but when I clicked it the "OK" button would NOT light up and let me click it.

Whenever I went out of the "Line 5" settings the Line Sub Type would clear again. Reboots, full power offs, and using 3 different computers, did not solve the problem.

So I Erased the config (File, Advanced, Erase Configuration) and created an entirely new config after exporting Extensions, Users, Short Codes, Incoming Call Routes, and Hunt Groups.

I then deleted all the extensions, users, short codes, and incoming call routes, (couldn't delete the "Main" hunt group...yet).

Then I imported all the stuff I'd exported, was able to set the Line Sub Type, and sent my new config to the 500V2 cabinet.

PRI came back up with inbound and outbound.

I'm not sure what caused the system to need me to do all that, but (trunk-wise) we're good now.

I now have transferred my attention to getting this US Module to work...and that's a WHOLE other story.
 
Every time I've downgraded from 9.1 to 9.0 it has hosed the lines, specifically the PRI's. The line type would be wrong, there would be a whole bunch of tabs not associated with PRI's available, and Manager would crash every time you went to the line to try and square it up. Erase and rebuild, importing where possible.
 
Glad I found this thread. A colleague upgraded a 3 site system yesterday from 8.1 to 9.1. He didn't bother to check the systems properly so we ended up with one system having no ISDN as the PRI on legacy card obviously stopped working. Did a downgrade this morning to 9.0 to get the PRI back working only to find all the PRI and SCN lines were still playing up.

Then had to get an engineer to site to default the system and upload the last good 8.1 config to the system - as we couldn't dial in due to the PRI issues!

Nice couple of hours of downtime for the customer who thankfully took it really well.

| ACSS SME |
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top