Warm (supervised) transfer to Attendant fails 1

[MrDV]

I had a number of agents (via Avaya one-X Agent version 2.5.60315.0) reporting the problem, that they couldn't transfer calls to the attendants. The problem also appears when physically doing the same on the IP Phone. It's exactly how it is described on this Avaya support page: Link

Customer Scenario:
1. IP1 call IP2
2. IP2 selects second call-appr and dials attendant.
3. Attendant answers
4. IP2 presses transfer button and transfer is denied.

Instead try doing following:
1. IP1 calls IP2
2. IP2 selects second call-app and dials attendant.
3. Attendant answers
4. Then again go back to IP1
5. Then do transfer it will work.

Solution: Working as designed: If attendant is active on a call they you cannot transfer that call

* I am looking for documentation and/or an explanation why this is "Working as designed". Thanks for your help.

 

[kyle555]

I suppose it's this:

https://downloads.avaya.com/css/P8/documents/100171721

Chapter 20: Attendant Conference
Using the Attendant Conference feature, an attendant can set up a conference call for as many as
six conferees, including the attendant. In an active call involving a desk attendant or an Avaya oneX® attendant, only the attendant can initiate a conference call or transfer the call to another party.
Communication Manager blocks other parties from initiating a conference call or transferring the
call.

Kinda makes sense in a weird roundabout way. The attendant is supposed to receive and transfer calls. You're not supposed to transfer calls to the attendant. That's why you're getting the behavior you're seeing - when you try transferring an active call to the attendant your call is being setup by CM under the pretense that the attendant is to take/receive the call you already have active. When you instead place the first call on hold, you call the attendant yourself on a separate and unrelated call.

Whatever the reason for needing a flow like that, why not just use attendant vectoring and transfer the call to a VDN/vector as a middle man and then let that get the call back to the attendant?

 

[MrDV]

VDN with attendant vectoring is enabled. Could the restriction be present when attendant vectoring is set to "yes"? Eventually all calls within the vector go to the attd-group.

 

[kyle555]

well, you said it was "exactly" as described in the solution article

What if it was just regular vectoring with a route-to the attd extension?

 

[MrDV]

It also doesn't work with regular vectoring with a route-to attd extension. It appears CM recognizes it's always going to the attd-group, but I'm happy with this solution and understand why. Thanks for your help Kyle!

 

[joe2938]

do not put 1st caller on hold and then grab the 2nd appearance, just hit transfer dial the operator, announce call and then hit transfer again to complete