Auto provisioning from public server

Home » Asterisk Users » Auto provisioning from public server
Asterisk Users 25 Comments


has anyone experience with auto provisioning IP-phones on different
locations through a central public provisioning server ? You use http or
https ?

Is there a danger that one uses a different MAC-address in the
provisioning link to obtain SIP username / password settings ?

Kind regards,

25 thoughts on - Auto provisioning from public server

  • You can provision over a WAN and access-lists or iptables can limit
    the networks allowed. Define what level of security you need first.
    For further security you can use an inbound proxy and check the http
    headers for agent identification. This can also be faked.

    Practice layers of security…

    Andrew “lathama” Latham


    * Learn more about OSS
    * Learn more about Linux
    * Learn more about Tux

    On Tue, Oct 26, 2010 at 12:31 PM, Jonas Kellens

  • I havent had much auto provisioning experience, however, what about just
    using IPTables to create an access list essentially for known IPs to connect
    via HTTP/HTTPS and block all other addresses. This would only work if the
    phones are coming from a Static IP, but I figured i’d give my 2 cents to try
    and help.

  • Thank you for your input, but IP-addresses will change, so this would
    then become an administrative and time-consuming job…


  • Hello,

    many SIP phones offer you the possibility to provisioning them over a FTP
    connection (with username and password).


    – Bakko

  • With the new phones with VPNs you can also do a stepped provision….
    One provisioning service for the vpn and another for the sip that can
    only be reached with the vpn. This is advanced stuff so take your
    time and learn about the tech.

  • Well, what I’m really aiming for is this :

    I let users make easy config files via web interface. This results in a
    config file with name MAC-address of the IP-phone. This config file is
    then available on the public server. User just needs to points his
    IP-phone to the provisioning URL.
    Remarks :
    user from site B and vica versa.

    Expand setup :
    Also a phone book becomes available from the public server for the users…


  • In this case I will want to use Snom phones. TFTP is available, but no
    FTP (with indeed then a username and password). FTP would be great…


  • On Tue, Oct 26, 2010 at 12:06 PM, Jonas Kellens

    I wouldn’t do this unless your connection is encrypted.

  • What handset? That’s rather what controls your options. Some support HTTPS with client certificate authentication. Some support passwords. Some don’t.


  • I think this “digest authentication” is for accessing the phone’s web
    interface, not for contacting a provisioning server


  • The company we use for provisioning snom phones delete the un pass info
    from the server once it has been picked up for the first time. That way
    no one else can access it by spoofing the MAC address

  • Yes, there is a danger, especially with TFTP, but also with FTP to a lesser

    If someone guessed correctly, they could download the config file for
    another phone.

    Steve T

  • What company is that? I have seen companies that do this but have never
    felt very secure handing the keys to the castle over to a 3rd party service.

    It seems like a good idea, but I have trust issues, especially when you top
    off your prepaid service with $15k a week.

    Steve T

  • It’s our hardware supplier, the provisioning server is a free service if
    you purchase the hardware from them.

    I totally understand your point but there’s always got to be some trust
    at some point whether it be in your suppliers or even your employees or
    co workers

    They are a UK based company called Provu, I’m pretty sure they are
    active on this list too

  • If I find a way to implement it… https would be safer ?

    Or is the only safe way to work with certificates that are loaded on the
    IP-phone ?!


  • Hi,

    What is it exactly that you want to guarantee?

    Authenticating the client? The server?

    Avoiding any leak of data to some eavesdropper?

    On a LAN it wouls be quite difficult to forge the MAC without it getting
    detected. But in your case, the MAC is merely an arbitrary ID of the
    client. It can probably serve as a useful unique ID. See the above
    question regarding authentication.

    I also guess you should not use TFTP. Unless you have some spare time at

  • Some guidelines:
    1. Https
    2. The file on the https server is username/pass protected.
    3. The username and pass combo has access ONLY to config files it should have.
    4. Directory listing should ALWAYS be disabled.

    If you can’t use https or username/pass then at the very least,
    disable directory listing.
    For Polycom phones keep in mind:
    If the password to the phones http page is not changed then using the
    following script one will be able to read the sip credentials, while
    some might not mind it, there should be no reason for an end user to
    know the sip credentials. Here is the script, just paste it into a
    favorite button on your toolbar with any browser and whenever you see
    asterisks on a page hit it 😀
    ===begin script, its one line===
    javascript:(function(){var s,F,j,f,i; s = “”; F = document.forms;
    for(j=0; j
    (f[i].type.toLowerCase() == “password”) s += f[i].value + “n”; } } if
    (s) alert(“Password is:nn” + s); else alert(“No passwords”);})();
    ====end script====
    This works even for saved passwords. Whats interesting is that even if
    the password was never entered or saved with the browser you are
    using, the Polycom interface will populate the real password masked
    with asterisks.

    With Polycom phones you can use the following (this is meant for when
    you give a phone to a customer but they are entering the provisioning
    1. Create a config file that is password protected with a temp password.
    2. That config file should contain new config settings with a new
    unique username/pass conbo
    3. Delete that file once accessed
    4. In the configs change the interface password of the phone.
    5. Make sure that directory listing is disabled on the http server and
    that the username/pass combo will only show this phones config files.

    Hope this helps.