Ucm6xxx CDR Rec Api Guide
Ucm6xxx CDR Rec Api Guide
UCM6xxx Series
CDR and REC API Guide
Table of Contents
Page | 2
UCM6XXX CDR and REC API Guide
Table of Figures
Table of Tables
Page | 3
UCM6XXX CDR and REC API Guide
CDR REPORT
CDR (Call Detail Record) is a data record generated by the PBX that contains attributes specific to a single
instance of phone call handled by the PBX. It has several data fields to provide detailed description for the call,
such as phone number of the calling party, phone number of the receiving party, start time, call duration…
CDR Filter
On the UCM6XXX, the CDR can be accessed under web GUI→CDR→CDR. Users could filter the call report
by specifying the date range and criteria, depending on how the users would like to include the logs to the report.
Click on button to display the filter criteria, a second click will start the search.
Page | 4
UCM6XXX CDR and REC API Guide
• 3XXX: It will filter out CDR that having caller number with leading digit 3 and
of 4 digits’ length.
• 3.: It will filter out CDR that having caller number with leading digit 3 and of
any length.
Enter the caller name to filter the CDR report. CDR with the matching caller name will
Caller Name
be filtered out.
Enter the callee number to filter the CDR report. CDR with the matching callee number
Callee Number
will be filtered out.
Select the account Code to filter with. If pin group CDR is enabled, the call with pin
Account Code
group information will be displayed as part of the CDR under Account Code Field.
Source Trunk Select source trunk(s) and the CDR of calls going through inbound the trunk(s) will be
Name filtered out.
Destination Trunk Select destination trunk(s) and the CDR of calls going outbound through the trunk(s)
Name will be filtered out.
Filter calls using the Action Type, the following actions are available:
• Dial
• Announcements
• Callback
• Call Forward
• Conference
• Disa
• Fax
• Follow Me
Action Type • IVR
• Page
• Parked Call
• Queue
• Ring Group
• Transfer
• VFax
• VM
• VMG
• Wakeup
Page | 5
UCM6XXX CDR and REC API Guide
Users can select the data they want to see in the exported CDR reports by choosing
the desired information in the Export File Data field. Users can select one or more of
the following data fields:
• ACCOUNT CODE
• SESSION
• ACTION OWNER
• ACTION TYPE
• SOURCE TRUNK NAME
• DEST TRUNK NAME
• CALLER NUMBER
• CALLER ID
• CALLER NAME
• CALLEE NUMBER
• ANSWER BY
Export File Data
• CONTEXT
• START TIME
• ANSWER TIME
• END TIME
• CALL TIME
• TALK TIME
• SOURCE CHANNEL
• DEST CHANNEL
• DISPOSITION
• DEST CHANNET EXTENSION
• LASTAPP
• LASTDATA
• AMAFLAGS
• UIQUEID
• USERFIELD
Groups the following:
• Inbound calls: Inbound calls are calls originated from a non-internal source
Call Type (like a VoIP trunk) and sent to an internal extension.
• Outbound calls: Outbound calls are calls sent to a non-internal source (like
a VoIP trunk) from an internal extension.
Page | 6
UCM6XXX CDR and REC API Guide
• Internal calls: Internal calls are calls from one internal extension to another
extension, which are not sent over a trunk.
• External calls: External calls are calls sent from one trunk to another trunk,
which are not sent to any internal extension.
Filter with the call status, the available statuses are the following:
• Answered
Status • No Answer
• Busy
• Failed
The call report will display as the following figure shows and since firmware version 1.0.15.16, the report will
display only CDR records for the current month since it’s split month by month.
In order to get records from previous months, users would need to use the filter search and specify start date
and end date to get records from the required period of time.
Page | 7
UCM6XXX CDR and REC API Guide
CDR Report Data Fields
The CDR report has the following data fields:
Account Code String An account code associated with the Party A channel. r/w
Caller Number String The Caller ID Number. r
Callee Number String The destination extension. r
Context String The context of the call. r
CallerID String The caller ID. r
Source Channel String The name of the source channel. r
Dest Channel String The name of the destination channel. r
Lastapp String The last application the Party A channel executed. r
The application data for the last application the Party A channel
Lastdata String r
executed.
Start time Date/time The time the CDR was created. r
The time when Party A was answered, or when the bridge between a
Answer Time Date/time r
Party A and a Party B was created.
The time when the CDR was finished. This occurs when either party
End time Date/time r
hangs up, or when the bridge between the parties is broken.
Call time Integer The time in seconds from start time until end time. r
Talk time Integer The time in seconds from answer time until end time. r
The final known disposition of the CDR record. The possible values are:
Disposition Enum r
“ANSWERED”,“NO ANSWER, CONGESTION, FAILED and BUSY.
A flag specified on the Party A channel. The possible values are: “OMIT,
Amaflags Enum r/w
BILLING and DOCMENTATION.
Uniqueid String A unique identifier for the Party A channel r
A user defined field set on the channels. If set on both the Party A and
Userfield String Party B channel, the userfields of both are concatenated and separated r/w
by a comma.
Dest Channel
String The destination extension of the call r
Extension
Caller Name String The name of the caller r
Answer by String The extension to be called r
Page | 8
UCM6XXX CDR and REC API Guide
A numeric value that, combined with uniqueid and linkedid, can be used
Session String r
to uniquely identify a single CDR record
Action Owner String The extension that made the call r
The action type of the call. The supported Action Type values are:
DIAL, ANNOUNCEMENTS, CALLBACK, CALLFORWARD,
CONFERENCE, DISA, FAX, FALLOWME, IVR, PAGE,
Action Type String PARKEDCALL, QUEUE, RINGGROUP, TRANSFER, VFAX, VM, r
VMG, WAKEUP, EMERGENCYCALL, EMERGENCYNOIFY, SCA,
VIDEOCONFERENCE, PRESENCE_STATUS, ANNOUNCEMENT
PAGE.
• Account code: --
• Caller Number: 1000
• Callee number: 7000
• Context: ext-did-1
• Caller ID: "1000" <1000>
• Source Channel: PJSIP/trunk_1-00000000
• Dest Channel: --
• Lastapp: ForkCDR
• Lastdata: ae
• Start time: 7/13/2018 12:00:12 PM
• Answer time: 7/13/2018 12:00:12 PM
• End time: 7/13/2018 12:00:32 PM
• Call time: 19 (in seconds)
• Talk Time: 19
• Disposition: ANSWERED
• Amaflags: DOCUMENTATION
• UniqueID: 1531497605
• Userfield: Inbound
• Dest channel extension: 7000
• Caller name: 1000
• Answer by: 7000
Page | 9
UCM6XXX CDR and REC API Guide
• Session: 1531497605793100-1000
• Action owner: 1000
• Action type: DIAL.
• Source Trunk name: test
• Dest Trunk name: --
• Delete All
Click on "Delete All" button to remove all the call report information.
P a g e | 10
UCM6XXX CDR and REC API Guide
To receive CDR record automatically from Email, check “Enable” and select a time period “By Day” “By Week”
or “By Month”, select Hour of the day as well for the automatic download period. Make sure you have entered
an Email or multiple email addresses where to receive the CDR records.
• Options
P a g e | 11
UCM6XXX CDR and REC API Guide
CDR CSV FILE
The downloaded CDR .csv file has different format from the web UI CDR. Here are some descriptions.
If "Caller number" shows empty, "Callee number" shows "s" (see the below figure) and the "Source Channel"
contains "DAHDI", this means the call is from FXO/PSTN line. For FXO/PSTN line, we only know there is an
incoming request when there is incoming call but we don't know the number being called. So we are using "s"
to match it where "s" means "start".
• Context
There are different context values that might show up in the downloaded CDR file. The actual value can vary
case by case. Here are some sample values and their descriptions.
Sample 1:
Figure 5: Downloaded CDR File Sample - Source Channel and Dest Channel 1
▪ For UCM6102/6202, DAHDI/(1-2) are FXO ports, and DAHDI(3-4) are FXS ports.
▪ For UCM6104/6204, DAHDI/(1-4) are FXO ports, and DAHDI(5-6) are FXS ports.
P a g e | 12
UCM6XXX CDR and REC API Guide
▪ For UCM6108/6208, DAHDI/(1-8) are FXO ports, and DAHDI(9-10) are FXS ports.
▪ For UCM6116, DAHDI/(1-16) are FXO ports, and DAHDI/(17-18) are FXS ports.
▪ For UCM6510, DAHDI/(1-2) are FXO ports, and DAHDI(3-4) are FXS ports.
Sample 2:
Figure 6: Downloaded CDR File Sample - Source Channel and Dest Channel 2
"PJSIP" means it's a SIP call. There are three possible formats:
1. PJSIP/NUM-XXXXXX, where NUM is the local SIP extension number. The last XXXXX is a random
string and can be ignored.
2. PJSIP/trunk_X/NUM, where trunk_X is the internal trunk name, and NUM is the number to dial out
through the trunk.
3. PJSIP/trunk_X-XXXXXX, where trunk_X is the internal trunk name and it is an inbound call from this
trunk. The last XXXXX is a random string and can be ignored.
There are some other possible values, but these values are almost the application name which are used by the
dialplan.
▪ Hangup: the call is hung up from the dialplan. This indicates there are some errors or it has run into
abnormal cases.
▪ Playback: play some prompts to you, such as 183 response or run into an IVR.
▪ ReadExten: collect numbers from user. It may occur when you input PIN codes or run into DISA.
P a g e | 13
UCM6XXX CDR and REC API Guide
API CONFIGURATION
The UCM6XXX supports CDR API interface to interact with third party external billing software and collect
recording details files from the PBX. The API uses HTTPS to request the CDR data and call recording data
matching given parameters as configured on the third-party application.
API Configuration
Before accessing the CDR API (to access call detail records) and REC API (to access call recording files), the
administrators need to enable API and configure the access/authentication information on the UCM6XXX first
under Value-added Features→API Configuration.
Basic Settings
Enable Enable/Disable API. The default setting is disabled.
Configure the IP address for TLS server to bind to. "0.0.0.0" means binding to all
interfaces. The port number is optional, and the default port number is 8443. The IP
TLS Bind Address
address must match the common name (host name) in the certificate so that the
TLS socket won't bind to multiple IP addresses. The default setting is 0.0.0.0:8443.
Configure the user name for TLS authentication. If not configured, authentication will
User Name
be skipped.
Password Configure the password for TLS authentication. This is optional.
Specify a list of IP addresses permitted by CDR and REC API. This creates an API-
specific access control list. Multiple entries are allowed.
Permitted IP(s) For example, "192.168.40.3/255.255.255.255" denies access from all IP addresses
except 192.168.40.3.
P a g e | 14
UCM6XXX CDR and REC API Guide
Port CDR server IP port
Important note:
Starting from firmware 1.0.16.20, UCM6xxx supports only digest authentication.
P a g e | 15
UCM6XXX CDR and REC API Guide
CDR API – ACCESS CALL DETAIL RECORDS
https://[UCM IP]:[Port]/cdrapi?[option1]=[value]&[option2]=[value]&...
The following table shows the parameter list used in the CDR API.
P a g e | 16
UCM6XXX CDR and REC API Guide
(Matches extensions 5300, hyphens will be ignored. (The pattern "0-0" will match all
5302, 5303, 5304, and any non-numerical and empty strings).
extension containing 4 as the
second digit/character).
Date and/or time of day in any
YYYY-MM-DDTHH:MM Filters based on the start (call start time) value. Calls
which start within this period (inclusive of boundaries)
YYYY-MM-DDTHH:MM:SS
will match, regardless of the call answer or end time. An
YYYY-MM- empty value for either field will be interpreted as range
DDTHH:MM:SS.SSS with no minimum or maximum respectively.
DDDDDDDDDD
Example Queries
The following illustrates the format of queries to accomplish certain requests. In most cases, multiple different
queries will accomplish the same goal, and these examples are not intended to be exhaustive, but rather to
bring attention to particular features of the CDR API connector.
▪ Query 1: Request all records of calls placed on extension 5300 which last between 8 and 60 seconds
(inclusive), with results in CSV format.
https://192.168.254.200:8443/cdrapi?format=CSV&caller=5300&minDur=8&maxDur=60
-OR-
https://192.168.254.200:8443/cdrapi?caller=5300&minDur=8&maxDur=60
P a g e | 17
UCM6XXX CDR and REC API Guide
▪ Query 2: Request all records of calls placed on extension 5300 or in the range 6300-6399 to extensions
starting with 5, with results in XML format.
https://192.168.254.200:8443/cdrapi?format=XML&caller=5300,6300-6399&callee=5@
-OR-
https://192.168.254.200:8443/cdrapi?cdrapi?format=XML&caller=5300&caller=6300-
6399&callee=5@
▪ Query 3: Request 10 records of calls placed on extension 5300 with results in JSON format.
https://192.168.254.200:8443/cdrapi?format=JSON&caller=5300&numRecords=10
▪ Query 4: Request all records of calls placed on extensions containing substring "53" prior to January 23,
2013 00:00:00 UTC to extensions 5300-5309, with results in CSV format.
https://192.168.254.200:8443/cdrapi?caller=@53@&callee=5300-5309&endTime=2013-01-23
-OR-
https://192.168.254.200:8443/cdrapi?caller=@53@&callee=530_&endTime=2013-01-23T00:00:00
▪ Query 5: Request all records of calls placed by an Anonymous caller during July 2013 Central Standard
Time to extensions starting with 2 or 34 or ending with 5, with results in CSV format.
https://192.168.254.200:8443/cdrapi?caller=Anonymous&callee=2@,34@,@5&startTime=2013-07-
01T00:00:00-06:00&endTime=2013-07-31T23:59:59-06:00
▪ Query 6: Request all records during July 2013 Central Standard Time, 200 at a time, with results in CSV
format.
https://192.168.254.200:8443/cdrapi?startTime=2013-07-01T00:00:00-06:00&endTime=2013-07-
31T23:59:59-06:00&numRecords=200&offset=0
-THEN-
https://192.168.254.200:8443/cdrapi?sstartTime=2013-07-01T00:00:00-06:00&endTime=2013-07-
31T23:59:59-06:00&numRecords=200&offset=200
-THEN-
https://192.168.254.200:8443/cdrapi?startTime=2013-07-01T00:00:00-06:00&endTime=2013-07-
31T23:59:59-06:00&numRecords=200&offset=400
Notes:
• Disallowed characters in the caller, callee, startTime, or endTime strings, and non-digit characters in
the values of numRecords, offset, minDur, or maxDur, will result in no records returned - the appropriate
container/header for the output format will be the only output. If the format parameter is in error, the
CSV header will be used. Error messages will appear in the Asterisk log (along with errors stemming
from failed database connections, etc.).
P a g e | 18
UCM6XXX CDR and REC API Guide
o Multiple hyphens in an extension range (e.g. caller=5300-5301-,6300)
o Extension values starting with comma, or with consecutive commas (e.g. caller=5300,,5303)
o Except for caller and callee, multiple instances of the same parameter within the URI (e.g.
minDur=5&minDur=10)
Output
Fields
From UCM6XXX firmware 1.0.11.x and higher, the CDR output has the following changes:
• New output fields are added for all format (CSV, XML and JSON):
o session
o action_owner
o action_type
o src_trunk_name
o dst_trunk_name
• For XML and JSON format output, sub record is added for certain call scenarios, e.g., call transfer. (CSV
format doesn’t have sub record added).
“session”
The new field “session” is the unique identifier for the call record and it exists in all CDR for this call. Same
“session” value indicates this is the same call. The value of the “session” consists of the time when the channel
is generated and the caller extension number, for example, 1461920017104140-1000.
“action_owner”
The new field “action_owner” indicates the owner of the CDR record, which is the initiator of this call. In a call
transfer scenario, the sub record 1 has A as the action_owner and the sub record 2 has B as the action_owner
who is performing the call transfer.
“action_type”
The new field “action_type” indicates the type for the call record. If this call type has its own extension number
or name, it will be listed in [ ]. For example, if an extension calls conference number 6300, the action_type will
be CONFERENCE [6300]. Here are the possible values of action_type:
P a g e | 19
UCM6XXX CDR and REC API Guide
• PAGE: paging/intercom
• CALLFORWARD: call forward always, call forward no answer, call forward busy
• IVR: enter IVR or call from IVR
• RINGGROUP: ring group
• VM: voice mail
• VMG: voice mail group
• CONFERENCE: conference call by calling into UCM’s conference extension
• DISA: enter DISA or call from DISA
• FAX: FAX
• VFAX: VFAX
• Announcements: Announcement center
• FOLLOWME: Follow Me
• QUEUE: call queue
• CALLBACK: call back
“src_trunk_name”
Source trunk name indicates the name of the trunk for the inbound call. For example, if the FOLLOWME call is
from trunk, this call record will have source trunk name field.
“dst_trunk_name”
Destination trunk name indicates the name of the trunk for the outbound call. Only outbound call has
dst_trunk_name field.
XML Output
On UCM6XXX, the XML output looks like below:
<cdr session=xxxxx-xxxx>
<main_cdr>
...
</main_cdr>
<sub_cdr>
<AcctID>1</AcctID>
...
</sub_cdr>
<sub_cdr>
<AcctID>2</AcctID>
...
</sub_cdr>
</cdr>
• One <cdr> element represents one call record. “session” is the unique identifier for this call.
• <main_cdr> is the primary record displayed in UCM web UI status->CDR page.
• <sub_cdr> is the sub record for this call. <AcctID> is the index for sub record.
P a g e | 20
UCM6XXX CDR and REC API Guide
Example:
Assuming the following scenario:
Extension A: 5000
Extension B: 5001
Extension C: 5002
A calls B->B answers->B Transfers the call to C.
• The XML output for the scenario above looks like below:
<root>
<cdr session="1461920017104140-1000">
<main_cdr>
<AcctId/>
<accountcode/>
<src>1000</src>
<dst>1001</dst>
<dcontext/>
<clid/>
<channel/>
<dstchannel/>
<lastapp/>
<lastdata/>
<start>2016-04-29 02:53:37</start>
<answer/>
<end/>
<duration>16</duration>
<billsec>9</billsec>
<disposition/>
<amaflags/>
<uniqueid/>
<userfield/>
<channel_ext/>
<dstchannel_ext/>
<service/>
<caller_name/>
<recordfiles/>
<dstanswer/>
<chanext/>
<dstchanext/>
<session>1461920017104140-1000</session>
<action_owner/>
<action_type>DIAL</action_type>
<src_trunk_name/>
<dst_trunk_name/>
</main_cdr>
<sub_cdr>
<AcctId>1</AcctId>
<accountcode/>
<src>1000</src>
P a g e | 21
UCM6XXX CDR and REC API Guide
<dst>1001</dst>
<dcontext>from-internal</dcontext>
<clid>"John Doe" <1000></clid>
<channel>PJSIP/1000-00000003</channel>
<dstchannel>PJSIP/1001-00000004</dstchannel>
<lastapp>Dial</lastapp>
<lastdata>PJSIP/1001/sip:[email protected]:5066,60,ztTkKA(dialog-being-
recorded)M(reco</lastdata>
<start>2016-04-29 02:53:37</start>
<answer>2016-04-29 02:53:44</answer>
<end>2016-04-29 02:53:49</end>
<duration>12</duration>
<billsec>5</billsec>
<disposition>ANSWERED</disposition>
<amaflags>DOCUMENTATION</amaflags>
<uniqueid>1461920017.7</uniqueid>
<userfield>Internal</userfield>
<channel_ext>1000</channel_ext>
<dstchannel_ext>1001</dstchannel_ext>
<service>s</service>
<caller_name>John Doe</caller_name>
<recordfiles>auto-1461920017-1000-1001.wav@</recordfiles>
<dstanswer>1001</dstanswer>
<chanext/>
<dstchanext/>
<session>1461920017104140-1000</session>
<action_owner>1000</action_owner>
<action_type>DIAL</action_type>
<src_trunk_name/>
<dst_trunk_name/>
</sub_cdr>
<sub_cdr>
<AcctId>2</AcctId>
<accountcode/>
<src>1000</src>
<dst>1002</dst>
<dcontext>from-internal-xfer</dcontext>
<clid>"John Doe" <1000></clid>
<channel>PJSIP/1000-00000003</channel>
<dstchannel>PJSIP/1002-00000005</dstchannel>
<lastapp>Dial</lastapp>
<lastdata>PJSIP/1002/sip:[email protected]:5066,60,ztTkKb(callee-
handler^s^1)</lastdata>
<start>2016-04-29 02:53:49</start>
<answer>2016-04-29 02:53:49</answer>
<end>2016-04-29 02:53:54</end>
<duration>4</duration>
<billsec>4</billsec>
<disposition>ANSWERED</disposition>
<amaflags>DOCUMENTATION</amaflags>
P a g e | 22
UCM6XXX CDR and REC API Guide
<uniqueid>1461920017.7</uniqueid>
<userfield>Internal</userfield>
<channel_ext>1000</channel_ext>
<dstchannel_ext>1002</dstchannel_ext>
<service>s</service>
<caller_name>John Doe</caller_name>
<recordfiles/>
<dstanswer>1002</dstanswer>
<chanext/>
<dstchanext/>
<session>1461920017104140-1000</session>
<action_owner>1001</action_owner>
<action_type>TRANSFER</action_type>
<src_trunk_name/>
<dst_trunk_name/>
</sub_cdr>
</cdr>
</root>
JSON Output
In general, the JSON output format looks like below:
{cdr_root:[
{
cdr: xxxx-xxxx,
main_cdr:{...},
sub_cdr_1:{...},
...
sub_cdr_n:{...}
},
...
{
cdr: xxxx-xxxx,
src: 2003,
...,
action_type:DIAL
}]
}
• cdr_root represents the JSON array that has all the call records in this query.
• The above result highlighted in red indicates the current call. The “cdr” value is the unique identifier for this
call, similar to the <session> element in XML format output.
• main_cdr is the primary record displayed.
• sub_cdr_x is the sub record for this call.
Example:
Assuming the following scenario:
Extension A: 5000
Extension B: 5001
Extension C: 5002
A calls B→B answers→B Transfers the call to C.
P a g e | 23
UCM6XXX CDR and REC API Guide
• The JSON output format for the above scenario looks like this:
{
"cdr_root": [
{
"cdr": "1461920017104140-1000",
"main_cdr": {
"AcctId": "",
"accountcode": "",
"src": "1000",
"dst": "1001",
"dcontext": "",
"clid": "",
"channel": "",
"dstchannel": "",
"lastapp": "",
"lastdata": "",
"start": "2016-04-29 02:53:37",
"answer": "",
"end": "",
"duration": "16",
"billsec": "9",
"disposition": "",
"amaflags": "",
"uniqueid": "",
"userfield": "",
"channel_ext": "",
"dstchannel_ext": "",
"service": "",
"caller_name": "",
"recordfiles": "",
"dstanswer": "",
"chanext": "",
"dstchanext": "",
"session": "1461920017104140-1000",
"action_owner": "",
"action_type": "DIAL",
"src_trunk_name": "",
"dst_trunk_name": ""
},
"sub_cdr_1": {
"AcctId": "1",
"accountcode": "",
"src": "1000",
"dst": "1001",
"dcontext": "from-internal",
"clid": "\"John Doe\" <1000>",
"channel": "PJSIP/1000-00000003",
"dstchannel": "PJSIP/1001-00000004",
"lastapp": "Dial",
"lastdata": "PJSIP/1001/sip:[email protected]:5066,60,ztTkKA(dialog-being-
recorded)M(reco",
"start": "2016-04-29 02:53:37",
"answer": "2016-04-29 02:53:44",
"end": "2016-04-29 02:53:49",
"duration": "12",
P a g e | 24
UCM6XXX CDR and REC API Guide
"billsec": "5",
"disposition": "ANSWERED",
"amaflags": "DOCUMENTATION",
"uniqueid": "1461920017.7",
"userfield": "Internal",
"channel_ext": "1000",
"dstchannel_ext": "1001",
"service": "s",
"caller_name": "John Doe",
"recordfiles": "auto-1461920017-1000-1001.wav@",
"dstanswer": "1001",
"chanext": "",
"dstchanext": "",
"session": "1461920017104140-1000",
"action_owner": "1000",
"action_type": "DIAL",
"src_trunk_name": "",
"dst_trunk_name": ""
},
"sub_cdr_2": {
"AcctId": "2",
"accountcode": "",
"src": "1000",
"dst": "1002",
"dcontext": "from-internal-xfer",
"clid": "\"John Doe\" <1000>",
"channel": "PJSIP/1000-00000003",
"dstchannel": "PJSIP/1002-00000005",
"lastapp": "Dial",
"lastdata": "PJSIP/1002/sip:[email protected]:5066,60,ztTkKb(callee-
handler^s^1)",
"start": "2016-04-29 02:53:49",
"answer": "2016-04-29 02:53:49",
"end": "2016-04-29 02:53:54",
"duration": "4",
"billsec": "4",
"disposition": "ANSWERED",
"amaflags": "DOCUMENTATION",
"uniqueid": "1461920017.7",
"userfield": "Internal",
"channel_ext": "1000",
"dstchannel_ext": "1002",
"service": "s",
"caller_name": "John Doe",
"recordfiles": "",
"dstanswer": "1002",
"chanext": "",
"dstchanext": "",
"session": "1461920017104140-1000",
"action_owner": "1001",
"action_type": "TRANSFER",
"src_trunk_name": "",
"dst_trunk_name": ""
}
}
]
}
P a g e | 25
UCM6XXX CDR and REC API Guide
CSV Output
The following CSV output is for an internal call from extension 6039 to extension 6011.
AcctId,accountcode,src,dst,dcontext,clid,channel,dstchannel,lastapp,lastdata,sta
rt,answer,end,duration,billsec,disposition,amaflags,uniqueid,userfield,channel_e
xt,dstchannel_ext,service,caller_name,recordfiles,dstanswer,chanext,dstchanext,s
ession,action_owner,action_type,src_trunk_name,dst_trunk_name
1201,,6039,6011,from-internal,"GVC Test" <6039>,PJSIP/6039-0000069e,PJSIP/6011-
0000069f,Dial,"PJSIP/6011/sip:[email protected]:5062&PJSIP/6011/sip:[email protected]
7.227.163:38102,30",2015-11-10 17:58:47,,2015-11-10 17:58:51,4,0,NO
ANSWER,DOCUMENTATION,1447207127.4182,Internal,6039,6011,s,GVC Test,,,,
1447207127558984-6039,6039,DIAL,,
P a g e | 26
UCM6XXX CDR and REC API Guide
REC API – ACCESS CALL RECORDING FILES
In this case, multiple file names are supported, separated by '@'; multiple file directories are not currently
supported.
Example Request:
https://192.168.254.200:8443/recapi?filedir=meetme&filename=meetme-conf-rec-6300-
[email protected]
Response:
The matching WAV file (if only one valid file found, in WAV format).
-OR-
A tarball containing all matching files, named [timestamp].tar, where the timestamp is set at the start of the
API callback function.
P a g e | 27
UCM6XXX CDR and REC API Guide
-OR-
404: Not Found (if no matching files are found).
Notes:
Requests formed incorrectly or with disallowed characters may result in an error, or cause the file to be skipped.
Error cases include:
• Multiple occurrences of the same parameter (filedir or filename) in the POST variable list are not
allowed. (404)
• Empty parameters in the POST variable list are not allowed. (404)
• File names longer than 256 characters will be truncated.
• File names containing ' ' (space) or '..' will be skipped.
P a g e | 28
UCM6XXX CDR and REC API Guide