Certain WTI Socket endpoints not working as documented

[avc1001497745966]

Hey gang, another question. There are a few endpoints where I'm trying to use them and I just keep getting the error: "<unspecified/></CSTAErrorCode>". I'm passing it

{
"device": "devicidofmystationgoeshere"
}

I do see it looks different in the generated swagger page, the payload looks like this:

{
"device": {
"typeOfNumber": "string",
"mediaClass": "string",
"connectionRate": "string",
"bitRate": "string",
"delayTolerance": 0,
"switchingSubDomainCCIEType": "string",
"switchingSubDomainInformationElements": "string"
},
"button": "string"
}

but that doesn't make sense as I don't even see a deviceid value in there.. I get the same thing for the GetHookswitchStatus endpoints..

Any ideas!! Thanks for any help!

Dave Morrison

Software Engineer.

[avc1001497745966]

Answering my own question: first-party station control needs RegisterTerminalRequest first

I asked why GetHookswitchStatus, SetHookswitchStatus, GetButtonInformation and the other station-control calls always failed for me, even though the WTI swagger shows them as normal operations. Every call came back as CSTA unspecified (HTTP 400 over REST) within ~13 ms, with nothing useful in telrestsvc.log.

The cause is that the device has to be registered with the application session before these calls work. I didn't see that in the WTI documentation, but I did see that in the older DMCC "Device and Media Control" guide. The SetHookswitchStatus docs also list "not registered yet" as a failure reason.

What works (AES 10.2):

1. Start your application session as usual.
2. Send RegisterTerminalRequest for the station:

{
"device": "1234567890:youraes:0.0.0.0:1",
"loginInfo": {
"forceLogin": false,
"sharedControl": true,
"password": "1234"
}
}

Success is RegisterTerminalResponse with code 1 and a signalingEncryption field.
3. The station-control calls now answer normally.

Notes:

- Shared control: sharedControl: true with forceLogin: false registers alongside the physical phone, and the user's one-X Agent stays logged in. forceLogin: true with sharedControl: false takes exclusive control and kicks one-X out.
- Extra fields: adding mediaMode and dependencyMode to a shared registration gave {"operation": "invalidParameterValue"}. Leaving both out fixed it.
- Spec gap: RegisterTerminalRequest is documented in the 10.1.3 REST spec but isn't in the 10.2 specs. My AES accepted it anyway.
- Socket support: RegisterTerminalRequest and UnregisterTerminalRequest also work as ordinary requests on the WebSocket, with the same responses. UnregisterTerminalResponse code 2000 is success.
- Lifetime: ending the application session drops the registration. A later unregister answers "already unregistered".

Hope that saves someone else the time.

Dave Morrison

Software Engineer