VoIP Mailing List Archives

[codecomplete at free.fr]

Hello

Even though I successfully set up an Asterisk voice server, I'm no
telecom expert, and would like some clarification about the following things:
- What is an SIP server as opposed to a IP PBX?
- What is the different between a PBX like Asterisk and a softswitch?

Thank you.


_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[brian at freeswitch.org]

It depends on how you look at it... most will say there is no difference... but last I checked you usually don't run heavy apps on a softswitch.


FreeSWITCH can be everything from softphone to softswitch and everything in between including PBX. The default config comes configured as a PBX.


/b


On Feb 28, 2009, at 9:47 AM, Fred wrote:

[dyfet at gnutelephony.org]

Where this is distinguished, it is not directly at the level that user's
experience the end result.

In the case of what is called a "softswitch", one answer is found in
organizations like the ISC (International Softswitch Consortium) and
vendors who built products around their architecture recommendations.
These systems tend to be very complex and componetized, where basic
functionality operates in self-contained components that then interact
with the whole through defined open standards and network protocols,
such as SIP.

The primary reason for ISC-style architectures is a result of
proprietary development, where code and internal operations cannot be
shared or modified. Hence, by breaking up functionality into
subcomponents, it is possible to replace a component subsystem as a
whole while retaining the interfaces. A perfect example is call
forwarding. In a "traditional" proprietary (ISC-model) softswitch, call
forwarding would be an entirely separate self-contained proprietary
"feature" server interacting over SIP. If someone wants to create a
different call forwarding behavior, one slips in an alternate server.

By contrast, it is far easier in an open source/free software PBX to
simply modify the feature code that implements call forwarding directly
to create new and specialized versions of that feature. Hence, you do
not find or have need for micro-services for tiny features in pbx
software that originated as open source and free software or that did
not follow the path of proprietary architectures, such as Bayonne,
Asterisk, or FreeSwitch. A perfect example of a traditional
"softswitch" architecture is SipX, which originated as a proprietary
VoIP pbx codebase.

However, even at this point, such distinctions I think are still
somewhat artificial, as Brian suggests. What does distinguish
architectures that may be relevant to end users is whether a IP-PBX
solution operates as a B2BUA (back-to-back user agent) or not. A pure
B2BUA solution is one where all media as well as signalling goes
directly through the central PBX switch. A perfect example of this is
how Asterisk traditionally works. This makes it very easy to adapt and
connect multi-protocol endpoints, to convert media formats for endpoints
who do not have common codecs, etc, since all media endpoints talk to
the switch rather than each other. However, since all media goes
through a central point, the scalability of such systems can often
become "compute-bound", and extra latency is induced.

A "pure" network solution by contrast has all media connect directly
peer to peer by the user agent endpoints, and the "pbx" really only
handles and coordinate independently operating endpoints through
signalling. This often requires separate servers for gateways to the
PSTN or other protocols. But it does offer better latency and
scalability, and the ability to provide end-to-end media security, such
as when using ZRTP.

This difference, between B2BUA and non-B2BUA, is I think far more
relevant today than traditional classifications such as IP-PBX,
softswitch, "SIP Server", etc.

Brian West wrote: