[Freeswitch-dev] Request for guidelines on endpoints inner working

Anthony Minessale anthony.minessale at gmail.com
Wed Nov 19 12:20:51 PST 2008


The receive message are called as needed by all kinds of things you simply
have to do what they want and return success or fail

when the world sends your protocol a message you just have to find the
channel like the last email described and call api calls on it depending
what the situation is.

The mod_iax is a pretty simple example to look at.


On Wed, Nov 19, 2008 at 12:43 PM, Giovanni Maruzzelli
<gmaruzz at celliax.org>wrote:

> Thank'you Anthony!
>
> Some more questions, maybe they're just misled:
>
> The event/signals sent by the core to the channel are automatically
> processed by the channel_receive_message() and channel_receive_event()
> functions.
>
> So, during a call, we have the signaling thread loop (that listen and
> act on signaling coming from the interface), the
> channel_receive_message loop (that listen and act on messages/events
> coming from the core) and maybe (not really needed) the
> channel_receive_event() loop (that listen and act on events from the
> core, eg there is text to be sent to the remote party).
>
> Is the above correct?
>
> There are other ways for the world to send input to the channel?
>
> The event/signals that the channel needs to send to the core (eg a
> remote hangup has been received by the signaling thread) are all
> communicated by changing the state of the channel and/or by calling
> function (eg channel_on_hangup() ) ?
>
> I mean, there is not something like channel_send_message() function,
> to interact with the core?
>
> ciao for now,
>
> Giovanni
>
>
>
> On Wed, Nov 19, 2008 at 4:22 PM, Anthony Minessale
> <anthony.minessale at gmail.com> wrote:
> > The general jist of your overview seems sound.
> >
> > To answer your question:
> >
> > Typically you would have the protocol specific side create some sort of
> > table of all the calls with something to tie it to the freeswitch
> channel.
> > To be threadsafe you can keep the channels uuid string in a table and
> > whenever you need to do something to that channel you can find it with
> > session = switch_core_session_locate(uuid)
> > This will only give you the session if it can acquire a read lock giving
> you
> > suitable level of guarentee that the channel will not be destroyed until
> you
> > release it with switch_core_session_rwunlock(session);
> >
> > for the other way around you can store some info to get back to the
> master
> > protocol by way of the
> > private structure found in the channel with either a direct pointer to
> your
> > master entity or some similar
> > token based lookup to find the correct entity.
> >
> >
> >
> > On Wed, Nov 19, 2008 at 8:58 AM, Giovanni Maruzzelli <
> gmaruzz at celliax.org>
> > wrote:
> >>
> >> First things first: when I'll understand, I'll write the wiki page on
> >> endpoints inner working and development.
> >>
> >> I'm now beginning to rewrite the skypiax implementation, and I would
> >> like to do it in the most "accepted" way.
> >>
> >> skypiax (and celliax in the future) will have multiple interfaces (eg:
> >> multiple concurrent skype clients managed by the module).
> >>
> >> So, you can think at it as similar to mod_openzap as a general
> structure.
> >>
> >> At module loading, I will parse the config file, and create a
> >> "globals" struct that will contains the global values that can be
> >> inherited by all interfaces and an array of pointers to interface
> >> structs.
> >>
> >> For each Skype interface that I find defined in the config file, I
> >> will alloc and populate one interface struct pointed by one array
> >> member.
> >>
> >> If not overridden in the interface definition in the config file, the
> >> interface struct members will inherit the values from the globals.
> >>
> >> For each Skype interface, I will have a thread, started on module
> >> loading, that monitors that interface for signaling (incoming call,
> >> offline, buddies, etc).
> >>
> >> When an incoming call arrives, the signaling thread creates the
> >> session, get the interface name, create a private tech_pvt that is
> >> just a series of pointers to the members of the interface structure
> >> that is located by the name, put the channel in the CS_INIT state,
> >> start the thread on it, and forget.
> >>
> >> When there is an outboubd call, channel_outgoing_channel() find the
> >> interface name from outbound_profile->destination_num, create a
> >> private tech_pvt that is just a series of pointers to the members of
> >> the interface structure located by the name, put the channel in the
> >> CS_INIT state and forget.
> >>
> >> Is the above correct?
> >>
> >> How to send messages/events/etc (state changes, whatever) from the
> >> signaling thread to an active interface (eg. remote hangup)?
> >> How an active interface receives  messages/events/etc (state changes,
> >> whatever) from the core FS (eg local hangup request)?
> >>
> >> Thank you to all that will answer, and please forgive the naiveness of
> >> this first posting.
> >>
> >> Ciao for now,
> >>
> >> Giovanni
> >>
> >>
> >>
> >> --
> >>
> >> Sincerely,
> >>
> >> Giovanni Maruzzelli
> >>
> >> =========================================
> >> Contact person : Mr Giovanni Maruzzelli
> >> Company : celliax
> >> Website: www.celliax.org
> >> Address : via Pierlombardo 9, 20135 Milano
> >> Country/Territory : Italy
> >> Business Email: gmaruzz at celliax dot org
> >> Phone : 39-347-2665618
> >> Fax : 39-02-87390039
> >>
> >> _______________________________________________
> >> Freeswitch-dev mailing list
> >> Freeswitch-dev at lists.freeswitch.org
> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> >> http://www.freeswitch.org
> >
> >
> >
> > --
> > Anthony Minessale II
> >
> > FreeSWITCH http://www.freeswitch.org/
> > ClueCon http://www.cluecon.com/
> >
> > AIM: anthm
> > MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> > IRC: irc.freenode.net #freeswitch
> >
> > FreeSWITCH Developer Conference
> > sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> > iax:guest at conference.freeswitch.org/888
> > googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> > pstn:213-799-1400
> >
> > _______________________________________________
> > Freeswitch-dev mailing list
> > Freeswitch-dev at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > http://www.freeswitch.org
> >
> >
>
>
>
> --
>
> Sincerely,
>
> Giovanni Maruzzelli
>
> =========================================
> Contact person : Mr Giovanni Maruzzelli
> Company : celliax
> Website: www.celliax.org
> Address : via Pierlombardo 9, 20135 Milano
> Country/Territory : Italy
> Business Email: gmaruzz at celliax dot org
> Phone : 39-347-2665618
> Fax : 39-02-87390039
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20081119/91fa4251/attachment-0001.html 


More information about the Freeswitch-dev mailing list