[Freeswitch-users] sessions and CS_INIT events

Stanislav Sinyagin ssinyagin at gmail.com
Thu Mar 5 16:19:51 MSK 2015


but for the task that OP has described, writing (and maintaining it in
the long term) a module is really an overkill. Plus, he would also
need to take care of multithreading within FreeSWITCH, as well as
memory management, etc.

Also, a module makes sense if it's some common task which can be
re-used by others and published as open source. If it's some
closed-source module for a specific enterprise task that Juan has, it
just doesn't make sense and too much risk for a long-term solution.





On Thu, Mar 5, 2015 at 1:56 PM, Vik Killa <vipkilla at gmail.com> wrote:
> It all depends on what you are trying to do with your module.
> You can use a dialplan handler in your module (see mod_enum for example) to
> route inbound calls using your custom dialplan.
> You can use a state handler in your module and bind to channel states (much
> like binding to events).
> You can create a dialplan app in your module to execute code when the app is
> called in dialplan
> (Example: <application action="mycustom_module" data="${uuid} arg1 arg2"/>)
> You can use an endpoint in your module to originate calls outbound (see
> mod_lcr or mod_callcenter for an example)
> Also, you can create an API for your module
>
> IMO creating a module is much more powerful than using a script with ESL.
> But if you are going to create a module, you really don't need to mess with
> events (unless they are very specific events like CUSTOM::) because your
> module has access to much of the freeswitch core.
>
> Thanks.
>
>
>
> On Thu, Mar 5, 2015 at 5:07 AM, Stanislav Sinyagin <ssinyagin at gmail.com>
> wrote:
>>
>> why at all do you need it to be a C module inside FreeSWITCH?
>>
>> Why not writing an ESL program which would subscribe to events and
>> perform the needed actions?
>>
>> How about the following scenario:
>>
>> 1. In the XML dialplan, you execute "park" application on the incoming
>> call.
>>
>> 2. Your program is listening to events via ESL, and it recognizes that
>> a channel has been parked
>>
>> 3. Your program starts to playback the ringback tone into that channel
>>
>> 4. Your program performs all the needed lookups and sets needed
>> variables on the channel
>>
>> 5. Your program transfers or bridges the call where needed.
>>
>> This is quite easy to implement in any programming language of your
>> choice, easy to debug, and it's easily scalable. It can be done in a
>> multi-threading fashion, like Go or Erlang, or even Java, and perform
>> as many parallel calls as required.
>>
>> quite easy, and you don't have to mess with FreeSWITCH internals :)
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 5, 2015 at 4:07 AM, Juan Pablo L.
>> <jpablolorenzetti at hotmail.com> wrote:
>> > Hi, i m writing a module in C that needs to check for certain
>> > information in
>> > a
>> > database for the caller and the destination number,
>> > for this the module is subscribing to the CS_INIT channel events, so
>> > everytime a channel is created
>> > the module callback is called and it checks the numbers,
>> > the problem is that the callback gets called twice,
>> > for the creation of the a-leg of the call and the creation of the b-leg.
>> > Is there any way to accomplish what i m trying to do ?
>> > Am i doing it the wrong way?
>> > I have already try getting testing for the flags in the channel but it
>> > did
>> > not work,
>> > testing of originator or originating does not yield anything ....
>> >
>> > i might be doing it wrong maybe ?
>> >
>> > Thanks!
>> >
>> >
>> >
>> > _________________________________________________________________________
>> > Professional FreeSWITCH Consulting Services:
>> > consulting at freeswitch.org
>> > http://www.freeswitchsolutions.com
>> >
>> > Official FreeSWITCH Sites
>> > http://www.freeswitch.org
>> > http://confluence.freeswitch.org
>> > http://www.cluecon.com
>> >
>> > FreeSWITCH-users mailing list
>> > FreeSWITCH-users at lists.freeswitch.org
>> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> > http://www.freeswitch.org
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org



Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list