~singpolyma/sgx-jmp

ref: d8cb419335c19fbb3cf487e3dfb2e00697c2d55b sgx-jmp/config.dhall.sample -rw-r--r-- 1.9 KiB
Merge branch 'no-more-catapult'

* no-more-catapult:
  Remove catapult import code
Remove catapult import code
Merge branch 'whitelist'

* whitelist:
  Allow whitelisting domains
  Use FormTemplate for activation form
Allow whitelisting domains

Some domains credit new users to the admin, some to no one.  We still have to
show a form to get them to pick a plan, but otherwise skip most of the process,
activate them with 1 month and go to Finish.
Merge branch 'reset-sip-v2'

* reset-sip-v2:
  After SIP reset, offer to change inbound fwd
  Reset sip account using v2 API
Reset sip account using v2 API

SipAccount now uses only v2 APIs for lookup, create, update, and delete
Record Voicemail Greeting command
Merge branch 'sip-outbound'

* sip-outbound:
  Support transcription disablement option
  Port in inbound calls + voicemail
  Allow fetching fwd timeout as well
  Get OGM for a customer
  Helper to fetch customer's vcard-temp
  Make Disposition more real
  Allow constructing CDR for an inbound or outbound event
  Outbound calls from v2 SIP endpoint work and save a CDR
Port in inbound calls + voicemail

The craziest part of this is the workaround for a serious bug in Bandwidth's
HTTP voice API (which they may yet fix, still negotiating with them about that).

When a call comes in, every 10 seconds that it is not "answered" the inbound
call gets cancelled by their upstream peer and then get retried.  The caller
sees only one oubound call for this, so it doesn't look odd to them, but to us
it looks like they keep hanging up and trying again every 10 seconds.  So what
we do for now is we wait 2 seconds after they disconnect before we decide
they're really gone.  If they call back in those 2 seconds we just connect the
eventual bridge or voicemail to this new call and everything works out.

Ew.
Customer Info

This should allow us, the admins, to query information about a customer
without having to dive in and run a couple redis queries and some
database queries before getting the full picture of who we're talking
to.

It also allows the users to request some data about themselves. Balance and
phone number are already visible in other places, but their expiry is currently
not, and people have been asking about it.
Check config against schema when loading

So we know very quickly why it's not working.
Merge branch 'low-balance-auto-top-up'

* low-balance-auto-top-up:
  Some people have exactly 5 who don't need to be told
  On low balance, top-up or notify
  ExpiringLock helper
On low balance, top-up or notify

On start up, check for users with low balance and NOTIFY about them.  LISTEN for
such notifications and process by either sending a low-balance warning message
or else attempting an auto-top-up as configured.

Using NOTIFY/LISTEN because then we can NOTIFY after any INSERT that leaves the
balance too low (using a trigger).  Doing the sync on start-up in case we missed
a NOTIFY during any downtime.  Using the Redis lock to prevent spamming a
low-balance user in case of many restarts or if they have many small
transactions happen in one day.
Ask electrum to notify on new BTC addresses

Otherwise we won't know when someone has paid...
Set location (API calls it "SipPeer") on new TN orders
Notify admin if a user goes over 500 messages in 30 days

Notify only once per day (using expiring redis key).
Can notify MUC or user, always sends directed presence first so it will join MUC
if not joined.
Ignore all messages direct to the component, mostly to throw out live messages
from MUC if we join that to notify.
Alt top up command

To show mailing address, eTransfer address, Bitcoin addresses, and allow
generating a new Bitcoin address.
Add plans and electrum structure to example
Reply to extdisco with sip server
Next