Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-9683

Pass call recovery status to Verto login callback


    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6, 1.9
    • Fix Version/s: 1.8
    • Component/s: verto, verto.js
    • Labels:
    • CPU Architecture:
    • Kernel:
    • Userland:
    • Distribution:
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
    • FreeSWITCH GIT Revision:
    • GIT Master Revision hash::
    • Target Version:


      The problem:

      Users wishing to a use Verto workflow where both user login and placing a new call are automated (eg., visiting a URL, and the videoconference loads automatically) face the challenge of not having a reliable way to know that a page load will result in Verto's call recovery mechanism reconnecting an existing detached call or not. This is problematic, as automatically placing a new call when another call is being recovered results in an unwanted duplicate call.

      Possible solutions:

      In both my own mucking around and discussions with core devs, four possible solutions have emerged to work around the problem:

      1. Use browser cookies to mark if a new call has already been placed: sloppy, difficult to manage the timeout of the cookie so it works well with the recovery mechanism.

      2. Set a timeout on page load for placing a new call, and don't place it if the call is recovered before the timeout fires: probably more reliable than option #1, but forces every user to wait longer for the call to connect, and opens possible race conditions on slow/crappy internet connections.

      3. Disable Verto's call recovery mechanism: certainly solves the problem on the client side, but could also lead to a lot of duplicate CDRs, as well as possibly slower connect times for users who reload their browser.

      4. When Verto.newCall() is called, check on the server side for a call in the attached/detached state, and don't start the new call if one is found: this eliminates the problems of #1 and #2, but feels sloppy -- it seems too late in the cycle, how do you log/report those dropped attempts, etc.

      5. When the "login" JSONRPC call is placed, check on the server side for a call in the attached/detached state, and include the recovery status as an attribute in the response: this seems like the best approach of the five -- it's late enough in the workflow to have access to attached/detached state on the server side, and early enough for the client to receive the recovery state in the onWSLogin() callback, allowing for logic that avoids placing any duplicate calls.

      I've drafted a patch for #5, PR coming shortly. Generated against latest master, and it applied cleanly and tested successfully on my 1.6.11 install. As far as I can tell it cleanly solves the problem with no side effects. Some outstanding questions from my first attempt:

      1. Should the recovery state also be passed in the login failure case? For now I put it in, but not sure if it would work properly, or even makes sense.

      2. Should the emitted login event also include the recovery state? Not sure, it only seems like useful information for the client, but maybe there's some other workflow where it could be useful? I've left that out, but it could easily be added if need be




            • Assignee:
              mikej Mike Jerris
              thehunmonkgroup Chad Phillips
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: