Hi Michael and group, I tried the mod_xml_curl after studying the wiki. It works like a charm and FS post to my java servlet easily (dialplan and user directory). I read on a blog there is option 'cacheable=true' to prevent a post every time a dial is made, do you know where to put this? I suspected that the reloadxml would trigger a post but it doesn't, dialplan is triggered from dial and user directory from startup of FS and dial I thought. FS is highly customizable and I need to find my way but it works like a charm. I wonder if there are people who had a successful mod_xml_java build on Windows. I made a own project and put references to the core but got stuck and left it because it took too much time. Thanks and have a nice weekend all! Peter On 14 sep 2012, at 19:01, Michael Collins wrote:

Hi Peter!

Welcome to FreeSWITCH! Glad to have you. These are great questions. FS has a db command that can be executed from fs_cli, however this isn't what you want/need for users. The user directory is where all that stuff is handled. Static XML is, of course, in conf/directory/* and you can add/remove there, but that doesn't sound like what you need. The best option for you right now is to get up to speed with mod_xml_curl. Using mod_xml_curl you can have FS poll a database each time there is a need, such as when there is an auth challenge taking place.

We have several people who've done lots of mod_xml_curl stuff, so feel free to ask away, but please check the wiki first since there is a lot of information and examples there. You may also enjoy discussing this live in #freeswitch channel on irc.freenode.net.

-MC

On Fri, Sep 14, 2012 at 2:03 AM, Peter van Raamsdonk <peetzer@gmail.com> wrote: Hi all,

Just wondering if I can add/ delete users to the db from the CLI (I'm using ESL java library)?

See http://wiki.freeswitch.org/wiki/Function_db

From the Dialplan this is possible, I want however to dynamically add new users.

<action application="db" data="insert/realm/key/value"/>

In the api (mod commands) nothing is mentioned about "db"

I don't know if something like this could work with my example extension 1999, default group named default...

response = client.sendSyncApiCommand( "db", "insert/default/1999/1999");

Another option is to use mod_xml_curl and feed the dialplan or user directory to FreeSwitch back again.

Kind regards,

Peter

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

On Fri, Sep 14, 2012 at 11:54 AM, Peter van Raamsdonk <peetzer@gmail.com> wrote:

I tried the mod_xml_curl after studying the wiki. It works like a charm and FS post to my java servlet easily (dialplan and user directory). I read on a blog there is option 'cacheable=true' to prevent a post every time a dial is made, do you know where to put this?

I've never seen this. I know there was some talk about it (I can't remember if it was ClueCon or the mailing list or what). But I think the general consensus was that simple cacheing isn't going to do much good. It's almost like you need to know, based on the POST info if you should cache or not. I'd love a link to the blog if you can find it. Meanwhile, I'm running off to the source to see if that's true. If it's something you really need, I'd consider adding caching at the webserver layer, take the work of evaluating the request away from freeswitch and move it to another box. Also, you could write your own dialplan that worked as a caching layer. First FreeSWITCH hits your custom dialplan, if it returns a cached dialplan you're done. If not, it moves on to mod_curl_xml. And finally, it makes its way to disk if it can't find a suitable dialplan. I've never done it, but I hear it's not that hard to write. Good luck. Gabe

Yep correct, that was the blog. Regards Peter On 23 sep 2012, at 10:05, Paul Cupis wrote:

On 23/09/12 02:30, Gabriel Gunderson wrote:

...

On Fri, Sep 14, 2012 at 11:54 AM, Peter van Raamsdonk<peetzer@gmail.com> wrote:

...

I tried the mod_xml_curl after studying the wiki. It works like a charm and FS post to my java servlet easily (dialplan and user directory). I read on a blog there is option 'cacheable=true' to prevent a post every time a dial is made, do you know where to put this?

...

I'd love a link to the blog if you can find it. Meanwhile, I'm running off to the source to see if that's true.

Possibly:

http://blog.godson.in/2011/06/pitfalls-to-avoid-while-using.html

Regards,

_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com

Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

On Sun, Sep 23, 2012 at 9:17 AM, Peter van Raamsdonk <peetzer@gmail.com> wrote:

The part although not the same website is on;

https://profiles.google.com/100965631603901259030/buzz

"Another tip is to use cacheable='true' attribute of user xml returned by web service. This will make FS to maintain a local cache of the account details. The details will stay in cache until cleared. This means that FS won't be hitting your web app for every REGISTER request that hoards of SIP UAs are sending, it will ask only once upon first request. The subsequent requests will be looked up from cache."

Ok, I see what you're talking about. I think what you're looking at isn't mod_xml_curl wide. It seems to be specific to user registration. I'm not sure about this, but I don't see the word 'cacheable' in the mod_xml_curl source, but you do see it on line 1946 of switch_xml.c. And there too, it appears to have something to do with users. If any of that is correct, is suggests that you will not be able to add "cacheable" to your dialplan served up by mod_xml_curl and "prevent a post every time a dial is made." Hope that helps. Best, Gabe

On Sun, Sep 23, 2012 at 5:07 PM, Gabriel Gunderson <gabe@gundy.org> wrote:

On Sun, Sep 23, 2012 at 9:17 AM, Peter van Raamsdonk <peetzer@gmail.com> wrote:

...

The part although not the same website is on;

https://profiles.google.com/100965631603901259030/buzz

"Another tip is to use cacheable='true' attribute of user xml returned by web service. This will make FS to maintain a local cache of the account details. The details will stay in cache until cleared. This means that FS won't be hitting your web app for every REGISTER request that hoards of SIP UAs are sending, it will ask only once upon first request. The subsequent requests will be looked up from cache."

Ok, I see what you're talking about. I think what you're looking at isn't mod_xml_curl wide. It seems to be specific to user registration. I'm not sure about this, but I don't see the word 'cacheable' in the mod_xml_curl source, but you do see it on line 1946 of switch_xml.c. And there too, it appears to have something to do with users.

Great... now you've got me thinking about this. I'd like to satisfy my curiosity, but naturally, there's nothing in the wiki and no comments in the source code :) I wonder, what does it mean to be 'cached'? And when does that cache get cleared? Now I must know ;) Gabe

On Mon, Sep 24, 2012 at 3:19 AM, Gabriel Gunderson <gabe@gundy.org> wrote:

...

...

"Another tip is to use cacheable='true' attribute of user xml returned by web service. This will make FS to maintain a local cache of the account details. The details will stay in cache until cleared. This means that FS won't be hitting your web app for every REGISTER request that hoards of SIP UAs are sending, it will ask only once upon first request. The subsequent requests will be looked up from cache."

Ok, I see what you're talking about. I think what you're looking at isn't mod_xml_curl wide. It seems to be specific to user registration. I'm not sure about this, but I don't see the word 'cacheable' in the mod_xml_curl source, but you do see it on line 1946 of switch_xml.c. And there too, it appears to have something to do with users.

Great... now you've got me thinking about this. I'd like to satisfy my curiosity, but naturally, there's nothing in the wiki and no comments in the source code :)

I wonder, what does it mean to be 'cached'? And when does that cache get cleared? Now I must know ;)

UPDATE: I got a chance to chat with anthm on IRC about this. I'm going up update the wiki, but only after I play with it for a bit. I'm posting the chat (cleaned up) here for archival purposes . ****************************************************************************** <gundy> anthm, I try not to bug you as I know you're busy... but I don't know who else would be involved with this Q. <gundy> anthm, do you know who might know about an undocumented "cacheable" parameter when returning directories via mod_xml_curl? <gundy> anthm, If I can get some clarity on it, I'll update the wiki. <anthm> gundy, sure <gundy> anthm, specifically, this is not a mod_xml_curl feature. Meaning, you can't expect to do that "cacheable" in other responses. <gundy> anthm, and I guess their isn't any info about when that cache is cleared. <anthm> if xml lookup returns a <user> tag with the param cacheable="true" , it saves it into a in-memory hash table and will pick it up in place of doing another lookup for the same user later <gundy> anthm, super, and how long does that cache last and is there a way to clear it? <anthm> xml_flush_cache api call <anthm> xml_flush_cache <id> <key> <val> <anthm> the less specific you are the more it clears <gundy> Awesome. <anthm> so no args is complete clear <gundy> You have my word, I'll doc it ;) This is only for users, right? <anthm> yes <gundy> anthm, thank you for your time. ****************************************************************************** Best, Gabe