
Users
Now, let's look at a true "user" item definition (eg, not to a "pointer"). Go inside /usr/local/freeswitch/conf/directory/default/ and open the file 1000.xml:

At the beginning, inside the very same "user" tag, is declared the "id" of the user (this is the same "id" that will be looked upon by the "pointer" kind of "user" item we saw in previous section). The id is specific to a "domain", eg: you can have a FreeSWITCH server that serves multiple domains, let's say, "domainA" and "domainB".
In both of them can exist one user whose "id" is "1000". Each one of those two "1000" is a completely different user, not related in any way to the other one. So, those two users will probably have different passwords, can make and/or receive calls both of them at the same time, etc. They are completely different users, they just happen to have the same "id". They can coexist on the same FreeSWITCH server because they belong to different domains. So, they would be "1000@domainA" and "1000@domainB". See? Different! When there is more than one domain in a FreeSWITCH platform, telco lingo sez: "is multi-tenant".
Inside the "user" container item, in this example we find both a "params" and a "variables" container item.
Inside the "params" container there are "param" items that define the parameters that belongs exclusively to this user. Possibly those "param" items override the ones set in the "domain" container, or in the "group" container. For example, you can repeat here the "jsonrpc-allowed-methods" param we found before in the domain definition, so this particular user will have its value explicitly set for him (perhaps to "", empty string, so no methods are allowed) instead of inheriting the one defined in domain (that was the string "verto").
Other ones you most probably want to modify are "password", obviously, so to set a specific password for this user (instead of inheriting the default one set into vars.xml file), and "vm-password".
And there are cases where it can be convenient to override the "dial-string" param item.
Exactly the same happens for the "variables" container, with "variable" items. Here, you may want to override "default_gateway", so to use a specific SIP gateway for this user. And very often you want to personalize some of the "*id_name" and "*id_number" variable items.
Also, you may want to set your own variables. There are some already set in the demo example user definitions 1000.xml...1019.xml. All of them can then be referenced in dialplan and scripts, for example you want to check what kind of call a user is allowed to originate, and you choose to test the content of the variable ${toll_allow} for this purpose. Remember, all those variables are available both to core FreeSWITCH and to all modules. So, the modules generating CDRs will be able to reference them, you can have the content of the ${callgroup} reported into your Call Detail Records (for accounting purposes):

The following table lists each variable and what it is used for:
