This is going to be a long one. Here we go:

To get your SMT-i series phones autoprovisioning to a non-Samsung system, you're going to need:

- An SMT-i series handset (I've been using an SMT-i3105 in my testing), running the SCM firmware
- A DHCP server where you can configure DHCP option 43.
(phones running SCM firmware ignore DHCP option 128, which is used by phones running OS firmware)
- You need a TFTP server, accessible by the phone device
- An HTTP (Web) server, accessible by the phone device

You will see these tags along the way:
<tftp_server>
<http_server>
<sip_server>

Substitute the IP address for these servers as necessary. I haven't tested this process using hostnames instead of IPs. It would probably work - give it a try and report back.

There is no rule that says these can't all be the same server.

Configure your DHCP server to provide option 43 to your phones. The value you need is sec,tftp://<tftp_server>

The first file you want is "sec_boot.xml". It needs to be put in your TFTP server root.

 

sec_boot.xml

This user_profile tag tells your handset that the user profiles can be found via HTTP, and the profile_http_server tag tells your handset which HTTP server the user profiles can be found on and in which directories.

The next thing your phone does is attempt to download the 'mac profile'. If you've left the configuration in sec_boot.xml largely alone, it will attempt to get this from http://<http_server>/sec_mac/sec_MACADDRESS.xml, where MACADDRESS is the MAC address of your handset. This part of the filename MUST BE IN CAPITALS, and no separators. So, if your phone's mac address is f4d9.fb43.2312 then it will go looking for sec_F4D9FB432312.xml.

 

sec_MACADDRESS.xml

This tells the handset that it plays host to user 6423, and that the user should use password 398697 to keep configuring itself. It will use this to attempt to download the sec_user_USERID.xml file, in this case sec_user_6432.xml from http://<http_server>/scm_profile/sec_user_USERID.xml

If you wish, you can secure the scm_profile directory on your HTTP server with Basic authentication. The phone will authenticate using the username and password in the sec_MACADDRESS.xml file. I chose not to.

Before the phone downloads the sec_user_USERID.xml file, it downloads the sec_phone.xml file.

 

sec_phone.xml

The sec_phone file describes to the handset how to find directory info, where to download user portraits for handsets with high res screens and so on. Most of these features I don't know how to use, nor do I have a capable handset to test, so haven't experimented.

What you will see in this file is the dialtone definitions. I've modified the dialtones to suit australian expectations. You'll need to modify to suit your environment.

The phone then downloads the sec_user xml file:

 

sec_user_USERID.xml

OK. So the sec_user_USERID.xml file basically says which SIP server we're using. It also defines:

- the time server - swap in your network values for <sntp_server>.
- daylight savings settings. You can see the settings for Australia/Melbourne above. We start on the first (1) sunday (0) of Octobe (10), and finish on the first sunday of April, hence the M10.1.0 and M4.1.0 above.

I'd guess that a lot of the unused settings could be excised here, but I haven't tested that yet.

The important thing in the sec_user_USERID.xml file is the contents of the <profiles> tag. These describe the next lot of files the handset will download. The first of these is the line file, sec_line_LINEID.xml, where LINEID in this case is 6423.

 

sec_line_LINEID.xml

As you can see, the sec_line_LINEID.xml file contains the line details for the handset, like auth id and password. It also defines the display name that appears on the screen of the handset. You'll see I've got my handle in there.

The next file the handset will go for (defined in the user xml file) is the sec_service.xml file.

 

 

sec_service.xml

As you can see, the service xml file defines the system feature codes the handset dials when you use buttons like DND and what not. I've left this one as defined by SCM, you can modify these codes to suit your system. I haven't tested modifications to this file yet.

The next file the handset downloads is sec_dialplan.xml.

 

 

sec_dialplan.xml

As you can see, the dialplan xml file contains the dial plan for the handset. numbers that match the dial plan are immediately sent to the SIP server, rather than waiting for keypress timeout or the send (#) key. The dial plan you see above suits my internal PBX and my __cpLocation - four digit numbers starting with 22, 25, 26, 27, 28, 61, 62, and 63 are dialled immediately, as are numbers that match local, interstate and 13/1300/1800 PSTN numbers, where prefaced by a leading zero. The emergency 000 (our 911) is in there as well. You should modify this to suit your environment. If you just want the normal timeout and # to dial, then delete the contents between <digitmap> and </digitmap>

The next file to be downloaded is sec_softmenu_eng.xml which contains the internationalised names of functions in the handset soft menu.

 

 

sec_softmenu_eng.xml

I didn't modify the sec_softmenu_eng.xml file.

The next file to be downloaded is sec_dialtone.xml

 

 

sec_dialtone.xml

This file sets the digit map a user dials to have the dial tone change to the tone_vir_dial dialtone set in the sec_phone.xml file. If your users dial a leading zero to access an outside line, this setting will cause the dialtone to change as soon as the handset sees the zero. Useful for old timer phone users who expect a prompt tone for an external line. Alter as you see fit. Remove the contents between <digitmap> and </digitmap> to never have the dialtone change.

Next file is sec_program_key_eng.xml.

 

 

sec_program_key_eng.xml

I didn't modify the sec_program_key_eng.xml file.

Next and last file is the sec_supplement_LINEID.xml file. LINEID matches the line id for the sec_line file. Of course, the handset will download whatever you tell it to in the sec_user file...

 

 

sec_supplement_LINEID.xml

The supplement xml file sets the programmable buttons on the handset. I've done a little experimentation, which you can see on button 4, but haven't yet worked out how to set a dial button yet. Still experimenting.

 

 

In short:
You'll need at minimum:

DHCP with option 43 set to sec,tftp://<tftp_server>

tftp:

sec_boot.xml file

http:

/sec_mac/sec_MACADDRESS.xml
/scm_profile/sec_phone.xml
/scm_profile/sec_user_USERID.xml
/scm_profile/sec_line_LINEID.xml

With these files, the phone will register. If you want more, like control over dial plan or menu names etc. then you need to add some or all of these files:

http:

/scm_profile/sec_service.xml
/scm_profile/sec_dialplan.xml
/scm_profile/sec_softmenu_eng.xml
/scm_profile/sec_dialtone.xml
/scm_profile/sec_program_key_eng.xml
/scm_profile/sec_supplement_LINEID.xml


There's a good chance you can remove a lot of the crud (sections with no settings etc.) from the files and still have it work. Samsung doesn't see the need to do that, though, so why should we?

Apologies if I've left any of my settings in the files.

Enjoy.

PS.

Add-on-Modules:

I have an AoM, but I don't have a spare compatible handset. I need to juggle some gear around to free up an i5210 or i5230 to test the AoM process.

As I understand it, the process involves an additional sec_aom_MACADDRESS.xml file. More to come.

+ Recent posts