XML Configuration

FreeSWITCH understands its configuration in terms of an all-encompassing XML tree. That XML tree is continuously searched and queried, as long as FreeSWITCH is running. Each time the FreeSWITCH core, or one of the modules, needs whatever information from the configuration, they ask (again and again) for that specific snippet of configuration. For example, let's imagine a SIP phone (or a WebRTC client) originates a call. The call is originated by user 1010@mydomain.org. When the first signaling of the originating call reaches FreeSWITCH, then the mod_sofia module (responsible for SIP) or mod_verto (responsible for... Verto!) will need to check the user authorization to make that call. The module will ask: in the users' directory, what is the SIP password corresponding to user 1010@mydomain.org? This question will be made each time via an internal FreeSWITCH API that will go and get the requested value from the indicated section of the XML configuration tree (in this case, the users' directory). There are many ways this task of fetching the XML configuration snippet can be accomplished: querying a database, via HTTP, through scripting languages, and so on. All of those methods return the requested XML snippet. The one used by the demo configuration out of the box is reading an XML main file from the filesystem, and then all the XML files included by it. This is done once at FreeSWITCH startup. So, each time you change one of those XML files, you must tell FreeSWITCH to refresh the XML tree it has built in its memory at startup. The command reloadxml is usually enough. The XML snippet fetching is executed each time information is requested by FreeSWITCH, but the fetching will be executed against the tree built in memory at startup, so it needs to rebuild it if you edit any XML file. Other methods such querying databases or HTTP servers are completely dynamic, they directly query the database or the web server each and every time.