With the sudden onset of Covid-19 and building trend of working-from-home , the demand for building scalable conferncing solution and virtual meeting room has skyrocketed . Here is my advice if you are building a auto- scalable conferencing solution
This article is about media server setup to provide mid to high scale conferencing solution over SIP to various endpoints including SIP softphones , PBXs , Carrier/PSTN and WebRTC.
Endpoints communicating over unicast. RTP and RTCP tarffic is private between sender and reciver even if the endpoints contains multiple SSRC’s in RTP session.
Advantages of P2p
Disadvantages of p2p
(+) Facilitates private communication between the parties
(-) Only limitaion to number of stream between the partcipants are the physical limiations such as bandwidth, num of available ports
Same as above but with a middle-box involved. Middle Box type are :
Translator
Mostly used interoperability for non-interoperable endpoints such as transcoding the codecs or transport convertion. This does not use an SSRC of its own and keeps the SSRC for an RTP stream across the translation.
Subtypes of Multibox :
Transport/Relay Anchoring
Roles like NAT traversal by pinning the media path to a public address domain relay or TURN server
Middleboxes for auditing or privacy control of participant’s IP
Other SBC ( Session Border Gateways) like characteristics are also part of this topology setup
Transport translator
interconnecting networks like multicast to unicast
media packetization to allow other media to connect to the session like non-RTP protocols
Media translator
Modifies the media inside of RTP streams commonly known as transcoding.
It can do up to full encoding/decoding of RTP streams. In many cases it can also act on behalf of non-RTP supported endpoints, receiving and responding to feedback reports ad performing FEC ( forward error corrected )
Back-To-Back RTP Session
Mostly like middlebox like translator but establishes separate legs RTP session with the endpoints, bridging the two sessions.
Takes complete responsibility of forwarding the correct RTP payload and maintain the relation between the SSRC and CNAMEs
Advantages of Back-To-Back RTP Session
Disadvantages of Back-To-Back RTP Session
(+) B2BUA / media bridge take responsibility tpo relay and manages congestion
(-) It can be subjected to MIM attack or have a backdoor to eavesdrop on conversations
Some more variants of this topology are Point to Multipoint with Mixer
Media Mixing Mixer
receives RTP streams from several endpoints and selects the stream(s) to be included in a media-domain mix. The selection can be through
static configuration or by dynamic, content-dependent means such as voice activation. The mixer then creates a single outgoing RTP stream from this mix.
Media Switching Mixer
RTP mixer based on media switching avoids the media decoding and encoding operations in the mixer, as it conceptually forwards the encoded media stream.
The Mixer can reduce bitrate or switch between sources like active speakers.
Middlebox can select which of the potential sources ( SSRC) transmitting media will be sent to each of the endpoints. This transmission is set up as an independent RTP Session.
Extensively used in videoconferencing topologies with scalable video coding as well as simulcasting.
Advantges of SFU
Disadvatages of SFU
(+) Low lanetncy and low jitter buffer requirnment by avoiding re enconding (+) saves on encoding decoding CPU utilization at server
(-) unable to manage network and control bitrate (-) creates higher load on receiver when compared with MCU
On a high level, one can safely assume that given the current average internet bandwidth, for count of peers between 3-6 mesh architectures make sense however any number above it requires centralized media architecture.
Among the centralized media architectures, SFU makes sense for atmost 6-15 people in a conference however is the number of participants exceed that it may need to switch to MCU mode.
There are various topologies for multi-endpoint conferences. Hybrid topologies include forward video while mixing audio or auto-switching between the configuration as load increases or decreases or by a paid premium of free plan
Hybrid model of forwarding and mixed streamings
Some endpoints receive forwarded streams while others receive mixed/composited streams.
Serverless models
Centralized topology in which one endpoint serves as an MCU or SFU.
Used by Jitsi and Skype
Point to Multipoint Using Video-Switching MCUs
Much like MCU but unlike MCU can switch the bitrate and resolution stream based on the active speaker, host or presenter, floor control like characteristics.
This setup can embed the characteristics of translator, selector and can even do congestion control based on RTCP
To handle a multipoint conference scenario it acts as a translator forwarding the selected RTP stream under its own SSRC, with the appropriate CSRC values and modifies the RTCP RRs it forwards between the domains
Cascaded SFUs
SFU chained reduces latency while also enabling scalability however takes a toll on server network as well as endpoint resources
Before getting into an in-depth discussion of all possible types of Media Architectures in VoIP systems, let us learn about TCP vs UDP.
TCP is a reliable connection-oriented protocol that sends REQ and receives ACK to establish a connection between communicating parties. It sequentially ends packets which can be resent individually when the receiver recognizes out of order packets. It is thus used for session creation due to its errors correction and congestion control features.
Once a session is established it automatically shifts to RTP over UDP. UDP even though not as reliable, not guarantying non-duplication and delivery error correction is used due to its tunnelling methods where packets of other protocols are encapsulated inside of UDP packet. However to provide E2E security other methods for Auth and encryption are used.
A Call session produces various traces for offtime monitoring and analysis which can include
CDR ( Call Detail Records ) – to , from numbers , ring time , answer time , duration etc
Signalling PCAPS – collected usually from SIP application server containing the SIP requests, SDP and responses. It shows the call flow sequences for example, who sent the INVITE and who send the BYE or CANCEL. How many times the call was updated or paused/resumed etc .
Media Stats – jitter , buffer , RTT , MOS for all legs and avg values
Audio PCAPS – this is the recording of the RTP stream and RTCP packets between the parties and requires explicit consent from the customer or user . The VoIP companies complying with GDPR cannot record Audio stream for calls and preserve for any purpose like audit , call quality debugging or an inspection by themselves.
Throwing more light on Audio PCAPS storage, assuming the user provides explicit permission to do so , here is the approach for carrying out the recording and storage operations.
Firther more , strict accesscontrol , encryption and annonymisation of the media packets is necessary to obfuscate details of the call session.
SIP is the most popular signalling protocol in VOIP ecosystem. It is most suited to a caller-callee scenario , yet however supporting scalable conferences on VOIP is a market demand. It is desired that SIP must for multimedia stream but also provide conference control for building communication and collaboration apps for new and customisable solutions.
To read more about buildinga scalable VoIP Server Side architecture and
Clustering the Servers with common cache for High availiability and prompt failure recovery
Multitier archietcture ie seprartion between Data/session and Application Server /Engine layer
Micro service based architecture ie diff between proxies like Load balancer, SBC, Backend services , OSS/BSS etc
Scalable and Flexible platform. Let’s go in-depth to discuss how can one go about achieving scalability in SIP platforms. ulti geography Scaled via Universal Router, Cluster SIP telephony Server for High Availability, Multi-tier cluster architecture, Role Abstraction / Micro-Service based architecture, uted Event management and Event Driven architecture , Containerization, autoscaling , security , policies…
To secure the publishers for a common application through username -password specific for stream names , this post is useful . It uses Module Core Security to prompt back the user for supplying credentials.
The detailed code to check the rtmp query-string for parameters and performs the checks – is user is allowed to connect and is user allowed to stream on given stream name is given below .
Initialize the hashmap containing publisher clients and IapplicationInstance
On app start initilaize the IapplicationInstance object .
public void onAppStart(IApplicationInstance appInstance)
{
this.appInstance = appInstance;
}
Onconnect is called called when any publisher tries to connects with media server. At this event collect the username and clientId from the client. Check if publisherclient contains the userName which client has provided else reject the connection .
AMFDataItem: class for marshalling data between Wowza Pro server and Flash client.
As the event user starts to publish a stream after sucessful connection Onpublishing function is called . It extracts the stream name from the client ( function extractStreamName() )and checks if user is allowed to stream on the given streamname (function isStreamNotAllowed()) .
public void publish(IClient client, RequestFunction function, AMFDataList params)
{
String streamName = extractStreamName(client, function, params);
if (isStreamNotAllowed(client, streamName))
{
sendClientOnStatusError(client, NetStream.Publish.Denied, "Stream name not allowed for the logged in user: "+streamName);
client.rejectConnection();
}
else{
invokePrevious(client, function, params);
}
}
Function when publisher disconnects from server . It removes the client from publisherClients.
public void onDisconnect(IClient client)
{
if(this.publisherClients!=null){
this.publisherClients.remove(client.getClientId());
}
}
Interoperable IMS core for heterogeneous access networks
IMS is a an architectural framework for IP based multimedia rich communications. It was standardized by a group called 3GPP formed in 1999. It started as an enabler for 3rd generation mobile networks in European market and later spread to wirelne networks too. IMS became the key to Fixed Mobile Convergence (FMC).
Based on IETF Protocols (such as SIP, RTP, RTSP, COPS, DIAMETER, etc), IMS is now crucial for controlling conmmunication in a IP based Next Genration Network (NGN).
Communication service providers and telecom operators are migrating from circuit-switched networks to IMS technology with the increasing bandwidth (5G) and user expectations.
Early days TDM networks were not robust enough to support emerging technologies and data networking. There was a need to migrate from voic eonly network to Triple play network ( voice , video and data ). Other factors included :
rapid service development
service availiability in both home and roaming network
wireline and wireless convergence
Due to these above mentioned reasons TDM was outdated and IMS gained support .
It offers counteless applications around rich multimedia services on wireless , packet swtched and even tradional circuit switched networks.
Easier to Create and Deploy New Applications and Services
(+)Enhanced applications are easier to develop due to open APIs and common network services.
(+) Third-party developers can offer their own applications and use common network services, sharing profits with minimal risk New services involving concurrent sessions of multimedia (voice, video, and data) during the same call are now possible.
(+) Reduced time-to-market for new services is possible because service providers are not tied to the timescales and functions of their primary NEPs
Capture New Subscribers,Retain Current Subscribers
(+) Better voice quality for business applications, such as conferencing, is possible
(+) Wireless applications (like SMS, and so on) can be offered to wire line or broadband subscribers.
(+) Service providers can more easily offer bundled services.
Lower Operating and Capital Costs
(+) Cost-effective implementation of services across multiple transports, such as Push-To-Talk (PTT), presence and Location-Based Services (LBS), Fixed-Mobile Convergence (FMC), mobile video services, and so on.
(+) Common provisioning, management and billing systems are supported for all networks.
(+) Significantly lower transport costs result when moving from time-switched to packet-switched channels.
(+) Service providers can take advantage of competitive offerings from multiple NEPs for most network elements.
(+) Reduced expenses for delivering licensed content to subscribers of different types of devices, encodings, or networks.
The strongest argument for adoption of IMS is that it follows established standards and open interfaces from 3GPP and ETSI. This makes it suited for interoperability, policy control accross networks, streamlined OSS/BSS, Value Added Services etc.
Abstraction from Underlying Network : IMS is essentially leading towards an open and standardized network and interface,irrespective of underlay network.
Fixed /Mobile Convergence : Inter operability with Circuit Switched (CS) Mobile application Part (MAP)
Roaming : Location awareness between home and visiting network.
Application layer Call Control : IMS application layer has the provision for defining proxy or B2BUA based call flow completion . This leads to operator being able to introduce business logic into call sessions.
IMS is supplemented by SIP (IETF), Diameter (IETF) and H248(ITU-T).The release cycle of IMS is as follows
2002-03-14 Rel-5 : IMS was introduced with SIP. Qos voice over MGW.
2004-12-16 Rel-6 : Services like emergency , voice call continuity , IPCAN ( IP connectivity Access Network )
2005-09-28 Rel-7 : Single Radio Voice Call Continuity , multimedia telephony,eCall ,ICS
2008-12-11 Rel-8 : IMS centralized services , supplementary services and internetworking between IMS and Circuit Switched Networks,charging , QoS
2009-12-10 Rel-9 : IMS emergency numbers on GPRS , EPS(Enhanced packet system) , Custom alert tone , MM broadcast/Multicast
2011-3-23 Rel-10 : home NodeB, M2M, Roaming and Inter UE transfer
Majorly IMS is divided into 3 horizontal layers given below :
Transport / Media Endpoint Layer
Unifies transports and media from analog, digital, or broadband formats to Real-time Transport Protocol (RTP) and SIP protocols. This is accomplished by media gateways and signaling gateways.
It also includes media servers with media processing elements to allow for announcements, in-band signaling, and conferencing. These media servers are shared across all applications (voicemail, interactive response systems, push-to-talk, and so on), maximizing statistical use of the equipment and creating a common base of media services without “hard-coding” these services into the applications.
Session & Control Layer
This layer arranges logical connections between various other network elements. It provides registration of end-points, routing of SIP messages, and overall coordination of media and signaling resources.
IMS core which is part of this layer primarily contains 2 important elements Call Session Control Function (CSCF) and Home Subscriber Server (HSS) database. These are explained below
HSS ( Home Subscriber Server)
It is a database of user profiles and location information . It is responsible for name/address resolution and also authorization/authentication .
CSCF ( Call Session Control Function)
Handles most routing, session and security related operation for SIP messages . It is further divided into 3 parts :
Proxy CSCF: P_CSCF is the first point of contact from any SIP UA. It proxies UE requests to subsystem.
Serving CSCF: S-CSCF is a powerful part of IMS Core as it decides how UE request will be forwarded to the application servers.
Interrogating CSCF: I-CSCF initiates the assignment of a user to an S-CSCF (by querying the HSS) during registration.
Application Services Layer
The Application Services Layer contains multiple Application Servers (AS), such as:
Telephony Application Server (TAS) – for defining custom call flow logic
IP Multimedia Services Switching Function (IM-SSF)
IMS has been mandated as the control architecture for Voice over LTE (VoLTE) networks. Also IMS is being widely adopted to mange traffic for Voice over WiFi (VoWiFi) systems.
FreeSWITCH is free and open source communications software licensed under Mozilla Public License. It if often the core of voice core to provider call routing and media control . Its core library, libfreeswitch, is capable of being embedded into other projects, as well as being used as a stand-alone application.
FreeSWITCH can route and interconnect communication protocols using audio, video, text, or any other form of media. First released in January 2006, FreeSWITCH has grown to become the world’s premier open-source soft-switch platform. This versatile platform is used to power voice, video, and chat communications on devices ranging from single calls on a Raspberry Pi to large server clusters handling millions of calls. FreeSWITCH powers several commercial products from start-ups to Carriers.
It can perform the functions of ( but not limited to )
PBX Server (Transcoding B2BUA)
IVR & Announcement Server
Conference host
Voicemail
Session Border Controller
Text to Speech (TTS)
VOIP endpoint
Class 5 softswitch
Freeswitch has a modular architecture that is both scalable and customisable. The most important modules are- Endpoint, dialplan and Application.
Application is the instruction added for a particular dial plan with an extension object. Data Arguments are also passed to an application. Examples like Set: configure extension parameter, Bridge: bridge a new channel to the existing one, Answer: answer the call for a channel, Hangup: hangup a current channel, Run an IVR menu etc
Protocols set up call legs/ channels, negotiate codecs and stream media. The endpoint module helps to bridge channels between different protocol supported endpoints like WebRTC , H323, SIP , Jingle etc. SIP being the most popular protocol for the VoIP session is implemented by mod_sofia module while RTP is inbuild into FreeSWITCH core. SRTP ( media protocol for webrtc ) is provided by mod_verto.
Freeswitch can form the basis of complicated and sophisticated communications backend framework with thousand CPS(Call per second ). It can connect to VOIP ( voice over IP ) as well as PSTN ( Public Switched Telephone network ) and PRI ( Primary Rate Interfaces – used in enterprises communication).
Core
Data strutters are opaque and operations can be invoke by APIs with routines getting maximum reuse .
Threaded Model
Enables parallel operation as every connection has its own thread. Event handlers push incoming events into threads . Sub system run in background threads .
Protocol module listens for call message and parses the call details inot an internal data structure for session management by the core’s state machine.
State Change CS_NEW -> CS_INIT
State NEW
Running State Change CS_INIT (Cur 1 Tot 274)
State INIT
SOFIA INIT
Standard INIT
The state is then changes to ROUTING. At this state the Dialplan’s is lookedup to see the operations that were defiendfor this call based on regex matching.
State Change CS_INIT -> CS_ROUTING
State INIT going to sleep
Running State Change CS_ROUTING (Cur 1 Tot 274)
Change DOWN -> RINGING
State ROUTING
Once the call flow logic is found and escuted form the dialplan the state is changes to EXECUTE.
State Change CS_ROUTING -> CS_EXECUTE
State ROUTING going to sleep
Running State Change CS_EXECUTE (Cur 1 Tot 274)
State EXECUTE
SOFIA EXECUTE
State change to Active and Exchnage_media
entering state [completed][200]
Channel [sofia/internal/from_number@sometelco.com:5060] has been answered
Callstate Change EARLY -> ACTIVE
Originate Resulted in Success: [sofia/external/to_number@ip_addr]
State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA
Running State Change CS_EXCHANGE_MEDIA (Cur 2 Tot 275)
State EXCHANGE_MEDIA
SOFIA EXCHANGE_MEDIA
Channel variables are used to manipulate dialplan execution, to control call progress, and to provide options to applications. They play a pervasive role, as FreeSWITCH™ frequently consults channel variables as a way to customize processing prior to a channel’s creation, during call progress, and after the channel hangs up.
$${variable} is expanded once when FreeSWITCH™ first parses the configuration on startup or after invoking reloadxml. It is suitable for variables that do not change, such as the domain of a single-tenant FreeSWITCH™ server.
<param name=”domain” value=”$${domain}”/>
${variable} is expanded during each pass through the dialplan, so it is used for variables that are expected to change, such as the ${destination_number} or ${sip_to_user} fields.
A Dialplan is designed to lookup list of instructions from the central XML registry within FreeSWITCH. In general dialplans are used to route a dialed call to an endpoint based on the extension and its condition. When a matching extension is found, it executes its actions . The combination of the above can create detailed control and call flow plans. FS uses Perl-compatible regular expressions (PCRE) for pattern matching. Few formats
sofia/profile2/8765@1.2.3.4 , will dial out 8765 at host 1.2.3.4 using profile2
sofia/gateway/gateway11.com/5432 , will dial through a Gateway (SIP Provider) to user 5432
sofia/profile2/8765@1.2.3.4;transport=tcp , dialing with specific transport like TCP, UDP, TLS, or SCTP.
{absolute_codec_string=PCMU}sofia/external/sip:9106@${local_ip_v4}:5080 , to specify the codecs
Speak Time and Date on Call
when dialed number matches regular expression 9172 , then call is answered , put to sleep for 1 seconds and using say application current date and time is said , then application hangs up .
When call arrives for destination 501 , the condition matches and this blocks action are executed such as in example below .
Exetnsion 501 rings , when not answered it sleeps or 1 seconds , then gets forwarded to voice mail .
If the call to 501 was answered ie handed off then further actions would not be executed
inline= true states that channel variables will be used for later reference while break=never and continue=true tell the program to keep looking for more condition matches incase of failed or successful match respectively
Match incoming network IP address with pre configured IP
Store incoming number to $1 variable and bridge the call with custom profile . Read more about sip profiles in sections below .
Routing by listening on the audio stream for a touch-tone * followed by a single digit.
If the called user dials *1, then the execute_extension::dx XML features command is executed.
<extension name="Local_Extension">
<condition field="destination_number" expression="^(10[01][0-9])$">
<action application="export" data="dialed_extension=$1"/>
<!-- bind_meta_app can have these args <key> [a|b|ab] [a|b|o|s] <app> -->
<action application="bind_meta_app" data="1 b s execute_extension::dx XML features"/>
<action application="bind_meta_app" data="2 b s record_session::${recordings_dir}/${caller_id_number}.${strftime(%Y-%m-%d-%H-%M-%S)}.wav"/>
<action application="bind_meta_app" data="3 b s execute_extension::cf XML features"/>
<action application="bind_meta_app" data="4 b s execute_extension::att_xfer XML features"/>
..
</condition>
</extension>
The dx extension in features accepts the digits and proceeds as defined with the call
Connect to the called party. On answer announce the name. since playback_terminators is set to digits , pressing any one of them will terminate the call
block certain NPAs that you do not want to terminate based on caller id area codes and respond with SIP:503 to your origination so that they can route advance if they have other carrier to terminate to.
DID – Direct Inward Dialling via dialplan Public.xml
Assume we have a DID number 676767 which is served by telco provider either over SIP trunk/PRI lines . When someone from external world calls this number , FE needs to route the call to an internal user for example user at extension 3003 ( in default .xml context)
If we are on multi domain setup , we need to setup the domain correctly .$${domain} is the default domain set from vars.xml but you can set it to any domain we have setup in user directory. Added the extra characters in from of DID number to adjust for various ISD code and number formats suffixes such as +1- ,91- , 0- etc .
IVR ( Interactive Voice Respondent ) using Menu
Main Menu – uses tts enginer and 3 attempsts to repond with timeout 10 seconds
On pressing 1 – bridge the call to conference , on press 2 – transfer to 2222 using default
On press of 3 – transfer using enum while on press 4 – play submenu. On press of 9 – goto top menu
<menu name="demo_ivr"
greet-long="say:Press 1 to join the conference, Press 2 to transfer, 3 to transfer, 4 to goto another menu"
greet-short="phrase:demo_ivr_main_menu_short"
invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
exit-sound="voicemail/vm-goodbye.wav"
confirm-macro=""
confirm-key=""
tts-engine="flite"
tts-voice="rms"
confirm-attempts="3"
timeout="10000"
inter-digit-timeout="2000"
max-failures="3"
max-timeouts="3"
digit-len="4">
<entry action="menu-exec-app" digits="1" param="bridge sofia/${domain}/888@conference.telcocompany.org"/>
<entry action="menu-exec-app" digits="2" param="transfer 2222 XML default"/>
<entry action="menu-exec-app" digits="3" param="transfer 1234*256 enum"/>
<entry action="menu-sub" digits="4" param="demo_ivr_submenu"/>
<entry action="menu-exec-app" digits="/^(10[01][0-9])$/" param="transfer $1 XML features"/>
<entry action="menu-top" digits="9"/>
</menu>
Submenu – press * to repeat menu , # to exit . the timeout is 15 seconds
If a users has lets say 3 phone – home , office and car then an incomming call should subesquently ring everywhere one by one till the user picks up the phone closet to him . leg_delay_start is the timer after which this endpoint will start riniging and leg_timeout is the duration till when this endpoint will ring.
Therfore as per below sample homephone will ring , after 5 sceonds office phone will ring and after 15 secons his cellphone 987654321 will ring . after 25 seconds call will end.
user busy – number of attempts is 3 and 480Hz 620Hz is the tone of frequency which is standard busy tone.
destination out of order – number of attempts 2 , 1776.7 Hz frequency . Note that as per condition only these frequencies are detected for action , others are ignored .
/usr/src/freeswitch-debs/freeswitch# scripts/perl/add_user 3000perl: warning: Setting locale failed.perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LANG = "en_US.UTF-8"are supported and installed on your system.perl: warning: Falling back to a fallback locale ("en_US.UTF-8").Added 3000 in file /usr/local/freeswitch/conf/directory/default/3000.xml Operation complete. 1 user added.Be sure to reloadxml.Regular expression information:Sample regex for all new users: ^3000$Sample regex for all new AND current users: ^(10(0[0-9]|1[0-9]|20)|3000)$In the default configuration you can modify the expression in the condition for 'Local_Extension'.
Adding a range of users , 3000 to 3010
Since 3000 was already added previously , it threw a warning , rest were successfully added
/usr/src/freeswitch-debs/freeswitch# scripts/perl/add_user -users=3000-3010
perl: warning: Setting locale failed.perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LANG = "en_US.UTF-8"are supported and installed on your system.perl: warning: Falling back to a fallback locale ("en_US.UTF-8").User id 3000 already exists, skipping...Added 3001 in file /usr/local/freeswitch/conf/directory/default/3001.xml Added 3002 in file /usr/local/freeswitch/conf/directory/default/3002.xml Added 3003 in file /usr/local/freeswitch/conf/directory/default/3003.xml Added 3004 in file /usr/local/freeswitch/conf/directory/default/3004.xml Added 3005 in file /usr/local/freeswitch/conf/directory/default/3005.xml Added 3006 in file /usr/local/freeswitch/conf/directory/default/3006.xml Added 3007 in file /usr/local/freeswitch/conf/directory/default/3007.xml Added 3008 in file /usr/local/freeswitch/conf/directory/default/3008.xml Added 3009 in file /usr/local/freeswitch/conf/directory/default/3009.xml Added 3010 in file /usr/local/freeswitch/conf/directory/default/3010.xml Operation complete. 10 users added.Be sure to reloadxml.Regular expression information:Sample regex for all new users: ^30(0[123456789]|10)$Sample regex for all new AND current users: ^(10(0[0-9]|1[0-9]|20)|30(0[0-9]|10))$In the default configuration you can modify the expression in the condition for 'Local_Extension'.
After adding the user to directory , users can now make outbound calls . But howver cannot be rechable for incoming calls . To enable that e need to add them to dialplan .
Creating dialplan for the newly added users in conf/dialplan/default.xml
update the existing condition
<conditionfield="destination_number"expression="^(10[01][0-9])$"> with <conditionfield="destination_number"expression="^30(0[123456789]|10)$">
After this goto fs_cli cmd prompt and do reloadxml
*experimental not suitable for production as per Freeswitch docs
The master branch depends on video libraries which are not available as packages in Debian distribution, but are available from FreeSWITCH repository , requires the use of the devscripts and cowbuilder packages.apt-get install git devscripts cowbuilder
for errors such as “The repository ‘http://files.freeswitch.org/repo/ubuntu-1604/freeswitch-unstable xenial InRelease’ is not signed.” and “The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 0xxxxxxx” please note than only debian 8 is the officially supported os version by FS now. hence is using AWS ( amazon web service ) stick with ubuntu v 14 ie Ubuntu Server 14.04 LTS (HVM), SSD Volume Type which is also free tier eligible.
Once build is successfull , install libtool-bin , libcurl4-openssl-dev , libpcre3-dev , libspeex-dev , libspeexdsp-dev ,libtiff5 ,libtiff5-dev , yasm for libvpx , liblua5.1-0-dev for scripting
For mod_enum support install libldns-dev or disable it in modules.conf
we can either install libedit-dev (>= 2.11) or configure with –disable-core-libedit-support
./bootstrap.sh
./configure
make
For errors around lua file such as Cannot find lua.h header file , just do apt-get install lua5.2 and lua5.2-dev and copy the headers file manually to freeswitch languages folder such as
cp -R /usr/include/lua5.2/ src/mod/languages/mod_lua/
or you can copy these one by one lauxlib.h lua.h lua.hpp luaconf.h lualib.h
ln -s /usr/lib/x86_64-linux-gnu/liblua5.1.so llua
sudo make install
sudo make uhd-sounds-install
sudo make uhd-moh-install
sudo make samples
If you want to make lua from source
mkdir -p ~/Developing/third_party
cd Developing
wget https://www.lua.org/ftp/lua-5.3.2.tar.gz
tar xf lua-5.3.2.tar.gz
cd lua-5.3.2.tar.gz
make linux
sudo make install INSTALL_TOP=/usr/local
cd ~/Developing/third_party/rtags/build
cmake -DLUA_INCLUDE_DIR=/usr/local/include/ -DLUA_LIBRARY=/usr/local/lib/liblua.a ../
For internal calls , originate api can be used to initiate calls such as originate ALEG BLEG
originate {origination_caller_id_number=9999988888}sofia/internal/1004@127.0.0.1:5060 91999998888 XML default CALLER_ID_NAME CALLER_ID_NUMBER
This will make a call out to sip:1004@1127.0.0.1 with the Caller ID number set to 999998888, then it will send the call to the XML dialplan using context=default. Then the dialplan will process call to 91999998888 with the Caller ID name and number specified in the fields CALLER_ID_NAME and CALLER_ID_NUMBER.
fsc_cli> originate sofia/internal/1002@127.0.0.1:5060 &echo()
switch_ivr_originate.c:2159 Parsing global variables
switch_channel.c:1104 New Channel sofia/internal/1002@127.0.0.1:5060 [5188806e-cabd-4acc-b20b-00620c3362ec]
mod_sofia.c:5026 (sofia/internal/1002@127.0.0.1:5060) State Change CS_NEW -> CS_INIT
switch_core_state_machine.c:584 (sofia/internal/1002@127.0.0.1:5060) Running State Change CS_INIT (Cur 5 Tot 122559)
switch_core_state_machine.c:627 (sofia/internal/1002@127.0.0.1:5060) State INIT
mod_sofia.c:93 sofia/internal/1002@127.0.0.1:5060 SOFIA INIT
sofia_glue.c:1299 sofia/internal/1002@127.0.0.1:5060 sending invite version: 1.9.0 -654-ed4920e 64bit
Local SDP:
v=0
o=FreeSWITCH 1538689496 1538689497 IN IP4 172.31.27.106
s=FreeSWITCH
c=IN IP4 172.31.27.106
t=0 0
m=audio 24636 RTP/AVP 9 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
m=video 19042 RTP/AVP 102
b=AS:1024
a=rtpmap:102 VP8/90000
a=sendrecv
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 ccm tmmbr
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
switch_core_state_machine.c:40 sofia/internal/1002@127.0.0.1:5060 Standard INIT
switch_core_state_machine.c:48 (sofia/internal/1002@127.0.0.1:5060) State Change CS_INIT -> CS_ROUTING
switch_core_state_machine.c:627 (sofia/internal/1002@127.0.0.1:5060) State INIT going to sleep
switch_core_state_machine.c:584 (sofia/internal/1002@127.0.0.1:5060) Running State Change CS_ROUTING (Cur 4 Tot 122612)
sofia.c:7291 Channel sofia/internal/1002@127.0.0.1:5060 entering state [calling][0]
sofia.c:7291 Channel sofia/internal/1002@127.0.0.1:5060 entering state [terminated][503]
Telecom R & D 