smahler

This is very wierd, and a little complex ...

I have calls that refuse to transfer from an 8434DX to various locations, but get another call and transfer it to the same location and it works ....

G3R with version 9.5 software ... this problem started when we upgraded from version 4 software...

Seems to be associated with calls coming in a ISDN-PRI trunk ( 8 DS1s, prime and backup D channel), most calls go DID, but some calls are to the main number (LDNs) which are answered by four attendant consoles. The consoles DO NOT have trouble transfering any calls.

If no attendant is available, we send these calls to other locations to be answered, via ...

1) console night service to VDN
2) VDN to Vector
3) Vector feeds an ACD split

so backup operators log into the split to recieve calls that would have gone to an attendant ...

When in "backup operator service" some times you will receive a call that you just can not transfer ANYWHERE. The only thing you can do on the call is talk and hang-up.

Using the trace command, we see this data ...

denial event 1763: cnf/xfr Intercept Anncmt D1=0x5d8f D2=0x1a52

Looking at disp events we see something like this ...

1763 Conf/Xfer Unstable Call and some other flags and time stamps


OK, so what is an unstable call? Why can a console transfer it but an 8434DX can not? Might this really be the problem? Where do I look to get info to work on and ISDN unstable call (does it need drugs?)

All theories welcome!
...STeve

__________________
S Mahler
Director, Information Networks
University of Louisiana at Lafayette

PBXBear

Sounds like it may be a COR to COR restriction. Check the COR of the incoming trunks, the COR of the station wanting to transfer and the COR of the station it's trying to be transfered to. Make sure that all the CORs have permissions to each other.

Check for Data Privacy and Data Restriction on the COS (note - COS, not COR) and on the stations (2nd page).

Any station that has Data Privacy or Data Restriction would not allow calls to be Transfered, Conferenced, or Bridged on-to it - as those settings are typically used for Data Mods, Modems...etc - where you want to ensure the integ. of the data connection and prevent any possible way of interruption.

Those are a few of the things I would check first.

Have fun.

-Chris

PBXtech.info

 

smahler

PBXBear:

Thanks for your reply. I must have not been totally clear. Please let me try again...

When you get a call that won't transfer, it won't transfer anywhere. Not even to a telephone that you know is on-hook and that you have transferred calls to for ten years. Then the next call that comes in you can transfer anywhere, including where the previous call did not transfer. (And you can see on the display that both calls are coming from the same trunk group (so the have the same COR arriving)).

This seems to happen only on ISDN-PRI calls, not on analog trunks or calls within the switch.

...STeve

__________________
S Mahler
Director, Information Networks
University of Louisiana at Lafayette

PBXBear

Did you try replacing out the 8434 with another kind of set temporarily and then try it?

ismith

sounds like when you get one of these un-transferrable calls the switch and the public network don't agree that the call has been established totally. if all of the timing and supervision settings aren't exact for all of your pri's, it's possible to have a talk path even though there isn't a call up (according to the switch). i know i've seen this happen before, where the provider didn't have their settings correct. maybe they have them right for all but one of your pri's....or maybe i'm way off here, something to look into with your provider though.