When you subscribe a destination profile to either the Configuration or the Inventory alert group, you can choose to receive the alert group messages asynchronously or periodically at a specified time. The sending period can be one of the following:

• Daily—Specify the time of day to send, using an hour:minute format hh:mm, with a 24-hour clock (for example, 14:30).
• Weekly—Specify the day of the week and time of day in the format day hh:mm, where the day of the week is spelled out (for example, monday).
• Monthly—Specify the numeric date, from 1 to 31, and the time of day, in the format date hh:mm.

When you subscribe a destination profile to the Environment or Syslog alert group, you can set a threshold for the sending of alert group messages based on the message’s level of severity. Any message with a severity lower than the specified threshold of the destination profile is not sent to the destination.

Note	When syslog level is changed via IOS CLI, the new value is propagated to non-IOS processes as well, with the result that these processes no longer send syslog messages of lower priority to IOS to process, thus "saving" CPU cycles for IOS.

The table below lists the keywords used to configure the severity, which range from catastrophic (level 9, highest level of urgency) to debugging (level 0, lowest level of urgency). If no severity threshold is configured, the default is debugging (level 0). However, the default is not recommended due to the number of messages that will be triggered.

Note	Call Home severity levels are not the same as system message logging severity levels.

1.    configure terminal


2.    call-home


3.    [no | default ] alert-group-config snapshot

4.    [no | default ] add-command command string

5.    end

Device# configure terminal

Device(config)# call-home

Device(cfg-call-home)# alert-group-config snapshot

Device(cfg-call-home-snapshot)# add-command "show version"

Device(cfg-call-home-snapshot)# exit

1.    configure terminal


2.    call-home


3.    mail-server {ipv4-address | name} priority number

4.    sender from email-address


5.    sender reply-to email-address


6.    source-interface interface-name


7.    source-ip-address ipv4/ipv6 address


8.    vrfvrf-name

Device# configure terminal

Device(config)# call-home

Device(cfg-call-home)# mail-server stmp.example.com priority 1

Device(cfg-call-home)# sender from username@example.com

Device(cfg-call-home)# sender reply-to username@example.com

Device(cfg-call-home)# source-interface loopback1

Device(cfg-call-home)# ip-address 209.165.200.226

Device(cfg-call-home)# vrf vpn1 

1.    configure terminal


2.    call-home


3.    rate-limit number

Device# configure terminal

Device(config)# call-home

Device(cfg-call-home)# rate-limit 40

1.    configure terminal


2.    call-home


3.    http-proxy {ipv4-address | ipv6-address name} name

Device# configure terminal

Device(config)# call-home

Device(config)# http-proxy 1.1.1.1 port 1 

1.    configure terminal


2.    call-home


3.    aaa-authorization


4.    aaa-authorization [username username]

Device# configure terminal

Device(config)# call-home

Device(cfg-call-home)# aaa-authorization

Device(cfg-call-home)# aaa-authorization username username

1.    configure terminal


2.    call-home


3.    [no] syslog-throttling

Device# configure terminal

Device(config)# call-home

Device(cfg-call-home)# syslog-throttling

1.    configure terminal


2.    call-home


3.    data-privacy {level {normal | high} | hostname}

Device# configure terminal

Device(config)# call-home

Device(cfg-call-home)# data-privacy level high

1.    configure terminal


2.    call-home

3.    profile name


4.    active


5.    no active

6.    end

Router# configure terminal

Router(config)# call-home

Router(config-call-home)# profile test 

Router(cfg-call-home-profile)# active

Router(cfg-call-home-profile)# no active

Router(cfg-call-home)# end

1.    configure terminal


2.    call-home


3.    rename profile source-profile target-profile

Router# configure terminal

Router(config)# call-home

Router(cfg-call-home)# rename profile2 testprofile

The CiscoTAC-1 profile is automatically configured in the Call Home feature for your use with the Cisco Smart Call Home service. This profile includes certain information, such as the destination e-mail address and HTTPS URL, and default alert groups for communication with the Smart Call Home service. Some of these attributes, such as the destination e-mail address, HTTPS URL, and message format cannot be modified.

