Tag Archives: Sip

Session Border controller for WebRTC

Session Border Controllers ( SBC )  assist in controlling the signaling and usually also the media streams involved in calls and sessions.

They are often part of a VOIP network on the border where there are 2 peer networks of service providers such as backbone network and access network of corporate communication system which is behind firewall.

A more complex example is that of a large corporation where different departments have security needs for each location and perhaps for each kind of data. In this case, filtering routers or other network elements are used to control the flow of data streams. It is the job of a session border controller to assist policy administrators in managing the flow of session data across these borders. – wikipedia

SBC act like a SIP-aware firewall with proxy/B2BUA.

What is B2BUA?

A Back to back user agent ( B2BUA ) is a proxy-like server that splits a SIP transaction in two pieces:

  • on the side facing User Agent Client (UAC), it acts as server;
  • on the side facing User Agent Server (UAS) it acts as a client.

B2BUAs keep state information about active dialog. Read more here .

Remote Access

SBC mostly have public url address  for teleworkers and a internal IP for enterprise/ inner LAN . This enables users connected to enterprise LAN ( who do not have public address ) to make a call to user outside of their network. During this process SBC takes care of following while relaying packets .

  1. Security
  2. Connectivity
  3. Qos
  4. Regulatory
  5. Media Services
  6. Statistics and billing information

Topology hiding

SBC hides and anonymize secure information like IP ports before forwarding message to outside world . This helps protect the internal node of Operators such as PSTN gateways or SIP proxies from revealing outside.

Explaining the functions of SBC in detail

1. Security

SBCs are often used by corporations along with firewalls and intrusion prevention systems (IPS) to enable VoIP calls to and from a protected enterprise network. VoIP service providers use SBCs to allow the use of VoIP protocols from private networks with Internet connections using NAT, and also to implement strong security measures that are necessary to maintain a high quality of service. The security features includes :

  • Prevent malicious attacks on network such as DOS, DDos.
  • Intrusion detection
  • cryptographic authentication
  • Identity/URL based access control
  • Blacklisting bad endpoints
  • Malformed packet protection
  • Encryption of signaling (via TLS and IPSec) and media (SRTP)
  • Stateful signalling and Validation
  • Toll Fraud – detect who is intending to use the telecom services without paying up

2. Connectivity

As SBC offers IP-to-IP network boundary, it recives SIP request from users like REGISTER , INVITE  and routes them towards destination, making their IP. During this process it performs various operations like

  • NAT traversal
  • IPv4 to IPv6 inter-working
  • VPN connectivity
  • SIP normalization via SIP message and header manipulation
  • Multi vendor protocol normalization

Further Routing features includes  :
Least Cost Routing based on MoS ( Mean Opinion Score ) : Choosing a path based on MoS is better than chooisng any random path . 

Protocol translations between SIP, SIP-I, H.323.

In essence SBC achieve interoperability, overcoming some of the problems that firewalls and network address translators (NATs) present for VoIP calls.

Automatic Rerouting

connectivity loss from UA for whole branch is detected by timeouts . But they can also be detected by audio trough SIP OPTIONS by SBC .  In such connectivity loss , SBC decides rerouting or sending back 504 to caller .

SBC 2 (1)

4. QoS
To introduce performance optimization and business rules in call management QoS is very important . This includes the following :

  • Traffic policing
  • Resource allocation
  • Rate limiting
  • Call Admission Control (CAC)
  • ToS/DSCP bit setting
  • Recording and Audit of messages , voice calls , files
  • System and event logging

5. Regulatory

Govt policies ( such as ambulance , police ) and/ or enterprise policies may require some calls to be holding priority over others . This can also be configured under SBC as emergency calls and prioritization.
Some instances may require communication provider to comply with lawful bodies and provide session information or content , this is also called as Lawful interception (LI) . This enables security officials to collect specific information rather than examining all the traffic that passes through a particular router. This is also part of SBC.
6. Media services

Many of the new generation of SBCs also provide built-in digital signal processors (DSPs) to enable them to offer border-based media control and services such as- DTMF relay , Media transcoding , Tones and announcements etc.

WebRTC enabled SBC’s also provide conversion between DTLS-SRTP, to and from RTCP/RTP. Also transcoding for Opus into G7xx codecs
and ability to relay VP8/VP9 and H.264 codecs.

7. Statistics and billing information

SBC have an interface with and OSS/BSS systems for billing process , as almost all traffic that pass through the edge of the network passes via SBC. For this reason it is also used to gather Statistics and usage-based information like bandwidth, memory and CPU.  PCAP traces of both signaling and media information of specific sessions .

New feature rich SBCs also have built-in digital signal processors (DSPs). Thus able to provide more control over session’s media/voice . They also add services like Relay and Interworking, Media Transcoding, Tones and Announcements, DTMF etc.

Session Border Controller (SBC)

Session Border Controller for WebRTC , SIP , PSTN , IP PBX and Skype for business .

Diagram Component Description

Gateways provide compression or decompression, control signaling, call routing, and packetizing.

PSTN Gateway : Converts analog to VOIP and vice versa . Only audio no support for rich multimedia .

VOIP Gateway : A VoIP Gateway acts like a translator converting digital telecom lines to VoIP . VOIP gateway often also include voice and fax. They also have interfaces to Soft switches and network management systems.

WebRTC Gateway : They help in providing NAT with ICE-lite and STUN connectivity for peers behind policies and Firewall .

SIP trunking : Enterprises save on significant operation cost by switching to IP /SIP trunking in place of TDM (Time Division Multiplexing). Read more on SIP trunk and VPN  here. 

SIP Server : A Telecom application server ( SIP Server ) is useful for building VAS ( Value Added Services ) and other fine grained policies on real time services . Read more on SIP Servers here . 

VOIP/SIP service Provider :   There are many Worldwide SIP Service providers such as Verizon in USA , BT in europe, Swisscom in Switzerland etc .

 

Building a SBC

The latest trends in Telecommunications industry demand an open standardized SBC to cater to growing and large array of SIP Trunking, Unified Multimedia Communications UC&C, VoLTE, VoWi-Fi, RCS and OTT services worldwide . Building an SBC requires that it meet the following prime requirements :

  • software centric
  • Cloud Deploybale
  • Rich multimedia (audio , video , files etc) processing
  • open interfaces
  • The end product should be flexible to be deployed as COTS ( Commercial Off the shelf) product or as a virtual network function in the NFV cloud.
  • Multi Configuration , should be supported such as Hosted or Cloud deployed .
  • Overcome inconsistencies in SIP from different Vendors
  • Security and Lawful Interception
  • Carrier Grade Scaling

Flow Diagram 

SBC WebRTC to SIP

Thus we see how SBC became important part of comm systems developed over SIP and MGCP. SBC offer B2BUA ( Back to Back user agent) behavior to control both signalling and media traffic.


 

Advertisements

IPTV ( Internet Based Television )

We know the power of Internet protocol suit as it takes on the world of telecom . Alreday half of Communication has been transferred from legacy telecom signalling protocols like SS7 to IP based communication ( Skype , Hangouts , whatsapp , facebook call ) . The TV service providers too are largely investing in IP based systems like SIP and IMS to deliver their content over Telecom’s IP based network ( Packet switched ).

A consumer today wants HD media content anytime anywhere . The traditional TV solutions just dont match upto the expectations anymore . The IPTV provider in todays time must make investments to deliver content that is media-aware, and device-aware. Not only this it should be  personal, social, and interactive . after all its all about user  experience.

Few popular applications for IPTV solutions developers are

  • Menu overlay with detailed description of channels , categories , programs , movies
  • Replay option also referred to as timeshift . It allows a user to pause , resume and  record the show in his absence and view it later
  • Video on demand which concerns paying and viewing music albums , movies etc on demand
  • Live streaming of events such as president speech , tennis match etc .

Application that can be build around the IPTV context

  • Record and Playback content
  • Information overlay on streaming content
  • Social networking services integrated with IPTV content
  • Parental Control to realtime view , monitor and control what your child is watching on the IPTV
  • Watch the surveillance  footage from IP cameras anywhere
  • Real time communication on IPTV  with advanced features like call continuity , content sync .

Service Creation Environment (SCE ) for SIP Applications

I hoped of making a SIP application Development environment a year back and worked towards it earnestly . Sadly I wasn’t able to complete the job yet I have decided to share a few things about it here .

Aim :

Develop  a SCE ( Service Creation Environment ) to addresses all aspects of lifecycle of a Service, right from creation/development, orchestration, execution/delivery, Assurance and Migration/Upgrade of services.

Similar market products :

  • Open/cloud Rhino
  • Mobicents and Telestax

Limitations of open source/other market products:

  • Free versions of the Service Creation Environments do not offer High Availability.
  • High Cost of Deployment grade versions.

Solution Description

I propose a in-house Java based Service Creation Environment “SLC SCE”. The SLC SCE will enable creation of JAINSLEE based SIP  services. It can be used to develop and deploy carrier-grade applications that use SS7 and IMS based protocols such as INAP, CAP, Diameter and SIP as well as IT / Web protocols such as HTTP and XML.

Benefits:

  • Service Agility
  • Significantly Lower price points
  • Open Standards eliminate Legacy SCP Lock-in

Timeline

  • Java-based service creation environment (SCE) – 1.5 Months
  • Graphical User Interface (GUI) and schematic representations to help in the design, maintenance and support of applications – 1.5 months
  • SIP Resource Adapter – 1 month

Architecture

Service Creation Environment (SCE) for SIP Applications

Service Creation Environment (SCE) for SIP Applications

In essence it encompasses the idea of developing the following

  1. SIP stack
  2. Javascript API’s
  3. Java Libraries for calling SIP stack
  4. Eclipse plugin to work with the SIP application development process
  5. Visual Interface to view the logic of application and possible errors / flaws
  6. SDKs (  Service Development Kit) , which are development Environment themselves

Extra Effort required to put in to make the venture successful

  1. Demo applications for basic SIP logic like Call screening , call rerouting .
  2. tutorial to create , deploy and run application from scratch . Aimed at all sections ie web developer , telecom engineer , full stack developer etc .
  3. Some opensource implementation on public repositories like Github , Google code , SourceForge
  4. Perform active problem solving on Stackoverflow , CodeRanch , Google groups and  other forums .

—————————————————————

BEA Weblogic SIP server

Bea server is a old SIP servlet container ie application server which is used to embed control logic in a program . It is supported on jdk1.5 hence the system’s environment variables must match . Otherwise in later stages deploying applications throw class version error .

1. Install Bea Weblogic

2. Follow the Installation steps

Make domain

3. Goto the installation directory . Usually C:/bea/user_projects/mydomain/ .

click on startweblogic.cmd in windows. In case the system is linux run startweblogic.sh script

4. Open Web console on url : http://127.0.0.1:7001/console. Enter username password

default username password weblogic , weblogic .

It can also be customized for example my username and password are altanai , tcs@1234

5.  Make Converged SIP Servlet Application in any editor such as notepad , edit+ etc .

The project structure looks like

Call screening
src
build
src
web
build.xml

The SIP servlet are put side directory structure of src

For example : sample application for Call screening

package com.altanai.voice;
import java.io.IOException;
import javax.servlet.*;
import javax.servlet.sip.*;
import javax.servlet.sip.Proxy;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import java.util.*;
public class CallScreening extends SipServlet
{
private static SipFactory factory;
private static SipApplicationSession sas;
private static Proxy proxy;
public void init(ServletConfig config) throws ServletException
{
System.out.println(“Call screening SIP servlet initiated”);
super.init(config);
}
protected void doInvite(SipServletRequest req) throws java.lang.IllegalArgumentException,java.lang.IllegalStateException,javax.servlet.ServletException,java.io.IOException
{
System.out.println(“Received an Invite Request”);
if(req.getFrom().toString().indexOf(“alice”)!=-1)
{
req.createResponse(406).send();
System.out.println(“User is blocked”);
}
else
{
req.createResponse(200).send();
System.out.println(“User is not blocked”);
}
}
}

6. Build it with ant . For this go inside the application folder and run ant. Output will either be “failed to build “ or “build successfully” .

The ant  command generates the war file from SIP servlet Web application .

7. Incase of successful build . Add the application to Weblogic web console install section and activate it .

I will demonstrate this process in step by step manner . First  click on “ Lock and Edit “ Button on the left panel . Then goto Install button in the centre area and browser to the location of application war or sar we have build through ant ,

8. We can delete an application in exactly the same way . click on “ Lock and Edit “ Button on the left panel . Then goto the delete button after selecting the radio button alongside the application we want to delete.

8. For enhanced application building we can also refer to sample provided along with bea weblogic . file:///C:/bea/sipserver30/samples/sipserver/examples/src/index.html

Legacy Telecom Networks

I use the term legacy telecom system many a times , but have not really described what a legacy system actually is . In my conferences too I am asked to just exactly define a legacy system . Often my clients are surprised to hear what they have in current operation is actually fitted in our own version of definition of ” Legacy system ” . This write up is an attempt to describe the legacy landscape . It also describes its characteristics , elements and transformation .

Characteristics of Legacy Systems

1. Analog Signals

1G , introduced in 1980s , used analog signals as compared to digital in 2G onward. In 1G voice was modulated to higher frequency and then converted to digital while communication with radio towers .

2.Legacy system have ATM / Frame Relay transmission .

This  is basically Hardware  Specific and results in High Expenses.

3. Legacy systems have POTS / PSTN / ISDN as their access layer technology .

Access layer is the first layer of telecom architecture which is responsible for interacting directly with the end use / subscriber . Legacy system technologies are again Hardware  Specific , bear High Expenses and offer Low stability.

Physical transmission media include :

  • Twisted wire (modems)
  • Coaxial cable
  • Fiber optics and optical networks – Dense wavelength division multiplexing (DWDM)

4. Legacy system use Traditional Switches / ISDN in their Core Layer

Core layer is the main control hub of the entire telecom architecture . Using old fashioned switches render high CAPEX ( capital Expenditure ) and OPEX ( Operational Expenses ) .

5. In the service delivery front legacy system employ Traditional IN switches

These are very Hardware Centric.

Services part of Legacy Telecom Networks

a)Virtual Private Network (VPN)

An Intelligent Network (IN) service, which offers the functions of a private telephone network. The basic idea behind this service is that business customers are offered the benefits of a (physical) private network, but spared from owning and maintaining it

b)Access Screening(ASC):

 An IN service, which gives the operators the possibility to screen (allow/barring) the incoming traffic and decide the call routing, especially when the subscribers choose an alternate route/carrier/access network (also called Equal Access) for long distance calls on a call by call basis or pre-selected.

c)Number Portability(NP)

An IN service allows subscribers to retain their subscriber number while changing their service provider, location, equipment or type of subscribed telephony service. Both geographic numbers and non-geographic numbers are supported by the NP service.

Transformation towards IMS (Total IP)

The telecommunications industry has been going through a significant transformation over the past few years. At the outset incumbent operators used to focus on mainly basic voice services and still remained profitable due to the limited number of players in the space and requirement of huge amounts as initial investment.

However, with the advent of competitive vendors, rise in consumer base, and introduction of cost effective IP based technologies a major revolution has come about. This has enabled operators to come out of their traditional business models to maintain and enhance subscriber base by providing better and cheaper voice, multimedia and data services in order to grab the biggest possible share in this multi- billion dollar industry.

The evolution in Telecom industry has been accelerating all the time. The Next-Generation Operators wants to keep pace with the rapidly changing technology by, adapting to market needs and looking at the system and business process from multiple perspectives concurrently. Communication Service Providers (CSPs) need to consider several factors in mind before proposing any solution. They need to deploy solutions which are highly automated, highly flexible, caters to customer needs coupled with ultra low operating costs.

By hosting new services on the new platform and combining new and old services CSP‟s aim to provide service bundles that would generate new revenue streams. This process is largely dependant on IMS ( IP Multimedia Subsystem ) architecture .

Transformation towards IMS (Total IP)

Transformation towards IMS (Total IP)

Optimization in operator landscape evolve as result of synergistic technologies that come together to address the innovation and cost optimization needs of operator for better user experience. In following sections different technological evolutions that are affecting overall operator ecosystems have been discussed with focus towards Service Layer.

Legacy to IP transformation

This section broadly covered the aspects of migration from legacy IN solution to new age JAINSLEE framework based one. Applies to Legacy IN hosting voice based services mostly  such as VPN, Access Screening ,Number Portability, SIP-Trunking ,Call Gapping.

