1. 14 Mar, 2018 1 commit
    • Denver Gingerich's avatar
      change "Show Monthly Usage" so JMP-side stats used · 5b1481b8
      Denver Gingerich authored
      Previously the "Show Monthly Usage" command showed the stats that
      Catapult recorded, which could sometimes over-represent one's usage
      (see 5e609a45, 0e664811, and 76d31968 for the original implementation).
      Now we instead show the stats that are recorded by jmp-fwdcalls and
      sgx-catapult, which were added in 09f98c8f and
      , respectively.  These stats are saved as integer values of the
      usage_minutes- and usage_messages-[TAI_date]-[JMP_number] keys.
      Although this does complete the implementation for jmp-fwdcalls, the
      code added here does rely on the new usage_start_day-[JMP_number] keys
      and the values are not yet generated by jmp-register (nor have they
      been manually populated in production databases where numbers have
      already been added without their respective usage_start_day-* values).
      Until that is done, one will receive "Unable to get usage statistics"
      when running the "Show Monthly Usage" command, which is the standard
      message if jmp-fwdcalls cannot determine a JMP number's start date.
  2. 13 Feb, 2018 1 commit
    • Denver Gingerich's avatar
      record total call minutes for each num in TAI days · 09f98c8f
      Denver Gingerich authored
      Though it works, the implementation is awkward in a couple ways:
      (a) we need to make another request to the calls endpoint (since the
      callback's JSON does not include the chargeableDuration parameter) and
      (b) we check the minutes for both legs of the call, even though it is
      probably possible to detect which leg we care about and only do the
      work for that leg (saves a database call and a shell call to "./tai").
      The code as-written seems to be pretty solid, though, so we'll see how
      it goes in practice before going back to make the above optimizations.
  3. 12 Feb, 2018 1 commit
  4. 24 Jan, 2018 2 commits
  5. 11 Dec, 2017 1 commit
    • Denver Gingerich's avatar
      limit voicemail length with recording max & hangup · b65a5462
      Denver Gingerich authored
      Before this commit, a caller leaving a voicemail would be able to stay
      on the line for over 24 hours (this was seen at least twice in
      practice), while only the first 60 minutes of the voicemail would
      actually be recorded and transcribed for delivery to the recipient.
      With this change the caller has a maximum of 10.5 minutes after the
      recording starts to leave their voicemail.  After that, both (a) the
      recording stops and (b) the call is hung up.  We chose 10.5 minutes
      because that means our limit is at least 10 minutes, but also means
      the call isn't longer than it has to be (most outgoing messages are
      less than 30 seconds so our billed call time will generally be 11
      minutes or less).
      This is achieved in two ways: (1) by setting a recordingMaxDuration on
      the recording when the recording is started and (2) by adding new code
      to automatically hangup the call once the recording is finished (which
      we know will be a reasonable time now since we set a maximum recording
      duration).  The latter required a bit of re-working parameter lists in
      the method we changed so that we could access the needed variables.
      The changes being made here are effectively fixes to 2208f6d6, which
      first introduced voicemail into jmp-fwdcalls (but did not set any
      limits on the length of voicemail calls or the voicemail recordings
  6. 11 Oct, 2017 1 commit
    • Denver Gingerich's avatar
      handle empty eventType's so likely no more crashes · 13c7bbec
      Denver Gingerich authored
      While 51457d68 did resolve certain types of crashes, it didn't resolve
      yet another type of crash we later saw, which occurs, for example,
      when someone tries to access jmp-fwdcalls' callback URL from a web
      browser (causing no GET or POST parameters to be sent, thus leading to
      no eventType parameter).
      This will hopefully be the last of this type of change (the other
      being 4c1314b6 ), though we can't know for sure that someone won't send
      as an eventType value that we can't handle.  It's not yet easy to make
      a fallback for such situations, since sgx-catapult is intended to work
      without knowing what the eventType value is prior to processing events
      as it handles both "mms" and "sms" events and does other work before
      checking which of those the event happens to be.  This worked fine
      when sgx-catapult was its own standalone component that handled only
      messaging events, but now that it is a component called by
      jmp-fwdcalls, which is intended to have both the messaging and voice
      events pointed at it, sgx-catapult is effectively acting as a backstop
      for all the events jmp-fwdcalls doesn't handle (it ostensibly handles
      all the voice-related events, but as we've seen from the other commits
      for handling "dtmf" and "error" eventType values, it sometimes fails
      at that).
      In any case, we've already confirmed with Bandwidth that they don't
      expect to send us any additional undocumented eventType values, and we
      do handle all the documented eventType values that we are likely to
      ever receive based on our use case, so we should be ok now.  But we do
      still plan to add some logic to sgx-catapult that at least prints the
      parameters when we run into an exception, so we can handle any further
      problems that might arise.
  7. 01 Sep, 2017 1 commit
    • Denver Gingerich's avatar
      add "error" handler so such events don't crash us · 51457d68
      Denver Gingerich authored
      This is a derivation of 4c1314b6, which was the same change, but for
      DTMF events.  We hadn't seen a message with eventType of "error"
      before, but now know that they can appear in response to certain types
      of failed calls.
      As in 4c1314b6, before this change jmp-fwdcalls would crash with this:
      "Shutting down gateway due to exception 013: no implicit conversion of
        nil into String"
      Note that the "error" messages we've seen so far contain very little
      detail, so the only parameter printed out is the callState parameter.
      In the long-term we may want to make our global handler a bit more
      tolerant of such errors (especially ones that are difficult to
      diagnose, as in this case where the error did not appear until an hour
      after the call failure occurred).  But since we haven't seen many such
      instances (and we're handling all the known documented cases), we will
      save that for later.
  8. 25 Aug, 2017 1 commit
    • Denver Gingerich's avatar
      fix cases of outgoing calls going to JMP voicemail · 4360de14
      Denver Gingerich authored
      The voicemail implementation was a bit too aggressive in which calls
      it chose to process, causing a couple of situations where calls placed
      by a JMP user would actually be directed to the JMP user's own
      voicemail, which is both confusing for the user, and in the first case
      caused the user to be unable to place calls if they had set a low
      number of rings to voicemail ("catapult_fwd_timeout-<JID>" setting).
      The first case involved the timeout mechanism of the voicemail logic
      (added in ca4fdb06 and 1f365b95), which didn't differentiate between
      calls to the user's JMP number and outgoing SIP calls, effectively
      making the latter receive timeout events that then directed them to
      voicemail.  So instead of doing this blindly all the time, we add an
      additional check to see if the caller is a SIP address (which is the
      way we differentiate outgoing calls in general, per 677c3765) and if
      so, then do not set a timeout nor go to voicemail.
      The second case involved the hangup logic, which was intended to
      direct incoming calls to the JMP number to voicemail if the JMP user's
      forwarding number was busy (added in 6d30b529).  However, this also
      caused all outgoing calls that received a busy signal to go to the JMP
      user's voicemail as well.  So we add some slightly more complicated
      logic to check if the recipient is the user's JMP number, and then let
      the usual busy signal handling take over if so.  Otherwise, it goes to
      voicemail as it always did.
  9. 04 Aug, 2017 1 commit
  10. 02 Aug, 2017 1 commit
  11. 31 Jul, 2017 1 commit
    • Denver Gingerich's avatar
      handle voicemail from anonymous (& similar) caller · e2032c87
      Denver Gingerich authored
      Previously jmp-fwdcalls would not validate the caller ID at all before
      putting it in a JID to send to Cheogram upon voicemail receipt.  Since
      that JID was thus not valid when the caller ID wasn't an E.164 number
      (as in the cases where the caller ID is "anonymous" or similar),
      Cheogram would reply with an error (which caused an error loop until
      sgx-catapult@95187ddc fixed that) and
      the voicemail was then never delivered to the user.
      Now we do some rudimentary checks to see if the caller ID is an E.164
      number and if not then we replace it with a different identifier,
      which uses the new "anonymous.phone-context.soprani.ca" phone-context.
      For now the number within that phone-context maps to a few different
      possible values that normally mean "anonymous", with a separate number
      to represent other caller IDs we might see (which are not necessarily
      anonymous).  Regardless of the non-E.164 value, we include that caller
      ID in the message sent to the user, so they know which caller ID was
      used, whether it's in our mapping or not.
  12. 27 Jun, 2017 1 commit
  13. 21 Jun, 2017 3 commits
  14. 20 Jun, 2017 1 commit
    • Denver Gingerich's avatar
      fix TTS broken by Catapult change; code fine again · 2551e9f8
      Denver Gingerich authored
      Catapult recently changed their text-to-speech engine (for details see
      expanded-voices/ ), which caused our code to be read out incorrectly.
      In particular, the new voice said "semicolon" for most instances of a
      semicolon (which we use to create pauses between characters), whereas
      previously those were consistently intepreted as pauses.  Furthermore,
      the default voice ("Susan") also does not say 'd' correctly - it is
      read as "dye" instead of "dee".
      To fix these, we first added a space after each semicolon, which did
      indeed cause the voice to always interpret the semicolon as a pause
      rather than "semicolon".  Then we switched to using a different voice
      ("Julie"), since we found that this voice pronounced 'd' correctly (as
      "dee").  We could have converted 'd's to "dee"s, but this seemed like
      a cleaner solution.
  15. 17 Jun, 2017 3 commits
  16. 13 Jun, 2017 1 commit
  17. 07 Jun, 2017 2 commits
    • Denver Gingerich's avatar
      merge "Ignore blank voicemail" - params just right · 9ad12232
      Denver Gingerich authored
      Works well in my testing, including not sending voicemail audio or
      text if caller hangs up immediately after beep, as well as sending
      both audio and text even with very short messages.  It seems that the
      five seconds or less parameter used in this commit is just right.
      See merge request !8 for the discussion and details behind the merge.
    • Denver Gingerich's avatar
      merge in "Timeout of 0 goes straight to voicemail" · b84ef53a
      Denver Gingerich authored
      This has the desired effect in my testing, though it does add more
      instances of #12 (namely that a fwdnum can exist, but we'll still hit
      that issue if the user has a catapult_fwd_timeout of zero).  All the
      more reason to deal with #12.
      See merge request !7 for the discussion and details behind the merge.
  18. 06 Jun, 2017 4 commits
  19. 05 Jun, 2017 1 commit
  20. 02 Jun, 2017 3 commits
  21. 27 May, 2017 6 commits
    • Denver Gingerich's avatar
      "Whitelist success hangup causes" fixes non-errors · 0f593996
      Denver Gingerich authored
      There are a number of reasons for hangups, which generally aren't
      truly errors.  And in any case, we want errors in reaching the
      forwarding number to be handled by transferring to voicemail.  So we
      whitelist the hangup causes instead.
      This fix was prompted by our improper handling of a particular type of
      call response that VoIP.ms sometimes uses: NORMAL_TEMPORARY_FAILURE.
      Such a response isn't really correct, but we need to handle it anyway.
      See merge request !3 for the discussion and details behind the merge.
    • Denver Gingerich's avatar
      merge in "Do not exception when hangup during OGM" · 1cfd2b7e
      Denver Gingerich authored
      I'm not totally convinced that this is a complete solution to #8, but
      I think it's good enough to merge now.  We can re-open later if we
      find it silences too many/few exceptions.  In any case, it does what
      it says on the tin in my testing.
      See merge request !4 for the discussion and details behind the merge.
    • Denver Gingerich's avatar
      merge in "Cleanup and fix ad-hoc commands" for #7 · 7d1571cf
      Denver Gingerich authored
      This works very well in testing, thanks to the previous changes in
      sgx-catapult!15 .
      See merge request !5 for the discussion and details behind the merge.
    • Stephen Paul Weber's avatar
      Cleanup and fix ad-hoc commands · 6ad0f3fa
      Stephen Paul Weber authored
      Primarily, inject the handlers in front so they run properly.
      But also, hide commands the user cannot use (like, all of them if
      unregistered and the OGM record command if there's no fwd set).
      Closes #7
    • Stephen Paul Weber's avatar
      Do not exception when hangup during OGM · 6ecc3e6b
      Stephen Paul Weber authored
      Catapult returns a 403 error when trying to modify a call that the user
      has hung up.
      Closes #8
    • Stephen Paul Weber's avatar
      Whitelist success hangup causes · 1799797b
      Stephen Paul Weber authored
      Most hangup causes are some kind of error, and should result in
  22. 24 May, 2017 3 commits
    • Denver Gingerich's avatar
      add DTMF handler so a DTMF event doesn't crash us · 4c1314b6
      Denver Gingerich authored
      Previously if a caller sent us a DTMF message (pressed a key on their
      phone) while the outgoing voicemail message was being played or while
      leaving a voicemail, jmp-fwdcalls would crash with this:
      "Shutting down gateway due to exception 013: no implicit conversion of
        nil into String"
      This is because we didn't have a DTMF handler as we weren't expecting
      to receive DTMF events.  But Catapult can send them out of the blue so
      we need to handle them.
      In the future we should have a better/some default request handler,
      but for now this DTMF handler should catch the majority of wayward
      requests that could bring down jmp-fwdcalls.
      This fix is related to !2.
    • Denver Gingerich's avatar
      preface transcriptions since subject not universal · 6f04a3bf
      Denver Gingerich authored
      Many XMPP clients (including Conversations) do not display the subject
      value provided in an XMPP message.  As a result, a transcription would
      look exactly the same as a text message to users of such clients.  So
      we need to preface the transcription text with a title until there is
      better client support for the subject parameter.
      This fix is related to !2.
    • Denver Gingerich's avatar
      use generic text instead of JID's localpart in OGM · 31b89996
      Denver Gingerich authored
      It is possible that a user does not want people calling their JMP
      number to know what the localpart of their JID is.  So instead of
      saying it when callers attempt to leave a message, we instead say
      something more generic.
      Users are free to set their own outgoing voicemail message so if they
      want people to know the localpart of their JID they can provide it in
      that message.  But we no longer tell it to callers by default.
      This fix is related to !2.