voltier

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.

@Vodia PBX - any updates?

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": "" }] }

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.

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

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.

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

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?

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

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)

I can confirm 63.0.2 fixed the issue. Thank you for the support!

Hi there, just checking in if there was any progress with this

@Vodia PBX - is there any other information i can supply that may help?

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.

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?