Most operator environments have seen a rise in the number of service delivery platforms. Also complexity of telecom networks have increased manifold hence CSPs are facing multiple challenges. Increased efforts and costs are required for maintaining all the SDP platforms. These platforms are generally of different vendors and cater to different technologies thereby greatly increase chances of limiting the scalability and flexibility of the operator landscape. More effort required for sustaining the life cycle of the platform and challenges in integrating non compatible SDPs due to proprietary design have been stumbling blocks in the progress of CSPs across the world.

To overcome these challenges there is trend in the market to move towards SDP consolidation wherein instead of maintaining several SDPs with their proprietary design CSPs prefer maintaining a single or less number of SDPs having standardized interfaces.

SDP consolidation SDP consolidation (1) SDP consolidation (2)

As illustrated in the above figure there is a transition that is taking place in the industry towards consolidation of service delivery session control. This would provide a cost effective sustenance of existing applications and the rapid creation and deployment of new services leading to increased revenue recognition by CSPs.

  • Agile Development
  • Innovative services
  • open SOA based architectures
  • IN/NGN Platform and Services
  • Reuse of existing investments in legacy service platforms
  • low cost of new service development
  • faster time to market
  • Monetize investment in Network Infrastructure uplift – SIP trunking, VoLTE etc.

Services that should be covered  in the Scope of Migration from fixed line to IP telephony are:

  • Virtual Private Network (VPN) : An Intelligent Network (IN) service, which offers the functions of a private telephone network. The basic idea behind this service is that business customers are offered the benefits of a (physical) private network, but spared from owning and maintaining it.
  • Access Screening(ASC): An IN service, which gives the operators the possibility to screen (allow/barring) the incoming traffic and decide the call routing, especially when the subscribers choose an alternate route/carrier/access network (also called Equal Access) for long distance calls on a call by call basis or pre-selected.
  • Number Portability(NP) : An IN service allows subscribers to retain their subscriber number while changing their service provider, location, equipment or type of subscribed telephony service. Both geographic numbers and non-geographic numbers are supported by the NP service.

WebRTC based Unified Communication platform

Using WebRTC Solution for Delivering In Context Voice which provides new monetizing benefits to the Enterprise customers of Service Providers. This includes following components:

  • WebRTC Gateway for implementation for inter-connect with SIP Legacy
  • Enhancement of WebRTC Client with new features like Cloud Address Book, Conferencing & Social Networking hooks.
  • Cloud based solutions

INtoJAISNLEE

Challenges in Migration to IMS  (Total IP )

Since long I have been advocating the benefits of migration to IMS  from a current fixed line / legacy/ proprietary VOIP / SS7 based system . However I decided to write this post on the challenges in migration to IMS system from a telecom provider’s view.  Though I could think of many , I have jot down the major 4 . they are as follows :

Data Migration challenges

  • Establishing a common data model definition
  • Data migration seamlessly
  • Configuration management
  • Extracting data from multiple sources and vendors , that includes legacy systems
  • Extracting data due to its large scale and volume

Training

  • Creating an effective knowledge share and transfer for live operations
  • Training in fallback plans, standards and policies .

Customer impact

  • Minimized customer outage
  • Enhance customer experience by delivering quality services on schedule
  • Ensuring security of customer’s confidential data
  • Transfer of customer services without any impact.

Testing in replicated environment

  • Physical pre-transfer test
  • Reducing cycle time
  • Verification and validation at every change in data environment
  • Detect production issues early in the test -lifecycle

Fallback plans

  • Pilot program and real network simulation for ensuring preparedness
  • Tracking changes in new network


Difference between WebRTC and plugin based communication

A lot of service providers ie telecom operators had deduced their own ways to provide Web based communication even before WebRTC was born . With time , as WebRTC has become stronger , more secure , resilient to failure they have come around to migrate their existing system from previous closed box native APIs to opensource WebRTC APIs.

The first figure ( given below ) depicts a communication platform build over plugins and proprietary APIs using HTTP REST based signaling .

2014-07-22_1212

Web Communication Service Architecture over HTTP/ REST API

As the migration took place the proprietary API components were replaced by Open standard based entities such as plugins were replaced by WebRTC APIs, HTTP REST based signalling was replaced by SIP ( Session Initiation Protocol ) .

Web Communication Service Architecture over WebRTC SIP

Web Communication Service Architecture over WebRTC SIP

Note telecom operator network did not had to face transformation by integration of WebRTC elements .

Tools for a Telecom software Engineer

evernote    desktop

  • Evernote for notekeeping
  • Eclipse to do real programming

github  mysql

  • Github to upload download code
  • MySQL  workbench to take care of Database Management

 

 

Technologies to Work with

 wenrtc players icon

  •  IETF
  • W3C
  • WebRTC
  • HTML
  • Java
  • GSMS standards

 

 

 

tools

Frameworks

frameworks

  • Struts
  • Hibernate
  • Spring
  • EJB

 

SIP Messages Explanied

1. Request Message

Request Message

Description

REGISTER A Client use this message to register an address with a SIP server
INVITE A User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited.
ACK This is used only for INVITE indicating that the client has received a final response to an INVITE request
CANCEL This is used to cancel a pending request
BYE A User Agent Client use this message to terminate the call
OPTIONS This is used to query a server about its capabilities

2. Response Message

Code

Category

Description

1xx Provisional The request has been received and processing is continuing
2xx Success An ACK, to indicate that the action was successfully received, understood, and accepted.
3xx Redirection Further action is required to process this request
4xx Client Error The request contains bad syntax and cannot be fulfilled at this server
5xx Server Error The server failed to fulfill an apparently valid request
6xx Global Failure The request cannot be fulfilled at any server

, based on RFC 3261


SIP headers :

Display names are described in RFC 2822
From also contains a display name and a SIP URI that indicate the originator of the request.  The From also contains a tag parameter which is used for identification purposes.
Call-ID contains a globally unique identifier for this call. Mandatory
CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.
Contact contains a SIP URI that represents a direct route to the originator usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted.  The Contact header field tells other elements where to send future requests.
Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.
Content-Type contains a description of the message body.
Content-Length contains an octet (byte) count of the message body.
sip headers 1 sip headers 2 sip headers 3

Mandatory SIP headers

  • INVITE sip:altanai@domain.comSIP/2.0
  • Via: SIP/2.0/UDP host.domain.com:5060
  • From: Bob <sip:bob@domain.com>
  • To: Altanai <sip:domain@wcom.com>
  • Call-ID: 163784@host.domain.com
  • CSeq: 1 INVITE

session description in SDP

sdp

  • v=  (protocol version)  Mandatory
  • o=  (owner/creator and session identifier).   Mandatory
  • s=  (session name)   Mandatory
  • t=  (time the session is active)   Mandatory
  • i=* (session information)
  • u=* (URI of description)
  • e=* (email address)
  • p=* (phone number)
  • c=* (connection information – not required if included in all media)
  • b=* (bandwidth information)
  • z=* (time zone adjustments)
  • k=* (encryption key)
  • a=* (zero or more session attribute lines)
  • r=* (zero or more repeat times)Media description
  • m=  (media name and transport address)  Mandatory
  • i=* (media title)

TYPICAL SIP INVITE :


INVITE sip:01150259917040@67.135.76.4 SIP/2.0

Via: SIP/2.0/UDP 69.7.163.154:5060;branch=z9hG4bK400fc6e6

From: "8069664170" <sip:8069664170@69.7.163.154>;tag=as42e2ecf6

To: <sip:01150259917040@67.135.76.4>

Contact: <sip:8069664170@69.7.163.154>

Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154

CSeq: 102 INVITE

User-Agent: MatrixSwitch

Date: Thu, 22 Dec 2005 18:38:28 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER

Content-Type: application/sdp

Content-Length: 268

v=0

o=root 14040 14040 IN IP4 69.7.163.154

s=session

c=IN IP4 69.7.163.154

t=0 0

m=audio 26784 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=fmtp:18 annexb=no - - - -

c=* (connection information - optional if included at session-level)

b=* (bandwidth information)

a=* (zero or more media attribute lines)

SIP Responses

sip resp

1xx—Provisional Responses
100 Trying
180 Ringing
181 Call is Being Forwarde
182 Queued
183 Session in Progress199 Early Dialog Terminated

