HELPPPP> Problems completing a second transfer..

[1ce]

Hi guys,

I am having an issue when trying to complete a second call transfer, I am recieving the following error when running a call trace on an extension trying to complete this transfer..

"denial event 1739: Div Reroute/Path Replace D1=0xa6 D2=0x6f"

Can anyone lend a hand?

 

[dimas]

Hi
What do you mean a second call transfer?
Which version of Definity you have ?
Which type of the phone?
Where you are going to transfer call ?(extension or outside line)

 

[1ce]

Some agents experience a problem when they attepmt to transfer the call. It happens when the call is transfered from Agent X to Agent Y. The Agent Y cannot complete the transfer. The calls are transfered internally only.
There is not a consistant point of failure - it happens randomly to agents that have one particular skill assigned. We tried to assign another skill but it still fails.
The system is G3siV11.
The type of phone 603A1.

 

[dimas]

Check the incoming and outgoing trunk parameter:
Disconnect Supervision In ? Out ? (on 1st page)
For test reason set both to "Yes".
If no effect - look at the COS:
for the agents with such problem Trk-to-Trk transfer override may be set to "Yes".

And finally may be first agent (X) sometime don't make Release but make Split or Conference?

 

[orypecos]

To me, when u say 'can't make the sencond transfer' makes me think that agent y is trying to tranfer to agent z after getting a tranfer from agent x. Is that what u are saying? And if so, what happens when they try to make the tranfer?
Are all the agents at the same site?
Many times tranfers have problems cuz the agent already has more than one call on their phone and the pbx doesn't know which call u want to transfer.
ARe u watching the agent trying to make the tranfer to see that they aren't doing wrong?


Da-vi'do

P.S. For the best response to a question, please read FAQ222-2244. Also give the type & version of your voice mail & pbx system & preview your post to make sure it is complete & understandable. Be aware that if u don't answer a question, I usually will not continue to help u. Please leave a post on how u fixed the problem too.

 

[ctr999]

I had that same problem on some NFAS ISDN-PRI tie trunks The first thing Dimas describes was exactly my problem. When I set Disconnect Supervision for Out to Yes (In was already Yes) everything worked fine.

 

[1ce]

Thanks guys, but it hasnt resolved the problem..

They are definately used the right call transfer process, they are all at the same site..

This problem is intermitant, so I am mainly looking for an explanation of the error code if anyone knows?

"denial event 1739: Div Reroute/Path Replace D1=0xa6 D2=0x6f"

Thanks

 

[ezncool]

Might it be possible that all call appearances are being used when they are trying to initiate the transfer? A transfer requires an available call appearance to be able to transfer. just a thought.

ezncool
I have no technical solution to your management problem

 

[1ce]

Agent A, recieves a call on appearance 1. They use appearance 2 to transfer the call to Agent B. Agent A explains to Agent B that they have a call they would like them to take, so Agent A completes the transfer to Agent B.

Agent B now has the transferred call on appearance 1, but when Agent B tries to transfer the call once again, for whatever reason, to Agent C.. The call will not transfer.

When running a trace, we recieve the mentioned denial event.

 

[dimas]

Agent A receives the call from who (station or trunk) and who was initiator of first call (Agent A or third party "C")?
How Agent A completes the transfer of such calls, which button press?
Is an attendant console take part in this example?

 

[SF0751]

How is the agent completing the transfer? Are they pressing the "Transfer" button a second time, or are they hanging up/using the "Drop Call" button?

Susan
"Few things are harder to put up with than the annoyance of a good example." - Mark Twain, Pudd'nhead Wilson (1894)

 

[1ce]

This problem is not end user error, there is also a witness system involved..

I have been on site and experienced the problem myself, I have a feeling that witness may be causing the problem, as the problem is intermitant and witness is only setup to record random calls..

(for those who do not know what witness is, it is a call recording program, which uses virtual extensions in the pabx to record physical extensions via service observe).

 

[SF0751]

If you suspect that the Witness system is a factor in this, then I would start testing - have an individual agent transfer a call when they are not being recorded, and when they are. Use the same parameters for both tests - same station, same transfer destination, etc.

Susan
"Few things are harder to put up with than the annoyance of a good example." - Mark Twain, Pudd'nhead Wilson (1894)

 

[orypecos]

What happens when they try to do the failing transfer? Does the light just flutter or does the call just get dropped?
Have u used the Russian free program to analyze the trace?

 

[1ce]

Russian prog?

 

[dimas]

I suggest you check system feature parameter - Pull Transfer (set "Yes") and
if possible try to down service observe function on "witness" for a time and make the tests again.

What as statistics of the unsuccess attempts of the transfer to success?
If witness influences on the second transfer, why it does not influence on the first transfer?
Sorry, I ask you again Agents A and agents B phone types the same or different?

But anyway your hypothesis is very close to the true, because from my experience if attendant is on conference call to somebody the user can not start transfer of his call untill attendant make release.
If attendant or someone else make service observe - agents can have a problem in that moment.