voltier

Anybody know what the maximum number of objects are in the new DTMF array? (v57)

Thanks admin. Anything more specific? There aren't many options. Where do you get the playback.wav file and how do you use it?

Hi, I was just looking at Vodia's site and it appears scheduled announcement is possible. That being said i cannot find how from the portal. Any idea how this can be done? e.g. We want to page that the store will be closing at 6pm etc. Is this something available from a specific firmware version onwards?

Ahh sorry root. is just the way I'm declaring my variable. Please see example below: "_id" : ObjectId("58a37b44f15415a52070"), "domain" : "example.com", "callid" : "6090-11e5-1142017214721-bn01", "from" : "\"61421790068\" <sip:XXXXXX@example.com", "to" : "<sip:XXXXXXXXXX@example.com>", "wuc" : "", "start" : ISODate("2017-02-14T21:47:22.222Z"), "connect" : ISODate("2017-02-14T21:47:22.223Z"), "end" : ISODate("2017-02-14T21:48:53.619Z"),

Looks like there is a new parameter called root.wuc. Im assuming this is Wake Up Call?

Thanks Admin, will update and report my findings (we are currently on Centos64 so that works well)

I have many of these types of records, and they all contain 'undefined'. Its definitely connecting to an ACD. Even on the PBX UI under call logs, its showing as an attendant call between two extension, but the fact is, it was actually an inbound ACD call. I dont quite know how to resolve this as it is incorrectly reporting ACD calls as Attendant. To be more precise, this is the behavior i have noticed: Scenario: Caller > Auto Attendant > Agent > Transfer >> Agent root.from = Caller Number root.to = DID (connected to ACD) No trunk legs The state array is not generating state for ACD. All i have is state for attendant. (where it would typically show 'attendant > ACD > XXX' I am currently on 5.5.4, do you know if this is potentially a bug for this version, or if upgrading to the latest version will resolve the issue?

I have a usual situation where caller reaches the Auto Attendant, Connects to Agent, Agent Transfers to another Agent. Typically under states, this would be represented as: Attendant > ACD > Attendant That being said, I have a number of records that show: Attendant > Attendant (which at a glance appears to be an internal call) - I dont understand why it is represented this way because clearly under the Trunglegs there is clearly records of an calling dialing the ACD first. I have pasted the CDR example below: { "_id" : ObjectId("5898fd2af15419f58ea30d82"), "domain" : "example.com", "callid" : "0_2827520363@10.0.0.46", "from" : "\"Hugh Boss\" <sip:519@example.com>", "to" : "\"John Smith\" <sip:504@example.com>", "start" : ISODate("2017-02-06T22:47:39.419Z"), "connect" : ISODate("2017-02-06T22:47:40.990Z"), "end" : ISODate("2017-02-06T22:48:24.533Z"), "trunklegs" : [ { "direction" : "I", "from" : "\"Hugh Boss\" <sip:519@example.com>", "to" : "\"John Smith\" <sip:504@example.com>", "remoteparty" : "\"XXXXXXXXXXX\" <sip:XXXXXXXXXXX@example.com>", "localparty" : "\"ACD Inbound\" <sip:YYYYYYYYYYY@example.com>", "trunk" : "6", "cost" : "", "start" : ISODate("2017-02-06T22:45:48.579Z"), "connect" : ISODate("2017-02-06T22:45:49.581Z"), "end" : ISODate("2017-02-06T22:48:24.498Z"), "ipadr" : "udp:0.0.0.0:5060", "quality" : "essionReport: CallTerm\r\nLocalMetrics:\r\nTimestamps:START=2017-02-06T22:45:49Z STOP=2017-02-06T22:48:24Z\r\nCallID:3c46-439-162017224535-img02-fme1-1-59.86.190.134\r\nFromID:\"XXXXXXXXXXX\"<sip:XXXXXXXXXXX@0.0.0.0;user=phone;noa=national>;tag=28528693-co6045-INS001\r\nToID:<sip:YYYYYYYYYYY@;user=phone>;tag=843c4cbd84\r\nSessionDesc:PT=8 PD=PCMA SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3\r\nLocalAddr:IP= PORT=41796 SSRC=0x43c20cdb\r\nRemoteAddr:IP=0.0.0.0 PORT=18626 SSRC=0x09965046\r\nx-UserAgent:Vodia-PBX/5.5.4\r\nx-SIPterm:SDC=OK SDR=AN\r\nPacketLoss:NLR=0.0 JDR=0.0\r\nBurstGapLoss:BLD=0.0 BD=0 GLD=0.0 GD=0 GMIN=16\r\nDelay:RTD=13 ESD=0 IAJ=2\r\nQualityEst:MOSLQ=4.1 MOSCQ=4.1\r\nPCM", "cmc" : "", "extension" : "", "extension-name" : "", "codec" : "A/8000", "mos" : "41" } ], "extensionlegs" : [ undefined, { "callid" : "3c46-439-162017224535-img02-fme1-1-59.86.190.134", "from" : "\"XXXXXXXXXXX\" <sip:XXXXXXXXXXX@example.com>", "to" : "\"ACD Inbound\" <sip:YYYYYYYYYYY@example.com>", "direction" : "O", "extension" : "519", "extension-name" : "Hugh Boss", "redirect" : "\"ACD Inbound\" <sip:YYYYYYYYYYY@example.com>", "idle" : 0, "start" : ISODate("2017-02-06T22:46:20.959Z"), "connect" : ISODate("2017-02-06T22:46:23.004Z"), "end" : ISODate("2017-02-06T22:47:43.330Z"), "ipadr" : "udp:10.0.0.46:5060", "quality" : "VQSessionReport: CallTerm\r\nLocalMetrics:\r\nTimestamps:START=2017-02-06T22:46:23Z STOP=2017-02-06T22:47:43Z\r\nCallID:0926a994@pbx\r\nFromID:\"ACD Inbound\" <sip:YYYYYYYYYYY@example.com>;tag=1728609211\r\nToID:\"Ext Conv [1] (XXXXXXXXXXX)\" <sip:XXXXXXXXXXX@example.com>;tag=995201706\r\nSessionDesc:PT=8 PD=PCMA SR=8000 FD=20 FO=0 FPP=1 PPS=50 PLC=3\r\nLocalAddr:IP= PORT=26368 SSRC=0x694e5c89\r\nRemoteAddr:IP=0.0.0.0 PORT=11900 SSRC=0x7664a04f\r\nx-UserAgent:Vodia-PBX/5.5.4\r\nx-SIPmetrics:SVA=RG SRD=51\r\nx-SIPterm:SDC=OK SDD=35 SDR=OR\r\nPacketLoss:NLR=0.0 JDR=0.0\r\nBurstGapLoss:BLD=0.0 BD=0 GLD=0.0 GD=0 GMIN=16\r\nDelay:RTD=24 ESD=0 IAJ=1\r\nQualityEst:MOSLQ=4.1 MOSCQ=4.1\r\n", "type" : "r", "cmc" : "", "codec" : "PCMA/8000" }, { "callid" : "0_2827520363@10.0.0.46", "from" : "\"Hugh Boss\" <sip:519@example.com>", "to" : "\"John Smith\" <sip:504@example.com>", "direction" : "I", "extension" : "519", "extension-name" : "Hugh Boss", "redirect" : "\"John Smith\" <sip:504@example.com>", "idle" : 121, "start" : ISODate("2017-02-06T22:47:39.419Z"), "connect" : ISODate("2017-02-06T22:47:40.992Z"), "end" : ISODate("2017-02-06T22:47:43.312Z"), "ipadr" : "tcp:0.0.0.0:12043", "quality" : "VQSessionReport: CallTerm\r\nLocalMetrics:\r\nTimestamps:START=2017-02-06T22:47:41Z STOP=2017-02-06T22:47:43Z\r\nCallID:0_2827520363@10.0.0.46\r\nFromID:\"Hugh Boss\" <sip:519@example.com:5060>;tag=2396606693\r\nToID:<sip:504@example.com:5060;user=phone>;tag=5d60bc39d1\r\nSessionDesc:PT=8 PD=PCMA SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3\r\nLocalAddr:IP= PORT=18424 SSRC=0x9c8fea84\r\nRemoteAddr:IP=0.0.0.0 PORT=11902 SSRC=0x72e95452\r\nx-UserAgent:Vodia-PBX/5.5.4\r\nx-SIPterm:SDC=OK SDD=18 SDR=OR\r\n", "type" : "d", "cmc" : "", "codec" : "PCMA/8000" }, { "callid" : "0_2827520363@10.0.0.46", "from" : "\"Hugh Boss\" <sip:519@example.com>", "to" : "\"John Smith\" <sip:504@example.com>", "direction" : "O", "extension" : "504", "extension-name" : "John Smith", "redirect" : "\"John Smith\" <sip:504@example.com>", "idle" : 217, "start" : ISODate("2017-02-06T22:47:39.421Z"), "connect" : ISODate("2017-02-06T22:47:40.990Z"), "end" : ISODate("2017-02-06T22:48:24.517Z"), "ipadr" : "udp:10.0.0.28:5060", "quality" : "essionReport: CallTerm\r\nLocalMetrics:\r\nTimestamps:START=2017-02-06T22:47:43Z STOP=2017-02-06T22:48:24Z\r\nCallID:48fef2b8@pbx\r\nFromID:\"John Smith\" <sip:504@example.com>;tag=4285727097\r\nToID:\"Hugh Boss\" <sip:519@example.com>;tag=1469755171\r\nSessionDesc:PT=8 PD=PCMA SR=8000 FD=20 FO=160 FPP=1 PPS=50 PLC=3\r\nLocalAddr:IP= PORT=36148 SSRC=0x3f89d61a\r\nRemoteAddr:IP=0.0.0.0 PORT=11964 SSRC=0x5e240c56\r\nx-UserAgent:Vodia-PBX/5.5.4\r\nx-SIPmetrics:SVA=RG SRD=61\r\nx-SIPterm:SDC=OK SDD=18 SDR=OR\r\nPacketLoss:NLR=0.0 JDR=0.0\r\nBurstGapLoss:BLD=0.0 BD=0 GLD=0.0 GD=0 GMIN=16\r\nDelay:RTD=25 ESD=0 IAJ=0\r\nQualityEst:MOSLQ=4.1 MOSCQ=4.1\r\nPCM", "type" : "r", "cmc" : "", "codec" : "A/8000" } ], "states" : [ { "type" : "attendant", "from" : "\"Hugh Boss\" <sip:519@example.com>", "to" : "\"John Smith\" <sip:504@example.com>", "language" : "", "start" : ISODate("2017-02-06T22:47:43.315Z"), "durationivr" : 0, "durationring" : 1568, "durationtalk" : 2325, "durationhold" : 0, "durationidle" : 221507, "reason" : "", "account" : "", "extension" : "504", "extension-name" : "John Smith" }, { "type" : "attendant", "from" : "\"Hugh Boss\" <sip:519@example.com>", "to" : "\"John Smith\" <sip:504@example.com>", "language" : "", "start" : ISODate("2017-02-06T22:48:24.533Z"), "durationivr" : 0, "durationring" : 1568, "durationtalk" : 43543, "durationhold" : 0, "durationidle" : 1584, "reason" : "", "account" : "", "extension" : "504", "extension-name" : "John Smith" } ]

Hi Admin, Based on the CDR, what would the best logic be to determine what is internal and what isn't? Would you go by trunk legs/extension legs? etc

Hi, We are currently trying to determine what API to call in order to get a Call State. Right now we are are able to get a 'connected' and 'alerting' state however there is no information coming through the API which indicates a call is 'holding'. Currently getting information using GET /rest/user/101%40ncoc.mycompany.us/wallboard HTTP/1.1 - to get a number of data about the call We can get some of this information through a websocket session, that being said, we cannot solve the following scenario purely via websocket: (hence why we are using a combination of REST and Websocket) We have 3 callers calling to ACD 123: Caller 1 Connected - ACD 123 Caller 2 Connected - ACD 123 Caller 3 Connected - ACD 123 Given that an Agent can only have 1 Connected state against a Caller i.e. Agent can only speak to one person at at time, it means the other 2 Calls would be in a Holding State - which we cannot find a reliable method to establish. Any thoughts?

Is this still available? (I remember this use to be available and registered to 1 domain and a few extensions). Reason is I want to spin up another test environment using later firmware.

Just wanting to know if there is anyway to have the queue announce message in a loop/interval, as right now the announcement is only made once at the start. If a user has been waiting for some time on the phone, the function becomes moot as they do not know how far they have progressed.

Just wondering if anybody out there has working code for Web Sockets that they could share. We have looked at Vodia's latest php sample, along with some samples found in the forum e.g. (http://forum.vodia.com/index.php/topic/14660-rest-api-calls-from-javascript/?hl=websocket&do=findComment&comment=42175) however they do not appear to work. We are currently sitting on 5.5.4 of the pbx. Edit: I am expecting to get this: {"action":"call-state","calls":[{"id":85895,"from":"\"AUTO PARTS\" But, instead, I am getting the following: {"action":"user-state","type":"","account":"","domain":"","chatstatus":"online"} {"action":"user-state","type":"attendants"," Which is not consistent with the REST API documentation.

As always, I appreciate the prompt responses!

It appears that you can only set audio announcements in a static sequence. Just wondering if there was a way to randomise this as, statistically, callers are more likely to listen to the first few recordings as opposed to the last few, unless there is a way to randomise the sequence

Just wanting to know if its possible to have custom CDR format templates on a domain level

Hi, Just reporting on my experiences with csv bulk upload on PBX firmware 5.3.2 for a dozen or so Extensions with Yealink Phones. My column values are: type,alias,first_name,display_name,mac Issue 1: MAC address information does not get sent to the Yealink Remote Provisioning Server Other observations: Delete mac address > save > reupload mac address save. After about 30 minutes or so, i can see the MAC address on the Yealink RPS. That phone is able to load the settings from the PBX and load the appropriate configs however on reboot, the phone does not register to the pbx. Solution: Manually create the extension. Everything works from RPS to retrieving configurations to registration on the PBX. Not entirely sure if this is pbx related, RPS related, or both.

I have two Snom Meeting Points, one has been running fine using 8.7.3.25.9 however had another MP on the same 8.7.3.25.9 firmware which refused to be auto provisioned. I had forced an older firmware 8.4.35 and the provisioning processed picked it up. Not sure if its related to the PBX (some bug/glitch), or maybe the snom device itself? Not sure if anybody else has any similar sort of experiences with the meeting point. (Currently on 5.3.2)

Sorry to resume an old topic but i can see ANI information with the SIP packets when making calls, however what i really wanted to get was the DID information for outbound calls (not sure if this is possible) I know its counter intuitive to try and resolve DID information for outbound calls - but the rationale here is to make a DID accountable for all outbound calls i.e. the DID becomes the billing entity

Hi, Call Forwarding ALL does not appear to work when calls are received via Hunt Groups or ACDs. The Use Case has come to us from a number of our clients requesting for this, but im not quite sure if there is a way of achieving this outcome or if there are workarounds to make this possible.

Hi again, once again many thanks for your help. Hopefully the last question regarding CDRs, but just wanting to know what parameter is used to differentiate a call when it hits an Operator Message. What i mean by that is, there will be certain scenarios where for example, a cell phone is switched off or out of range and will hit the providers automated response system i.e. there is no charge to the user. As far as the PBX and CDRs are concerned, it will treat this as a connected call. My suspicion is there is some agreed Carrier Response codes which is shared, but what I'm really wanting to know if that is embedded somewhere within a CDR record.

Thanks Admin, that page was definitely useful. I just want to run by you my assumptions (from a billing perspective): I intend on using a combination of {Domain} + {Extension} to uniquely identify and bill my end user; Primary focus will be: where trunk legs is greater than 0 (all else doesn't matter) - Not quite sure if its possible to have more than 1 outbound Trunk Leg per CDR? Trunk Leg > Connect value is not 0 (or 1970 etc) Trunk Connect Time = billable call duration Trunk Leg > Direction = Outbound Any advice or suggestions otherwise to the above is most appreciated!

Hi, I was hoping to get some light on how to read actual CDRs. So from an old manual I found, CDR broken into 3 types: IVR Information Extension Information Trunk Information ...which im assuming translates to: Root (IVR) Information Extension Leg (s) Trunk Leg (s) Follow up questions: When are additional legs populated? In some instances I see one leg, some two, some three... Extcall - im assuming this is either extension or external call? If the connect field is blank does that mean the call was not established (what if the call hit the recipients voice message service - would it show a connect time?) How is From and To, different to, Local and Remote? (i have found that From is not necessarily Local, and To not exactly Remote) What does the State Leg(s) meant to portray/depict? Would it be safe to assume that, in the context of billing, you only care about Trunk Legs? Other feedback/assumptions: There is no consistency between call type, direction and im getting really confused when trying to understand the CDRs. When looking at CSV files, im assuming one CDR may be spread out over multiple rows to illustrate the various legs Been going crazy looking at the CDRs so hopefully somebody can share some light Thanks!

Just wanting to know if its possible to retrieve DID/ANI information from Extensions when retrieving CDR information. I could not find anything about it in the documentation. I suppose the {Domain Information} + {Extension} would be sufficient to be a unique identifier but it would be easier to use something like the DID.

Really appreciate your help Snomonepbx! In addition to your invaluable response, i did not know the vodia had a documentation section on its site. (i did not know about webcdr and mongodb and others - which is great!) Thanks again