2xx—Successful Responses
200 OK
202 Accepted
204 No Notification

3xx—Redirection Responses
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service

4xx—Client Failure Responses
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Conditional Request Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
417 Unknown Resource-Priority
420 Bad Extension
421 Extension Required
422 Session Interval Too Small
423 Interval Too Brief
424 Bad Location Information
428 Use Identity Header
429 Provide Referrer Identity
430 Flow Failed
433 Anonymity Disallowed
436 Bad Identity-Info
437 Unsupported Certificate
438 Invalid Identity Header
439 First Hop Lacks Outbound Support
470 Consent Needed
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected.
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
489 Bad Event
491 Request Pending
493 Undecipherable
494 Security Agreement Required

5xx—Server Failure Responses
500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure

6xx—Global Failure Responses
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

Mandatory Headers in SIP Response 
  • SIP/2.0 200 OK
  • Via: SIP/2.0/UDP host.domain.com:5060
  • From: Bob<sip:bob@domain.com>
  • To: Altanai<sip:altanai@domain.com>
  • Call-ID: 163784@host.domain.com
  • CSeq: 1 INVITE
Note : – 

Via, From, To, Call-ID 

, and  

CSeq  

are copied exactly from Request. 
You can read more about SIP based Architecture here : SIP based architecture

WebRTC communication diagrams

webrtc Real Time communication between SIP softphone supporting both SIP over websockets


webrtc Real Time communication between native SIP and SIP over Websockets


webrtc Real Time communication between clients supporting sip over websockets


SIP ( Session Initiation Protocol )

Update :

At the time of writing this article on SIP and related VOIP technologies I a newbie in VOIP domain , probably just out college . However over the past decade , looking at the steady traffic to these articles , I have tried updating the same with new RFC standards and market trends .


SIP ( Session Initiation Protocol) negotiates session between 2 parties.  It primarily exchanges headers that are used for making a call session such as example of outgoing telephone call from SIP session invite . It is a L

Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:altanai@telecomcompany.com;transport=tcp SIP/2.0
Method: INVITE
Request-URI: altanai@telecomcompany.com;transport=tcp
        Request-URI User Part: altanai
        Request-URI Host Part: telecomcompany.com
        [Resent Packet: False]

Message Header

Via: SIP/2.0/TCP 1.2.3.4:5080;rport;branch=z9hG4bKceX7a2H2866cN
        Transport: TCP
        Sent-by Address: 1.2.3.4
        Sent-by port: 5080
        RPort: rport
        Branch: z9hG4bKceX7a2H2866cN

Max-Forwards: 41

From: "+16014801797" <sip:+16014801797@1.2.3.4>;tag=7HKgjNQ6y2FSj
        SIP Display info: "+16014801797"
        SIP from address: sip:+16014801797@1.2.3.4
                SIP from address User Part: +16014801797
                E.164 number (MSISDN): 16014801797
                        Country Code: Americas (1)
                SIP from address Host Part: 1.2.3.4
        SIP from tag: 7HKgjNQ6y2FSj

To: <sip:altanai@telecomcompany.com;transport=tcp>
        SIP to address: sip:altanai@telecomcompany.com;transport=tcp
        SIP to address User Part: altanai
        SIP to address Host Part: telecomcompany.com
        SIP To URI parameter: transport=tcp

Call-ID: e10306be-0cfd-4b38-af3c-b2ada0827cef
CSeq: 126144925 INVITE
Contact: <sip:mod_sofia@1.2.3.4:5080;transport=tcp>
User-Agent: phone1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY
Supported: path, replaces
Allow-Events: talk, hold, conference, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 249
SIP Display info: "+16014801797"
SIP PAI Address: sip:+16014801797@1.2.3.4

The SIP philosophy :

  • reuse Internet addressing (URLs, DNS, proxies)
  • utilize rich Internet feature set
  • reuse HTTP coding
  • text based
  • makes no assumptions about underlying protocol:
    TCP, UDP, X.25, frame, ATM, etc
  • support of multicast

SIP URI can either be in format of sip:altanai@telecomcompnay.com (RFC 2543 ) or sips:altanai@telecomcompany.com ( secure with TLS over TCP RFX 3261) . Additionally SIP URI resolution can either be

  • DNS SRV based such as altanai@telecomcompnay.com with SIP servers locating record for domain “telecomcompnay.com ” or
  • FQDN ( Fully qualified domain name ) / contact / ip address based such as altanai@2.2.2.2 or altanai@us-west1-prod-server . Both of which do not need any resolution for routing.

Tags are pseudo-random numbers inserted in To or From headers to uniquely identify a call leg

Max forwards  is a count decremented by each proxy
that forwards the request.When count goes to zero, request is discarded and 483
Too Many Hops response is sent.Used for stateless loop detection.

Content-Type indicates the type of message body attachment. In this case application /SDP but  others could be text/plain, application/cpl+xml, etc.)

Content-Length indicates the octet (byte) count of the message body

Firewalls can sometimes block SIP packets , change TCP to UDP or change IP address of the packets. Record-Route can be used , ensures Firewall proxy stays in path . Clients and Servers copy Record-Route and put in Route header for all messages

Message body is separated from SIP header fields by a blank line (CRLF).

sip arch

SIP transaction

A SIP transaction occurs between a UAC and a UAS. The SIP transaction comprises all messages from the first request sent from the UAC to the UAS up to a final response (non-1xx) sent from the UAS to the UAC

Branch

The branch parameter is a transaction identifier. Responses relating a request can be correlated because they will contain the same transaction identifier.

Dialog

The initiator of the session that generates the establishing INVITE generates the unique Call-ID and From tag. In the response to the INVITE, the user agent answering the request will generate the To tag. The combination of the local tag (contained in the From header field), remote tag (contained in the To header field), and the Call-ID uniquely identifies the established session, known as a dialog. This dialog identifier is used by both parties to identify this call because there could be multiple calls set up between them.

Components of SIP Solution

Screen Shot 2018-08-16 at 10.11.14 PM

SIP Request methods :

  1. INVITE : Initiates negotiation to establish a session ( dialog). Usually contains SDP payload. Another invite during an existing session ( dialog) is called an RE-INVITE. A RE-INVITE can be used for
    • hold / resume a call
    • change session parameters and codecs in mid of a call
  2. ACK : Acknowledge an INVITE request by completing the 3 way handshake . If an INVITE did not contain media contain then ACK must contain it .
  3. BYE : Ends a session ( dialog).
  4. CANCEL : Cancels a session( dialog)  before it establishes  .
  5. REGISTER : Registers a user location (host name, IP) on a registrar SIP server.
  6. OPTIONS : Communicates information about the capabilities of the calling and receiving SIP phones ( methods , extensions , codecs etc )
  7. PRACK : Provisional Acknowledgement for provisional response as 183 ( session in progress) . PRACK only application to 101- 199 responses .
  8. SUBSCRIBE : Subscribes for Notification from the notifier. Can use Expire=0 to unsubscribe.
  9. NOTIFY : Notifies the subscriber of a new event.
  10. PUBLISH : Publishes an event to the Server.
  11. INFO : Sends mid session information.
  12. REFER : Asks the recipient to issue call transfer.
  13. MESSAGE : Transports Instant Messages.
  14. UPDATE : Modifies the state of a session ( dialog).

Some SIP responses :

1xx = Informational SIP Responses
100 Trying
180 Ringing
183 Session Progress

2xx = Success Responses
200 OK – Shows that the request was successful

3xx = Redirection Responses

4xx = Request Failures
401 Unauthorized
404 Not Found
405 Method Not Allowed
407 Proxy Authentication Required
408 Request Timeout
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
482 Loop Detected
483 Too Many Hops

5xx = Server Errors
500 Server Internal Error
503 Service Unavailable

6xx = Global Failures
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable

SIP callflow diagram for a Call Setup and termination using RTP for media and RTCP for control.

Screen Shot 2018-08-16 at 10.17.57 PM

SIP Transport Layers

We know the ISO OSI layers  which servers as a standard model for data communications .

