stubborne

Hey, we have some POS gear that dial toll free for whatever they do. I'm getting:

denial event 1190: ISDN no circ/chan avail D1=0x830056 D2=0x222

on alot of the outdials from a particular piece of equipment to a particular toll free. Any ideas??

Thx!

__________________
Stu

koelemon

At first glance it looks like the trunk may be too busy, have you checked out any trunk reports for blockage? Also, try "list ars route 18001234567" to make sure its routing the same as other toll free numbers since you mentioned it is a particular toll free number. In addition to that, is this particular unit partitioned?

__________________
"There are only 10 types of people in the world,
those who can read binary and those that cannot."

PBXtech.info

 

stubborne

Yeah, got plenty of capacity. I think I stumbled on the problem, altho it doesn't reflect on the denial message at all. I had another complaint from a new piece of equip we're installing, it couldn't connect to it's vendor. Let me back up and let you know the configs: we use VOIP to our analog devices as well. We have a Cisco solution, basically a router with a gateway to the PBX (2 ISDN/pri's) and a gatekeeper database. The endpts are various Cisco crap, ATA186, which are two port CHEAP devices ($125) with little config - pretty snazzy - and some FXS blades that fit right into our routers. Anyway, the call comes from the gatekeeper with CID = 5-digit extension (what is programmed in the GK db for each endpt). I was assuming the PBX was using the ISDN PUK table to create a valid CID - WRONG. It wasn't. So, calls were going out with a 5-digit (invalid) CID and some of these vendors were denying connectivity. Whew. My fangers hurt. Anyway, seems to be fine now - I'm just padding the CID on the gateway trunk group. Come on friday....

__________________
Stu

tek

holy crap that was a lot of info in 5 sentences. hahaha amazingly I understood all of it.

ahays

Did you ever get this fixed? I'm having a similar problem in a 5-node IP Trunking network. Node 0 is the hub. There are 4 spokes. Node 0 talks to node 1 and 2 in both directions. Node 0 can talk to node 3 but Node 3 gets the ISDN Denial 1190 event. Node 4 can talk to Node 0 but Node 0 gets the ISDN Denial event when attempting to call Node 4. It's bizarre.

.al.

__________________
Al Hays, ACE, MCSE, CCNA
Homepage: http://www.jeral.com/
Training: http://www.jeral.com/avaya-learning.html

ahays

I just spent about 30 minutes on the phone with several of my Tier IV buddies and the solution was a forehead-slapper that they found within 5 minutes of dialing into the remote switch. The H.323 signalling group on the far end did not have the trunk group number in the "Trunk Group for Channel Selection" field set. Once the correct IP trunk group number was filled into this field the call went through just fine.

Here's a note to ponder, however ... the actual ISDN denial event was being reported on the calling end but the call was actually being denied on the far (receiving) end. I mention this because, in your case, the Cisco device is likely denying the call and the Definity is simply reporting the result of that denial. That doesn't necessarily mean that the Cisco was the culprit but it's where I would start looking.

regs,

.al.

__________________
Al Hays, ACE, MCSE, CCNA
Homepage: http://www.jeral.com/
Training: http://www.jeral.com/avaya-learning.html

PBXtech.info

 

stubborne

Interesting. Yeah, I did end up clearing that particular event up by sending the correct CID with the call. I can't for the life of me see the resemblence between these two issues other than the event ID.

__________________
Stu