You can use either email or http transport to communicate with the Smart Call Home service backend server. By default, the CiscoTAC-1 profile is inactive and uses email as the default transport method. To use email transport, you only need to enable the profile. However, to use this profile with the Cisco Smart Call Home service secure server (via HTTPS), you not only must enable the profile, but you must also change the transport method to HTTP as shown in the following example:

Router# configure terminal
Router(config)# call-home
Router(config-call-home)# profile CiscoTAC-1
Router(cfg-call-home-profile)# destination transport-method http
Router(cfg-call-home-profile)# active

For more information about additional requirements for Configuring the Smart Call Home service, see the How To Configure Call Home to Support the Smart Call Home Service section.

To verify the profile configuration for Call Home, use the show call-home profile command. See Displaying Call Home Configuration Information for more information and examples.

The following example shows a request for analysis of a user-specified show command:

Router# call-home request output-analysis "show diag" profile TG

The following example shows how to send the output of a CLI command to a user-specified email address:

Device# call-home send "show diag" email support@example.com

The following example shows the command output sent in long-text format to attach@cisco.com, with the SR number specified:

Device# call-home send "show version"; "show run tac-service-request 123456

The following example shows the command output sent in XML message format to callhome@cisco.com:

Device# call-home send "show diag" email callhome@example.com msg-format xml

Diagnostic signatures (DS) subsystem is introduced within the call-home system to provide a flexible framework that allows the defining of new events and corresponding CLIs that can analyze these events without upgrading the Cisco software.

DS provides you the ability to define more types of events and trigger types to perform the required actions than the Call-Home feature. The DS subsystem downloads and processes files on a device as well as handles callbacks for diagnostic signature events.

The Diagnostic signature feature downloads digitally signed signatures that are in the form of files to devices. DS files are formatted files that collate the knowledge of diagnostic events and provide methods to troubleshoot these events.

DS files contain XML data to specify the event description, and these files include a CLI to perform required actions. These files are digitally signed by Cisco or a third party to certify its integrity, reliability, and security.

The structure of a DS file can be one of the following formats:

• Metadata-based simple signature that specifies event type and contains other information that can be used to match the event, perform actions such as collecting information by using the CLI or resetting the line card in the device if there is an event match.

• Embedded Event Manager (EEM) Tool Command Language (Tcl) script-based signature that specifies new events in the event register line and additional action in the Tcl script.

• Combination of both the formats mentioned above.

The following basic information is contained in a DS file:

• ID (unique string)—unique key that represents a DS file that can be used to search a DS.

• Name (ShortDescription)—unique description of the DS file that can be used in lists for selection.

• Description—long description about the signature.

• Revision—version number, which increments when the DS content is updated.

• ProductFamily

  • OsVersion (multiple values)—a list of operating system versions for each product family.

  • Technology—technology that the DS belongs to.

To download the diagnostic signature (DS) file, you require the secure HTTP (HTTPS) protocol. If you have already configured an email transport method to download files on your device, you must change your assigned profile transport method to HTTPS to download and use DS.

There are two types of DS update requests to download DS files: regular and forced-download.

Regular download requests DS files that were recently updated. You can trigger a regular download request either by using a periodic configuration or by initiating an on-demand CLI. The regular download update happens only when the version of the requested DS is different from the version of the DS on the device. Periodic download is enabled by checking responses to periodic inventory messages. When an inventory message checks for any assigned DS on the device, the device sends a DS update request message that requests for an updated DS. In a DS update request message, the status and revision number of the DS is included such that only a DS with the latest revision number is downloaded.

Forced-download downloads a specific DS or a set of DSes. You can trigger the forced-download update request only by initiating an on-demand CLI. In a force-download update request, the latest version of the DS file is downloaded irrespective of the current DS file version on the device.

The diagnostic signature (DS) files are digitally signed before they are made available for downloading. The following methods are used for digitally signing DS files:

• Signing algorithm (Rivest Shamir and Adleman [RSA] 2048 bits)

• Request keypairs to Abraxas system, which is the digital signing client

• DS signed via secure socket layer (SSL) through a code signing client, where the signature is embedded using XML tags

• Public keys are embedded in the DS subsystem (Cisco signed, partner signed, third-party signed) in the Cisco software. The digitally signed DS file contains the product name such as Diagnostic_Signatures (Cisco signed), Diagnostic_Signatures_Partner, Diagnostic_Signatures_3rd_Party. The product names are only used to sign the DS files.

