Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

CDRs pushed to a remote server questions?

We are trying to parse cdrs\cmrs setn to us via ftp push from several call managers.

(1) Is there a way to tell the ip address of the call manager that setup the call?

(2) How can we identify whether the endpoint is an IP phone or  media device (gateway, CUBE, etc...)?  Is origSpan/destSpan != 0 an indication ?
     What about a non Zero / incomingProtocolID?

(3) What does orig/dest Ipv4v6Addr represent, IpAddr as a string?

(4) Why is orig/dest Ipv4v6Addr sometimes "0.0.0.0" when the corresponding orig/dest IpAddr is not zero?

(5) Can the orig/dest MediaTransportAddress_IP always be relied upon to be the ip addresses of the
     actual endpoints tha made the call?

Thanks,

-tom

1 REPLY
Silver

CDRs pushed to a remote server questions?

Have you read the CDR admin guide?  Since you didn't mention version, I guessed:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/8_0_1/cdrdef/cdradminguide.pdf


(1) Is there a way to tell the ip address of the call manager that setup the call?

Yes, but indirectly.  The filename of the CDR/CMR files give you the cluster id and node id (tag_clusterId_nodeId_datetime_seqNumber)

.  Since you're working with multiple clusters, you'll need to give each cluster a unique id under enterprise params.  Then either hardcoding in your app or via an AXL request you obtain node address or other information as needed.

(2) How can we identify whether the endpoint is an IP phone or  media device (gateway, CUBE, etc...)?  Is origSpan/destSpan != 0 an indication ?

     What about a non Zero / incomingProtocolID?

From the admin guide:

"For calls that originate at a gateway, this

field indicates the B-channel number of the

T1, PRI, or BRI trunk where the call

originates, or a zero value for FXS or FXO

trunks.

For H.323 gateways, the span number

remains unknown, and this field contains

the call leg ID of the originator.

For calls that did not originate at a gateway,

the value specifies zero.

Default - This field gets populated based on

these rules."

Since gateways/trunks are fairly static in terms of changes, re-addressing, additions, etc, I've always statically defined them.  As For the incomingProtocolID, I'm not seeing that column header in my cmr/cdr files.  Where are you seeing that and what version of UCM?

(3) What does orig/dest Ipv4v6Addr represent, IpAddr as a string?

Yes.  Pg74/174 of the linked doc explains this.  Unlike the other ip address fields, these 2 use strings.  The cdr/cmr file headers actually define the datatype and string length, so you shouldn't have to resort to guessing.

(4) Why is orig/dest Ipv4v6Addr sometimes "0.0.0.0" when the corresponding orig/dest IpAddr is not zero?

The only examples I have of that are when I was testing an mwi issue recently and directly dialed mwi on/off dn's since there isn't a destination device.  The docs give examples of this such as an ipv6 device calls v4v6 device and the call fails.  For destipv4v6addr, the docs show:

"Default - Empty String ““ or null.  If the

destination does not get reached, this field

stays empty."

I'm sure that we could brainstorm different scenarios, but the rest of the data in the cdr file should point you toward who called what and you can figure out just step through it to figure it out.  Question though, are you seeing orig 0.0.0.0 to dest non-0.0.0.0 calls or only seeing 0.0.0.0 on the destination side?

(5) Can the orig/dest MediaTransportAddress_IP always be relied upon to be the ip addresses of the 

     actual endpoints tha made the call?

Not always.  This is explained in the doc I linked to as well:

"This field identifies the v4 IP address of the device that terminates the media for the call.  For Cisco Unified IP Phones, this field

designates the v4 address of the phone.  For PSTN calls, this field designates the v4 address of the H.323 gateway.  For intercluster calls, this field shows the v4 address of the remote phone.  The “IP Addresses” section on page 3-5 describes the IP address format.  Default - 0. If the destination cannot be reached or the IP addr  ess of the destination is not v4, this field stays 0."

The admin guide for your UCM version and the headers of the files themselves should be all that you need.  For the columns with multiple caveats like some of the ones mentioned above, it might take a few test calls and some intuition to figure out but by and large the docs should get you 95% of the way there.

thanks,

will

203
Views
0
Helpful
1
Replies
CreatePlease to create content