- Maintain state of all sessions:
- Authenticated Google session
- Attached clients by socketId
- Call ID
- Surface endpoint to link calls via Access Code, Call ID, Google ID
- Display all keypresses
- Display as chunks
- Display which node of the IVR the chunk came from
- If Account / PIN input, show validity of input
- Push or Pull?
- Using Call ID
- Listen for call status changes
- Poll for Risk Score
- Using Call ID
- Gather PRS Data
- With Fallover URI
- Communicate with OpenCNAM
- For now, should be handled / cached by PRS
- Determine Risk Reasons
- Hopefully for now.
- Maintain API Log
- Move this to server?
- Control Brutus
- Hook into Twilio's SIP Trunk
- Maintain state of all call data
- Call ID
- DTMF tones + metadata
- Call Status
- Calculate keypresses from DTMF tones and surface for Julius
- Send keypresses to Ingest with a Call ID
- Communicate Call Status to Julius for a given call ID
- Ask Julius about valid Access Codes
- Check validity of Account / PIN input
Exposing an endpoint in Julius to accept information about IVR transactions sounds like a good plan to me - especially since the Twilio IVR is already build using webhook endpoints. It'd be nice if Julius could also get keypress details with that POST, but polling Call Service for those data would work fine (especially since we're already polling for risk score).
I'm happy to meet in person tomorrow or early next week.