<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:courier, monaco, monospace, sans-serif;font-size:12pt"><DIV></DIV>
<DIV>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?</DIV>
<DIV>A)</DIV>
<DIV> </DIV>
<DIV>Every session has a thread which is managed by the state machine in the core which sees it from creation to destruction.<BR>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.<BR>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 <BR>well as forcing you to expose something that can be polled, (not all channels have sockets)</DIV>
<DIV>The states of the orignatee channel are overridden from the default behaviour to perform the bridge<BR>in this case:<BR>CS_HOLD pauses the thread.<BR>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. <BR>CS_LOOPBACK runs the audio bridge code sending the audio back to the other channel.</DIV>
<DIV>The originator is in CS_EXECUTE meaning it's running instructions installed by a dialplan module.</DIV>
<DIV>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.</DIV>
<DIV>If either is interrupted the functions exits in both sessions and the originatee state override table <BR>is cleared and the session is moved to the new state where the execution continues. if this state is hangup<BR>the call ends.</DIV>
<DIV><BR>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.</DIV>
<DIV>A)</DIV>
<DIV> </DIV>
<DIV>The default for loopback is to echo the audio back to the channel, <BR>in the case of a bridge it's overridden to send it audio to the other session instead<BR>of itself.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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?</DIV>
<DIV> </DIV>
<DIV>A)</DIV>
<DIV>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 <BR>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.<BR>The point is we have waited for it to be safe for us to control.</DIV>
<DIV><BR>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?</DIV>
<DIV> </DIV>
<DIV>A)</DIV>
<DIV>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<BR>on a read or write operation such as the socket api call "shutdown()" does </DIV>
<DIV>We are not using exosip anymore, we have started coding mod_sofia which is our preferred sip code.<BR>There are several changes comming up this week you may want to study.</DIV>
<DIV><BR>Thanks,<BR><BR> </DIV>
<DIV>Anthony Minessale II<BR><BR>FreeSWITCH http://www.freeswitch.org/<BR>ClueCon http://www.cluecon.com/<BR><BR>AIM: anthm<BR>MSN:anthony_minessale@hotmail.com<BR>JABBER:anthony.minessale@gmail.com<BR>IRC: irc.freenode.net #freeswitch</DIV>
<DIV><BR>FreeSWITCH Developer Conference<BR>sip:888@66.250.68.194<BR>iax:guest@66.250.68.194/888<BR>googletalk:freeswitch@gmail.com<BR>pstn:712-432-7800</DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: courier, monaco, monospace, sans-serif"><BR><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif">----- Original Message ----<BR>From: Alex Guan <alex.guan@prodeasystems.com><BR>To: freeswitch-dev@lists.freeswitch.org<BR>Sent: Wednesday, September 6, 2006 10:13:43 AM<BR>Subject: [Freeswitch-dev] Questions regarding the architecture<BR><BR>
<DIV>Gang,<BR><BR>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.<BR><BR>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?<BR><BR>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.<BR><BR>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?<BR><BR>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?<BR><BR>Thanks,<BR>Alex</DIV>
<DIV>_______________________________________________<BR>Freeswitch-dev mailing list<BR>Freeswitch-dev@lists.freeswitch.org<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></DIV></DIV><BR></DIV></div></body></html>