[Freeswitch-dev] Need some direction

[David Knell]

Hi Mark,

Unless you have good reason, then writing a custom FS module is probably
not the right way to go about this - I don't think I can see anything
here which you couldn't do with Lua or an event socket client.

--Dave

> I need to create a custom Freeswitch module that acts as a leg/endpoint 
> of a call.  Unlike a conference, it needs to maintain a UUID so that a 
> parked call can be bridged to it.  Once the call is bridged, the module 
> will be in "connect" mode.  After the bridged leg disconnects, the 
> module goes into "data collection" mode and gets DTMF call results from 
> the operator.  It then goes into a "parked" mode, waiting for another 
> call to be bridged to it or for the operator to hit a DTMF logout sequence.
> 
> I just need to know what I should look at for a template/sample to start 
> with.  Conferences don't seem to be applicable because they don't have 
> UUIDs for bridging (I'd tried doing this behaviour using them and failed 
> miserably.)  The code for audio_bridge_function is interesting, but I 
> don't believe that's what I need to start with either, as it _bridges_ 
> calls rather than providing a virtual endpoint.
> 
> Just to make things real interesting, I'll have to have the custom 
> module generating custom events so that the Erlang control code gets 
> notified with the call results so it can update an RDBMS with the result 
> code.  If I decide to get fancy, I'd like to have a mini-IVR associated 
> with it that can provide voice prompts about the result codes available 
> to the operator.
> 
> Last but not least, I'm uncertain as to whether such a custom module 
> needs to be "released" to the Freeswitch team, or whether it would be an 
> "internal only" module.  Hopefully it _has_ to be released -- I'd like 
> to contribute in some small way to the community.
> 
> As a "for example", picture the tech support call center -- after each 
> call the operator/tech has to enter a code indicating whether the call 
> was 1) handled; 2) passed to level 2 tech support; 3) passed to level 3 
> tech support; or 4) scheduled for callback.
>