The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This section provides an outline of the types of data that are collected during the Service Inventory process. The purpose of the format specification is to represent the information in a common format that is not specifically tied to any single customer’s format requirements. The data points listed comprise elements required by current customers, elements required by Cisco, and additional fields that are reserved for future use. This section is a summary of the types of data that are collected and is not a complete list. See the format definitions and example files in Filename Specifications for a complete listing of fields and data.
Note | This listing does not specify the order or arrangement of data in the files. This section provides a summary of the types of data that are presented. |
The following data points are included in the Report Summary Information:
The following data points are included in the Report Statistical Information:
The following data points are found in the Service Inventory Report Data:
This section outlines the layout and format of data points in the Cisco Service Inventory output file. In general, the data stored in the files is displayed by the customer with some additional processing information included where necessary. The following section gives an overview of the format, a description of the file layout, a listing of the various row formats and data types that are in the output files, and finally, examples of Cisco Service Inventory output files.
The Cisco Unified Communications Domain Manager Service Inventory Common Format presents all necessary data in a human-readable format while keeping output file size to a minimum. The format is an ASCII-based file with the ".si" file extension. Files that are delivered by the Cisco Unified Communications Domain Manager server (or any other Domain Manager) before final output are identified by the ".dsi" file extension ("Domain Manager Service Inventory"). The Domain Manager server delivers files in a single-file output. The file extension for the UC Application Service Inventory Common Format is ".ucsi". The Service Inventory application also maintains additional intermediate file formats that follow a similar naming convention; however, these file formats are for internal use only and are not the focus of this document.
The output is arranged into the following sections:
MACD data in the file is represented as a row indicating the updated state of whatever entity is currently being added, changed, or deleted. Unlike a change notification, which shows a "before" and "after" state of the entity, the MACD representation shows only the "after" state. For a delete operation, the "before" state is shown fully, and in most cases, it shows precisely the information that is being deleted. This information may differ depending on the Unified Communications Domain Manager and the case. Where necessary, the parsing applications must interpret intermediate states based on the combination of static service inventory data and MACD data.
You can also run a report for the UC Applications that is slightly different from the MACD for the Unified Communications Domain Manager report. See MACD Format for UC Applications.
The Unified Communications Application Service Inventory Common Format generates a report with information that is specific to the UC Application. It contains similar information to the Unified Communications Domain Manager report but with data from your UC Application. You can also generate a specific report for MACD information on your UC Application. See MACD Format for UC Applications.
The format of the service inventory filenames are critical to the proper operation of the SI applications. The following parameters apply to filenames in this format:
The filename follows this format:
<date><time><timezone>+<domainManagerSequenceID>+<domainManagerType>+<fileNumber>+ <fileCount>.<extension>
The standard field delimiter in the filename is “+”. This avoids UNIX/Linux escape character issues and minimizes character escape when writing Java applications against the format.
The <domainManagerSequenceID> field is mandatory and identifies the specific Domain Manager that is used to generate the output file. This field must be unique across Domain Managers within a data center.
If it becomes necessary to compress the service inventory file for any reason, prior to transmission across a network, for instance, then the transmitting entity "ZIPs" up the file in an appropriate format. We recommend a ".gz" file format. Domain managers add the .gz extension to the existing filename+extension. In this case, the transmitted file is “<filename>.<extension>.gz”.
Additionally, you should assign compressed files the appropriate permissions to allow proper reading and writing upon being extracted into their uncompressed form. We recommend an “a+rw” permission. File ownership should be treated similarly.
Additional general format specifications include:
Data elements in the file are stored in text, integer, and standard date/time formats where appropriate.
The standard end-of-line character "\n", while not typically visible in common text-editing applications, is used and available for parsing applications to use for line tokenization.
The data element delimiter is the pipe symbol (|). Each line starts and ends with a pipe symbol, with a pipe symbol between each data point on the line.
The pipe symbol "|" is not a valid character within fields in the format.
An empty (null) field is represented by a tilde symbol (~). Empty fields/columns are not skipped.
Data rows that are entirely or partially inaccurate are appended with an asterisk (*). This notation is not applied to Report Summary or Report Definition rows. For more information see Data Accuracy Handling.
All MACD rows in the file are listed in the MACD section defined by the starting tag |MACDSTART| and by the closing tag |MACDEND|. (For more information see MACD Row Format .) MACD rows are ordered TOP to BOTTOM in the file by timestamp, NEWEST to OLDEST.
Certain scenarios exist in which the data provided is not entirely accurate or does not even exist while Service Inventory data is processed. To effectively handle such scenarios while still preserving the overall integrity of a service inventory file, the format provides the asterisk (*) symbol for proper notation.
Note | You cannot apply this notation to Report Summary rows. Use caution with parsing applications that handle and process data in the report. |
If a single data element is known to be invalid, an asterisk is placed at the end of the field itself.
|CUST|1|31|1|XYZ, Inc.|~| ~*|~*|~*|~*|~*|~*|~*|
Note | The * after the ~ in the preceding example indicates that the fields are not empty but are shown as empty because the actual values for the data field in question cannot be provided for some reason. For more information see Customer Data Row. |
If an entire row is known to be inaccurate, the asterisk is placed at the end of the row outside the final pipe symbol.
|DEF|FGROUP|CompanyXYZ|1|Basic Feature Group|10|11|19|17|*
Note | The * in the preceding example indicates here that the list of features in this feature group are not guaranteed to be accurate at report generation time. For more information the feature group definition row field see Report Definition Row. |
This section outlines the data formats that are used throughout the row formats. Deviation from these global formats is not permitted in the scope of this SI Common Format definition.
This format describes the representation of an internal telephone number (TN) or line (terms used interchangeably) throughout the specification.
|810100001| |
Note | Anywhere internal TNs are reported, the format is changed to report the IPPBX-configured full internal number. |
This format describes the representation of an external E.164-compliant telephone number (TN) or line (terms used interchangeably) throughout the specification.
|+19195552600| |
Note | External TNs that are listed in the report must adhere to the standard E.164 format specification. Typically, a list of external E.164 telephone numbers is associated with an internal TN. The first E.164 number listed (if there is more than one) is the primary E.164 number. |
This format describes the representation of a device name and, where applicable, the device type, the Media Access Control (MAC) address number throughout the specification.
|SEP044553abf49C|044553abf49C| |TCPNAME|~| |
Note | No colon (:) is needed between the HEX digits in the MAC address element. |
This format definition describes the way in which Date/Time elements are represented in information rows. All dates/times are represented in Greenwich Mean Time. All times are represented in 24-hour format. No separate definition row is required in the file to describe the date elements.
The following describes the characters that are used to construct the format:
|20110423163455GMT| |
This format describes the representation of a Time Zone throughout the report. The Time Zone format is <"Region/City">.
|Africa/Pretoria| |Europe/London| |Pacific/Fiji| |Indian/Maldives| |
This section outlines the various secondary row formats that are used in the Cisco SI Common Format. Each type specification provides a format definition and an example usage.
File Header is the first line of each output file.
|FSTART| |
Note | This row is required. |
File Footer is the last line of each output file.
|FEND| |
Note | This row is required. |
|DEFSTART| |
Note | This row is required. |
These row definitions specify which interpreted fields later on in the format are defined specific to the file. For instance, you need to define the list of features that are available on the system before specifying feature inclusion in a feature group. By encapsulating these definitions in the output, a parsing application can programmatically, at runtime, determine how to interpret information that is presented later in the output file.
|DEF|COUNTRY|<country[1] ID>|<country[1] Name>|<country[1] Code>|…|<country[N]ID>| <country[N]Name>|<country[N] Code>| |
|DEF|COUNTRY|15|United States|USA|16|United Kingdom|UK| |
|DEF|DEV| <customerName>|<device [1]ID>|<device[1]Make>| <device[1]Model>|…| <device[N]ID>|<device[N] Make>|<device[N]Model>| Format for Entitlement Feature Group: |DEF|EFGROUP|<Entitlement Feature Group Name>| feature [1] ID|>|<feature [2] ID>|…|<feature [N] ID>| Format for Entitlement Device Group: |DEF|DGROUP|<Entitlement Device Group Name>|>|<device [1] ID>|<device [1] Make>|<device [1] Model>|…|<device [N] ID>|<device [N] Make>|<device [N] Model>| Format for Entitlement Catalog: |DEF|ECATALOG|<Provider Name>|<Reseller Name>|<Customer Name>|<Entitlement Feature Group Name>|<maximum allowed number of total devices irrespective of the device groupings>|<Device Group [1] Name>|<maximum allowed number of devices in the group >|… |< Device Group [n] Name >|< maximum allowed number of devices in the group >| Format for Entitlement Profile: |DEF| EPROFILE |<Provider Name>|<Reseller Name>|<Customer Name>|<Entitlement Profile Name>|<Entitlement Feature Group Name>|< maximum allowed number of total devices irrespective of the device groupings>|<Device Group [1] Name>|< maximum allowed number of devices in the group >|… |< Device Group [n] Name >|< maximum allowed number of devices in the group >| |
|DEF|DEV|CompanyXYZ|1|Cisco|7960|2|Cisco|7965|3|Cisco|Cius_V1 |4|Avaya|Phone1000|5|Apple|iPhone 3GS|11|Cisco|CUPC8| Example - Entitlement Feature Group |DEF|EFGROUP|EntitlementFeatureGroup_1|1|51| Example - Entitlement Device Group |DEF|DGROUP|devicegroup2|3|~|Cisco DX80|2|~|Cisco 7961|1|~|Cisco 7961G-GE| Example - Entitlement Catalog |DEF|ECATALOG|Provider1|Reseller 1|~|EntitlementFeatureGroup_1|10|devicegrp1| 9|devicegroup2|1| Example - Entitlement Profile |DEF|EPROFILE|Provider1|Reseller1|Customer1|ent_profile|EntitlementFeatureGroup_3 |1|devicegroup2|1| |
|
Note | The Feature Definition, |DEF|FEATURES| in the Service Inventory report for Cisco Unified Communications Domain Manager 10.x are derived from features assigned to each subscriber, phone. |
Note | Cisco Unified Communications Domain Manager 10.x does not have the concept Feature Groups (FGROUP). For backward compatibility reasons, Service inventory reports notional feature group (FGROUP) definitions for reports generated from Cisco Unified Communications Domain Manager 10.x. This notional Feature Group is based on the actual feature assigned to each subscriber. |
Note | The Customer Device Definition rows |DEF|DEV| in the SI report for Cisco Unified Communications Domain Manager 10.x are derived from the actual devices configured for subscriber or devices provisioned under a site. |
|DEFEND| |
Note | This row is required. |
|SISTART| |
Note | This row is required. |
|PROV|-1|PartnerXYZ| |
Note | All fields are required in this row. |
Note | The <providerID> field value is always "-1" because its original value accuracy is not guaranteed. |
|PEND| |
Note | This row is required if a |PROV| data row exists. |
|RESELL|-1|-1|ResellerXYZ| |
Note | All fields are required in this row. |
Note | The <providerID> and <resellerID> field values are always "-1" because their original value accuracy is not guaranteed. |
|REND| |
Note | This row is required if a |RESELL| data row exists. |
The <customerCountry> within this field is represented by an ID that maps to the country definition row in this example.
Note | All fields are required in this row. |
Note | The <provider_id>, <reseller_id> and <customer_id> <providerID> field values are always "-1" because its original value accuracy is not guaranteed. |
|CEND| |
Note | This row is required row if a |CUST| data row exists. |
|SITE|<customerID>|<siteID>| <siteName>|<externalSiteID>| <siteAddress1>|<siteAddress2>| <siteAddress3>|<siteCity>| <siteState>|<siteCountry>| <sitePostalCode>|<cityTimezone>| |
|SITE|-1|-1|RTP|~|7600 RTP Road|~|~|Cary|NC|15|27513|EST| |SITE|-1|-1|New York|~|100 Broadway Ave|~|~|New York|NY|15|10101|EST| |
|
Note | All fields are required in this row. |
Note | The field values for<customer_id> and <site_id> are replaced with "-1" because their original value accuracy is not guaranteed. |
|SEND| |
Note | This is a required row if a |SITE| data row exists. |
This section describes the format of the Subscriber Data Row.
|SUBEND| |
Note | This row is required if a |SUB| data row exists. |
|DEV|<profilename>|<profileID>| <customerID>|<customerprofile>|<deviceIDs>| <devicegroup>| <numberofdevices>| <numberofdevicesingroup>| |
|DEF|EPROFILE|p1|~|cust02|cust02EntProfile|51|53|1|46|p1devicegroup02|10|10| |
|DEV|<profilename>|<profileID>| <customerID>|<customerprofile>|<deviceIDs>| <devicegroup>| <numberofdevices>| <numberofdevicesingroup>| |
|DEF|ECATALOG|p1|~|cust01|51|53|1|46|p1devicefroup01|10|10| |
|DEV|<groupname>|<devicegroup>| <numberofdevices>| |
|DEF|DGROUP|p1devicegroup02|25| |
This format defines how a single device is represented in the report. The device is registered and assigned to the subscriber when represented within a |SUB|/|SUBEND| pair. The device is registered to and functional at a site but is not assigned to a user when a device is placed outside a |SUB|/|SUBEND| pair in the report. Device examples include conference room phones, lobby phones, or Cisco Extension Mobility-enabled “empty” devices.
In these scenarios, the |DEV| row exists immediately following the |SITE| row and before |SUB| rows for that site. Device Data Rows cannot exist anywhere else in the report. Cisco Extension Mobility profiles are reported in the same way as traditional devices.
|DEV|<customerID>| <siteID>|<subID>|<deviceName>| <deviceMAC>| <phoneOrExtMobility>| <deviceTypeID> or <device Type>|<lineCount>| <HCS License Type>| |
|DEV|-1|-1|-1|SEP0445687B8AAF|0445687B8AAF||0|3|1|~| In the example above, the <deviceMAC> field follows the preceding MAC Address format definition. The <deviceTypeID> field references the device type as defined in the Device Definition Row. The device type is "3" in this example. It shows a device assigned to a subscriber with an ID "9865." The <phoneOrExtMobility> parameter is set to 0 to indicate that it is a physical phone.
|DEV|-1|-1|~|SEP1143ADFE23FF|1143ADFE23FF|0|3|1| HCS Standard| The example above shows a similar device, but in this case, the device is registered to a site/location but not assigned to an individual subscriber. The tilde (~) shows that there is no <subID> associated with this device. The <phoneOrExtMobility> parameter is set to 0 to indicate that it is a physical phone. |DEV|-1|-1|-1|jsmith|~|1|3|1|~| The example above shows an Extension Mobility profile assigned with profile name "jsmith," <deviceTypeID> = "3", and no <deviceMAC> field. The <phoneOrExtMobility> parameter is set to 1 to indicate that it is a Cisco Extension Mobility profile.
|DEV|-1|-1|-1|sep098765432108|098765432108|0|8|0|HCS Foundation| The example above shows how a typical |DEV| data row appears in the 10.6.1 report format. This format provides the HCS License Type to report the type of HCS license activated by the device. For devices owned or controlled by subscribers, the value appears as “~”. |
||
|
Note | All fields are required on this row. The following fields may not be empty: <device Name> (if an EM Profile) -or- <deviceMAC> (if a physical device or soft client). |
Note | The values for the following fields:<customer_id> , <site_id>, and <subscriber_ID> are replaced with "-1" because their original value accuracy is not guaranteed. |
This format definition describes how device lines are represented in the report. This format definition depends on the previous definitions of Telephone Number (Internal TN) and Telephone Number (External TN).
|LINE|<internalTN>| <contactCenterAgentLineService>| <externalTNe164[1]>|…|<externalTNe164[N] >| |
|LINE|4761000|0| The example above describes a single internal TN only. |LINE|4761001|1|+19194761001| The example above describes a single internal TN with a mapped external TN (E.164 compliant) and the extension enabled as a contact center agent line. |LINE|4761001|0|+19194761001|+19194761002| The example above describes two external TNs associated with a single line. |
||
The <contactCenterAgentLineService> field in all the examples above is a Boolean field indicating whether this particular device LINE is activated for contact center agent usage. Availability of contact center features is described by the appropriate feature in the subscriber's assigned feature group. The <contactCenterAgentLineService> field indicates actual activation of the feature, rather than simply indicating availability of this feature.
|
|SIEND| |
Note | This row is required. |
|MACDSTART| |
Note | This row is required. |
This format definition describes the general layout of all MACD rows in the report. Certain fields described are required of each MACD row, regardless of type, while individual differences are highlighted in the definition for each type later.
|MACD|<macdEffectiveDT>| <macdCategory>|<macdCode… <additional fields>…| |
|MACD|201108111983040511GMT|FGROUP|A|...| |MACD|201108111983040511GMT|RESELL|A|...| |MACD|201108111983040511GMT|CUST|A|...| |MACD|201108111983040511GMT|SUB|A|...| |MACD|201108111983040511GMT|SITE|A|...| |MACD|201108111983040511GMT|DEV|A|...| |MACD|201108111983040511GMT|LINE|A|...| |
|
This format definition describes how MACD Code elements are represented in all MACD rows. No separate definition row is required in the file to describe the MACD Code elements.
The following list describes the characters used to construct the format:
|M||A| |D| |C| |
|
This field applies to all row types that have corresponding MACD rows, except devices. Devices have additional states for registration and assignment that require a separate representation. See MACD Code Element (Devices Only). |
This format definition describes how MACD Code elements are represented in all MACD rows for devices. No separate definition row is required in the file to describe the MACD Code Elements for devices.
The following list describes the characters used to construct the format:
A = Device is Registered
D = Device is Unregistered
S = Device is Associated to a user/Cisco Extension Mobility profile is added to a user
U = Device is Disassociated from a user/Cisco Extension Mobility profile is removed from a user
C = Device is Modified/Cisco Extension Mobility profile is Modified
|A||D| |S| |U| |C| |
This format definition describes how the function “add, change, or delete” a feature group can appear in the MACD section of the SI report.
|MACD| <macdEffectiveDT>| FGROUP|<macdCode>| <customerName>| <featureGroupName>| <feature[1]ID>|<feature[2]ID>| …|<feature[N]ID>| |
|MACD|20110423163455GMT|FGROUP|A|CompanyXYZ|Advanced Feature Group|10|11|19|33|99| In the example above, a feature group is added to the system, assigned to customer “CompanyXYZ” and contains features 10, 11, 19, 33, and 99 (mapped to the |FEATURES| definition row previously). |MACD|20110423163455GMT|FGROUP|C|CompanyXYZ|Advanced Feature Group|10|11|19|99| In the example above, the same feature group is modified, and feature 33 is removed. |MACD|20110423163455GMT|FGROUP|D|CompanyXYZ|Advanced Feature Group|10|11|19|99| In the example above, the entire feature group is deleted. In the next day’s report, this feature group would no longer exist unless it was re-added. |
There is no "Provider" MACD information supported or needed in this version of the report format.
This format definition describes how reseller MACD information is presented within the SI report file.
|MACD|20110423163455GMT|RESELL|A|ResellerXYZ| In the example above, a reseller named “ResellerXYZ” is added to the Domain Manager on April 23, 2011 at 04:34:55 PM GMT. |MACD|20110423163455GMT|RESELL|D|ResellerXYZ| The example above shows that the reseller is deleted from the Cisco Unified Communications Domain Manager. |MACD|20110423163455GMT|RESELL|C|ResellerXYZ| The example above shows a change to the reseller in the example. |
|||
|
This format definition describes how customer MACD information is presented within the SI report file.
|MACD| <macdEffectiveDT>|CUST| <macdCode>| <customerName>| <resellerName>| <externalCustomerID>| |
|MACD|20110423163455GMT|CUST|A|CompanyXYZ|ResellerXYZ|~| In the example above, “CompanyXYZ” is added on April 23, 2011 at 4:34:55 PM GMT to the Cisco Unified Communications Domain Manager. |MACD|20110423163455GMT|CUST|D|CompanyXYZ|ResellerXYZ|~| The example above describes deleting the customer. |MACD|20110423163455GMT|CUST|C|CompanyXYZ|ResellerXYZ|34587573| The above example describes the change of the customer where the <externalCustomerID> field was updated. |
||
|
No "Division" MACD information is supported or needed in this version of the report format.
This format definition describes how site MACD information is presented within the SI report file.
|MACD| <macdEffectiveDT>|SITE| <macdCode>| <customerName>| <siteName>|<externalSiteID>| |
|MACD|20110423163455GMT|SITE|A|CompanyXYZ|New York|~| In the example above, a site with the name “New York” is added on April 23, 2011 at 4:34:55 PM GMT to the Domain Manager. |MACD|20110423163455GMT|SITE|D|CompanyXYZ|New York|~| In the example above, a site was deleted from customer “CompanyXYZ”. |MACD|20110423163455GMT|SITE|C|CompanyXYZ|New York|74536577456| In the example above, the <externalSiteID> field was updated. |
||
|
This format definition describes how subscriber MACD information is presented within the SI report file.
|MACD|<macdEffectiveDT>|SUB| <macdCode>|<customerName>| <siteName>|<subUsername>| <subEmail>|<subNameFirst>| <subNameMiddle>|<subNameLast>| <subTitle>|<subDepartment>| <subDepartmentCode>| <subContactTelephone>| <featureGroupName>| |
|MACD|20110423163455GMT|SUB|A|CompanyXYZ|NewYork| jsmith|jsmith@xyz.com|John|Thomas|Smith|Manager|Finance|99| +19198548001|Basic Features| In the example above, subscriber John Smith is added on April 23, 2011 at 4:34:55 PM GMT to the customer “CompanyXYZ” at site “New York”. John Smith’s full details are provided on the MACD line to show all the data that was added. |MACD|20110423163455GMT|SUB|D|CompanyXYZ|NewYork| jsmith|jsmith@xyz.com|John|Thomas|Smith|Manager|Finance|99| +19198548001|Basic Features| The example above shows the deletion of user John Smith. |MACD|20110423163455GMT|SUB|C|CompanyXYZ|NewYork| jsmith|jsmith@xyz.com|John|Thomas|Smith|Manager|Finance|99| ~|Basic Features| Various types of changes are possible where a subscriber is concerned. The first type is metadata changes including modifications to email, name (first, middle, last), title, department, and department code. The second type of change are modifications to, additions, or deletions of the <subContactTelephone> and <featureGroupID> fields. A deletion of the external TN from the user, therefore, appears as a MACD change type. |MACD|20110423163455GMT|SUB|C|CompanyXYZ|NewYork| jsmith|jsmith@xyz.com|John|Thomas|Smith|Manager|Finance|99| +19198548001|~| Adding or removing a user to or from a feature group also appears as a MACD change type. The example above shows the removal of user John Smith from the feature group. 110423163455GMT|SUB|A|CompanyXYZ|NewYork| jsmith|jsmith@xyz.com|John|Thomas|Smith|Manager|Finance|99| +19198548001|Basic Features| The example above shows the addition of user John Smith back into the feature group. |
Only the new state of the entity is reported in the MACD row. Entitlement/SNR enabled/EM enabled/Licensing delta are not reported in MACD section.
This format definition describes how device and line MACD information is presented within the SI report file. Reporting MACD data for devices includes registration, assignment, and change operations for devices listed as part of sites and subscribers only. It also includes the addition, deletion, and modification of lines for those devices. In almost all cases, the device and line MACD rows are presented together. In some cases, the line MACD rows can be omitted. Line MACD rows can never be presented in standalone fashion. Service Inventory and MACD data for devices listed in Provider, Reseller, and Division, Customer, and Site inventories are not reported. Only data for registered devices under Site and Subscriber entities are reported.
|MACD|<macdEffectiveDT>|DEV|<macdCode>|<customerName>|<siteName>|<subUsername>| <deviceName>|<deviceMAC>|<phoneOrExtMobility>|<deviceTypeID>|<lineCount>| |MACD|<macdEffectiveDT>|LINE|<macdCode>|<internalTN>|<contactCenterAgentLineService>|… |MACD|<macdEffectiveDT>|LINE|<macdCode>|<internalTN>|<contactCenterAgentLineService>| |
The following are examples of different scenarios for the MACD Data Row:
A device with two lines is registered and assigned to a subscriber.
A device with two lines is unassigned and unregistered from a subscriber.
A device with two lines. Contact Center service is enabled on line 2.
A device with two lines. Contact Center service is disabled on line 1 and enabled on line 2.
A device with 0 lines is registered and assigned to a subscriber.
A device with three lines is modified. The second line is deleted.
|MACD|20110423171235GMT|DEV|A|CompanyXYZ|NewYork|~|SEP0445687B8A11|0445687B8A11|0|3|2| | MACD|20110423171235GMT|LINE|A|4761000|0| | MACD|20110423171235GMT|LINE|A|4761001|0|
Example 13-27 |MACD|20110423171235GMT|DEV|S|CompanyXYZ|NewYork|~|SEP0445687B8A11|0445687B8A11|0|3|0| |
|||
|
Example 13-27 |MACD|20110423171235GMT|DEV|U|CompanyXYZ|NewYork|jsmith|SEP0445687B8A11|0445687B8A11|0|3|~| |
|||
|
Example 13-29 |MACD|20110423171235GMT|DEV|D|333|1|~|SEP0445687B8A11|0445687B8A11|0|3|~| |
|||
|
|MACD|20110423171235GMT|DEV|S|CompanyXYZ|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|~| |MACD|20110423171235GMT|DEV|A|CompanyXYZ|NewYork|~|SEP0445687B8A11|0445687B8A11|0|3|2| |MACD|20110423171235GMT|LINE|A|4761000|0| |MACD|20110423171235GMT|LINE|A|4761001|0|
|MACD|20110423171235GMT|DEV|D|CompanyXYZ|NewYork|~|SEP0445687B8A11|0445687B8A11|0|3|~| |MACD|20110423171235GMT|DEV|U|CompanyXYZ|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|~|
Note | Line information may be omitted in this scenario. |
|MACD|20110423171235GMT|DEV|C|CompanyA|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|2| | MACD|20110423171235GMT|LINE|C|4761000|0| | MACD|20110423171235GMT|LINE|C|4761001|0|
|MACD|20110423171235GMT|DEV|C|CustomerXYZ|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|2| |MACD|20110423171235GMT|LINE|C|4761000|1| |MACD|20110423171235GMT|LINE|C|4761001|1|
Note | In this example, the second line already has Contact Center service enabled. However, due to the nature of reporting MACD operations, the new state of the entire device (and lines) is reported, which, in this example, now includes Contact Center service on both lines for the device. |
|MACD|20110423171235GMT|DEV|C|CustomerXYZ|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|2| |MACD|20110423171235GMT|LINE|C|4761000|0| |MACD|20110423171235GMT|LINE|C|4761001|1|
|MACD|20110423171235GMT|DEV|C|CustomerXYZ|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|2| | MACD|20110423171235GMT|LINE|C|4761000|0| | MACD|20110423171235GMT|LINE|C|4761001|1|
Note | A device with two lines. Contact Center service is enabled on line 1 but is already enabled on the second line. and A device with two lines. Contact Center service is enabled on line 2. represent different scenarios resulting in the generation of identical MACD rows for this device. In both cases, the new state of the device (and lines) is reported, regardless of the operation leading to that state. |
Example 13-36 |MACD|20110423171235GMT|DEV|S|CustomerXYZ|NewYork|jsmith| SEP0445687B8A11|0445687B8A11|0|3|~| |MACD|20110423171235GMT|DEV|A|CustomerXYZ|NewYork|~| SEP0445687B8A11|0445687B8A11|0|3|~| |
|||
|
|MACD|20110423171235GMT|DEV|C|CompanyXYZ|NewYork|jsmith| SEPMyNewPhoneName|0445687B8A11|0|3|1| |MACD|20110423171235GMT|LINE|A|4761002|0|
|MACD|20110423171235GMT|DEV|C|CompanyXYZ|NewYork|jsmith| SEPMyNewPhoneName|0445687B8A11|0|3|1| |MACD|20110423171235GMT|LINE|D|4761001|0|
Note |
|
|MACDEND| |
|||
|
|STATSTART| |
|||
|
|STAT|providerCount|1|~| |STAT|resellerCount|1|~| |STAT|customerCount|3|~| |STAT|siteCount|6|~| |STAT|subscriberCount|12|~| |STAT|devRegAssigned|20|~| |STAT|devRegUnassigned|20|~| |STAT|macdCount|126|~| |STAT|siRequestDT|06013011030000GMT|~| |STAT|siStartDT|06013011030800GMT|~| |STAT|siEndDT|06013011032314GMT|~| |
|||
|
The following lists the meaning of each requested statistic:
The total number of unique providers (and thus, |PROV| rows) listed in the report. |
|
The total number of unique resellers (and thus, |RESELL| rows) listed in the report. |
|
The total number of unique customers (and thus, |CUST| rows) listed in the report. |
|
The total number of unique sites (and thus, |SITE| rows) listed in the report. |
|
The total number of unique subscribers (and thus, |SUB| rows) listed in the report. |
|
The total number of unique devices that are both registered and assigned to a subscriber listed in the report. If devices are shared, this count does not accurately reflect the number of |DEV| rows present in the report. Uniqueness is required. |
|
The total number of unique devices that are registered but not assigned to a subscriber, listed in the report. This is the count of devices that are assigned to sites, such as conference room phones, lobby phones, and "empty" Cisco Extension Mobility phones. If devices are shared, this count does not accurately reflect the number of |DEV| rows that are present. Uniqueness is required. |
|
The total number of MACD rows reported in the MACD section of the file. |
The following lists the meaning of each requested Date/Time (DT) field:
The time when the SI request is received or activated by the Domain Manager. |
|
The time when the Domain Manager begins the SI process (after delays, for example). |
|
The time when the Domain Manager ends the SI process. This field should not include any file transfer times or the like. |
|STATEND| |
|||
|
The Summary Licensing Sections are added with the following licenses in the Service Inventory Report.
PLM License: It contains the information about PLM server details, cluster applications which are assigned to the PLM host, license usages such as License type, Installed licenses, Required licenses, Status of the licenses from the specific clusters.
Customer License: It contains the information about PLM server details with hierarchy of customer level, including the cluster applications which are assigned to the customers with IP Address of the cluster, Licenses type and Number of licenses used by the customer from the cluster Apps.
Site License: It contains the information about Site level licensing which includes the information of Lobby Device licenses, Subscriber licenses and license usages such as License type and License count with each hierarchy of sites.
Note | The PLM customer summary section shows only those customers who are available in the service inventory report. |
|INFOSTART| |
Note | This row is required. |
|LICENSESUMMARYSTART| |
Note | This row is required. |
This format definition describes how summary information is presented in the output files. An example of each data element is described.
Cisco Unified Communications Domain Manager 8.1(x) format: |INFO|formatVersion|9.0.1.1| |INFO|filename|20110528032329GMT+12345+CUCDM+1+1.si| |INFO|dmVerPlatform|4.1.6+0.4.47| |INFO|dmVerSoftware|7.3.0+er15| |INFO|dmHostname|nelco-cucdm4| |INFO|dmDomain|cisco.com| |INFO|dmIP|172.18.200.200| |INFO|reportStartDT|06012011000000GMT| |INFO|reportEndDT|06012011235959GMT| Cisco Unified Communications Domain Manager 10.6(1) format: |INFO|formatVersion|10.6.1| |INFO|filename|20141126132645GMT+1+CUCDM2+1+1.si| |INFO|dmVerPlatform|1.2.0-1415027768| |INFO|dmVerSoftware|1.2.0+65| |INFO|dmHostname|10.106.215.12| |INFO|dmDomain|~| |INFO|dmIP|10.106.215.12| |INFO|reportStartDT|20141126132645GMT| |INFO|reportEndDT|20141126132645GMT |
|||
2
|
|LICENSESUMMARYEND| |
Note | This row is required. |
|INFOEND| |
Note | This row is required. |
Step 1 | Generate a Microsoft Excel-Based Service Inventory Report by selecting the Generate XLS report checkbox. |
Step 2 | Download the generated report. |
Step 3 | To perform an audit of the Entitlement violations, perform the following: A popup box appears when the audit is complete. The Audit tab is added as the last sheet of the Microsoft Excel-Based Service Inventory Report. If the Audit sheet is blank, there are no entitlement violations. |
Service Inventory information can also be provided in a Microsoft Excel-based report. It is a additional provision to a text based SI report. User has a choice to select for Microsoft Excel-based report format. The Excel-based report contains the following information:
Note | Fields are left blank if they do not apply to the specific Cisco Unified Communications Domain Manager used to generate the report. |
Tab |
Description |
Correlation to regular SI Report |
||
---|---|---|---|---|
MetaData |
Click Audit on this tab to perform an audit for Entitlement violations. Audit results appear in an Audit tab. |
Information between |INFOSTART| and |INFOEND| |
||
Features |
A list of all possible features that are currently on the domain manager and their feature numbers. The feature numbers are generated at runtime, and are merely integers used for cross-referencing in the current file. There is no guarantee that feature IDs are consistent between files. |
|DEF|FEATURES| |
||
FeatureGroups |
A list of feature IDs by Feature Group Name and Customer Name. Features listed in the feature group are “assigned” and available to those subscribers who were placed in this group. A subscriber does not necessarily use these features. |
|DEF|FGROUP| |
||
DeviceDefs |
A list of devices configured for each customer. Each row includes the Customer Name, as well as the Device ID, Make, and Model. The Device ID is a value provided by the Cisco Unified Communications Domain Manager server that stores the device make and model information. |
|DEF|DEV| |
||
DeviceGroup |
A list of the configured device groups, each on a separate row. Includes the Device Group Name, ID, Make, and Model. The Device ID is a value provided by the Cisco Unified Communications Domain Manager server that stores the device make and model information. |
|DEF|DGROUP| |
||
EntitlementFeatureGroup |
Provides a row for each Entitlement Feature Group, with a list of the feature IDs that are available to the Entitlement Group. Features listed in this tab are “assigned” and available to those subscribers who were placed in this group. A subscriber does not necessarily use these features. |
|DEF|EFGROUP| |
||
EntitlementCatalog |
A list of Entitlement Feature Groups by Provider, Reseller, and Customer. Includes the maximum number of allowable devices for each Entitlement Feature Group. |
|DEF|ECATALOG| |
||
EntitlementProfile |
A list of Entitlement Profiles by Provider, Reseller, Customer, and Entitlement Catalog. Includes the maximum number of allowable devices for each Entitlement Feature Group. The maximum number of devices are limitations for an individual user, not for all users in the system. |
|DEF|EPROFILE| |
||
Providers |
A list of Providers by name |
|PROV| to |PEND| |
||
Resellers |
A list of Resellers by name, for each Provider |
|RESELL| to |REND| |
||
Customers |
A list of Customers by Reseller and Provider. Customer information includes Name, External Customer ID, Address, City, State, Country, and Postal Code. |
|CUST| to |CEND| |
||
Sites |
A list of Sites by Customer. Site information includes Name, External Site ID, Address, City, State, Country, Postal Code, and Time Zone. |
|SITE| to |SEND| |
||
Subscribers |
|
|SUB| to |SUBEND| |
||
Devices |
|
|DEV| |
||
DeviceLines |
|
|LINE| |
||
MACD |
Provides all MACD details |
Information between |MACDSTART| and |MACDEND| |
||
PLMLicense |
Provides PLM server details, as well as information about the cluster applications (for example, Cisco Emergency Responder (CER) or HCS Cisco Unity Connection (HCUC)) which are assigned to the PLM host. License Type, number of Installed licenses, number of Required and Available Licenses, and the Status of the licenses from the specific clusters is provided. |
|SUMMARY|PLMINFO| |
||
CustomerLicense |
Provides PLM server details for the Customer hierarchy node level, including the cluster applications which are assigned to the customers. IP Address of the cluster, License Type, and number of licenses used by the customer from the clusterApps is provided. |
|SUMMARY|CUSTLICENSEINFO| |
||
SiteLicense |
Provides details about site level licensing, including lobby device licenses, subscriber licenses, and license usage. The License Type is provided as well as a count of the number of licenses for each hierarchy of sites. |
|SUMMARY|SITELICENSEINFO| |
||
Audit |
A pop-up message indicates when the audit is finished, and the results are displayed in the Audit tab. If there are no violations, the Audit tab is created, but it is left blank. |
Not Applicable |
As of 9.1(1), Service Inventory can generate reports directly from Cisco Unified Communications Manager and Cisco Unity Connection application servers for customers that are provisioned in Cisco Hosted Collaboration Mediation-Fulfillment that do not have a Unified Communications Domain Manager configured. Most of the formats in the generated report are the same as the Unified Communications Domain Manager report results. However, a new MACD format report is also available specifically for a supported UC Application.
The following section shows the formats for the MACD Service Inventory Report for supported UC Applications.
Note | The <LOCATION> field is configured differently for UC Applications. Make sure you have configured the <LOCATION> correctly in your Cisco Unified Communications Manager under System > Location. This field is required for Service Inventory to generate UC Application-based reports. |
HCM-F provides a Service Inventory (SI) application that periodically queries Unified Communications Application Servers and reports their current operating state. This report provides information about modifications to Subscribers, Devices and Lines provisioned on the UC Applications Servers of the HCS system. This data is ultimately used by the service provider (SP) customer to generate or facilitate the correct generation of appropriate billing records for their end customers as part of their regular business processes.
This section outlines the layout and format of data points in the Cisco Service Inventory MACD output file. The MACD file is organized by Customer with some additional processing information included where necessary. The following sections give an overview of the format, a description of the file layout, a listing of the various row formats and data types contained in the output file, and finally, examples of Cisco Service Inventory MACD output file.
The Cisco SI Common MACD Format is designed to present all Subscriber MACD data in a human-readable format while keeping output file size to a minimum. The format is an ASCII-based file, with the “.simacd” file extension.
The output is arranged into the following sections:
Report Information
Customer Data
Subscriber MACD Data
Subscriber Total Count
UC Application, Subscriber, Device, Line, and Feature MACD data
Subscriber MACD data will be represented as a row indicating the new state of whatever entity is currently being added, changed, or deleted. Unlike a change notification, which would show a “before” and “after” state of the entity, the MACD representation only shows the “after” state.
|FILESTART| |INFOSTART| |<FORMAT-VERSION>|<REPORT_CREATION_TIME>| |INFOEND| |CUST| |<CUSTOMER_NAME>|<APP1_TYPE>|<APP1_VERSION>|<APP_1HOSTNAME>|<APP2_TYPE>| <APP2_VERSION>|<APP2_HOSTNAME> |...| <APP(N)_TYPE>|<APP(N)_VERSION>|<APP(N)_HOSTNAME>| |MACDSTART| |SUB-TOT|<COUNT>| |SUB|<MACDCODE>|<CUCM_IP>|<CUC_IP>|<SUB_USERNAME>| <SUB_UUID>|<SUB_FIRSTNAME>|<SUB_LASTNAME>|<SUB_EMAIL>| <PRIMARY_TN>|<PRIMARY_EXTENSION>|<CUC_VM_EXTENSION>|<CUC_BILLING_ID>| <VOICE_FEATURE>|<VM_FEATURE>| <PRESENCE_FEATURE>|<CUEAC_FEATURE>|DEV|<DEVICE_NAME>|<DEVICE_TYPE>| <DEVICE_MODEL>|<LOCATION> |<EXT_MOBILITY>|LINE|<DIRECTORY_NUMBER>|<EXTERNAL_NUM_MASK>|LINE(N) |…| LINE_END(N)|DEV_END|DEV(N) |…| DEV_END(N)|SUB_END| |MACDEND| |CUSTEND| |CUST(N)| |CUSTEND(N)| |FILEEND| |
The format of the Service Inventory MACD filename is critical to the proper operation of the SI applications. The following parameters apply to filenames in this format:
The filename follows this format:
<date><time><timezone> .<extension>
SI MACD File
20130111015000GMT.simacdThis MACD file naming convention is for a single file output that contains all Customers and their respective Subscriber MACD data.
Some additional general format specifications include the following:
Data elements in the file will be stored in text, integer, and standard date/time formats where appropriate.
The standard end-of-line character “\n,” while typically not visible in common text-editing applications, will be used and is available for parsing programs to use for line tokenization.
The data element delimiter will be the PIPE symbol “|”. Each line will start and end with a PIPE symbol, with a PIPE symbol between each data point on the line as well.
The PIPE symbol “|” is not a valid character within fields in the format.
An empty (null) field will be represented by a TILDE symbol “~”. Empty fields/columns will not be skipped.
Report Data Collection Failures will be noted in the Customer Data Row. At a minimum the failed Customer Name will be appended with an asterisk “*” and if available the failed UC Application(s) will also will be appended with an asterisk “*”. See the Customer Data Row Definition Section for example.
This section outlines the data formats that are used throughout the row formats. Deviation from these global formats is not permitted in the scope of this SI Common Format definition.
This format definition describes the way in which Date/Time elements are represented in information rows. All dates/times are represented in Greenwich Mean Time. All times are represented in 24-hour format. No separate definition row is required in the file to describe the date elements.
The following describes the characters that are used to construct the format:
|20110423163455GMT| |
This section outlines the various row formats used in the Cisco SI Common MACD Format. Each type specification provides a format definition and an example usage.
File Header is the first line of each output file.
|FSTART| |
Note | This row is required. |
File Footer is the last line of each output file.
|FEND| |
Note | This row is required. |
|INFOSTART| |
Note | This row is required. |
This format definition describes the manner in which summary information is presented in the output files. An example of each data element is described below.
|9.1.1.1|20130108225300GMT| |
|||
|
|INFOEND| |
Note | This row is required. |
|CUST| |
Note | This row is required. |
|<customer_name>|<app_type>|<app_version>| <app_hostname>| <app2_type>|<app2_version>| <app2_hostname>|... |<app(N)_type>|<app(N)_version>| <app(N)_hostname>| |
|Customer2|CUCM|VERSION_8_6|10.81.120.27| |Customer5|CUCM|VERSION_8_6|CUCM-5| |Customer4*|CUCM|VERSION_8_6|10.81.120.29|CUC|VERSION_8_6|si911cxnpub-1|
|Customer6*|CUCM|VERSION_8_6|~*|
|
||||
|
|CEND| |
Note | This row is required row if a |CUST| data row exists. |
|MACDSTART| |
Note | This row is required. |
| SUB-TOT |6| |
|||
|
This format definition describes the way in which MACD Code elements will be represented in all Subscriber MACD rows. There is no separate definition row required in the file to describe the MACD Code elements.
MACD operations are reported at the Subscriber level only. Changes to Devices and Lines, including adding and deleting Devices and Lines are reported as a Change (‘C’) in the Subscriber MACD Row.
The following list describes the characters used to construct the format:
|<macdcode>| |
|A| |D| |C| |
||
|
This format definition describes the general layout of all MACD rows in the report. Certain fields described below are required of each MACD row, regardless of type, while individual differences are highlighted in the definition for each type later.
Format
|SUB|<MACDCODE>|<CUCM_IP>|<CUC_IP>|<SUB_USERNAME>|<SUB_UUID>|<SUB_FIRSTNAME>|<SUB_LASTNAME>|<SUB_EMAIL>|
<PRIMARY_TN>|<PRIMARY_EXTENSION>|<CUC_VM_EXTENSION>|<CUC_BILLING_ID>|<VOICE_FEATURE>|<VM_FEATURE>|
<PRESENCE_FEATURE>|<CUEAC_FEATURE>|DEV|<DEVICE_NAME>|<DEVICE_TYPE>|<DEVICE_MODEL>|<LOCATION>|
<EXT_MOBILITY>|LINE|<DIRECTORY_NUMBER>|<EXTERNAL_NUM_MASK>|LINE(N)|…|LINE_END(N)|DEV_END|DEV(N)|
…
|DEV_END(N)|SUB_END|
The above fields are populated with the value retrieved from the provisioned Unified Communications Manager and Cisco Unity Connection UC Application servers. If a value for a field is not provisioned on the UC Application Servers or is not available for the type of Subscriber, then a ‘~’ appears in the field of the SUB MACD row. In this case, where a field value is available on both the Unified Communications Manager and Cisco Unity Connection, the Unified Communications Manager value is always be used. The Cisco Unity Connection value is only be used if Unified Communications Manager value are not available for that subscriber, for example voice mail only user.
The <CUCM_IP> and <CUC_IP> fields are populated with the UC Application Server’s HCM-F provisioned IP address or the Hostname where Subscriber data is retrieved.
The <SUB_UUID> field for a Voice Mail Only user is the equivalent Cisco Unity Connection Object ID field that is defined in the Cisco Unity Connection Rest API. If the user has both Unified Communications Manager and Cisco Unity Connection features enabled, then this SUB_UUID field is populated with the Unified Communications Manager UUID and the Cisco Unity Connection Object ID is ignored.
The <SUB_USERNAME>, <SUB_FIRSTNAME> and <SUB_LASTNAME> fields are populated with the Unified Communications Manager End User’s “User ID”, “First name” and “Last name” unless the Subscriber is a Voice Mail Only User. In that case, the fields are populated with the Cisco Unity Connection User’s “Alias”, “First Name” and “Last Name" fields.
The <SUB_EMAIL> is populated with Unified Communications Manager “Email ID” field. For a Voice Mail Only User, the <SUB_EMAIL> field is populated with the Cisco Unity Connection “Corporate Email Address” field.
The <PRIMARY_TN> field is populated from the Unified Communications Manager End User “Telephone Number” field. If the Subscriber is a Voice Mail Only User, then the “Extension” field of the Cisco Unity Connection User is used.
The <PRIMARY_EXTENSION> field is populated from the “Directory Number” of the Unified Communications Manager End User’s first LINE of the first DEVICE.
The <VOICE_FEATURE> field is populated with a ‘1’ is the Subscriber is provisioned on a Unified Communications Manager
The <PRESENCE_FEATURE> field is populated with the Unified Communications Manager End User’s provisioned “Primary Extension” field and typically populated with 0/1.
The <VM_FEATURE> field is populated from the Cisco Unity Connection User’s provisioned “Class of Service”. If the COS indicates that the User is enrolled in Voice Mail, then the field is set with 1. Otherwise, this field is set to ‘~’.
The Subscriber <CUC_BILLING_ID> and <CUC_VM_EXTENSION> Fields are only be populated if the <VM_FEATURE> field is 1, and is filled with a ~ in the event that the <VM_FEATURE> is set to ‘0’ or ‘~’.
The Subscriber field <CUEAC_FEATURE> is always filled with a ‘ ~’ as the field is unobtainable with the current UC Application API's available.
All <DEVICE> and <LINE> field data is only available from Unified Communications Manager.
The <DEVICE_NAME> and <DEVICE_MODEL> fields are populated from the “MAC Address” and the “Product Type” of the Unified Communications Manager Device. The <DEVICE_TYPE> field is populated from the Unified Communications Manager API and is set to “Phone” for all Phone Device Types.
The <LOCATION> field is populated with the device’s provisioned location name. The device’s location name is set using the Unified Communications Manager "System->Location" configuration page
The Device’s < EXT_MOBILITY> field is set using the Unified Communications Manager’s “Enable Extension Mobility” check box of the Unified Communications Manager device.
The < EXTERNAL_NUM_MASK > field is populated using the “External Phone Number Mask” of the Line of the Unified Communications Manager Device.
Below are examples of a Subscriber MACD Add records.
An Add record is seen when a new End User is provisioned on CUCM or CUCxN since the last success report or if this is a Day Zero Report.
|SUB|A|10.81.120.27|~|userA|{4BFD972A-F280-B694-E616-E4FBD7060711}|sitest|userA|userA| ~|v1501merpart1|~|~|1|~|1|~|DEV|SEP111111A01016|Phone|Cisco|7970|Hub_None|1|LINE|801016|~|LINE_END| DEV_END|SUB_END|
|SUB|A|~|108.2.5.25|user09000|3722c735-a696-4efb-9c7d-91b0e9ae5e07| 09000_first_changed0110|09000_last_changed0110|9000@yutu.com.changed0110|809000|~|809000|user09000billing |~|1|~|~|DEV|LINE|LINE_END|DEV_END|SUB_END|
A lobby phone has more than 0 lines and is not associated to any end user. The Change indicates that a DEVICE or LINE or some other Device or Line field was Added, Deleted or Changed. The Lobby Phone Subscriber has a list of Devices Per Customer. The Lobby Phone Subscriber is Add when the “Day Zero Report” is generated.
|SUB|A|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|DEV|SEP111111A09006|Phone|Cisco 7970|Hub_None|0|LINE|809006|~|LINE_END| LINE|29006|~|LINE_END|DEV_END|DEV|SEP111111A09008|Phone|Cisco 7970|Hub_None|0|LINE|809008|~|LINE_END|LINE|29008|~| LINE_END|LINE|39008|~|LINE_END|DEV_END|DEV|SEP111111A09013|Phone|Cisco 7970|Hub_None|0|LINE|809013|~|LINE_END|DEV_END| DEV|SEP999999999999|Phone|Cisco E20|Hub_None|0|LINE|999999999|~|LINE_END|DEV_END|DEV|SEP111111A08001|Phone|Cisco 7970| Hub_None|0|LINE|808001|~|LINE_END|LINE|7777|~|LINE_END|LINE|28001|~|LINE_END|DEV_END|DEV|SEP111111A08002 |Phone|Cisco 7970|Hub_None|0|LINE|808002|~|LINE_END|DEV_END|DEV|SEP111111A08003|Phone|Cisco 7970|Hub_None|0|LINE| 808003|~|LINE_END|DEV_END|DEV|SEP111111A08011|Phone|Cisco 7970|Hub_None|0|LINE|808011|~|LINE_END|DEV_END|DEV| SEP111111A08012|Phone|Cisco 7970|Hub_None|0|LINE|808012|~|LINE_END|DEV_END|DEV|SEP111111A08013|Phone|Cisco 7970| Hub_None|0|LINE|808013|~|LINE_END|DEV_END|DEV|SEP123412341234|Phone|Cisco TelePresence|v1501mer_loc1_50k|0|LINE|1234 |~|LINE_END|LINE|8888|~|LINE_END|DEV_END|DEV|SEP444444444444|Phone|Cisco Cius|v1501mer_loc3_160k|0|LINE|4444 |~|LINE_END|DEV_END|DEV|SEP555555555555|Phone|Cisco 7975|Hub_None|0|LINE|5555|~|LINE_END|DEV_END|DEV| SEP999999999999|Phone|Cisco E20|Hub_None|0|LINE|999999999|~|LINE_END|DEV_END|SUB_END|
|SUB|C|~|~|~|~|~|~|~|~|~|~|~|~|~|~|~|DEV|SEP5679650A2502|Phone|Cisco 7970|Hub_None|0|LINE|2502|~| LINE_END|DEV_END|DEV|SEP5679650A2503|Phone|Cisco 7970|Hub_None|0|LINE|2503|~|LINE_END|DEV_END|DEV |SEP111111A01000|Phone|Cisco 7970|Hub_None|0|LINE|801000|~|LINE_END|DEV_END|DEV| SEP5679650A2201|Phone|Cisco 7970|Hub_None|0|LINE|23423510101|~|LINE_END|DEV_END|SUB_END|
Below are examples of a Subscriber MACD Delete records.
|SUB|D|108.2.5.23|~|test111|{1297144E-C445-ED64-3679-A1F103F949B1} |cucm111|cucm111_changed|cucm111@cisco.com|cucm_TN_111|~|~|~|1|~|1|~|DEV|LINE|LINE_END|DEV_END|SUB_END|
|SUB|D|~|108.2.6.13|user08013|538cb999-d224-4432-bfad-ddfe4e39e94f|sitest|user08013 |~|808013|~|808013|~|~|1|~|~|DEV|LINE|LINE_END|DEV_END|SUB_END|
Below are examples of a Subscriber MACD Change records.
|SUB|C|108.2.6.11|108.2.6.13|user08005|{0AE9953B-37EF-54AE-B930-454E6553DFD0}| sitest|user08005_chanagedforES|~|808005|v1501mer-part1|808005|~|1|1|1|~|DEV|SEP111111A08005 |Phone|Cisco 7970|Hub_None|0|LINE|808005|~|LINE_END|DEV_END|SUB_END|
|SUB|A|10.81.120.27|~|userA|{4BFD972A-F280-B694-E616-E4FBD7060711}|sitest|userA|userA| ~|v1501merpart1|~|~|1|~|1|~|DEV|SEP111111A01016|Phone|Cisco|7970|Hub_None|1|LINE|801016|~|LINE_END| DEV_END|SUB_END|
|MACDEND| |
|||
|