Profile_Rule lines in SPA5xG phone configs

[damone717]

Hello!

I have tried to feed myself by looking through the Admin Guide and the Provisioning Guide but things are not clear for me.  I'm hoping someone can shed some light for me.

I am trying to figure out the best scheme to auto-provision a phone via TFTP (probably switching over to HTTPS later on once I iron this out).  Currently, I'm testing with a SPA502G.  When the phone boots, gets and IP via DHCP and contacts the TFTP server in option 66, it "resyncs" looking for the /spa502G.cfg file and gets it successfully.  My Profile_Rule in that file looks like this:

  <Profile_Rule ua="na">tftp://<server's IP>/SPA$MAU.cfg</Profile_Rule>

The phone reboots, "resyncs" by looking for the /SPA$MAU.cfg file via TFTP and gets it.  Here's where my confusion is:  What should my Profile_Rule look like in the phone's own custom config file?  Should it be blank?  Should it point back to the first spa502G.cfg file?  Are the spa$PSN.cfg files meant to be used only on a factory-default boot?  Please help set me straight :-)

Sort of off-topic, but can someone clarify the term "resync" for me?  Does that mean it's only checking for changes in it's config file?  Does a difference between the running config on the phone and the config file on the provisioning server trigger an immediate reboot?

Thanks in advance for anyone's help/guidance!

[Alberto Montilla]

Dear Sir;

I suggest you read the/docs/DOC-9894, It will provide you good guidance on the processes, what goes where and when and also the terminology. After you check this, glad to go over your questions.

Regards
Alberto

[richard.l]

In my phone specific (mac specific) file I do not include any on the profile rule parameters.  Just remove the lines all together.

My suggestion:

Have a file on your boot server named spa502G.cfg.  This file will be used only when the phone is at it's factory default configuration and could look something like this:

  /spa502.xml
  /spa$MA.xml
 
 
  66,160,159,150
  tftp

Then have a file called 'spa502.xml' this file will contain the majority of the parameters set to your environment and will be loaded by all of the 502's on your network.  It could also contain the profile rules above but it's not necessary.  If you're also using the 504, 508, etc. have a "model" file for each of those.  Having this model specific file will allow you to make changes to all phones of a specific model by modifying a single file.

Now you'll need a phone specific (mac specific) file.  This file should contain only the parameters necessary to register the extensions with the call server.  Do not put profile rules in this file.

Hope this helps...

[damone717]

Rick,

Thanks for the tips.  The phone is no longer rebooting continuously, but now it's not resyncing at all.  The Profile_Rules are all blank in the device-specific config file and I cranked up the Resync Periodic to 30 seconds.

Does this make sense?

[Patrick Born]

Hi damone717,

Take a look at the Asterisk zero-touch config guide. I deal extensively with the boot process and how to build config files:

https://www.myciscocommunity.com/docs/DOC-10647

To answer your questions specifically:

Here's where my confusion is:  What should my Profile_Rule look like in the phone's own custom config file?

It should contain whatever changes you need to make to a factory-default phone.

For example, Line key registration, phone name, etc. Usually this file will only contain about 20 lines of information.

Here's how it works:

1. Factory-defaulted phone boots and looks for /spa$PSN.cfg

2. Your server serves /spa504G.cfg [for example]

3. The spa504G.cfg changes the phones profile rule to look for a phone-specific file [by MAC address] [example: spa$MA.xml]

4. spa.xml contains phone-specific configuration.

Resync is when then phone checks in with its configuration server to determine if any of its parameters need changing. Example, you decide to change the phone's firmware so you edit the phone's profile. Next time the phone resync, it will pull an updated version of firmware.

Regards,

Patrick

-----------