ISDX does not release line after call is terminated 1

[pbx1960]

Does anyone have a clue as to why every call into our queue does not release after the agent terminates it? Don't know squat about this system, we hope to replace it soon, but in the mean time the Call Center Manager is steaming. I just started working here three weeks ago, and have never worked on ISDX.
This is a GPT ISDX, here is the version (I think):

GPT LIMITED.LACE

ALL RIGHTS RESERVED.
iSDX
5.2.001 0001100 UK 09 27/08/97 A C 018
26/07/06 14:04:58

Sure hope someone can help me, I dread having to learn this system just to throw it away!

 

[speckledhen]

Are the incoming lines on an isdn link or are they analogue lines.
Also are you in the UK or elswhere in the world?

 

[speckledhen]

PBX1960

I know if this was analogue lines in the UK a disconnect clear time has to be set in the main exchange to enable the ISDX to clear the line, this is obviously what the promlem is but as you have premicells/gsm gateway there are not normally setting that can be changed so will need a work-around within the ISDX, which by the way looks like a 2nd user one that has come from the UK according to the header.
I will check out the EPs and see what I can find.

PS to reply to this post, scroll down the page a bit and enter your reply in the box provided within this post.

 

[pbx1960]

Wow, didn't have this box before! Thanks so much for your reply. Looking forward to the next one.

 

[pbx1960]

Hey!
I checked here often, and hadn't heard anything new. Now I check, and I see a lot of new comments. Awesome!
Good one about Siemens tech support! I feel the same way.
Whoever you are, that has done PBX work in Afghanistan, I probably know, or have heard of you, there aren't too many people crazy enough to come here and do the work! BTW, I am in Kabul.
A revision to my original question; I have run traces from our main exchange, and at the Plessy ISDX PABX, the conditions under which the line does not release, are actually a little different than I originally described. Essentially, when a customer calls in to discuss a problem, an agent in the ACD picks up the call, and speaks w/ the customer, if the customer hangs up before the agent does a hook switch, the agent must wait thirty five seconds before another call will ring into the queue. I checked and changed WUPT time, but no change. I also read that some variants of Q931 will ignore commands from different variants, still open to help, scratching my head on this one, as did the guy before me. BTW, the setup I described originally, is incorrect, essentially customers call into a standard exchange, and the exchange hands off to us, basic ISDN lines using.

 

[dark5tar]

Hello
I have seen this kind of thing before (sort of). I believe that you need to adjust timer T391U in your DX. Use the LQ9p and RQ9P commands to list then change the value to 2 or 1 seconds, i think the default is 30 (ring any bells). to find the q931 varient that you are useing use the LQ9I command. 5.2
software as you know is way old so there may be other problems in store.
good luck and stay safe in Kabul

 

[pbx1960]

Thanks Darkstar,
I hope that works, it has been going on for years.
I tried changing the T305 time, but doubt it helped. I checked the q931 variant yesterday, it is 8 EuroISDN.
I will try this as soon as I get back over that way. Have work to do in another location for a few days. If it works, I owe you big time!

 

[pbx1960]

Hey Darkstar,
I looked at my list of Q931 timers, I don't see the one you are referring to, I see T320, and T321 listed as 30 second default. Am I missing something?

Thanks,

 

[dark5tar]

pbx1960

does your list not look like this then?
?lq9p
VARIANT:9 (different variant prehaps)
ATTRIBUTE:a
L2PC N
EXCL N
SEG N
CRC4 N
N200 00003
N202 00003
T200 001.0
T201 001.0
T202 002.0
T203 010.0
CERT 00000
DLET 00004
N303 00002
N30Y 00000
N316 00002
N322 00006
T301 00180
T302 00015
T303 00004
T304 00030
T305 00030
T306 00000
T307 00000
T308 00004
T309 00006
T310 00045
T312 00000
T313 00004
T314 00000
T316 00120
T317 00000
T318 00000
T319 00000
T320 00000
T321 00000
T322 00004
T391U 00030 <<<<<<<
T30Y 00000
T3SS 00000
IRST 00005
CHNS 00000
RACS 00001

 

[pbx1960]

well, I don't recall if it listed that, I will have to look, we are set up for variant 8, who knows, amybe that is the problem?

 

[dark5tar]

