The general jist of your overview seems sound.<br><br>To answer your question:<br><br>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)<br>
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);<br><br>for the other way around you can store some info to get back to the master protocol by way of the <br>
private structure found in the channel with either a direct pointer to your master entity or some similar<br>token based lookup to find the correct entity.<br><br><br><br><div class="gmail_quote">On Wed, Nov 19, 2008 at 8:58 AM, Giovanni Maruzzelli <span dir="ltr"><<a href="mailto:gmaruzz@celliax.org">gmaruzz@celliax.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">First things first: when I'll understand, I'll write the wiki page on<br>
endpoints inner working and development.<br>
<br>
I'm now beginning to rewrite the skypiax implementation, and I would<br>
like to do it in the most "accepted" way.<br>
<br>
skypiax (and celliax in the future) will have multiple interfaces (eg:<br>
multiple concurrent skype clients managed by the module).<br>
<br>
So, you can think at it as similar to mod_openzap as a general structure.<br>
<br>
At module loading, I will parse the config file, and create a<br>
"globals" struct that will contains the global values that can be<br>
inherited by all interfaces and an array of pointers to interface<br>
structs.<br>
<br>
For each Skype interface that I find defined in the config file, I<br>
will alloc and populate one interface struct pointed by one array<br>
member.<br>
<br>
If not overridden in the interface definition in the config file, the<br>
interface struct members will inherit the values from the globals.<br>
<br>
For each Skype interface, I will have a thread, started on module<br>
loading, that monitors that interface for signaling (incoming call,<br>
offline, buddies, etc).<br>
<br>
When an incoming call arrives, the signaling thread creates the<br>
session, get the interface name, create a private tech_pvt that is<br>
just a series of pointers to the members of the interface structure<br>
that is located by the name, put the channel in the CS_INIT state,<br>
start the thread on it, and forget.<br>
<br>
When there is an outboubd call, channel_outgoing_channel() find the<br>
interface name from outbound_profile->destination_num, create a<br>
private tech_pvt that is just a series of pointers to the members of<br>
the interface structure located by the name, put the channel in the<br>
CS_INIT state and forget.<br>
<br>
Is the above correct?<br>
<br>
How to send messages/events/etc (state changes, whatever) from the<br>
signaling thread to an active interface (eg. remote hangup)?<br>
How an active interface receives messages/events/etc (state changes,<br>
whatever) from the core FS (eg local hangup request)?<br>
<br>
Thank you to all that will answer, and please forgive the naiveness of<br>
this first posting.<br>
<br>
Ciao for now,<br>
<br>
Giovanni<br>
<br>
<br>
<br>
--<br>
<br>
Sincerely,<br>
<br>
Giovanni Maruzzelli<br>
<br>
=========================================<br>
Contact person : Mr Giovanni Maruzzelli<br>
Company : celliax<br>
Website: <a href="http://www.celliax.org" target="_blank">www.celliax.org</a><br>
Address : via Pierlombardo 9, 20135 Milano<br>
Country/Territory : Italy<br>
Business Email: gmaruzz at celliax dot org<br>
Phone : 39-347-2665618<br>
Fax : 39-02-87390039<br>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400<br>