Jump to content

voltier

Members
  • Posts

    57
  • Joined

  • Last visited

Posts 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. 2 hours ago, Vodia PBX said:

    Is this "DNS SRV"?

    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

  7. 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)

  8. 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.
  9. 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?

  10. 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?

  11. 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.

×
×
  • Create New...