Skip to content

Instantly share code, notes, and snippets.

@taggartbg
Created April 28, 2016 18:58
Show Gist options
  • Save taggartbg/cb4865092541f5c6578a62d9ded23343 to your computer and use it in GitHub Desktop.
Save taggartbg/cb4865092541f5c6578a62d9ded23343 to your computer and use it in GitHub Desktop.

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
@taggartbg
Copy link
Author

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.

@taggartbg
Copy link
Author

taggartbg commented Apr 28, 2016

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment