Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by voltier

  1. Thanks @Vodia PBX - Yes the version is currently on v66 and we are trying to establish if upgrading to v67 will resolve our issues. I understand the differences between missed type 1 (which we internalize as Abandoned), and missed type 2 (which we internalize as missed). Please correct me if im wrong, but in context of users sitting inside an ACD, for type 1, the CDR should show 'reason: hw The Call was disconnected while the user while waiting in the ACD', and type 2, the CDR should show 'reason: hr' The Call was disconnected while the user was ringing in the ACD. In my example above, the call traversed through an Auto Attendant (State 0), and an ACD (State 1), which either had agents or did not have agents in queue. The CDR should have shown reason:hr or reason:hw, but showed neither. It produced reason:missed (which by your documentation, relates to a missed call from an Auto Attendant. And finally, my example shows 'type = acd', and 'reason = missed' - these two variables, should not be possible in the same JSON message. I hope this clarifies my question.
  2. So just to clarify, are you saying the matter is resolved in v67? or this is just part of the new pattern established to handle missed calls and if so, how do we now define a missed call that occurs during an ACD for example. Again, i refer back to the documentation, the example that i am finding not matching is reason = hw or hr. Definition for hw is "The call was disconnected by the user while waiting in the ACD.", however in this scenario, our mongodb extracts are showing "reason: missed" "states": [{ "type": "acd", "from": "\"Calling Number\" <sip:number@domain>", "to": "\"Call\" <sip:number@domain>", "language": "uk", "start": { "$date": "2021-06-20T23:59:22.680Z" }, "durationivr": 11384, "durationring": 16422, "durationtalk": 0, "durationhold": 0, "durationidle": 0, "reason": "missed", "account": "300", "account-name": "Call", "extension": "", "extension-name": "" }] }
  3. Currently using version 66. Seeing MongoDB records where once a call has traversed into in ACD from Attendant but reason is still showing as 'missed', rather than 'hw' OR 'hr' depending if user was ringing ACD or waiting for ACD. The definition of 'missed' from the documentation is 'The call was missed in the auto attendant'. I have various samples showing 2 legs (states), first leg = attendant, second leg = acd, and reason = missed. This has become a problem after upgrading from version 63.
  4. So ive followed the steps from https://doc.vodia.com/docs/voicemailtranscription Ive enabled API Cloud Speech to Text API I've created an API key and inserted it into Settings in PBX I do some text calls and nothing transcribes with voicemail emails. I cannot see the API being called Google Console Thoughts? Running 66.0.5
  5. So other than being able to receive calls flowing from the PBX down to a Teams User, I have a list of questions after a call has been answered by Teams User: 1. Placing a Caller on Hold - is that part of Microsoft's On Hold System? or the PBXs? 2. How does transferring work? Can we transfer calls back to Internal PBX extensions/accounts? It seems like we are going through alot of effort for the basic ability of making/receiving a call (via Teams) after it lands on Teams.
  6. Hi Vodia, just to be clear I’m referring to Auto Attendants. I wouldn’t think DMTF is the issue here as User Inputs 1-9 function as intended. Not sure if # is classified as special characters or not
  7. As per title, the system isn’t doing anything with # and I’m suspecting it’s waiting for a command for something else perhaps. Anybody encounter this?
  8. voltier


    Yes thats correct. Mongo call it DNS seedlist connection string - for the purposes of quickly scaling out a cluster without needing to configure individual clients
  9. voltier


    Has anybody had any luck connecting to Mongodb's atlas service? I dont think the connection string from the admin console allows for SRV (which im suspecting is the issue)
  10. I can confirm 63.0.2 fixed the issue. Thank you for the support!
  11. Hi there, just checking in if there was any progress with this
  12. @Vodia PBX - is there any other information i can supply that may help?
  13. Hi there, Just a snippet. 200 is the ACD, 101-107 are the Agents of 200. When the call is connected to one of the Agents, say 102 - we get the following output below, which does not allow us to uniquely identify which Agent has entered the connected state. account":"200","start":"1522280.620","domain":"domain.com","rec":"none","cmc":"","priority":"1","trunk":["Outbound Trunk*"],"extension":["101","102","103","104","105","106","107"],"callstate":"","state":"connected"}]} Pre v60, it will output: (where Agent 102 connected the call) "account":"200","start":"1522220.620","domain":"domain.com","rec":"none","cmc":"","priority":"1","trunk":["Primary Inbound*"],"extension":["102"],"callstate":"","state":"connected"}]} So unless there is a setting on the ACD page which changes this behavior, im not sure what has happened.
  14. Hi, Pre-version 60, Websocket data relating to ACDs would allow us to identify which Agent has picked up the call (showing only the Agent that connected to the call) under Call-state. Since the update to version 60+, when an Agent is connected to the Caller, it simply shows ALL logged in Agents (which was not the behaviour previously). Given there have been a substancial number of changes and configuration parameters now available under ACDs, does anybody know if this is simply a bug, or is there a parameter in the ACD group which needs to be turned on/off?
  15. We have been caught out multiple times when there is a sudden change in the CDR file structure, where it breaks out data ingestion because there are new variables that need to be declared. Can Admins please ensure this information is made available in the Release Notes 'Please'.
  16. Hi there - we are wanting to provide an interface on our own portal which will allow the end customer to add/delete/manage the Address Book. Will there be any plans to have Address Book via your API?
  17. Hi Support - any update on this? (Pick up group) I still cant see any documentation and would really like to test this
  18. Hi Devs/Admin, With the release of 57.0, can you point us in the right direction in terms of how to use some of these features. I found Pickup Group under buttons but it isnt exactly intuitive to figure out how to use. Same thing with the Call Back function within ACD. Possibly if you can provide a sample tied to a scenario, that would be great.
  19. Anybody know how long is it before the session key times out or expires?
  20. The construct for DMTF elements is horrible IMHO. Is it possible to have the array represented in the same way as extensionlegs or trunklegs?
  21. @Ahennis - Referring to the WebUI @Admin - does this mean you will be reverting the behavior to what it was previously and the Polycom use case will be managed seperately?
  22. Ok, turns out that the 'resync the selected accounts' function does the job for me. I was making changes to the custom config files and wanted to apply some changes and couldnt figure out how to do it.
  23. any way around this? Most of our customers are either on Snom or Yealink handsets. Touchless provisioning is somewhat useless if we cant reboot the device remotely.
  24. Since upgrading to version 57 (from 56), it appears the ability to reboot phones via the console no longer works.
  • Create New...