Skip to main content



Every call leg (channel) is by definition a connection between FreeSWITCH and something else. That something else can be a VoIP phone, a PRI connection or even an audio device on your computer. Each type of device has their own protocol for setting up channels, negotiating codecs, sending and receiving media. In FreeSWITCH a channel itself is not tied to a specific protocol, instead it uses an Endpoint module to implement the protocol. This architecture allows us to bridge channels using different protocols. It also allows us to easily implement new protocols.

You will sometimes see the term Session, this is a programmatic interface used by Endpoint modules to create and manage a channel.


There are 2 types of protocols used for communications.

Signaling - these protocols are responsible for notifying the other party of our intention to start a communication channel, negotiating all the details required for setting up the channel, status of the channel and ending the channel

Media - These protocols handle the actual media streams.

The most popular signaling protocol for VoIP is SIP, In FreeSWITCH we use the Sofia SIP Stack. The endpoint module that ties Sofia to FreeSWITCH is mod_sofia.

For any type of internet calls RTP is usually used for the Media protocol. In fact RTP is actually built into the FreeSWITCH core.

Another popular protocol is WebRTC (which uses SRTP). WebRTC is only a media protocol, it's not a signalling protocol. Many people use SIP as the signaling protocol for WebRTC. In FreeSWITCH we support that, however we also have our own signalling protocol called Verto which is designed to be javascript friendly.


How does FreeSWITCH know which endpoint module will handle a particular channel?

For incoming channels it's pretty simple. When an endpoint module is loaded, it starts listening for connections using the information in the configuration file, the listener can be tied to an IP Address and port in case of a VoIP protocol, or it can be a physical port on a connected piece of hardware, in either case, the endpoint module that's listening on that port is the one that will handle the call.

For outgoing channels, you have to specify which endpoint to use. When you start an outgoing channel, you use a dialstring to identify the recipient. The dialstring starts with the identity of the endpoint module that should be used, followed (optionally) by additional information specific to the module, then finally the destination number. The components of a dialstring are separated by a "/" For example to make a call using the SIP protocol your dialstring would look something like



ProtocolModuleDialstring PrefixComments
SIPmod_sofiasofiaThis is the most commonly used endpoint
SCCP (Skinny)mod_skinnyskinny
Jingle (google talk)mod_dingalingdingaling
GSMmod_gsmopengsmopenSupports voice & SMS over a GSM network
PortAudiomod_portaudioportaudioFor interacting with the sound card on your computer
Vertomod_vertoverto.rtcYou can also use the verto_contact function to generate the dialstring
WebRTCmod_rtcrtcThis endpoint is only for media, not signaling
RTMP (flash)mod_rtmprtmpYou can also use the rtmp_contact function to generate the dialstring
TDMmod_freetdm)freetdmProvides support for telephony cards from manufacturers such as Digium, Sangoma and Zaptel. Can communicate in most legacy telephony protocols such as ISDN, SS7 & analog

There are also a few pseudo Endpoint Modules that don't actually handle any calls themselves, but provide shortcuts or customized functionality to the other endpoints. These are listed on the bridge page.