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.
Cisco HCM-F provides the Service Inventory application to periodically query the Cisco Unified Communications Domain Manager server and report the current operating state of the underlying Unified Communications applications. It provides information about customers, subscribers, devices, and other details that are currently provisioned in Cisco HCS. This data is ultimately used by the service provider (SP) customer to generate appropriate billing records for end customers as part of a regular business processes.
To address the many and disparate requirements of various SP customers, a common SI file format is required. This chapter specifies Version 8.6(2) of a "Cisco Service Inventory Common Format" designed to contain and report all appropriate service fulfillment data currently provisioned in Cisco HCS. This common format is not specifically designed to meet any single Cisco HCS customer's requirements. The format helps you address the collective needs of multiple SP customers. During deployment, the SP has the option of accepting the output of the SI process in the Cisco SI Common Format as presented, or engaging with Cisco Advanced Services organization for the development of technologies to translate the Cisco SI Common Format into a custom output.
This chapter outlines the requirements for the Service Inventory Common Format, the data contained within the output files, and finally, the formal specification of the format and data types.
Note This chapter describes the format of the final output files but does not describe how data is collected by the Service Inventory application.
This chapter contains information on the following topics:
•Example Service Inventory File
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" section 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:
•Filename
•Domain Manager Hostname
•Domain Manager IP Address
•Reporting Period Start Date/Time (reporting period)
•Reporting Period End Date/Time (reporting period)
The following data points are included in the Report Statistical Information:
•Total Provider Count
•Total Reseller Count
•Total Customer Count
•Total Site Count
•Total Subscriber Count
•Total Unassigned Device Count
•Total MACD Row Count
The following data points are found in the Service Inventory Report Data:
•Customer Information
–Name
–Address
–Contact Information
–Additional Details
•Customer Details
–Customer Device Information
–Device Make
–Device Model
–Site Information
–Customer Name
–Site Name
–Site Address
–Additional Details
•Subscriber Information
–Customer Name
–Site Name
–Subscriber Username
–<Additional Details>
•Subscriber Feature Information
–Customer Name
–Feature Name/Identifier
–Feature State Details
•Device/Line Information
–Device identifiers, Device MAC addresses
–Device Line Associations
•Move/Add/Change/Delete (MACD) Information
–Reseller MACD Events
–Customer MACD Events
–Site MACD Events
–Subscriber MACD Events
–Feature Group MACD Events
–Device MACD Events
–Line MACD Events
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 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 SI 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 delivered by the CUCDM 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 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:
•Report Summary Information
•Report Definition Information
•Service Inventory Data
–Provider Data > Reseller Data > Customer Data > Site Data > Subscriber Data (+Subscriber Feature Data, +Subscriber Device Data)
•MACD Data
–Reseller, Customer, Site, Subscriber, Device, Line, and Feature Group MACD Data
•Report Statistical Information
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 shows fully in and in most cases precisely the information being deleted. This information may differ depending on the Domain Manager and the use case. Where necessary, the parsing applications must interpret intermediate states based on the combination of static service inventory data and MACD data.
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>+<fileCou nt>.<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.
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 (*) at the end. This notation is not applied to Report Summary or Report Definition rows. See "Data Accuracy Handling" section for more information.
•All MACD rows in the file are listed in the MACD section defined by the starting tag |MACDSTART| and by the closing tag |MACDEND|. (See "MACD Row Format" section for more information.)
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|1011|333|236|XYZ, Inc.|~| ~*|~*|~*|~*|~*|~*|~*|
Note The * after the ~ in the preceding example indicates that the fields are empty but are shown as empty because the actual values for the data field in question cannot be provided for some reason. See "Customer Data Row" section for an explanation of fields.
If an entire row is known to be inaccurate, place the asterisk at the end of the row outside the final pipe symbol.
|DEF|FGROUP|CompanyXYZ|27|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. See "Report Definition Row" section for an explanation of the feature group definition row fields.
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.
|
|
---|---|
|<internalTN>| |
|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.
|
|
---|---|
|+<countryCode><areaCode><localNumber>| |
|+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.
|
|
---|---|
|<deviceName>|<16DigitHexMACAddress>| |
|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:
•yyyy = Year
•MM = Month
•dd = Day
•HH = Hours
•mm = Minutes
•ss = Seconds
•z = Time Zone
|
|
---|---|
|<yyyyMMddHHmmssz>| |
|20110423163455GMT| |
This format describes the representation of a Time Zone throughout the report. The Time Zone format is <"Region/City">.
|
|
---|---|
|<timeZone>| |
|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| |
|FSTART| |
Note This is a required row.
File Footer is the last line of each output file.
|
|
---|---|
|FEND| |
|FEND| |
Note This is a required row.
|
|
---|---|
|INFOSTART| |
|INFOSTART| |
Note This is a required row.
This format definition describes how summary information is presented in the output files. An example of each data element is described.
|
|
---|---|
|INFOEND| |
|INFOEND| |
Note This is a required row.
|
|
---|---|
|DEFSTART| |
|DEFSTART| |
Note This is a required row.
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|<definitionName>|{additional column definitions here}| |
|
|
---|---|
|DEF|DEV|<customerName>|<device[1]ID>|<device[1]Make>|<device[1]Model>|...|<device[N]ID>|<device[N]Make>|<device[N]Model>| |
|DEF|DEV|CompanyXYZ|1|Cisco|7960|2|Cisco|7965|3|Cisco|Cius_ V1|4|Avaya|Phone1000|5|Apple|iPhone 3GS|11|Cisco|CUPC8| |
Note •The <deviceID> field is used to cross-reference the device make and model information in the Device Data Row for a particular device assigned to a subscriber. •The device ID is a value provided by the CUCDM server that stores the device make and model information. •Soft clients and Mobile devices are reported in this row. •All fields are required. |
|
|
---|---|
|DEFEND| |
|DEFEND| |
This is another way
Note This is a required row.
|
|
---|---|
|SISTART| |
|SISTART| |
Note This is a required row.
.
|
|
---|---|
|PROV|<providerID>|<providerName>| |
|PROV|-1|Verizon| |
Note All fields are required in this row.
Note The <providerID> field is always "-1".
|
|
---|---|
|PEND| |
|PEND| |
Note This is a required row if a |PROV| data row exists.
|
|
---|---|
|RESELL|<providerID>|<resellerID>|<resellerName>| |
|RESELL|-1|-1|ResellerXYZ| |
Note All fields are required in this row.
|
|
---|---|
|REND| |
|REND| |
Note This is a required row if a |RESELL| data row exists.
The <customerCountry> is 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.
|
|
---|---|
|CEND| |
|CEND| |
Note This is a 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 •See the "Time Zone Element" section for proper representation of the <cityTimezone> field for the site/location. •All fields are required in this row. |
|
|
---|---|
|SEND| |
|SEND| |
Note This is a required row if a |SITE| data row exists.
This section describes the format of the Subscriber Data Row.
|
|
---|---|
|SUBEND| |
|SUBEND| |
Note This is a required row if a |SUB| data row exists.
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.
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).
|
|
---|---|
|SIEND| |
|SIEND| |
Note This is a required row.
|
|
---|---|
|MACDSTART| |
|MACDSTART| |
Note This is a required row.
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|...| |
Note •The fields are required for ALL MACD rows, regardless of type. •In the format and examples, the <macdCategory> field always matches the row type name of the corresponding type to the change. •The <macdEffectiveDT> field represents the effective date/time of the MACD event. The format of this element should follow the "Date/Time Element" section format. |
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 = Moved
•A = Entity is Added
•D = Entity is Deleted
•C = Entity is Changed
|
|
---|---|
|<macdCode>| |
|M| |A| |D| |C| |
Note 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)" section. |
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
|
|
---|---|
|<macdCode>| |
|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.
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.
This format definition describes how customer MACD information is presented within the SI report file.
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.
This format definition describes how subscriber MACD information is presented within the SI report file.
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.
The following are examples of different scenarios for the MACD Data Row.
•A device with two internal TNs is registered to a site.
•A device with two lines is unregistered from a site.
•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 two lines is modified. A third line is added.
•A device with three lines is modified. The second line is deleted.
|
|
---|---|
Example 13-26 |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| |
|
Note Line information is omitted in this scenario if it has not changed. |
|
|
---|---|
Example 13-28 |MACD|20110423171235GMT|DEV|U|CompanyXYZ|NewYork|jsmith|SEP0445687B8A11|0445687B8A11|0 |3|~| |
|
Note Line information is omitted in this scenario if it has not changed. |
|
|
---|---|
Example 13-29 |MACD|20110423171235GMT|DEV|D|333|1|~|SEP0445687B8A11|0445687B8A11|0|3|~| |
|
Note Line information is omitted in this scenario. |
|
|
---|---|
Example 13-32 |MACD|20110423171235GMT|DEV|C|Citibank|NewYork|jsmith|SEP0445687B8A11|0445687B8A11|0|3 |2| | MACD|20110423171235GMT|LINE|C|4761000|0| | MACD|20110423171235GMT|LINE|C|4761001|0|
|
|
|
---|---|
Example 13-34 |MACD|20110423171235GMT|DEV|C|Citibank|NewYork|jsmith|SEP0445687B8A11|0445687B8A11|0|3 |2| |MACD|20110423171235GMT|LINE|C|4761000|0| |MACD|20110423171235GMT|LINE|C|4761001|1|
|
|
|
---|---|
Example 13-37 |MACD|20110423171235GMT|DEV|C|CompanyXYZ|NewYork|jsmith|SEPMyNewPhoneName|0445687B8A11 |0|3|1| |MACD|20110423171235GMT|LINE|A|4761002|0| |
|
|
---|---|
Example 13-38 |MACD|20110423171235GMT|DEV|C|CompanyXYZ|NewYork|jsmith|SEPMyNewPhoneName|0445687B8A11 |0|3|1| |MACD|20110423171235GMT|LINE|D|4761001|0| |
Note•The examples describe several scenarios that may occur in the registration and assignment of devices to both sites and subscribers. If a device is registered with lines, the line MACD row is reported with the device MACD row. If a device is already registered and later assigned, the line MACD rows are not reported because those have not changed.
•The only supported change to a device for Service Inventory purposes is the modification of the <lineCount> field. Modifications to the <lineCount> field, however, is the result of additions or deletions of lines, and those corresponding line MACD rows must immediately follow this device MACD row.
•Modify various device and line settings on the CUCDM application for a device that do not affect the billing record. Such changes, however, still result in the generation of a MACD row for the device (with optional line MACD rows). You cannot capture the nature of the change and indicate whether the MACD row in question has or has not affected the billing record. Similar to MACD rows for other entities, the Device (& Line) MACD rows simply report the state of the device (and lines) following the change operation in question.
•To modify user assignment of a device, the device must be unassociated with a user, then associated with another user.
•You can also modify the site assignment. If the device is associated with a user it must be unassociated with that user. Then it must be unregistered from the site, then reregistered under another site.
•If multiple devices are added, changed, or deleted at the same time, these are reported on separate MACD row.
•Soft client and mobile device MACDs are reported the same way as traditional devices.
•Device MACD rows use the <lineCount> field to identify the number of |LINE| MACD records that immediately follow the |DEV| MACD record in the report. This number is NOT the total count of lines that are assigned to the device at the time of the MACD operation. Be aware of this notation when you use parsing applications. For device changes that result in zero line changes, the <lineCount> field is a tilde (~).
|
|
---|---|
|MACDEND| |
|MACDEND| |
Note This is a required row. |
|
|
---|---|
|STATSTART| |
|STATSTART| |
Note This is a required row. |
The following lists the meaning of each requested statistic:
The following lists the meaning of each requested Date/Time (DT) field:
|
|
---|---|
|STATEND| |
|STATEND| |
Note This is a required row. |
This section provides example output files following the format specifications provided throughout this document. Example 13-39 shows an example output file for an SI reporting period resulting in a data set that fits in a single file.
Example 13-39 Single File Inventory Report
|FSTART|
|INFOSTART|
|INFO|formatVersion|8.6.2|
|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|
|INFOEND|
|DEFSTART|
|DEF|COUNTRY|15|United States|USA|16|United Kingdom|UK|
|DEF|FEATURES|10|Voice|11|Voicemail|19|CallForwarding|33|ExtMobility|53|Presence|9 9|Conferencing|
|DEF|FGROUP|XYZ, Inc.|27|Basic Feature Group|10|11|
|DEF|FGROUP|SmartTech|29|Advanced Feature Group|10|11|19|33|99|
|DEF|FGROUP|ComputerCo|233|Engineering Dept Feature Group|10|11|19|33|53|
|DEF|DEV| XYZ, Inc.|1|Cisco|7960|2|Cisco|7965|3|Cisco|Cius_V1|4|Avaya|Phone1000|
|DEF|DEV|SmartTech|1|Cisco|7960|2|Cisco|7965|3|Cisco|Cius_V1|4|Avaya|Phone1000|5|A pple|iPhone 3GS|
|DEF|DEV|ComputerCo|1|Cisco|7960|3|Cisco|Cius_V1|5|Apple|iPhone 3GS|11|Cisco|CUPC8|
|DEFEND|
|SISTART|
|PROV|-1|Verizon|
|RESELL|-1|-1|ResellerXYZ|
|REND|
|RESELL|-1|-1|MidWestCom|
|CUST|-1|-1|-1|XYZ, Inc.|~|7600 RTP Road|~|~|Cary|NC|15|27513|
|SITE|-1|-1|RTP|~|7600 RTP Road|~|~|Cary|NC|15|27513|EST|
|DEV|-1|-1|~|SEP0445687BDDDD|0|003|1|
|LINE|8548111|+19198548111|0|
|SUB|-1|-1|-1|jsmith|jsmith@xyz.com|John|Thomas|Smith|Manager|Finance|99|+19198548 001|Basic Feature Group|
|DEV|-1|-1|-1|SEP0445687B8AAF|0|003|1|
|LINE|8548001|+19198548001|0|
|DEV|-1|-1|-1|SEP95AAEEFF3456|0|001|2|
|LINE|98548002|+19198548002|0|
|LINE|8548003|+19198548003|1|+19198548004|
|SUBEND|
|SUB|-1|-1|-1|jdoe|jdoe@xyz.com|Jane|Mary|Doe|SeniorAccountant|Finance|99|+1919854 8005|Basic Feature Group|
|DEV|-1|-1|-1|SEPAAAABBBBCCCC|001|1|
|LINE|98548002|+19198548002|0|
|SUBEND|
|SEND|
|SITE|-1|-1|New York|~|100 Broadway Ave|~|~|New York|NY|15|10101|EST|
|SUB|...
|DEV|...
|LINE|...
|SUBEND|
|SEND|
|SITE|...
|SEND|
|CEND|
|CUST|-1|-1|-1|ComputerCo|~|8000 RTP Road|~|~|Cary|NC|15|27513|
|SITE|...
|SUB|...
|DEV|...
|LINE|...
|SUBEND|
|SEND|
...
|CEND|
|CUST|...
|SITE|...
...
|SEND|
...
|CEND|
...
|REND|
|PEND|
|SIEND|
|MACDSTART|
|MACD|20110423163455GMT|C|SITE|XYZ, Inc.|New York|74536577456|
|MACD|20110423163455GMT|C|RESELL|111|ResellerXYZ|
|MACD|20110423171235GMT|DEV|C|TechCo|RTP|jsmith|SEPNewPhoneName|0445687B8A11|0|3|1 |
|MACD|20110423171235GMT|LINE|D|4761002|1|+19194761002|
|MACD|...
...
|MACDEND|
|STATSTART|
|STAT|providerCount|1|~|
|STAT|resellerCount|2|~|
|STAT|customerCount|3|~|
|STAT|siteCount|6|~|
|STAT|subscriberCount|12|~|
|STAT|macdCount|126|~|
|STAT|devRegUnassigned|344|~|
|STAT|devRegAssigned|5235|~|
|STAT|siRequestDT|06013011030000GMT|~|
|STAT|siStartDT|06013011030800GMT|~|
|STAT|siEndDT|06013011032314GMT|~|
|STATEND|
|FEND|