I'm attempting to use CallControlCall.transfer("918315551234").

I see all or the activity I'd expect in the TSAPI trace but it finally fails with CSTA 70 (GENERIC_UNSPECIFIED_REJECTION).

The basic setup is One-X Agent with station registered and an active inbound call. Wanting to transfer that inbound caller out to a destination (either over PSTN or to internal VDN).

for (Connection connection : address.getConnections()) {

	for (TerminalConnection tc : connection.getTerminalConnections()) {

		if (tc instanceof CallControlTerminalConnection) {

			CallControlTerminalConnection cctc = (CallControlTerminalConnection) tc;

			if (cctc.getCallControlState() == CallControlTerminalConnection.TALKING) {

				CallControlCall ccCall = (CallControlCall) connection.getCall();

				ccCall.setTransferController(cctc);

				Connection newConn = ccCall.transfer(callee);

				break;

			}

		}

	}

}

1) can you successfully do the transfer to that same phone number from the phone 'manually' - using the phone's UI?
2) does the sat command 'display events' with a type of denial provide any clue as to the call failure reason - you may need to 'clear events' before running a test.
3) can you transfer to something simpler (like another on premises station)?

Yes, I verified that I can complete and transfer using the One-X UI.

I'm a remote contractor and getting access to telecom admins at the client site is a challenge.

Both your #2 #3 questions & suggestions were my next step. I'll pass them along to the client ans see if I get a response.

Thanks!

It is hard to keep up with all the endpoints and configuration permutations ... 4) is your one-X Agent is using H.323 protocol?
5) I assume the inbound call is answered on the one-X Agent, correct?
Transfers to VDNs are difficult to achieve.
6) Have you tried this call flow with the JTAPI Exerciser instead of your code?
7) Have you tried single step transfer in lieu of a multi step consultative or blind transfer?

4) I believe my One-X is behind a session manager using SIP. Will verify with Client.
5) Yes, I set up the inbound call from my location (over SIP->PSTN trunking)
6) The SDK I downloaded didn't have a JTAPI Exerciser - I'll look for that and try the transfer that way.
7) I am attempting single-step transfer (which is supported by Avaya JTAPI implementation and I do see queries and events suggesting that all the setup requisites are happening).

I'm working on getting a telecom admin on the line who should be able to run a trace on my registered station device and see what's happening from the CM's perspective.

4) check https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/device_authorization.gsp#110

Here is another clue - it may be that the client gave me bad info:

2019-10-30 15:16:19 DEBUG TsapiSession:759 - CSTAUniversalFailureConfEvent ::=

2019-10-30 15:16:19,842 [GetEventThread] DEBUG TsapiSession - {

2019-10-30 15:16:19 DEBUG TsapiSession:759 - {

2019-10-30 15:16:19,842 [GetEventThread] DEBUG TsapiSession -   error 12 < INVALID_CSTA_DEVICE_IDENTIFIER >

2019-10-30 15:16:19 DEBUG TsapiSession:759 -   [color=red]error 12 < INVALID_CSTA_DEVICE_IDENTIFIER >[/color]

2019-10-30 15:16:19,842 [GetEventThread] DEBUG TsapiSession - }

2019-10-30 15:16:19 DEBUG TsapiSession:759 - }

That is in response to the SST? yet you see originated, & delivered events!?? It would be more helpful to see a more complete trace of the request and responses. It says some identifier you are using for an extension/destination is known to be incorrect (not provisioned).