sip 3

  1. Physical Layer : Ethernet , USB , IEEE 802.11  WiFi, Bluetooth  , BLE
  2. Data Link Layer : ARP ( Address Resolution Protocol ) ,  PPP ( point to point protocol ) , MAC ( Media Access control ) , ATM , Frame Relay
  3. Network Layer :  IP (IPv4 / IPv6), ICMP, IPsec
  4. Transport : TCP , UDP , SCTP
  5. Session : PPTP ( Point to point tunnelling protocol) , NFS, SOCKS
  6. Presentation : Codecs such as JPEG , GIFF , SSL
  7. Application : Application level like Call -manager/ softphone  as HTTP , FTP , DNS , SIP  , RTSP , RTP , DNS

SDP ( Session Description Protocol)

SIP can bear many kinds of MIME attachments , one such is SDP. It uses RTP/AVP Profiles for common media types . Specified by RFC 3264 . It defines media information and capabilities such as codecs , termination points .

Contains connection headers used for establishing the session . Sample SDP payload for Invite SIP above :

Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): FreeSWITCH 1532932581 1532932582 IN IP4 1.2.3.4
        Owner Username: FreeSWITCH
        Session ID: 1532932581
        Session Version: 1532932582
        Owner Network Type: IN
        Owner Address Type: IP4
        Owner Address: 1.2.3.4
Session Name (s): FreeSWITCH
Connection Information (c): IN IP4 1.2.3.4
        Connection Network Type: IN
        Connection Address Type: IP4
        Connection Address: 1.2.3.4
Time Description, active time (t): 0 0
        Session Start Time: 0
        Session Stop Time: 0
Media Description, name and address (m): audio 29398 RTP/AVP 0 101
        Media Type: audio
        Media Port: 29398
        Media Protocol: RTP/AVP
        Media Format: ITU-T G.711 PCMU
        Media Format: DynamicRTP-Type-101
Media Attribute (a): rtpmap:0 PCMU/8000
        Media Attribute Fieldname: rtpmap
        Media Format: 0
        MIME Type: PCMU
        Sample Rate: 8000
Media Attribute (a): rtpmap:101 telephone-event/8000
        Media Attribute Fieldname: rtpmap
        Media Format: 101
        MIME Type: telephone-event
        Sample Rate: 8000
Media Attribute (a): fmtp:101 0-16
        Media Attribute Fieldname: fmtp
        Media Format: 101 [telephone-event]
        Media format specific parameters: 0-16
Media Attribute (a): silenceSupp:off - - - -
        Media Attribute Fieldname: silenceSupp
        Media Attribute Value: off - - - -
Media Attribute (a): ptime:20
        Media Attribute Fieldname: ptime
        Media Attribute Value: 20

 v=0  indicates the start of the SDP content.

o=FreeSWITCH 1532932581 1532932582 IN IP4 1.2.3.4 , is session origin and owner’s name

c=IN IP4 1.2.3.4 is connect information Specifies the IP address of a session.  

m= is Media type – audio, port – 29398, RTP/AVP Profile – 0 and 101

Attribute profile – 0, codec – PCMU, sampling rate – 8000 Hz and Attribute profile – 101, telephone-event

SIP Authorization

authentication , security , confidentiality and integrity form the basic requirement for any communication system .

To protect against hacking a user account and Denial of service attacks  , SIP uses HTTP digest authentication mechanism. Here the SIP request is responded with challenge and nonce . The sender has to resend the request with MD5 hash of nonce and password ( password id never send in clear ) . Thus preventing man-in-middle attacks.

Challenge / Response Scheme :

  • Sends REGISTER   and receives 407 Challenge + nonce                           
  • Again sends REGISTER + MD-5 hash (pw + nonce) get a 200 OK

To prevent spoofing ie impersonating as server , SIP provides server authentication too. Required by ITSP’s  ( Internet telephony service providers ) .

Mobility

To provide session mobility SIP endpoints send Register request to their respective registrar as they move and update their location.

As User changes terminals , they registers themselves to the appropriate server
Location server tracks the location of user
Redirect servers prioritize the possible locations of the user
Users keep same services as located at home server, while mobile
Call is processed by home servers using RECORD-ROUTE

NAT

National Address Translator , defined by RFC 3022 to conserve network space as most packets are exchanged inside a private network itself .

All internet users whether they are using Wifi , 3G/LTE,  home AP, any other telecom data packet network  by TSP or ISP , are assigned a private IP address , which is unreachable from out side world .Addresses are assigned by Internet Assigned Numbers Authority (IANA). Private address blocks are in format of 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

Therefore when they access the Internet , this address is converted into a  globally unique public IP address through a NAT for external communication

Screen Shot 2018-08-18 at 4.33.06 PM

SIP Issues around NAT

NATs modify IP addresses (Layer 3)- SIP/SDP are Layer 7 protocols – transparent to NAT

SIP Via:, From: and Contact: headers use not-routable private addresses
SDP states that originator wishes to receive media at not-routable private addresses
If destination on the public internet tries to send SIP or RTP traffic to those private address
Traffic will be dumped by first router

Solution are to use  either Application level gateway (ALG) or STUN or Universal Plug and Pray (UPnP)

To rewrite all SIP/SDP source addresses

  • SIP Via:, From: and Contact: headers use public NAT address
  • SDP addresses use NAT public address
  • Use SIP over TCP

Use draft-ietf-sip-symmetric-response-00 and “Symmetric” SIP/RTP
Use same UDP port number for incoming/outgoing
Hold ports open for call duration
Send UDP packet typically every 30 seconds
SIP over UDP uses 30 second re-INVITE, REGISTER or OPTIONs
RTP sends at much higher frequency by default

NAPT ( Network Address Port Translator )

  • Can map multiple private IP addresses and ports to one public IP address and ports

SIP Flows

Registration

Localization Server  –Used by the Proxy Server and Redirect Server to obtain the location of the called user (one or more addresses)

Registration Server- Accept registration requests from the client applications . Generally, the service is offered by the Proxy Server or Redirect Server

DNS Server – Used to locate the Proxy Server or Redirect Server

Screen Shot 2018-08-18 at 12.46.14 PM

Call Redirection

Sending Call invite but as Redirect Server responded with 302 moved temporary , a new destination address is returned. The invite is forwarded to another proxy server which connects the sip endpoints again after consultation with Redirect server .

Screen Shot 2018-08-18 at 10.37.38 AM

In this stage of we see the call getting connected to sip endpoint via 2 proxy servers . The redirect server doesnt get into path once the initial sip request is send.

Screen Shot 2018-08-18 at 11.12.17 AM

After communication the endpoints send BYE to terminate the session

Screen Shot 2018-08-18 at 11.13.59 AM

 

Forking

This callflow deals with the use-case when a user maybe registered from multiple SIP phones ( perhaps one home phone , one car and one office desk etc ) and wants to receive a ring on all registered phone ie fork a call to multiple endpoints .

Screen Shot 2018-08-18 at 11.17.19 AM

In the above diagram we can see a forked invite going to both the sip phones . Both of them reply with 100 trying and 180 ringing, but only 1 gets answered by the user .

Screen Shot 2018-08-18 at 11.17.26 AM

After one endpoint sends 200 ok and connects with session , the other receiver a cancel from the sip server .

Screen Shot 2018-08-18 at 11.17.33 AM

Click to Dial

A web or desktop application which has HTTP can fire a API call which is interpreted by the controller or SIP server  and call is fired .

Screen Shot 2018-08-18 at 1.23.36 PM

The API can contain params for to and from sip addresses as well as any authentication  token that is required for api authentication and validation .

Source code for some of the SIP application can be found on github 

https://github.com/altanai/sip-servlets

 

SIPMLE

SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)

  • several vendors who intend to implement SIMPLE
  • provides for presence and buddy lists
  • Instant Messaging in the enterprise
  • telephony enabled user lists

 

Using SIP based Call routing algorithms and flows , one can build carrier grade communication solution . SIP solutions can hook up with existing telecom networks and service providers to be backward compatible . Also has untapped unlimited potential to integrate with any external IP application or service to provide converged , customised control both for signalling and media planes.

References :

  1. SIP by Henning Schulzrinne Dept. of Computer Science Columbia University New York
  2. International Institute of Telecommunications 2000-2004
  3. Introduction to SIP by Patrick Ferriter from ZULTYS
  4. Internet Draft, IETF, RFC 2543
  5. NTU – Internet Telephony based on SIP

IP Multimedia Subsystem ( IMS )

 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.
ims layers

Why IMS ?

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 .

 