The digital signing client can be found at https:/​/​abraxas.cisco.com/​SignEngine/​submit.jsp

These conditions that must be met to verify the digital signature in a DS file:

• Code sign component support must be available in Cisco software.

• Various public keys that verify the different kinds of diagnostic signatures must be included in platforms where DS is supported.

• After parsing and retrieving the DS, the DS must execute the verification application program interface (API) to verify that the DS is valid.

The Diagnostic Signature is enabled by default on the Cisco software.

• Use the destination transport-method http command to configure both email and HTTP data transfer methods to download DSes.

• Download all DS files or specific DS files either by using the on-demand or periodic download.

• Store the downloaded DS files on nonremovable disks, such as bootflash or harddisk, so that DS files can be read after a device reload. Syslog messages are displayed if the disk space is not sufficient.

• Use periodic download to verify if the same version of DS is already available on the device. If a different version of DS is available on the device, the older version is uninstalled and the newer version is installed. Service disruption may occur during this time because of the unavailability of the DS.

• Associate the DS on your device with only one profile. Associating a DS with two different profiles may lead to unexpected results.

• Use the severity and pattern of occurrence of events on the device to determine the CLI commands that must be included in the new DS to trigger actions. For events that have already been identified, the metadata of the DS is in a much simpler format.

The DS metadata is parsed and stored in a database for event registration and information collection. When an event occurs, the action specified in the DS is performed.

Diagnostic signature (DS) events and actions are defined while digitally signing a DS. The DS events and actions data are included after the administrator metadata and operational metadata in the DS.

1.    enable


2.    configure terminal


3.    service call-home


4.    call-home


5.    contact-email-addr email-address


6.    mail-server {ipv4-addr | name} priority number


7.    profile profile-name


8.    destination transport-method {email | http}


9.    destination address {email address | http url}


10.    subscribe-to-alert-group inventory [periodic {daily hh:mm | monthly day hh:mm | weekly day hh:mm}]


11.    exit

Device> enable

Device# configure terminal

Device(config)# service call-home

Device(config)# call-home

Device(cfg-call-home)# contact-email-addr userid@example.com

Device(cfg-call-home)# mail-server 10.1.1.1 priority 4

Device(cfg-call-home)# profile user1

Device(cfg-call-home-profile)# destination transport-method http

Device(cfg-call-home-profile)# destination address http https://tools-stage.cisco.com/its/service/oddce/services/DDCEService

Device(cfg-call-home-profile)# subscribe-to-alert-group inventory periodic daily 14:30

Device(cfg-call-home-profile)# exit

Configure DS with profile user1 as described in the “Configuring Diagnostic Signatures” section. The attributes set for the call-home profile user1 apply to DS.

1.    diagnostic-signature


2.    profile ds-profile-name


3.    environment ds_ env-varname ds-env-varvalue


4.    end


5.    call-home diagnostic-signature {{deinstall | download} {ds-id | all} | install ds-id}


6.    show call-home diagnostic-signature [ds-id [actions | events | prerequisite | prompt | variables] | failure | statistics [download]]


7.    debug call-home diagnostic-signature {action | all | api | cli | download | event-registration | parsing}

Device(cfg-call-home)# diagnostic-signature

Device(cfg-call-home-diag-sign)# profile user1

Device(cfg-call-home-diag-sign)# environment ds_env1 envarval

Device(cfg-call-home-diag-sign)# end

Device# call-home diagnostic-signature download 6030

Device# show call-home diagnostic-signature

Device# debug call-home diagnostic-signature all

Before you configure and use the Smart Call Home Service, be sure that you have completed the following prerequisites:

• Verify that you have an active Cisco Systems service contract for the device being configured.
• Verify that you have IP connectivity to the Cisco HTTPS server.
• Obtain the latest Cisco Systems server security certificate. In Cisco IOS XE Release 2.6.0, the following shows the latest text for the Cisco Systems server security certificate:

MIIDAjCCAmsCEH3Z/gfPqB63EHln+6eJNMYwDQYJKoZIhvcNAQEFBQAwgcExCzAJ
BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xh
c3MgMyBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcy
MTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3Jp
emVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMB4X
DTk4MDUxODAwMDAwMFoXDTI4MDgwMTIzNTk1OVowgcExCzAJBgNVBAYTAlVTMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMyBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEo
YykgMTk5OCBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQDMXtERXVxp0KvTuWpMmR9ZmDCOFoUgRm1HP9SFIIThbbP4
pO0M8RcPO/mn+SXXwc+EY/J8Y8+iR/LGWzOOZEAEaMGAuWQcRXfH2G71lSk8UOg0
13gfqLptQ5GVj0VXXn7F+8qkBOvqlzdUMG+7AUcyM83cV5tkaWH4mx0ciU9cZwID
AQABMA0GCSqGSIb3DQEBBQUAA4GBAFFNzb5cy5gZnBWyATl4Lk0PZ3BwmcYQWpSk
U01UbSuvDV1Ai2TT1+7eVmGSX6bEHRBhNtMsJzzoKQm5EWR0zLVznxxIqbxhAe7i
F6YM40AIOw7n60RzKprxaZLvcRTDOaxxp5EJb+RxBrO6WVcmeQD2+A2iMzAo1KpY
oJ2daZH9

1.    configure terminal


2.    crypto pki trustpoint name


3.    enrollment terminal


4.    exit


5.    crypto pki authenticate name


6.    At the prompt, paste the security certificate text.

7.    quit


8.    yes


9.    end


10.    copy running-config startup-config

Router# configure terminal

Router(config)# crypto pki trustpoint cisco

Router(ca-trustpoint)# enrollment terminal

Router(ca-trustpoint)# exit

Router(config)# crypto pki authenticate cisco

Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself

<Paste certificate text here>

quit

% Do you accept this certificate? [yes/no]: yes

Router# end

Router# copy running-config startup-config

1.    call-home send alert-group inventory profile CiscoTAC-1

Device# call-home send alert-group inventory profile CiscoTAC-1

The following examples show the sample output when using different options of the show call-home command.

Lists of default Call Home settings.

Call Home trigger events are grouped into alert groups, with each alert group assigned CLI commands to execute when an event occurs. The CLI command output is included in the transmitted message. Table 1 lists the trigger events included in each alert group, including the severity level of each event and the executed CLI commands for the alert group.

