[Freeswitch-dev] Questions regarding the architecture

Wed Sep 6 15:57:55 EDT 2006

Anthony,

This information is incredibly invaluable!  Is there any other
documentation outside of the source code that contains this kind of
"here's what happens and why" type of info?  Just curious.  

Thanks for working on such a great idea.  I'm looking forward to using
FreeSwitch in the not-so-distant future.

-MC

P.S. - Before I go drop $2K on a Sangoma T1 card, has anyone started
working on mod_zap for FreeSwitch?  I have a Tormenta2 clone that
actually works very well and I don't want to spend more $$ on hardware
if I don't have to... :-)

  _____  

From: Anthony Minessale [mailto:anthmct at yahoo.com] 
Sent: Wednesday, September 06, 2006 12:02 PM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Questions regarding the architecture

1.   Thread architecture.  For a basic call, why do we need two threads
for the sessions (one for each endpoint)?  While the thread in charge of
originator  is in the switch_core_standard_on_execute(), the other
thread is in the switch_core_session_run() while loop.    What's
advantage of doing this compared to Asterisk's one thread approach?  Why
do we need the thread for the originatee?

A)

Every session has a thread which is managed by the state machine in the
core which sees it from creation to destruction.
In the case of a bridged call the existing thread of both sessions are
used to move inbound audio across to the opposite session at the same
time.
A one threaded approach such as asterisk will leave you doing poll's on
2 sockets at once and blocking in one direction will impeed the other as

well as forcing you to expose something that can be polled, (not all
channels have sockets)

The states of the orignatee channel are overridden from the default
behaviour to perform the bridge
in this case:
CS_HOLD pauses the thread.
CS_RING moves the state to CS_HOLD where it will wait until it's moved
to CS_LOOPBACK or CS_HANGUP by the originate function. 
CS_LOOPBACK runs the audio bridge code sending the audio back to the
other channel.

The originator is in CS_EXECUTE meaning it's running instructions
installed by a dialplan module.

At this point both channels are in the same code reading A and writing B
as well as moving messages and dtmf across one another.

If either is interrupted the functions exits in both sessions and the
originatee state override table 
is cleared and the session is moved to the new state where the execution
continues.  if this state is hangup
the call ends.

2. What does CS_LOOPBACK really mean?  When A calls B, B is in the
LOOPBACK state after the call is established.  Yet, the
switch_core_on_loopback() is not really called.

A)

The default for loopback is to echo the audio back to the channel, 
in the case of a bridge it's overridden to send it audio to the other
session instead
of itself.

3. When A calls B and before B answers, the caller session thread does
busy waiting by constantly calling check_channel_status().  Is there a
better approach than this?   And with this architecture how are we going
to incorporate with the voice mail and other timer-based applications?

A)

Yes this is the best approach, the originator has created the originatee
and is waiting for the endpoint module to place it into the CS_RING
state 
when this happens because we overrode it we move it to CS_HOLD and wait
for it to be answered or for a timeout to occur.
The point is we have waited for it to be safe for us to control.

4. When the orginatee hangs up, the exosip_kill_channel() was called 3
times just for the orginatee channel.  The same function is called twice
for the originator channel.  Is this by design?

A)

The should be as few calls to this as possible once it's ok to have
mutiple calls to it it just calls for any blocking to end
on a read or write operation such as the socket api call "shutdown()"
does 

We are not using exosip anymore, we have started coding mod_sofia which
is our preferred sip code.
There are several changes comming up this week you may want to study.

Thanks,

Anthony Minessale II

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

AIM: anthm
MSN:anthony_minessale at hotmail.com
JABBER:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at 66.250.68.194
iax:guest at 66.250.68.194/888
googletalk:freeswitch at gmail.com
pstn:712-432-7800

----- Original Message ----
From: Alex Guan <alex.guan at prodeasystems.com>
To: freeswitch-dev at lists.freeswitch.org
Sent: Wednesday, September 6, 2006 10:13:43 AM
Subject: [Freeswitch-dev] Questions regarding the architecture

Gang,

I am new to freeswitch and have been studying it for the last week.  A
few questions regarding the architecture.  Any input will be greatly
appreciated.

1.   Thread architecture.  For a basic call, why do we need two threads
for the sessions (one for each endpoint)?  While the thread in charge of
originator  is in the switch_core_standard_on_execute(), the other
thread is in the switch_core_session_run() while loop.    What's
advantage of doing this compared to Asterisk's one thread approach?  Why
do we need the thread for the originatee?

2. What does CS_LOOPBACK really mean?  When A calls B, B is in the
LOOPBACK state after the call is established.  Yet, the
switch_core_on_loopback() is not really called.

3. When A calls B and before B answers, the caller session thread does
busy waiting by constantly calling check_channel_status().  Is there a
better approach than this?   And with this architecture how are we going
to incorporate with the voice mail and other timer-based applications?

4. When the orginatee hangs up, the exosip_kill_channel() was called 3
times just for the orginatee channel.  The same function is called twice
for the originator channel.  Is this by design?

Thanks,
Alex

_______________________________________________
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 <http://www.freeswitch.org/> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20060906/de3d9c59/attachment.html 