What benefits does IMS bring ?

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 is possible 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.
  • IMS results in reduced expenses for delivering licensed content to subscribers of different types of devices, encodings, or networks.

 

The reason for widespread adoption of IMS is also that it follows standards and open interfaces  from 3GPP and ETSI, also is flexible for policy control , OSS/BSS , Value Added Services etc .

 

IMS features

1. Abstraction from Underlying Network :
IMS is essentially leading towards an open and standardized network and interface ,  irrespective of underlay network.
2. Fixed /Mobile Convergence 
Inter operability with Circuit Switched (CS) Mobile application Part (MAP)
3. Roaming 
Location awareness between home and visiting network.
4. 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
  • 2012-09-12 Rel-11 :-tbd
  • 2014-09-17 Rel-12 :- tbd
  • 2015-12-11 Rel-13 :- tbd

IMS Layers

Majorly IMS is divided into 3 horizontal layers given below :

2014-05-24_0015

•Transport / MediaEndpoint 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 and 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)
  • Open Service Access Gateway (OSA-GW), and so on.

Additional Links :


Update on IMS :

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.

Telecommunications convergence

First, the mobile phone network enabled universal, affordable, personal communication, regardless of your location.

Then in the second wave of the communication revolution, the smartphone redefined all aspects of the way we communicate with people, businesses, information and entertainment access whilst on the move. As bandwidth has increased, so has the proliferation of VoIP systems.

From the user’s perspective, modern mobile devices deliver the converged, multi-media communication and entertainment experience.

VOIP

VOIP , short for Voice over IP , is called so beacuse it not only converts your voice calls in analog voice into digital packets but also channels voice data through IP networks such as LAN , WAN , Internet etc using the Internet Protocol (IP) .

  • VOIP system on LAN ( Local Area Network ) can use it as its backbone system to establish communication between endpoints . For example : Office communication system within the same enterprise/building  .
  • Similarity  VOIP over WAN ( Wide Area Network ) use the help  of IP PBX and VoIP service provider to enable communication across Internet . For example : OTT providers and internet calls .
  • By using the services of telecom providers in support with above plan it is also possible to land a VOIP call onto a real phone over GSM / PSTN via gateways .

 

As you opt for a IP telephony system , number of factors come into picture such as :

  1. Bandwidth
    Low bandwidth has always been a big concern for IP calls . While a LAN connection ensures good experience , calls over internet or VOIP PBX are not necessarily as neat. Network switching between different Internet service providers is factor.
  2. Inter-operability
    connecting remote works / employees to the VOIP network requires interoperablity between their hand held device like android , ios , tablets , smart watch or other types od communication devices such as hardphone, desktop-systems , kiosk , surveillance cams etc
  3. Traffic
    max simultaneous call ie peak traffic rate can create bottlenecks in comm channel or worse still result in high bandwidth usage . for example as p2p conf call between 5 parties will create a mesh network between each participant resulting in 4 outgoing and 4 incoming channels .
  4. QoS (Quality of service )
    call drops , prioritize important calls
    Security
    preventing the attacks and hacks , keeping information secure by encryption end to end ,
  5. AAA
    managing Authentication , Authorization and accounting
  6. Reuse existing Hardware
    replacing old hardware or installing softphone apps on mobiles etc .
  7. Scaling
    Will the comm system grow as your business grows ?
    If yes then how easy will it be to accommodate new users , office location , remote centers etc ?
  8. Codecs
    Under low bandwidth condition it is a good idea to switch to low resolution ( in case of video ) and low bandwidth codec ( in case of audio ) .

Some of the positive aspects of using VOIP are :

  1. ROI
    Return of investment is a big factor for SME before making the switch to IP telephony inplace of traditional established system like landline phone and cables. However it is for a fact that once the VOIP comm system is setup , it most certainly reduces call costs by 70%.
  2. Third party Interations
    It is often a necessaity to integrate communication system with CRM ( content realationship management ) systems or Sales management systems . Since most web portals are on IP , VOIP fits very well, with the click to call on webpage itself .
  3. VAS
    Value Added Services , refer to services such as IVR , call recoring , find-me-follo-me , voicemail , re-routing , called ID etc . In short it can add intelligence to the way calls are managed .

Hosting the PBX

Unified communication Solutions as SaaS or IaaS refer to on-premise or cloud-hosted IP PBX Solutions. Comparison of both is as follows

On -premise Cloud Based
The solution is usually of the SaaS nature ( software as a service ) which is hosted by the consumer / business unit itself . The service provider offers his infrastructure to the consumer as a service and bills monthly / yearly etc .
Hosting the solution system on premise and setting up the infrastructure means more customization and flexibility but it also means more investment and maintenance . On the other hand hosting the solution on cloud is often a quick setup with relatively lower upfront payment. The billing is either carried out per per user basis or based on consumption . The data is synced to cloud servers for storage and can be fetched from there when required such as cloud synced Call-logs or contact-book .

Convergence Vision 

We already know some of the latest trends of industry with respect to telecom convergence such as :

FMC

Fixed Mobile Convergence (FMC) stands for integrating user’s fixed desk phone with his mobile phone. Call continuity is a VAS( Value added service ) which lets him to switch calls between different call devices even softphones , mid call also. It has multi-faced advantages such as not missing any call on account of being out of office , having the same call preferences on each device such as blocked numbers , IVR settings etc .

UC

Unified Communication refers to the accessibility of all communication and collaboration services from the users call agent ( phone / soft-phone ) . These services can include file transfer , chat , conference , call settings , blocking , white-listing , fax , cloud sync , call logs , called ID , favorites , recording .
Read more about Unified communication and collaboration here .

BYOD
Bring your own device is one of the hottest trends in industry almost across all domains where user is expected or is given to option to bring his personal laptop for official use . It is the responsibility of enterprise comm system to seamlessly integrate it with in-office communication system and provide the same privileges and security to business critical applications as preset in configuration settings .
It increases the flexibility and productivity while keeping the infrastructure cost down.

IMS provided Network Interoperability and Access Independence

ims-access-network-independence

IMS based tele-coommunication convergence described in figure below

  • clients get direct connectivity to IP PBX in offices or hotels
  • home users connect through cable wires or Wifi/WiMax
  • non SIP based legacy endpoints connect via signalling and media gateways

The access endpoints connecte to a single managed core IP network which intercoonectes with IMS core . The back end system not only manages calls and sessions but also registration  ,  billing , operations and adminstartion.

IMS convergence vision

picture courtesy – unknowni

 Intelligent Network   —>    Next Generation IMS System 

The signalling protocols migration like from signalling system 7 (SS7) to session initial protocol (SIP) have been taking place in Telco-Industry. Similarly nodes of legacy network like signal transfer point (STP) of legacy network are being migrated to call session control function (CSCF) of IMS  that allows the rapid development and deployment of enhanced, revenue-generating multimedia services for fixed, mobile and cable operators.

IMS architecture enables operators to seamlessly run a plethora of next-generation converged services over their fixed, mobile and cable networks, achieve a faster time-to-market for new services and have fewer performance bottlenecks.

converged telecommunications

Business benefits of IMS 

  1. Delivering Services: Delivering services and applications on a “wherever, however, whenever” basis.
  2. Multimedia services: Enabling service providers to offer multimedia services across both next-gen, packet-switched networks and traditional circuit-switched networks.
  3. Protocol stack: IMS architecture provides pipes and protocols onto which service providers can attach no. of applications very conveniently.
  4. Open Source standard: IMS architecture is based on open standard which makes it possible for different vendors of hardware and software to integrate with each other seamlessly.

As a subscriber, one of the main benefits of the IMS architecture is the capacity of the network to deliver the same set of services whatever the access network used.

convergence

This is made possible thanks to the centralization of the service execution process. A specific call server of the control plan (called Serving Call Session Control Function, S-CSCF) is responsible for invoking the application servers based on criteria provisioned in the central database. The S-CSCF gets these criteria (called Initial Filter Criteria) during the user’s registration in the IMS network.

Circuit Switched Voice –> Packet based VOIP 

Voice over IP revolutionized in the Telecommunication space.It also makes your communication experience much richer and nicer with a series of enhanced features and extended possibilities. The no. of user migrating from traditional circuit switched network to IP has been quite substantial in recent years. CSP are embracing VOIP technology as a potential revenue generator and investing huge chunk of money to create value propositions for themselves in VOIP.


 

