Page tree
Skip to end of metadata
Go to start of metadata


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.



 Click here to expand Table of Contents


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_gsmopengsmopen Supports voice & SMS over a GSM network
PortAudiomod_portaudioportaudioFor interacting with the sound card on your computer


You can also use the verto_contact function to generate the dialstring

WebRTCmod_rtc rtcThis endpoint is only for media, not signaling
RTMP (flash)mod_rtmprtmp

You can also use the rtmp_contact function to generate the dialstring

TDMmod_freetdmfreetdmProvides 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.