julius_refactor.md

Julius Refactor

Julius Requirements

1. Maintain state of all sessions:

• Authenticated Google session
• Attached clients by socketId
• Call ID

1. Surface endpoint to link calls via Access Code, Call ID, Google ID
2. 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

1. Listen for call status changes
2. Poll for Risk Score

• Using Call ID

1. Gather PRS Data

• With Fallover URI

1. Communicate with OpenCNAM

• For now, should be handled / cached by PRS

1. Determine Risk Reasons

• Hopefully for now.

1. Maintain API Log

• Move this to server?

1. Control Brutus

Asterisk / Call Service Requirements

1. Hook into Twilio's SIP Trunk
2. Maintain state of all call data

• Call ID
• DTMF tones + metadata
• Call Status

1. Calculate keypresses from DTMF tones and surface for Julius
2. Send keypresses to Ingest with a Call ID
3. Communicate Call Status to Julius for a given call ID
4. Ask Julius about valid Access Codes
5. Check validity of Account / PIN input

@randylaman Actually, the IVR will have to be aware / hold some of the state actually due to requirements of the front end that cannot be supported by back-end functionality currently available in the IVR.

The Front end needs to know which DTMF events occurred during different steps in the IVR for display, like showing "pin entered", "account entered" etc. This is functionality that the IVR system will not support and so asterisk will have to alert the Demo application when these occur.

I think you're going to run into a problem building the dial plan in Asterisk getting the DTMF durations -- that information will need to come from Intercept unless you are writing custom modules in Asterisk.

I think it might make sense to have Asterisk make a REST call to Julius on every transition (end of Account number and PIN, successful or not) and have Julius use that to trigger its poll of the Call Service to get the digits and metadata.

This discussion might be getting to the point we need to talk in person...

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.

Also, @rlayman, the answer to:

#5: In today's world we'd need a new end point (possibly already there in 1.4) in Call Service/Ingest that will allow Julius to poll the call and get the call information. The question becomes how does Julius know what call id to poll on? Possible answers:

should be

b. Use the access code for the alt_call_id field (which the UI already knows)

Since Asterisk will have to ask Julius if the access code is valid anyway, if it sends along a Call ID, we can link the sessions that way. (Which is essentially how the system works at the moment.)