Jump to content

FASTDEVICE

Members
  • Posts

    437
  • Joined

  • Days Won

    26

Posts posted by FASTDEVICE

  1. @tomas_ oddly enough, it didn't work on Josh's account using the user id. However, It did work on mine. Once we switched to using the group id, it worked perfectly for him. That's the right approach anyway for security reasons, but I'm uncertain why the behavior is different between reseller accounts. My only thought is he subscribes to Qubicle and I don't.  

  2. The feature code *72 updates the User JSON doc, therefore, you can adjust these settings in the User Portal. The exact setting is "Settings & Devices" | Enable Call Forward | Keep Caller ID. 

    For those that want to directly change the user doc:

    {
       "data": {
          "call_forward": {
               "substitute": false,
               "require_keypress": true,
               "keep_caller_id": true,
               "ignore_early_media": true,
               "failover": false,
               "enabled": true,
               "direct_calls_only": false,
               "number": "2125551212"
            }
        }
    }

  3. That's what we do (development), if you are interested. My opinion though, having looked hard at many solutions, is use the 2600hz click-to-dial resource. There are too many issues with phone IP addresses and action URLs. Besides, the click-to-dial resource is SIP phone agnostic. In other words, you can use Yealink, Polycom, etc. and achieve the same results without programming the phone. Makes for easier deployment.  PM me and we can discuss.   

  4. Mine uses a click-to-dial resource from 2600hz. When the decorated number is clicked, it automatically dials the user's SIP phone. Obviously, in this case, the user's phone is a SIP phone authenticated to 2600hz. I'm not sure I fully understand what you mean by actual phone vs SIP authentication. Maybe you are asking if my Chrome extension acts as a SIP phone? If so, no. The extension is only a decorator and utilizes the 2600hz click-to-dial resource.    

  5. Google Chrome uses JavaScript to develop browser extensions. The same code, when developed, can easily be used for MS Edge. We developed our own and placed it in the Google Chrome store for our client base. I'm not aware of other solutions apart from developing your own at this time. At some point, we intend to publish it as a monster app. 

  6. The Regex is straight from the documentation slightly modified with your example.

    Dial Plan using Device level.
    Regex: ^1?([2-9][0-9]{2}[2-9][0-9]{6})$
    Prefix: BARRED

    Dial any 10 digit number and you get an error trying to complete a call; as I would expect.  

    Do the same with pivot on the no_match and I never see the "BARRED2125551212" in the request or anywhere for that matter. 

    I'm concluding there must be a behavior difference when global carrier is evoked in the no_match.

     

  7. therefore, in the hosted service, I don't have access to the classifiers being located in the number_manager config?

    and,  It appears that dial plan has no effect when the global carrier is removed from no_match. I.e. if I place a pivot there and look at requestbin the request is always normalized. However, if I replace global carrier, I can use dial plan to create nonconforming numbers that fail. Does having global carrier in the no_match callflow enable dial plan?     

×
×
  • Create New...