the variant depends on what 'flavour' the far end is set to
and whether the link is basic BRA (2b+d) or primary PRA(30b+2d T1)
the options are ...
?lq9i
XXYY:????
0 S_PRA HOSTLINK
1 T_PRA AUSTRALIA
2 T_PRA FINLAND
3 T_BRA UKISDN
4 S_BRA EUROPBX
5 S_BRA CORDLESS
6 S_BRA UKISDN
7 T_BRA AUSTRALIA
8 T_PRA EUROISDN
9 T_BRA EUROISDN
10 T_PRA UKISDN
11 S_BRA EUROISDN

8 is correct for a 30 channel T bearer link using q931 euro, i'm not sure why T391u is not listed on your system though

 

[pbx1960]

Hey Folks, concerning the release issue, is there a way to check the switch side settings in the ACD, maybe switch release, or something?

Thanks

 

[dark5tar]

Here is a test to check if the problem has anything to do with ACD. Call the queue pilot number from an extension on the DX once answered hang up, then call the q again. If the same 35 sec wait applies the q settings are the prob ,if not it's the q931 settings.

apart from the wupt times I cant't think of any timers that apply. The ACD setting have nothing to do with clearing the call down. use the trex and trtk commands to trace what is going on when a agent answers a call.

good luck

 

[phones1]

Im the one who was silly enough to go to Afghanistan, Who is you services provider? do you recieve your lines from the exchange at the ministry of communication? As last time i was there we had a similar problems when we hocked up the mobile net

Remember if it doesn't work hit it harder

 

[phones1]

pbx1960 just read your previous post. when we brought in the mobile service we had problems with calls not releasing correctly, this was down to the satalite link in kabul, we were compressing voice calls to much (via the multiplexer) during busy periods,(does this fault occur more in busy times of the day)there were really bad error rates & delay on the link. to get around this we asked the sat ser provider to bump up bandwidth a little to allow for some forward error correction. check with them & ask it the link still has it

Remember if it doesn't work hit it harder

 

[pbx1960]

Hey Phones1,
Good to hear from a Vet of Kabul. As you may have seen, things have really heated up here lately, in many ways, we are more concerned with staying alive, than impeccable communications!
I conducted Darkstars' test, and indeed the test reveals that it is on the network side, my switch documentation states that it simply ignores some IEs from many Qsig variants, I also learned that this call center used to have an ISDX large, and this problem didn't exist!
I have managed, after many months to convince them to buy an Avaya S8700, just finished training on an S8300 in Dubai, and am quite impressed, hope it leads to good things.

 

[pbx1960]

Again, to Phones1,
I work for the folks with the MOC switch, and they have actually increased the compression ratio if you can believe it, we recently opened a new link through Karachi, it really helped our Internet speed, but they didn't dedicate any to Voice, I was using Skype to call home, and it worked brilliantly, lately however, when I call out, the distant end can not hear me, I suspect they are blocking us, just can't stand the idea that we are getting quality service and they aren't getting paid!

 

[phones1]

What kind of exchange have they now in the MOC. I put that large in & the version they had was a T for TRAFFIC & the software is designed for use on high compression sat links.If your skype dont work they are blocking your port & there are some tools available to encrypt your call & then change the ports you use? it should get around it!!! F***ers that will teach them, they'll never learn. As for Avaya what were you thinking, you have strayed to the dark side my son if you want to redeem yourself have a little look at the nortel succession range but this should only be done when a DX solution is a total no goer

Remember if it doesn't work hit it harder

 

[pbx1960]

Hey Phones1,
I am not sure what is at MOC now. Probably a Siemens. Our Skype is working again, so not sure what was up.
Actually, I am An Avaya Engineer, so I am more comfortable with that brand. That is the reason I keep coming here for help, no training whatsoever on ISDX, so every day is a challenge.
We may go with Nortel, hard to say. The thing is, we received a bid on a Nortel solution, it was almost 1/2 million British pounds, the big cheeses were none to happy with that, the Avaya solution is less than 200,000 US, plus, that is what we have at most of our other locations so they would link up well. Went to training in Dubai on the G700 and the S8300 and came away quite impressed, it is a sweet machine.

 

[phones1]

You should speak to some people in the know about nortel kit, a friend of mine just bought a 3000 extn option 81(2000 dgtl extns 1000 ana) for £38000 with a truck full of phones!!!

Remember if it doesn't work hit it harder

Scott UK