Interesting issue on PRI w/DID in US

[ronromano]

I am installing a 406v2 3.2.17 w/ 2 PRIs from AT&T. Here is an interesting observation that might be of some help, or might point out that i don't know what the hell I'm doing.

The carrier is presenting the last 4 digits. If there is no user with those digits as the ext, the carrier comes back with a message saying the number is not in service.

If I send the call to VM:module, it works fine.

I find it strange that if I try to send it to another user not with the matching digits, the call fails.

I point this out as a workaround for those who have not seen this. If you have seen it, do you have any suggestions.

I've got systems from 2.1 to 3.2 and this is new to me.

 

[jml2665]

You might be missing the default ICR that was on the system originally, usually set to send the trunk group to "Main" This would be the "Catch-All" for any un-defined numbers

 

[flashover]

were do you want the calls to be routed to when no digits match

 

[CarGoSki]

The problem is likely what the two previous posters said.

In IPO you have to define and incoming route for each DID or else you will get what you have described.

You can rebuild the default route after you have determined the destination for unassigned DIDs.

Create and incoming route with the proper line group(perhaps 2 incoming routes if you have 2 PRIs and they are in different incoming groups), leave the incoming number field blank and define a destination. Viola!

 

[ronromano]

I would have to say that this falls on the side of me not knowing what the hell I'm doing. I didn't think to look at that.

I checked and somehow it was gone.

Thank you all for your posts.

 

[crumthwacket]

Join the club - I sincerely appreciate your honesty and good humor. I was once working with a tech who stepped away from me to call Avaya support (and used my id) - the Partner system wouldn't initialize. He couldn't spell C L E A R correctly.