Cisco SPA2102-AU Provisioning Guide - Page 60

Partitioned Profiles, Parameter Name Aliases - r password

Get Cisco SPA2102-AU PDF manuals and user guides View all Cisco SPA2102-AU manuals
Add to My Manuals
Save this manual to your list of manuals

Page 60 highlights

Profile Formats Chapter 3 Provisioning Tutorial On resync, the new file is downloaded by the SPA and used to update its parameters. Partitioned Profiles The SPA download multiple separate profiles during each resync. This allows managing different kinds of profile information on separate servers and maintaining common configuration parameter values separate from account specific values. Exercise Step 1 Step 2 Step 3 Step 4 Step 5 Create a new XML profile, basic2.txt, that specifies a value for a distinct parameter from the earlier exercises. For instance, the file can contain the following: ABCD Store the basic2.txt profile in the TFTP server virtual root directory. Leave the first profile rule as in any the earlier exercises, but configure the second profile rule (Profile_Rule_B) to point to the new file: tftp://192.168.1.200/basic2.txt Click Submit All Changes. The SPA now resyncs to both the first and second profiles, in that order, whenever a resync operation is due. Observe the SPA syslog trace to confirm the expected behavior. Parameter Name Aliases When generating an XML profile for the SPA, it may be convenient to assign names to certain configuration parameters that are different from the canonical names recognized by the SPA. For example, a customer account database may generate XML element tags for a customer telephone number and SIP registration password with names such as SIP-number and SIP-password. These names can be mapped to the SPA canonical names (User_ID_1_ and Password_1_ ) before being applied to SPA Line 1. In many instances, the back-end provisioning solution used by the service provider can perform this mapping. However, the SPA itself can remap the parameter names internally. To do this, an alias map is defined and stored in one of the general purpose provisioning parameters. Then, the profile rule which invokes the resync is directed to remap the non-canonical XML elements as specified by the alias map. Exercise Step 1 Generate a profile named customer.XML containing the proprietary customer-account XML form indicated in the following example: 3-12 Linksys SPA Provisioning Guide Version 3.0

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
3-12
Linksys SPA Provisioning Guide
Version 3.0
Chapter 3
Provisioning Tutorial
Profile Formats
On resync, the new file is downloaded by the SPA and used to update its parameters.
Partitioned Profiles
The SPA download multiple separate profiles during each resync. This allows managing different kinds
of profile information on separate servers and maintaining common configuration parameter values
separate from account specific values.
Exercise
Step 1
Create a new XML profile, basic2.txt, that specifies a value for a distinct parameter from the earlier
exercises.
For instance, the file can contain the following:
<flat-profile><GPP_B>ABCD</GPP_B></flat-profile>
Step 2
Store the basic2.txt profile in the TFTP server virtual root directory.
Step 3
Leave the first profile rule as in any the earlier exercises, but configure the second profile rule
(Profile_Rule_B) to point to the new file:
Step 4
Click
Submit All Changes
.
The SPA now resyncs to both the first and second profiles, in that order, whenever a resync operation is
due.
Step 5
Observe the SPA syslog trace to confirm the expected behavior.
Parameter Name Aliases
When generating an XML profile for the SPA, it may be convenient to assign names to certain
configuration parameters that are different from the canonical names recognized by the SPA. For
example, a customer account database may generate XML element tags for a customer telephone number
and SIP registration password with names such as SIP-number and SIP-password. These names can be
mapped to the SPA canonical names (User_ID_1_ and Password_1_ ) before being applied to SPA
Line 1.
In many instances, the back-end provisioning solution used by the service provider can perform this
mapping. However, the SPA itself can remap the parameter names internally. To do this, an alias map is
defined and stored in one of the general purpose provisioning parameters. Then, the profile rule which
invokes the resync is directed to remap the non-canonical XML elements as specified by the alias map.
Exercise
Step 1
Generate a profile named customer.XML containing the proprietary customer-account XML form
indicated in the following example:
<customer-account>