Conclusion

In conclusion here are the top business benefits of adopting a converged and unified IP telephony solution such as IMS and SIP are

Cost Savings:
Saving money is the number-one reason most businesses and households make the switch to a VoIP system, VoIP systems don’t require a phone cabinet or on-site routing equipment- just phones.

Features:
VoIP also allows users to take advantage of advanced features only available on internet-based phone systems. Features like online call monitoring, and online phone system access to add or configure extensions are also available with VoIP systems.

Flexibility:
VoIP allows people to go mobile and call directly from their cell phone and be charged at low VoIP rates

Tracking Options:
Since VoIP is an internet-based system, user can track and manage their system from their computer. Most VoIP systems allow user to track call volume and call time fairly easily- a feature that can be especially helpful for businesses that bill clients hourly or for time spent on the phone.

FreeSwitch SIP and Media Server

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 is designed to route and interconnect popular 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 a number of commercial products

from start-ups to Carriers.

– freeswitch.com

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 which 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 . SIP being the most popular protocol for 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.

Architecture and Design of Freeswitch

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 .

Freeswitch

Channel Variables

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.

Expansion

  • $${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.

Setting a channel variable :

<application="set" data="rtp_secure_media=true"/>

Reading a channel variable:

<route service="E2U+SIP" regex="sip:(.*)" replace="sofia/${use_profile}/$1;transport=udp"/>

Exporting channel variables in bridge operations

  • from one to another call leg using export_var
  • exporting to a list using export application
<action application="export" data="dialed_extension=$1"/>

Custom channel variables can be defined anytime too such as

<action application="set" data="conference_auto_outcall_caller_id_name=Mad Boss"/>

Also channel variables can be limited to scope on an extension . An example of passing some channel variable to log application .

<action application="log" data="INFO Inbound call CallUUID ${call_uuid} SIPCallID ${sip_call_id}- from ${caller_id_number} to ${destination_number}"/>

If the conditions are not met, optional anti-actions are executed.

<name="is_secure" continue="true">
<-- Only Truly consider it secure if its TLS and SRTP -->
<condition field="${sip_via_protocol}" expression="tls"/>
<condition field="${rtp_secure_media_confirmed}" expression="^true$">
    <action application="sleep" data="2000"/>
    <action application="playback" data="misc/call_secured.wav"/>
    <anti-action application="eval" data="not_secure"/>
<condition>
<extension>

Inline actions are executed during the hunting phase of dialplan

Dialplan

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 .

<include>
<extension name="speak_date_time" >
<condition field="destination_number" expression="^9172$">
    <action application="answer"/>
    <action application="sleep" data="1000"/>
    <action application="say" data="en CURRENT_DATE_TIME pronounced ${strepoch()}"/>
    <action application="hangup"/>
</condition>
</extension>
</include>

There may be 3 kinds of contexts  :

  1. default  : used for all internal users  such as PBX . Local_Extension can route the call between internal users .
  2. public  : used by external world users such as DID
  3. features : other custom in call features using bind_meta_app application etc

Call Routing based on destination number and forwarding to voice mail on no answer

Configure the sip driver to use the custom context while processing the call such as ,

<profile name="telco_custom_sipprofile">
    <param name="context" value="custom_sipcontext"/>
...
</profile>

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

<context name="custom_sipcontext">
<extension name="501">
<condition field="destination_number" expression="^501$">
    <action application="bridge" data="user/501"/>
    <action application="answer"/>
    <action application="sleep" data="1000"/>
    <action application="bridge" data="loopback/app=voicemail:default ${domain_name} ${dialed_extension}"/>
</condition>
</extension>
</context>

Call routing based on day and time

<extension name="Time of day, day of week setup" continue="true">
<condition wday="2-6" hour="8-16 break="never">
<action application="set" data="office_status=open" inline="true"/>
<anti-action application="set" data="office_status=closed" inline="true"/>
</condition>
<condition wday="2-6" time-of-day="1:30-2:30" break="never">
<action application="set" data="office_status=lunch" inline="true"/>
</condition>
</extension>

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 .

<extension name="ipmatch">
<condition field="network_addr" expression="^198\.168\.1\.0$"/>
<condition field="destination_number" expression="^(\d+)$">
    <action application="bridge" data="sofia/customprofile/$1@198.168.2.0"/>
</condition>
</extension>

Note : $1 varibles value is not available outside of the condition block
Store captured values in standard variables 

<action application=”set” data=”domain_name=$${domain}”/>

Following example store stores destination_number ( freeswitch variable ) into ‘dialed_number’

<extension name="ipmatch_variable">
<condition field="destination_number" expression="^(\d+)$">
    <action application="set" data="dialed_number=$1"/>
</condition>
<condition field="network_addr" expression="^192\.168\.1\.1$">
    <action application="bridge" data="sofia/customprofile/${dialed_number}@192.168.2.2"/>
</condition>
</extension>

 

Playback

Media recording and playback in audio (wav)

<extension name="recording">
<condition field="destination_number" expression="^(4444)$">
    <action application="answer"/>
    <action application="set" data="playback_terminators=#"/>
    <action application="record" data="/tmp/audiofile.wav 20 200"/>
</condition>
</extension>

<extension name="playback">
<condition field="destination_number" expression="^(5555)$">
    <action application="answer"/>
    <action application="set" data="playback_terminators=#"/>
    <action application="playback" data="/tmp/audiofile.wav"/>
</condition>
</extension>

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

<extension name="dx">
<condition field="destination_number" expression="^dx$">
    <action application="answer"/>
    <action application="read" data="11 11 'tone_stream://%(10000,0,350,440)' digits 5000 #"/>
    <action application="execute_extension" data="is_transfer XML features"/>
</condition>
</extension>

 

Some authentication and security related dialplan applications :-

Checking user is authenticated before routing call , else respond 407

<extension name="9191">
<condition field="destination_number" expression="^9191$"/>
<condition field="${sip_authorized}" expression="true">
    <anti-action application="respond" data="407"/>
</condition>
<condition>
    <action application="playback" data="misc/connected_securly.wav"/>
</condition>
</extension>

Checking if there is TLS and SRTP security , else set not_secure

<extension name="is_secure">
<condition field="${sip_via_protocol}" expression="tls"/>
<condition field="${rtp_secure_media_confirmed}" expression="^true$">
<action application="sleep" data="1000"/>
<action application="playback" data="misc/connected_securly.wav"/>
<anti-action application="eval" data="not_secure"/>
</condition>
</extension>

Catching invalid destinations or extensions

Catch numbers which didnt match any other case. Add this extension to bottom. It plays an invalid tune

<extension name="catchall">
<condition field="destination_number" expression=".*" continue="true">
    <action application="playback" data="misc/invalid_extension.wav"/>
</condition>
</extension>

 

Call screening and blocking dialplan applications

Call Screening by name announcement

User caller’s name store in wave file

<action application="set" data="call_screen_filename=/tmp/${caller_id_number}-name.wav"/>

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

<action application="set" data="hangup_after_bridge=true" />
<action application="answer"/>
<action application="sleep" data="1000"/>
<action application="phrase" data="voicemail_record_name"/>
<action application="playback" data="tone_stream://%(500, 0, 640)"/>
<action application="set" data="playback_terminators=#*0123456789"/>
<action application="record" data="${call_screen_filename} 7 200 2"/>

If called party presses 1 connect the call, or hang up.

<action application="set" data="group_confirm_key=1"/>
<action application="set" data="fail_on_single_reject=true"/>
<action application="set" data="group_confirm_file=phrase:screen_confirm:${call_screen_filename}"/>
<action application="set" data="continue_on_fail=true"/>
<action application="bridge" data="user/$1"/>

If the called party hangs up, the caller is connected with voicemail.

<action application="voicemail" data="default $${domain} $1"/>

finally hangup

<action application="hangup"/>

Block caller

Dial *77 followed by the number to be blocked

<extension name="block_caller_id">
<condition field="destination_number" expression="^\*77(\d+)$">
<action application="privacy" data="full"/>
<action application="set" data="sip_h_Privacy=id"/>
<action application="set" data="privacy=yes"/>
<action application="transfer" data="$1 XML default"/>
</condition>
</extension>

Block certain codes

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.

<extension name="blocked_cid_npa">
<condition field="caller_id_number" expression="^(\+1|1)?((876|809)\d{7})$">
<action application="respond" data="503"/>
<action application="hangup"/>
</condition>
</extension>

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)

