CDR API

RE: Duplicate CDR Records

2013-01-29T17:23:30Z

Regarding INTER_COMPANY DIRECTDIAL and questions 2 and 3: 2. All of the examples we have seen appear to all have been rejected with reason 21. 3. They are not all from the same endpoint.

RE: Duplicate CDR Records

2013-01-29T00:53:12Z

Hi Mike, I consulted with the development team on each of the two duplicate CDR cases you mentioned, and here is our analysis: [b]INTER_COMPANY DIRECTDIAL[/b] Our theory is that somehow the call may be directed to both engine servers separately. To further anaylze: 1. Can you send logs from both the engine and admin servers. We want logs from when this happened so if logs from the record you show below have already rolled-over, can you send us logs from a more recent occurrence of this. You can send us logs through the usual channel. 2. Is this observed only for the case where call was rejected with reason 21? 3. Is this observed only for calls from/to a specific endpoint. 4. Is this observed only for calls from/to a particular route. [b]INTRA_COMPANY DIRECTDIAL[/b] These CDRs are imported from the CUCM as part of a background periodic task. Our theory is that the CUCM is sending duplicates and CTX is not detecting them as duplicates, perhaps because of some subtle difference in the data received from CUCM that is not exposed in the CDR API. Please send us admin server logs for around that time period, and we can further diagnose. Thanks - John

RE: Can there be Gaps in the Instance ID Values

2012-10-24T23:21:40Z

Hi Mike, There should never be gaps in the instance ID values, according to our development team. An instance begins with a valid call into the meeting, hence there should be at least one CDR record with each instance ID. Is this for Release 1.1? There is a possibility that this was a defect fixed in 1.2. Is this easily reproduceable? - John

RE: Callee and Caller Service Provider

2012-09-06T23:33:42Z

Hi Mike, Some instances where one of these will be null are: For an incoming call, the caller SP will be null if There is no cic-id when the call comes in or if the cic-id matches multiple org's and the org's have different SP's. For an outgoing call, callee SP will be null if Route selected is the default route. ISDN/H323 dialout is done to an unknown endpoint.

RE: Expected Value for meetingInstanceID in CDR for non-Rendezvous Meeting

2012-09-06T21:15:40Z

Mike, Yes, Meet-me meetings will always have the instance ID set to 0. The first instance of a Rendezvous meeting will have a value of 0, the next instance will have a value of 1, and so on, always incrementing by 1. I will ask our documentation team to make this clearer in the API document. - John

Callee and Caller Service Provider

2012-09-06T21:07:21Z

The API documentation says that "If the Cisco TelePresence Exchange System cannot determine a value for this field, the value is null." Can you provide some additional information about when the CTX is unable to determine a value or when it is able to determine a value?

Expected Value for meetingInstanceID in CDR for non-Rendezvous Meeting

2012-09-06T21:01:54Z

According to the CTX 1.1 API Guide: [i]This indicates the instance number of a Rendezvous meeting. The number increments by one for each instance of the Rendezvous meeting. For other meeting types, the value is always null. [/i] We are seeing the meetingInstanceID returned with a value of 0 for Meet-me meetings. Is this the value that will always be returned for Meet-me meetings? Will the value of 0 ever be returned for a Rendezvous Meeting?

RE: ApiCompanyScope versus CompanyScope

2012-06-04T23:44:47Z

For enums that are exposed by the API, we define API-specific definitions that are independent of the back-end representation in the database. We do this primarily to guarantee backward compatibility. In this case, ApiCompanyScope is the enum exposed in the API but CompanyScope is what we use in the back-end. Suppose we add another value to CompanyScope called "XYZ" in an upcoming release. We don't want to unknowingly expose this in the WSDL for any clients that are operating in backward compatibility mode. By having a separate ApiCompanyScope, we have tight control over what we expose, and furthermore, we can define any necessary adaptation logic. This also implies we can have separate ApiCompanyScope definitions for each release. In short, for now CompanyScope and ApiCompany scope have the same values. But if they diverge at all on the back-end, we won't automatically break any backward compatibility.

ApiCompanyScope versus CompanyScope

2012-06-04T23:21:19Z

We recently installed the pre-FCS of CTX 1.1. With that install we noticed a new file ApiCompanyScope.java. It looks to be the same as CompanyScope. Are there any recommendations or guidence regarding these files?

RE: disconnectCauseCode and disconnectData exhaustive description

2012-05-11T02:12:19Z

Hello Lionel, Below are fields and their possible values. [b]disconnectCauseCode[/b] Values: 1 - 128 (Q.850 codes) for DirectDial, SIPDialin, SIPDialouts. 1 - 12 for H323, ISDN dialouts. [b]disconnectCauseStr[/b]: String representation of disconnect cause. [b]disconnectData[/b]: Additional disconnect text if available. [b]conferenceParticipantDisconnectCode[/b]: 1 - 12 [b]conferenceParticipantDisconnectReason[/b]: String representation of disconnect cause. conferenceParticipantDisconnectCode and conferenceParticipantDisconnectReason are only applicable to calls into meetings.

RE: INTERSP Call Types Removed from CTX 1.1 CDR API

2012-04-29T08:24:13Z

Hi Michael, For calls in the 1.0 environment that generated a INTERSP_INCOMING CDR record, what would the CDR record for the same calls look like in the 1.1 environment? If the answer is that it would be a MEETME_INCOMING CDR record, is there anything in the CDR that would tell us that the call was interSP? In 1.1, this would have MEETME_INCOMING in 1.1 if the call was going to a meetme bridge. Since InterSP, you can see different values for callerServiceProviderand calleeServiceProvider. for example callerSP ATT and calleeSP BT. For calls in the 1.0 environment that generated a INTERSP_OUTGOING CDR record, what would the CDR record for the same calls look like in the 1.1 environment? If the answer is that it would be a MEETME_OUTGOING CDR record, is there anything in the CDR that would tell us that the call was interSP? In 1.1, these would be DIRECTDIAL. Since IntersP, you will see different values for [color=#1f497d]callerServiceProviderand [/color][color=#1f497d] and [/color][color=#1f497d]calleeServiceProvider[/color][color=#1f497d].[/color]

RE: Binding CDRs records to Meetings

2012-04-27T17:30:26Z

Hi Lionel, Sorry for the late response, but the e-mail notification system was broken and I just now saw this. The APICallDetailRecord which is returned by the CDR API does contain a meetingID field. This is exactly what you would use to correlate CDR data with the meetings returned by the getMeetings method. Note that there will only be a meetingID present in the CDR for calls into Meet-Me or Rendezvous meetings. Direct dial calls will not contain meetingID data in the CDR because they are point-to-point. - John

disconnectCauseCode and disconnectData exhaustive description

2011-09-01T15:35:49Z

Hello, Where may i find exhaustive description of cdr API disconnectCauseCode and disconnectData fields ? By exhaustive, i mean all the possible values, and their corresponding meaning. Thanks for your support. Regards.

Binding CDRs records to Meetings

2011-09-01T15:31:40Z

Hello folk, Would like to know which field i may use from cdr API in order to get the related meeting in sched API ? For instance, i would like to use getMeeting method from sched API in order to get meeting info. The only filter i can use with getMeeting is "meetingID". What is the field in cdr API that binds to "meetingID" ? Thanks for your support. Regards.