[Freeswitch-dev] Need some explainations about method switch_core_session_run(switch_core_session_t *session) in switch_core_state_machine.c
Alex To
tonhudung at gmail.com
Wed Jan 6 09:01:17 PST 2010
Hi, Anthony
I appreciate you spend your time answering my questions. I have no problem
with FreeSwitch. Since you ask, I am digging into this code because I am
trying to understand how FreeSwitch works inside the core, probably will
take me a great deal of time but I am trying.
I wrote a custom EndPoint in FreeSwitch before to run a modem created by
the hardware engineer team. Basically it is similar to Zaptel compatible
card. The Modem Endpoint runs in FreeSwitch to provide PSTN Connectivity
that uses our specific modem.
While working with FreeSwitch, I have this idea to implement something
similar to FreeSwitch in 100% .NET managed code. Of course I am not
expecting it to be as mature as FreeSwitch but something basic first. A core
that allows me to write pluggable modules, basic dial plan and the the first
supported endpoint would be XMMP since I had some experience working with
this XMMP .Net library before.
The ultimate aim is code readability, simplicity and maintainability. I have
some other aims too but basically this is it, mostly. I am working on this
as a personal hobby project only J.
Cheers
Alex To
From: freeswitch-dev-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony
Minessale
Sent: Thursday, January 07, 2010 12:16 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Need some explainations about method
switch_core_session_run(switch_core_session_t *session) in
switch_core_state_machine.c
On Wed, Jan 6, 2010 at 9:20 AM, Alex To <tonhudung at gmail.com> wrote:
Hi,
First of all, pardon my English. English isn’t my native language J.
I am reading the method switch_core_session_run(switch_core_session_t
*session) and I would be really appreciated if someone could shed some light
on how the method works. Below is the logic according to my understanding:
1. LINE 303: while ((state =
switch_channel_get_state(session->channel)) != CS_DESTROY)
ð if state is CS_DESTROY return and do nothing ?
state typically starts at CS_NEW the loop runs until state destroy is
reached
2. Inside if (state !=
switch_channel_get_running_state(session->channel) || state >= CS_HANGUP)
{
}
a. LINE 308: state !=
switch_channel_get_running_state(session->channel) || state >= CS_HANGUP
ð to check if channel->state and channel->running_state not equal. This is
to avoid running the STATE_MACRO multiple times. However I don’t understand
why do we need (state >= CS_HANGUP) ?.
Once we are >= HANGUP we dont want to do that test anymore.
b. Inside STATE_MACRO code block
i. LINE
229: midstate = state
ð to save the current state.
ii. LINE
231: if (!driver_state_handler->on_##__STATE ||
(driver_state_handler->on_##__STATE(session) == SWITCH_STATUS_SUCCESS)
ð to check either endpoint_interface->state_handler is NULL or return
SWITCH_STATUS_SUCCESS so it will continue to execute handlers in
session->channel, runtime.state_handlers and core standard state handlers.
It means if the condition is not true, channel->state_handlers,
runtime.state_handlers and core standard state handlers will NOT be executed
at all ?
iii. LINE
246: if (!proceed) global_proceed = 0;
ð If something wrong in the previous while loop, do not run core standard
state handlers ?
yes the endpoints have the power to veto state handlers from being called
iv. LINE
247: proceed = 1;
LINE 248: while (do_extra_handlers && proceed &&
(application_state_handler = switch_core_get_state_handler(index++)) != 0) {
}
ð Since we set proceed = 1, do we still need (&& proceed) inside the
condition in while loop ?
yes because proceed can become 0 within that loop
v. LINE
260: if (!proceed || midstate !=
switch_channel_get_state(session->channel)) global_proceed = 0;
ð If not proceed or the channel state has changed by some of the state
handlers executed earlier, do not execute core standard state handler ?
Again, veto power.
vi. LINE
266: while (silly)
ð silly is never changed, does it mean we could go into an endless while
loop ?
Its to stop the compiler from getting mad, that's why it's called silly its
specific to using a while loop inside a macro
Sorry for the long email and some questions are probably dumb but I am
trying to understand about FreeSwitch, especially the core and the core
state machine. If it is documented somewhere about the workflow happening
inside FreeSwitch, please enlighten me as what I am doing now is to read the
code line by line and figure out which may not be the most efficient .
Why are you digging into this code? do you have some problem you are
attempting to solve?
The most important thing is that code like this that has taken so long to
perfect, even if there could be improvements, is hard to even look at
without causing regressions. So I'm curious what you were looking for.
Thank you for reading this
Regards
Alex To
_______________________________________________
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/
Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm
MSN:anthony_minessale at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100107/0b9c3fa2/attachment-0001.html
More information about the FreeSWITCH-dev
mailing list