<include>
<extension name="public_did">
<condition field="destination_number" expression="^\+?1?(676767)$">
    <action application="set" data="domain_name=$${domain}"/>
    <action application="transfer" data="3003 XML default"/>
</condition>
</extension>
</include>

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

<menu name="demo_ivr_submenu"
greet-long="phrase:demo_ivr_sub_menu"
greet-short="phrase:demo_ivr_sub_menu_short"
invalid-sound="ivr/ivr-that_was_an_invalid_entry.wav"
exit-sound="voicemail/vm-goodbye.wav"
timeout="15000"
max-failures="3"
max-timeouts="3">
    <entry action="menu-top" digits="*"/>
    <entry action="menu-exit" digits="#"/>
</menu>

Find me Follow Me

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.

<action application="bridge" data="user/homephone0@mydomain.com, 
[leg_delay_start=5]user/officephone@mydomain.com, 
[leg_delay_start=15,leg_timeout=25] sofia/gateway/flowroute/987654321" />

DID can bridge to multiple extensions or gateways sequentially in a hunt pattern

<extension name="did_hunt">
<condition field="destination_number" expression="87654321">

<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=true"/>

<!-- this is needed to allow call_timeout to work after bridging to a gateway -->
<action application="set" data="ignore_early_media=true"/>

<!-- ring desk extension for 10 seconds. -->
<action application="set" data="call_timeout=10"/>
<action application="bridge" data="sofia/$${domain}/1001"/>

<!-- Now try cell phone, hangup after 13 -->
<action application="set" data="call_timeout=13"/>
<action application="bridge" data="sofia/gateway/voicepulse/987654321" />

<!-- No answer, transfer to voicemail -->
<action application="answer"/>
<action application="sleep" data="1000"/>
<action application="voicemail" data="default $${domain} 1001"/>

</condition>
</extension>

Ring Multiple Targets

<action application="bridge" 
data="{ignore_early_media=true}user/7001@$${domain}, 
user/7010@$${domain}, user/7022@$${domain}, user/7007@$${domain}, 
sofia/gateway/flowroute/12345678901"/>

Handle Failures and Early Media

<action application="bridge" 
data="{ ignore_early_media=true, 
monitor_early_media_fail=user_busy:3:480+620!
destination_out_of_order:2:1776.7 }
sofia/internal/3000@local.telco.com|
sofia/internal/3004@local.telco.com"/>

To detect early media fail the conditions are
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 .

 

Directory

A simple directory listing containing two groups with 2 users each

<domain name="$${domain}">
<params>
<param name="dial-string" value="{^^:sip_invite_domain=${dialed_domain}:
presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(*/${dialed_user}@${dialed_domain})}/>
</params>

<variables>
<variable name="record_stereo" value="true"/>
<variable name="default_gateway" value="$${default_provider}"/>
<variable name="default_areacode" value="$${default_areacode}"/>
<variable name="transfer_fallback_extension" value="operator"/>
</variables>

<groups>
<group name="default">
    <users>
        <X-PRE-PROCESS cmd="include" data="default/*.xml"/>
    </users>
</group>

<group name="team1">
    <users>
        <user id="1000" type="pointer"/>
        <user id="1001" type="pointer"/>
    </users>
</group>

<group name="team2">
    <users>
        <user id="1002" type="pointer"/>
        <user id="1003" type="pointer"/>
    </users>
</group>

</groups>
</domain>

1001 user’s xml

<include>
<user id="1001">
<params>
<param name="password" value="$${default_password}"/>
</params>
<variables>
    <variable name="toll_allow" value="domestic,international,local"/>
    <variable name="accountcode" value="1001"/>
    <variable name="user_context" value="default"/>
    <variable name="effective_caller_id_name" value="Extension 1001"/>
    <variable name="effective_caller_id_number" value="1001"/>
    <variable name="outbound_caller_id_name" value="$${outbound_caller_name}"/>
    <variable name="outbound_caller_id_number" value="$${outbound_caller_id}"/>
    <variable name="callgroup" value="team1"/>
</variables>
</user>
</include>

Adding users

/usr/src/freeswitch-debs/freeswitch# scripts/perl/add_user 3000

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").
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

root@ip-172-31-27-106:/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 <condition field=destination_number expression=^(10[01][0-9])$> with <condition field=destination_number expression=^30(0[123456789]|10)$>

After this goto fs_cli cmd prompt and do reloadxml

 

Installation

Quick Installation on MacOS

Download and run the dmg , screenshots attached .

 

Building from source on Ubuntu 16.04 Xenial

*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

Change to root and add freeswitch to sources.list

sudo su 
echo "deb http://files.freeswitch.org/repo/ubuntu-1604/freeswitch-unstable/ xenial main" > /etc/apt/sources.list.d/freeswitch.list

Enter freeswitch directory and Build

./debian/util.sh build-all -aamd64 -cxenial

 

Manual Process of bootstarp and cofigure

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 ../
aptitude install -y -r -o APT::Install-Suggests=true freeswitch-meta-vanilla
cp -a /usr/share/freeswitch/conf/vanilla /etc/freeswitch
/etc/init.d/freeswitch start

To see if freeswitch is running  – ps aux | grep freeswitch

fs_cli

Screen Shot 2018-09-20 at 10.45.47 AM

To check listening ports – ngrep -W byline -d any port 5060 or netstat -lnp | grep 5060

HTTP TCP 80 0.0.0.0/0
HTTP TCP 80 ::/0
Custom TCP Rule TCP 5080 – 5081 0.0.0.0/0
Custom TCP Rule TCP 5080 – 5081 ::/0
Custom UDP Rule UDP 16384 – 32768 0.0.0.0/0
Custom UDP Rule UDP 16384 – 32768 ::/0
All traffic All All 0.0.0.0/0
All traffic All All ::/0
SSH TCP 22 0.0.0.0/0
Custom TCP Rule TCP 8021 0.0.0.0/0
Custom TCP Rule TCP 8021 ::/0
Custom UDP Rule UDP 5060 – 5062 0.0.0.0/0
Custom UDP Rule UDP 5060 – 5062 ::/0
Custom UDP Rule UDP 5080 – 5081 0.0.0.0/0
Custom UDP Rule UDP 5080 – 5081 ::/0
HTTPS TCP 443 0.0.0.0/0
HTTPS TCP 443 ::/0
Custom TCP Rule TCP 8081 – 8082 0.0.0.0/0
Custom TCP Rule TCP 8081 – 8082 ::/0
Custom TCP Rule TCP 5060 – 5061 0.0.0.0/0
Custom TCP Rule TCP 5060 – 5061 ::/0

Security

-tbd

  • ACL
  • Fail2Ban
  • IPtables

Debugging and Call

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]

 

Ref :
https://freeswitch.org/confluence/display/FREESWITCH/Ubuntu+16.04+Xenial
https://freeswitch.org/confluence/display/FREESWITCH/Ubuntu+Quick+Start

My freeswitch contributor profile  https://freeswitch.org/confluence/users/viewuserprofile.action?username=altanai

Freeswitch Wiki

Freeswitch bitbucket Codebase 

 

Features set JAINSLEE vs SIP/J2EE

Feature Set JAINSLEE vs SIP/J2EE
Portability Portability of JAINSLEE is limited to number of available applications servers on the market.
Complexity 1) SIP Servlet components handle directly SIP signaling, there is no abstraction layer so there is no loss in network features. 2) If a comparison between SIP Servlets and JAIN SLEE is made it can be said that JAIN SLEE is a more complex specification than SIP Servlets and it seems that JAIN SLEE has not gained much support in the SDP industry which has been dominated by servers running J2EE.
Protocol Agnosticism Lagre number of protocols are supported in JAINSLEE using resource adapters.
Failure Handling JAINSLEE uses ACID (Atomicity,Consistency, Isolation, and Durability) properties of transactions and features of the SLEE programming model for failure handling.
Network Abstraction Capability JAINSLEE define a high level API that developers must use to access network resources.
Expandibility Expandability means whether the technology supports the addition of new protocol stack into the SDP.For that purpose the technology must provide a sort of plug-in architecture.
Flexibility Flexibility is high or low depending on the level of abstraction of network protocols.