(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
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
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
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.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: firstname.lastname@example.org Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...