[Freeswitch-dev] freeswitch as a standard-alone sip server
Anthony Minessale
anthony.minessale at gmail.com
Fri Apr 18 17:49:27 EDT 2008
The libsofia_sip has its own concurrency model that only uses 1 thread per
UA instance. The code in our module is only our usage implementation of
that library. So each UA that has 1 ip:port to listen too manages all the
SIP traffic for that port with this alternate concurrency model that runs in
1 thread provided by mod_sofia. Each individual call is then broken into
it's own thread for I/O etc.
I can assure you, it's very efficient. We have FreeSWITCH users taking 200k
switches offline just by sending them legitimate SIP traffic.
You can call the public conference if you wish at
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
you can also join IRC at irc.freenode.net #freeswitch
On Fri, Apr 18, 2008 at 4:33 PM, xmlya <telecomsphere at 163.com> wrote:
>
> Hi Anthony,
> I saw your name on the right section of freeswitch.org homepage.
> Didn't know it was you, a big surprise! my honour to talk with you, the
> great creator to bring promising Freeswitch to the world, which will benefit
> everyone!
> Just a few days ago, I read an article about the born of Freeswitch,
> named "How does FreeSWITCH compare to Asterisk". It's a very good article
> and we can see there is a long story behind the born of Freeswitch. Every
> time a new thing born, the creator spends much more efforts than we can
> imagine. Now I know the author is you!
> Before receiving your email, I spent some time to go through
> Freeswitch source code and I think I get the answer for Q2 now.
> Perhaps I did not explain my puzzle well enough to let you understand.
> When I talked thread-safe, I mean, can messages of a same sip transaction be
> handled by multiple Freeswitch sip endpoint threads. The answer is "No".
> There can be multiple sip endpoint threads, but each thread has
> different assigned job. For example, one thread for outboud, one thread for
> nat, one thread for normal sip message processing on port 5060. These
> different threads are thread-safe and well protected within switch core
> service logic. But these threads work on different ports and for different
> purposes. For a kind of job, there is actually only one single thread.
> When you talked about thread-safe, you mean thread-safe between
> different job threads, while I mean thread-safe for a kind of job, a more
> lower level thread safe(multiple threads for single job).
>
> Below is my found,
> (1) initialization
> when sofia module is loaded, config_sofia() called
> ==> load sip profiles, check xml tag with "profiles", if the
> profile
> has "sip_ip" tag ==>
> aunch_sofia_profile_thread ==> create thread and run
> sofia_profile_thread_run, =>
> create seperate root object and nua object, register
> sofia_event_callback
> (2) Run time
> each thread runs its event loop
>
> For performance, it's very good. If you test the on multiple cores
> server, the performance should be even better.
> Last, is there online Freeswitch server for experience purpose?
> Experience plan can help promotion of Freeswitch and bring users "close
> touch", especially when the binary distributions can't cover all platforms.
>
> Thanks many, good luck!
> xmlya
>
>
>
> On Fri, Apr 18, 2008 at 1:22 PM, xmlya <telecomsphere at 163.com> wrote:
>
> >
> > Anthony,
> > Glad to have you join the discussion. Seems you are one of the
> > developers of Freeswitch and thanks for your answer. It will help us to
> > learn Freeswitch more and clarify what we don't know and misunderstand.
> >
>
>
> Yes, I am the primary author of FreeSWITCH as a matter of fact.
>
>
>
>
> > I am not a user of freeswith now. I only keep an eye on it and join
> > the mailing list to get what experts say about Freeswitch and get latest
> > update. I think I will experience Freeswitch once a stable release can be
> > seen.
> > Now let's get down to the our discussions.
> > Q1: Registar
> > Your answer: Freeswitch can act as stand-alone registar, even
> > without openser, etc.
> > OK, that's great.
> >
> > Q2: Thread-safe
> > Why I post here is that, I noticed that there was no mutex proection
> > over sofia sip transaction hash table. SIP thread run its own event loop(if
> > there is something wrong, please correct me).
> > I still don't know how many threads(only sip signaling threads)
> > Freeswith sip endpoint can launch, from technique aspect. The answer is more
> > like a function description, can you explain in detail how these threads
> > work? Or give me a link I can learn myself.
> > * "To teach you something, there is no such thing as "thread safe".
> > All code needs to be able to exist in a threaded environment to have any
> > useful purpose. This does not mean trying to use mutexes and threads on
> > your behalf. It means to design your api so that whatever code is using it
> > can implement it in a threaded environment."
> > *Are you talking about lock/mutex free programming? but the fact is
> > Freeswith is using sofia as the sip channel, so Freeswitch design must base
> > on sofia, what's the wrapper you've done, I am keen to hear the detail...
> > Thanks a lot!
> >
>
>
> No, I'm just saying that all code should be "thread safe" that's all.
>
> Our SIP module is defiantly thread safe I can assure you.
> We have people doing 450 calls per second nonstop.
> FreeSWITCH is a heavily threaded application and is tested quite
> thoroughly to work with thousands of threads at the same time.
>
>
>
> >
> >
> > Respectfully the much work you refer to that we have to do is mostly to
> > seek out and correct the page where you gentlemen were both misinformed
> > about FreeSWITCH.
> >
> > FreeSWITCH supports not only inbound and outbound registration but
> > enterprise scaled simultaneous instances of a complete SIP UA where each
> > instance can be in charge of it's own registration entities.
> >
> > Inbound registrations support multiple simultaneous registrations to the
> > same account and full subscription presence with SLA and BLF on several
> > popular SIP phones.
> >
> > Sofia is quite threaded and our sofia endpoint can easily sustain
> > hundreds of calls per second with each call in it's own thread.
> >
> > To teach you something, there is no such thing as "thread safe". All
> > code needs to be able to exist in a threaded environment to have any useful
> > purpose. This does not mean trying to use mutexes and threads on your
> > behalf. It means to design your api so that whatever code is using it can
> > implement it in a threaded environment.
> >
> > Our SIP module also does SRTP TLS SIP and wide and narrow band audio.
> >
> > Below is our spec sheet that is listed twice on our homepage in the top
> > 10% of the page.
> > http://wiki.freeswitch.org/wiki/Specsheet
> >
> > Can you please show me where you got the information that we do not
> > support registrations so I may correct it because clearly that document is
> > in excess of 2 years old since we have supported registration since at least
> > 2006 (about 8 months into the projects start from scratch)
> >
> >
> > On Fri, Apr 18, 2008 at 10:12 AM, xmlya <telecomsphere at 163.com> wrote:
> >
> > >
> > > Brian,
> > > I think I can understand Pete Kay. His concern is whether
> > > Freeswitch can have registration function in one day, or the development
> > > activity for this feature has been scheduled.
> > > By the way, as said in the website documents, Freeswitch is a
> > > multi-threaded softswitch and has different endpoints for each protocols,
> > > SIP, H.323, etc. My question is, does each endpoint use multiple threads,
> > > say SIP endpoint? It seems that sofia is not thread-safe, how did
> > > Freeeswitch use this library? If it is used in multi-thread environment,
> > > there is much work to do.
> > > Don't have time to look into the code yet. And see your back and
> > > forth email.
> > > Thanks for your reply!
> > >
> > > Regards,
> > > xmlya
> > >
> > > This really isn't for us to decide. OpenSER is built for that so you
> > > have to make the choice on what tool to use for your needs.
> > >
> > > On Apr 18, 2008, at 7:41 AM, Pete Kay wrote:
> > >
> > > > I have a question for the creators of freeswitch. With freeswitch,
> > > > people are still going to need Openser to do sip registering and it
> > > > is understandable that a pure sip register is more efficient. The
> > > > problem with Openser is that it is not that easy to config as
> > > > compared to freeswitch. So, I am wondering does it make sense for
> > > > use part of the current freeswitch function to just make a
> > > > "freeser" ( for pure sip registration) so that users can enjoy an
> > > > efficient sip server and the ease-of-use from the freeswitch design?
> > >
> > > Brian Westsip:brian at freeswitch.org <sip%3Abrian at freeswitch.org>
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> > > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
> > >
> > >
> > >
> > > ------------------------------
> > > ìÎè׬QQÐãÓ®ÂÃÐÐȯ <http://popme.163.com/link/004062_0416_4599.html>
> > > _______________________________________________
> > > 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
> >
> >
> >
> > ------------------------------
> > ìÎè׬QQÐãÓ®ÂÃÐÐȯ <http://popme.163.com/link/004062_0416_4599.html>
> > _______________________________________________
> > 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
>
>
>
> ------------------------------
> ìÎè׬QQÐãÓ®ÂÃÐÐȯ <http://popme.163.com/link/004062_0416_4599.html>
> _______________________________________________
> 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/20080418/27fc9715/attachment-0001.html
More information about the Freeswitch-dev
mailing list