The following example shows a sample syslog alert notification in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://www.w3.org/2003/05/soap-envelope">
<soap-env:Header>
<aml-session:Session xmlns:aml-session="http://www.cisco.com/2004/01/aml-session"
soap-env:mustUnderstand="true"
soap-env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
<aml-session:To>http://tools.cisco.com/neddce/services/DDCEService</aml-session:To>
<aml-session:Path>
<aml-session:Via>http://www.cisco.com/appliance/uri</aml-session:Via>
</aml-session:Path>
<aml-session:From>http://www.cisco.com/appliance/uri</aml-session:From>
<aml-session:MessageId>M8:9S1NMSF22DW:51AEAC68</aml-session:MessageId>
</aml-session:Session>
</soap-env:Header>
<soap-env:Body>
<aml-block:Block xmlns:aml-block="http://www.cisco.com/2004/01/aml-block">
<aml-block:Header>
<aml-block:Type>http://www.cisco.com/2005/05/callhome/syslog</aml-block:Type>
<aml-block:CreationDate>2013-06-05 03:11:36 GMT+00:00</aml-block:CreationDate>
<aml-block:Builder>
<aml-block:Name>CSR1000v</aml-block:Name>
<aml-block:Version>2.0</aml-block:Version>
</aml-block:Builder>
<aml-block:BlockGroup>
<aml-block:GroupId>G9:9S1NMSF22DW:51AEAC68</aml-block:GroupId>
<aml-block:Number>0</aml-block:Number>
<aml-block:IsLast>true</aml-block:IsLast>
<aml-block:IsPrimary>true</aml-block:IsPrimary>
<aml-block:WaitForPrimary>false</aml-block:WaitForPrimary>
</aml-block:BlockGroup>
<aml-block:Severity>2</aml-block:Severity>
</aml-block:Header>
<aml-block:Content>
<ch:CallHome xmlns:ch="http://www.cisco.com/2005/05/callhome" version="1.0">
<ch:EventTime>2013-06-05 03:11:36 GMT+00:00</ch:EventTime> <ch:MessageDescription>*Jun 5
03:11:36.041: %CLEAR-5-COUNTERS: Clear counter on all interfaces by
console</ch:MessageDescription> <ch:Event> <ch:Type>syslog</ch:Type>
<ch:SubType></ch:SubType> <ch:Brand>Cisco Systems</ch:Brand> <ch:Series>CSR1000v Cloud
Services Router</ch:Series> </ch:Event> <ch:CustomerData> <ch:UserData>
<ch:Email>weijuhua@cisco.com</ch:Email>
</ch:UserData>
<ch:ContractData>
<ch:CustomerId></ch:CustomerId>
<ch:SiteId></ch:SiteId>
<ch:ContractId></ch:ContractId>
<ch:DeviceId>CSR1000V@C@9S1NMSF22DW</ch:DeviceId>
</ch:ContractData>
<ch:SystemInfo>
<ch:Name>qiang-vm</ch:Name>
<ch:Contact></ch:Contact>
<ch:ContactEmail>weijuhua@cisco.com</ch:ContactEmail>
<ch:ContactPhoneNumber></ch:ContactPhoneNumber>
<ch:StreetAddress></ch:StreetAddress>
</ch:SystemInfo>
<ch:CCOID></ch:CCOID>
<ch:IdToken></ch:IdToken>
</ch:CustomerData>
<ch:Device>
<rme:Chassis xmlns:rme="http://www.cisco.com/rme/4.0">
<rme:Model>CSR1000V</rme:Model>
<rme:HardwareVersion></rme:HardwareVersion>
<rme:SerialNumber>9S1NMSF22DW</rme:SerialNumber>
<rme:AdditionalInformation>
<rme:AD name="PartNumber" value="" />
<rme:AD name="SoftwareVersion" value="15.4(20130604:093915)" /> <rme:AD
name="SystemObjectId" value="1.3.6.1.4.1.9.1.1537" /> <rme:AD name="SystemDescription"
value="Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-ADVENTERPRISEK9-M),
Experimental Version 15.4(20130604:093915) [mcp_dev-qiazhou-ultra_ut 100] Copyright (c)
1986-2013 by Cisco Systems, Inc.
Compiled Tue 04-Jun-13 02:39 by jsmith" /> <rme:AD name="ServiceNumber" value="" />
<rme:AD name="ForwardAddress" value="" /> </rme:AdditionalInformation> </rme:Chassis>
</ch:Device> </ch:CallHome> </aml-block:Content> <aml-block:Attachments>
<aml-block:Attachment type="inline"> <aml-block:Name>show logging</aml-block:Name>
<aml-block:Data encoding="plain"> <![CDATA[show logging Syslog logging: enabled (0
messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering
disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 391 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 391 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
Trap logging: level informational, 56 message lines logged
Logging Source-Interface: VRF Name:
Log Buffer (4096 bytes):
*Jun 5 03:11:18.295: %SYS-5-CONFIG_I: Configured from console by console
qiang-vm#]]></aml-block:Data> </aml-block:Attachment> </aml-block:Attachments>
</aml-block:Block> </soap-env:Body> </soap-env:Envelope>

The following example shows a Smart Licensing alert notification in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://www.w3.org/2003/05/soap-envelope">
<soap-env:Header>
<aml-session:Session xmlns:aml-session="http://www.cisco.com/2004/01/aml-session"
soap-env:mustUnderstand="true"
soap-env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
<aml-session:To>http://tools.cisco.com/neddce/services/DDCEService</aml-session:To>
<aml-session:Path>
<aml-session:Via>http://www.cisco.com/appliance/uri</aml-session:Via>
</aml-session:Path>
<aml-session:From>http://www.cisco.com/appliance/uri</aml-session:From>
<aml-session:MessageId>M2:98I1W09R72W:5136E366</aml-session:MessageId>
</aml-session:Session>
</soap-env:Header>
<soap-env:Body>
<aml-block:Block xmlns:aml-block="http://www.cisco.com/2004/01/aml-block">
<aml-block:Header>
<aml-block:Type>http://www.cisco.com/2005/05/callhome/license</aml-block:Type>
<aml-block:CreationDate>2013-03-06 06:34:14 GMT+00:00</aml-block:CreationDate>
<aml-block:Builder>
<aml-block:Name>CSR1000v</aml-block:Name>
<aml-block:Version>2.0</aml-block:Version>
</aml-block:Builder>
<aml-block:BlockGroup>
<aml-block:GroupId>G3:98I1W09R72W:5136E366</aml-block:GroupId>
<aml-block:Number>0</aml-block:Number>
<aml-block:IsLast>true</aml-block:IsLast>
<aml-block:IsPrimary>true</aml-block:IsPrimary>
<aml-block:WaitForPrimary>false</aml-block:WaitForPrimary>
</aml-block:BlockGroup>
<aml-block:Severity>1</aml-block:Severity>
</aml-block:Header>
<aml-block:Content>
<ch:CallHome xmlns:ch="http://www.cisco.com/2005/05/callhome" version="1.0">
<ch:EventTime>2013-04-10 07:47:28 GMT+08:00</ch:EventTime>
<ch:MessageDescription>Smart Licensing </ch:MessageDescription>
<ch:Event>
<ch:Type>License</ch:Type>
<ch:SubType>Register</ch:SubType> <!maybe other values like certificate_renewal,
id_certificate_ack, poll_for_data, license_disable, license_usage, entitlement_request>
<ch:Brand>Cisco Systems</ch:Brand>
<ch:Series>CSR1000v Cloud Services Router</ch:Series>
</ch:Event>
<ch:CustomerData>
<ch:UserData>
<ch:Email>test@cisco.com</ch:Email>
</ch:UserData>
<ch:ContractData>
<ch:CustomerId></ch:CustomerId>
<ch:SiteId></ch:SiteId>
<ch:ContractId></ch:ContractId>
<ch:DeviceId>CSR1000V@C@98I1W09R72W</ch:DeviceId>
</ch:ContractData>
<ch:SystemInfo>
<ch:Name>router</ch:Name>
<ch:Contact></ch:Contact>
<ch:ContactEmail>test@cisco.com</ch:ContactEmail>
<ch:ContactPhoneNumber></ch:ContactPhoneNumber>
<ch:StreetAddress></ch:StreetAddress>
</ch:SystemInfo>
<ch-inv:CCOID>xxxx</ch-inv:CCOID>
<ch:IdToken>yyyy</ch:IdToken> <!either CCOID or IdToken needs to be specified when
subtype is Register>
</ch:CustomerData>
<ch:Device>
<rme:Chassis xmlns:rme="http://www.cisco.com/rme/4.0">
<rme:Model>CSR1000V</rme:Model>
<rme:HardwareVersion>1.4</rme:HardwareVersion>
<rme:SerialNumber>98I1W09R72W</rme:SerialNumber>
<rme:AdditionalInformation>
<rme:AD name="PartNumber" value="68-3376-01" />
<rme:AD name="SoftwareVersion" value="15.3(20130303:013635)" />
<rme:AD name="SystemObjectId" value="1.3.6.1.4.1.9.1.1537" />
<rme:AD name="SystemDescription" value="Cisco IOS Software, IOS-XE Software
(X86_64_LINUX_IOSD-ADVENTERPRISEK9-M), Experimental Version 15.3(20130303:013635)
[mcp_dev-BLD-BLD_MCP_DEV_LATEST_20130303_000028-ios 171]
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Sat 02-Mar-13 20:49 by mcpre" />
<rme:AD name="ServiceNumber" value="" />
<rme:AD name="ForwardAddress" value="" />
</rme:AdditionalInformation>
</rme:Chassis>
</ch:Device>
</ch:CallHome>
</aml-block:Content>
<aml-block:Attachments>
<aml-block:Attachment type="inline">
<aml-block:Name>smart_licensing_data</aml-block:Name>
<aml-block:Data encoding="plain">
<![CDATA[…licensing data… ]]></aml-block:Data>
</aml-block:Attachment>
</aml-block:Attachments>
</aml-block:Block>
</soap-env:Body>
</soap-env:Envelope>
<response><![CDATA[{"signature":{"type":"SHA_1","value":"SIG_SIGNED_VALUE"},"response":"{\
"header\":null,\"status_code\":\"ERROR\",\"status_message\":\"Failed to process the
request.\",\"response_data\":\"\"}"}]]></response>
								<email>xxx@yyy.com</email><result xmlns="">succeeded</result>
				</soapenv:Body>
</soapenv:Envelope>