Innovations in telecommunication today are largely driven by the advancements in Open source tech tools, standards and stacks. IP-based video and voice communication systems, Unified Communication systems such as Enterprise CPaaS platforms or even an external independent VoIP provider. The challenge for service providers today is that operating costs are growing faster than revenues. A large number of growing systems and vendors make operation a complex and expensive process.
Discrepancies between traffic growth and revenue growth (Source: Accenture)
Maintaining a network for communication service providers can be a complex and challenging task for several reasons:
Network maintenance and upgrades: Service providers must constantly maintain and upgrade their networks to ensure that they are able to provide reliable service to their customers. This can involve replacing outdated equipment, installing new technology, and troubleshooting issues that arise.
Managing traffic: Service providers must manage the traffic on their networks to ensure that it is distributed efficiently and that users are able to access the services they need. This can be a challenge, especially when the network is congested or there are unexpected spikes in traffic.
Ensuring security: Communication networks are vulnerable to a variety of security threats, including hacking, malware, and denial of service attacks. Service providers must take measures to protect their networks and their customers’ data from these threats.
Managing costs: Maintaining a communication network can be expensive, and service providers must find ways to manage costs while still providing high-quality service to their customers.
Meeting regulatory requirements: Service providers must comply with a variety of regulations, including those related to privacy, data protection, and network security. Failing to comply with these regulations can have serious consequences, including fines and reputational damage.
Network virtualization is the process of creating a virtual version of a network, including the hardware, network topology, and protocols, using software. This allows multiple virtual networks to be created and run on the same physical infrastructure, which can be used to isolate different network environments, test new network configurations, or provide network resources as a service.
NV = NFV + SDN
NFV is SW-defined network functions with separation of HW and SW. Once network elements are SW-based, network HW can be managed as a pool of resources
SDN is Interconnecting Virtual Network Functions with separation of control and data plane. Orchestration together with SW domain
There are several ways to implement network virtualization, including using software-defined networking (SDN) technologies, which allow the network to be controlled and managed using software, and using virtualization technologies such as virtual LANs (VLANs) or virtual private networks (VPNs) to create isolated network segments within a larger network. In a virtualized network the setup network functionalities are SW-based over COTS HW. Multiple roles can be made over same HW.
Network Virtualisation is an opportunity to build mouldable networks and redefine the architecture to make the infrastructure uniform.Virtual network services lowered CAPEX. Lessening dependencies on proprietary hardware and dedicated appliances.
(+) Improves management of risk in a changing and ambiguous environment
(+) capacity alteration Network flexibility
(+) scalability
(+) Service provisioning speed
(+) holistic management:
(+) granular security
There are several approaches to network virtualization that service providers can use, including:
Network Function Virtualization (NFV): NFV involves virtualizing network functions, such as routers, firewalls, and load balancers, and running them on standard servers or other off-the-shelf hardware using virtualization platforms like VMware or OpenStack.
Software-Defined Networking (SDN): SDN involves separating the control plane (which determines how data is routed through the network) from the data plane (which carries the actual data). This allows the control plane to be more flexible and responsive to changes in the network.
Virtual Private Network (VPN): A VPN allows service providers to create virtual private networks (VPNs) over the public Internet, allowing them to securely connect users to the resources they need.
Service providers can use network virtualization to reduce costs, increase flexibility, and improve the scalability and reliability of their networks. Managed Service Providers (MSPs) can use a single viewpoint and toolset to manage virtual networking, computing and storage resources. However, implementing network virtualization can also be complex and require significant investments in hardware, software, and training.
A software-defined network (SDN) is a networking architecture that uses software provisioning interfaces to control and manage the flow of traffic in a network. In an SDN, the control plane, which determines how data is routed through the network, is separated from the data plane, which carries the actual data traffic.
The main benefit of an SDN is that it allows the control of the network to be abstracted from the underlying hardware. This makes it possible to use software to dynamically configure the network, rather than relying on fixed configurations that are set using hardware switches and routers. SDN allows network administrators to easily and quickly change the way that data is routed through the network, which can be useful in a variety of scenarios. For example, an SDN can be used to optimize the flow of traffic in a data center, or to quickly reconfigure a network in response to changing traffic patterns or security threats such as DDoS.
Control plane: The control plane is the part of the SDN that determines how data is routed through the network. It consists of a central controller, which is a software application that runs on a server, and a series of software agents that run on the network devices (such as switches and routers). The controller communicates with the agents using a protocol such as OpenFlow, which allows it to control the flow of traffic in the network.
Data plane: The data plane is the part of the SDN that carries the actual data traffic. It consists of the network devices (such as switches and routers) that forward data packets through the network.
Management plane: The management plane is the part of the SDN that is responsible for configuring and managing the network. It consists of a set of tools and applications that allow network administrators to monitor and control the network.
Application plane: The application plane is the part of the SDN that consists of the applications that run on the network. These applications may include things like web servers, email servers, and database servers.
Software-defined network functions separates hardware and software. Once network elements are Software-based, network harware can be managed as a pool of resources. Separating route/switching intelligence from packet forwarding reduces hardware prices as routers and switches must compete on price-performance features.
SDN interconnects Virtual Network Function and orchestrated with SW domain. Enables separation of control and data plane.Setting up networks in an SDN can be as easy as creating VM instances, and the way SDNs can be set up is a far better complement to VMs than plain old physical networks. SDNs enable “network experimentation without impact”. Overcome SNMP limitations and experiment with new network configurations without being hamstrung by their consequences.
Infrastructure Savings
Reducing margin of Error : By eliminating manual intervention, SDNs enable resellers to reduce configuration and deployment errors that can impact the network.
Operational Savings: SDNs lower operating expenses. Network services can be packaged for application owners, freeing up the networking team.
Flexibility: SDNs create flexibility in how the network can be used and operated. Resellers can write their own network services using standard development tools.
Better Management gives Better visibility into the network, computing, and storage
SDN protocols : OpenFlow, NETCONF. Its applications could be
Bandwidth on Demand or test networks.
Platform Virtualization for emulation/simulation of Network Nodes (BSS/MSS)
SDN based Application Layer Traffic Optimization
Intrusion Detection System that can interact with controller in terms of capturing packets, analyzing them for anomaly and sharing results real-time / near real-time with controller.
Software-Defined Branch and SD-WAN
IP Multi-Media Subsystem (IMS)
Session Border Control (SBC)
Video Servers
Voice Servers
Universal Customer Premises Equipment (uCPE)
Content Delivery Networks (CDN)
Network Monitoring
Network Slicing
Service Delivery
Network security functions such as firewalls, IDS, IPS, vRR, NAT
Network Function Virtualization (NFV) is a technology that allows network functions, such as routers, firewalls, and load balancers, to be implemented in software rather than hardware. This allows these functions to be run on standard servers or other off-the-shelf hardware, rather than dedicated appliances.
In an NFV system, network functions are implemented as software called Virtual Network Functions (VNFs). These VNFs are run on virtualization platforms, such as VMware or OpenStack, which allow multiple VNFs to be run on the same physical hardware. To use NFV, a service provider will first define the network functions that it needs in its network, and then create VNFs for each of these functions. These VNFs can then be deployed on virtualization platforms and used to build the service provider’s network.
One of the main benefits of NFV is that it allows service providers to be more flexible and agile in building and managing their networks. Because VNFs can be easily added, removed, or scaled up or down as needed, service providers can quickly respond to changes in demand or new business opportunities. NFV decouples network functions from proprietary hardware appliances (routers, firewalls, VPN terminators, SD-WAN, etc.) and delivers equivalent network functionality without the need for specialized hardware. And this way it helps service providers reduce costs, as they can use standard hardware rather than specialized appliances ( vendor lockins) to implement their network functions.
A traditional appliance based IMS setup is dedicated to every single service, limited hardware/people/process leveraging.Some drawbacks of this approach is
Not suited for Heterogeneous Networks that are evolving – inflexible
Higher footprint cost per customer/service – high OPEX
New services would need a new dedicated network thus high maintenance cost for solios of operation
Virtualisation will help to redesign the network architecture. In an IMS (IP Multimedia Subsystem) system, VNFs might be used to implement a variety of functions, including:
Call Session Control Function (CSCF): The CSCF is responsible for managing call sessions and routing signaling messages between the IMS network and other networks.
Media Gateway Control Function (MGCF): The MGCF is responsible for translating between different media formats, such as voice and video, and for controlling media gateways that connect the IMS network to other networks.
Home Subscriber Server (HSS): The HSS is a database that stores information about IMS subscribers, including their profiles and service subscriptions.
Serving Gateway (S-GW): The S-GW is responsible for routing data packets between the IMS network and the user’s device.
Policy and Charging Rules Function (PCRF): The PCRF is responsible for enforcing policy decisions and charging rules for IMS services.
IP-SM-GW (SMS Gateway): The IP-SM-GW is responsible for routing SMS messages between the IMS network and other networks.
Presence Server: The presence server is responsible for managing presence information (such as availability status) for IMS subscribers.
Multi-tenant subscriber and service environment. Keeping traffic local but with common services & management
Local Data Centre can rapidly build Network Intelligence rationalisation using Real Time Network Analytics on virtul STB, EPC, NAT, BRAS, PE, DHCP , PCRF etc. Core can be simplified and centralised with common and standard interfaces within core network and services to interact with OSS and BSS (standardized billing and fulfillment process).
OpenStack is an open-source virtualization platform. It enables service providers to deploy virtual network functions (VNFs) using commercial off-the-shelf (COTS) server hardware. OpenStack is widely used in the telecommunications industry, as it allows service providers to build and manage large-scale cloud computing environments that can be used to deliver a wide range of services, including virtualized infrastructure, NFV, and containerized applications. Applying Openstack to virtualize networks :
Infrastructure as a Service (IaaS): OpenStack can be used to create and manage virtualized infrastructure, including compute, storage, and networking resources. This allows service providers to offer users the ability to spin up and manage virtual machines, storage volumes, and other resources on demand.
Network Function Virtualization (NFV): OpenStack can be used as a platform for virtualizing network functions, such as routers, firewalls, and load balancers, and running them on standard servers or other off-the-shelf hardware.
Container orchestration: OpenStack can be used to manage containerized applications, allowing service providers to deploy and scale applications more quickly and efficiently.
Image Credits OpenStack Wiki Example of OpenStack implementation. Image source: OpenStack Wiki
With the dawn of IP telephony service and cloud communication platforms in recent years, the SIP has caught the attention of many application developers. while SIP is essentially a session management multimedia signalling protocol its generic stack can be used for various use cases from IoT camera streaming sessions to call centres even auto calling for purpose of sharing OTP(one-time password) etc. In this I will highlight the usecase of large calltraffic and the use of SIP trunks.
SIP based trunking can provide significant cost savings and business process improvements by supporting the native SIP protocol that controls the VoIP systems used in call centres and business communication platforms.
(+) unified communication
(+) lower telco network
(+) streamline operations for multicountry/ geography
In the past, telephone systems used trunk lines to connect different parts of the network. Trunk lines were long-distance communication lines that connected telephone exchanges in different locations. Trunk calls were calls made over these trunk lines. They were typically used for long-distance communication, as they allowed calls to be made between exchanges that were geographically far apart. Trunk calls were generally more expensive than local calls, as they involved the use of long-distance communication lines.
Traditional trunk calls operated like a circuit with local loops , trunk lines and switching offices. The telco acted as carriers that sell of lease communication lines to facilitate communication over long distances using local exchanges and interexchange carriers.
In the early days of telephone systems, trunk lines were typically made of copper wires or cables. Later, trunk lines were replaced with satellite links and fiber optic cables, which provided higher capacity and faster transmission speeds. Today, with the widespread adoption of VoIP (Voice over Internet Protocol) technology, many telephone systems no longer use trunk lines in the traditional sense. Instead, they use virtual connections, such as SIP trunks (Session Initiation Protocol trunks), which allow organizations to make and receive phone calls over the internet. SIP trunks are generally more flexible and cost-effective than traditional trunk lines, and do not require the installation of additional hardware.
Voice trunk Lines in SS7 based Next Generations IN networks used media gate ways and MGCP, H323 protocols
SIP is a protocol that is commonly used in VoIP (Voice over Internet Protocol) systems to set up, modify, and terminate sessions that involve the exchange of audio, video, and other media. SIP Trunks are virtual voice channels (or paths) which deliver media (voice, video, IM) over an IP network to a designated endpoint. SIP Trunks can be thought of as a virtual line or concurrent call path. SIP Trunks are delivered over an IP connection like Tier One Carrier or Voice Optimized Recommended or UDP. SIP Trunk may be over-subscribed ie can have more numbers than trunks for example G.711 – 17 calls over T1 or G.729a – 45 calls over T1. SIP Trunking can be provided as one-way or two-way lines. Direct Inward Dialing (DIDs) can be used for toll-free number service.
Centralized SIP Trunk Model is designed to aggregate all calls from all sites and funnels them into a single entry point. Each site has its own SIP trunk termination of the appropriate capacity for calls to and from that site.
Such SIP trunks models offer benefits in three significant areas:
Cost savings, arising from many factors including reduced telecommunications network charges and streamlined operations.
Unified communications, where voice, video, email, text and other messaging technologies are combined to provide greater flexibility for users by enabling new ways to transfer information and manage connectivity. Many SIP trunk providers offer advanced features such as call forwarding, call waiting, and voicemail, which can improve the overall communication experience for employees.
Business Continuity and Disaster Recovery, where the right physical configuration in conjunction with intelligence in the network can be leveraged to provide uninterrupted communications and alternative means to stay connected for employees in the event of system bottlenecks or failures.
SIP Trunking is a low-cost IP-based alternative to ISDN offering for medium to large businesses needing upwards of several tens of channels in a trunk, often across multiple sites, with IP VPN access.
(+) Optimal utilization of bandwidth by delivering both data and voice in the same bandwidth
A telephony company such as a telecom service provider may expose SIP trunks as a means of connecting inbound or outbound calls through its telecom network. For the integrator ( or the service provider managing the other enedpoint of the call leg ) it can be no different that a traditional phone call.The SIP signalling however is useful for enabling better session understaning using standard SIP requests and responses as compared to SS7 or PRI lines.
•Cost analysis •Assess traffic volumes and patterns •Assess network design implications •Emergency call policy •Define production user community phases •Define user community to pilot •Evaluate future new services •Assess security precautions
The steps to set up a SIP trunk connection may vary depending on the specific provider and the equipment being used. However, here are some general steps that are often involved in the process:
Choose a SIP trunk provider: Research and compare different SIP trunk providers to find one that meets your organization’s needs and budget.
Sign up for a SIP trunk account: Follow the provider’s instructions to sign up for a SIP trunk account. This may involve completing an online form, providing contact information and payment details, and selecting the desired features and services.
Configure your VoIP phone system: Consult your VoIP phone system’s documentation to learn how to configure it to work with a SIP trunk. This may involve specifying the SIP trunk’s IP address and port number, as well as any authentication credentials that are required.
Test the connection: Once the SIP trunk is set up, it is a good idea to test the connection to ensure that it is working properly. Make a few test calls to verify that the connection is functioning as expected.
Use the SIP trunk: Once the SIP trunk is set up and tested, it can be used to make and receive calls using your VoIP phone system.
SIP Trunking platform has to integrate with multiple networks seamlessly. Components for setting up a SIP trunking system requires atleast these
Compliance with standrad signalling protol, like SIP.
SBC( Session Border Controller ) facing the private PBX
Gateway for specific endpoints such as PSTN gateway , public internet gateway etc
L3/L4 Layer switches
Telco operator lines
Codec support
Kamailio is an open-source SIP (Session Initiation Protocol) server that can be used to create a SIP trunk. Kamailio can be PBX used to connect different locations within an organization, enabling employees to communicate with each other using their VoIP phones. Kamailio can also be used to set up a SIP trunk in a number of ways. For example, it can be used to connect an organization’s VoIP phone system to the public telephone network, allowing employees to make and receive calls from outside the organization.
Kamailio is a highly flexible and customizable SIP server that can be configured to meet the specific needs of an organization. It offers a range of features and functionality, including call routing, load balancing, and security. Kamailio is a popular choice for organizations that want to set up a SIP trunk because it is open-source and can be customized to meet their specific needs.
SIP trunk with VoIP phone systems are often preferred over traditional phone systems because they are generally more flexible and cost-effective. They allow employees to make and receive calls from any device with an internet connection, including desk phones, smartphones, and laptops. They can be easily scaled up or down to meet changing communication needs and do not require the installation of additional physical hardware. Some factors to consider when evaluating SIP trunks include:
Cost: It is important to compare the costs of different SIP trunk providers and consider factors such as monthly fees, per-minute charges, and any additional fees for features or services.
Coverage: Make sure that the SIP trunk provider has coverage in the areas where your organization needs to make and receive calls.
Quality: The quality of a SIP trunk can vary greatly depending on the provider and the connection. Be sure to research the provider’s reputation for call quality and reliability.
Features: Different SIP trunk providers may offer different features, such as call forwarding, call waiting, and voicemail. Consider which features are important to your organization and make sure that the SIP trunk provider offers them.
Customer support: It is important to choose a SIP trunk provider that offers reliable customer support in case you experience any issues with your service.
Other features that are good to have is integration to existing backend for OSS/BSS stack. Some of the feature set for a carrier grade SIP trunking solution are listed here
Inbound and outbound trunks
Number Import/Export
Security
Dynamic registeration of users
Authentication and Authorization
Security (SRTP)
Cost Savings
Low cost for large traffic volumes instead of charges of call per second
CDR for tracing and monitoring call failures
Clear media stream ( no robotic or choopy audio). Good MOS score
realtime traffic monitoring to rule out bad players.
Inbound and Outbound call – Call Establishment, Rejection, Termination
DDI: Direct Dialling-In ranges can be provided on the SIP Trunk
CLIP(Calling Line Identification Presentation )/CLIR Calling Line Identification Presentation Restriction)for Inbound and Outbound
Incoming Call Barring: bar receiving of calls to certain extensions
Outgoing Call Barring: Restrict calls to certain numbers
Incoming Call Diversion – unconditional, busy, and unreachable
Call Admission Control: Call Admission Control (CAC) is a mechanism to restrict the number of simultaneous sessions (calls)
Incoming Call Diversion (DestNo not reachable, CAC exceeded, unconditional)
Geographic and Non-Geographic Number Support
Multiple Codec Support
Emergency Calling: Emergency Calls are routed on a priority basis irrespective of the customer’s available channel
Trunking inbound services voice can be used to support contact centres, conferencing, number translation services etc. Regulatory requirements for the operation of the customer in the PSTN of respective countries must be met with Country Specific Emergency Calling support Enhanced feature set for SIP trunking should include the features of the SIP Trunking with Multicountry support
Proactive MCID (Malicious CallerId) Identification and tracing
Call Distribution(CD)
Intelligent Routing involving machine learning and constant feedback
Origin Based Routing
Menu Routing
Origin Dependent Routing (ODR)
PIN Routing
Dynamic Route Select
Time-Dependent Routing (TDR)
Uniform Load Distribution(ULD)
International Routing
Mobile Routing
Payphone Routing
Product Association
Ultimately, the most useful SIP trunk for your organization will depend on your specific needs and budget. It is a good idea to research and compare different SIP trunk providers to find the one that best meets your organization’s needs.
SIP trunking systems are likely to continue to be an important part of the telecommunications landscape in the future. As more and more organizations adopt WebRTC or SRT based VoIP (Voice over Internet Protocol) technology for their phone systems, the demand for SIP trunks is likely to continue to grow. One trend that is expected to shape the future of SIP trunking is the increasing adoption of cloud-based communication systems. As more organizations move their communication systems to the cloud, they are likely to turn to SIP trunks as a way to connect their phone systems to the public telephone network and enable remote communication. Another trend that is expected to impact the future of SIP trunking is the increasing adoption of 5G technology. 5G networks offer faster speeds and lower latency, which may make it possible to use SIP trunks for real-time communication applications such as interactive and/or immersive video conferencing.
It is an multi-functional, multi-purpose SIP server especially used in VoIP landscape as standalone SIP server or SBC ( Session Border Controller ) for inbound and outbound traffic by carriers, telecoms backend layers or ITSPs for call routing and trunking solutions. It can be deployed with Class4/5 Platforms, SIP Trunking , hosted or IP PBX setup , existing gateways/ Session Border Controllers, Application Servers, proxy server, Front-End Load Balancers, IMS Platforms, Call Center etc.
Due to its very flexible and customisable routing engine it can be used in number of scenarios such as an SIP proxy or a router and due to its high throughput it is widely recommended as an enterprise grade inbound/outbound proxy server.
SIP to XMPP gateway for presence and IM (bidirectional)
Load-balancer or dispatcher
Inbound/front end for gateways/asterisk
SIP NAT traversal unit
Application server with custom logic
Since Opensips has emerged as a resilent SIP server , it is also used in specific usecases such as – DID ( Direct Inward dialling ) for SIP trunking solutions , – Local Number Portability (LNP) providers, – Canonical Name (CNAME) providers etc
It can act as Registrar with NAT traversal abilities (STUN, TURN, SIP pinging)
UDP , TCP , TLS , SCTP and WS transports over both IPv4 and IPv6 Additionally it can be connected to multiple networks ( Multihomed ) and do IP authentication or IP blacklisting
Class 4 routing capabilities in opensips include SIP aliases, Direct Inward Dialing , Speed dial, CPL,vDialplan , dispatcher with various algorithms, prefix-based routing to multiple carriers , failover support, Load balancing , ENUM-based or Geolocation-based routing etc. Some of the Class 5 capabilities in opensips are B2B , call queuing UAC registration , authentication, mangling, White/Black list
SIP SIMPLE features as messaging , Presence , Busy Lamp Field (BLF), Shared Call/Line Appearance (SCA) , Bridged Line Appearance (BLA) , Message Waiting notifications (MWI), XCAP , Resource List Server ( RLS ) , XMPP , SMS gateway (AT and SMPP)
Although opensips has no built-in media capabilities, but it modules for external media engines for Media relaying (RTPProxy, MediaProxy, RTPEngine), Media transcoding (Sangoma D1 cards) , Codec manipulation.
Opensips has majorly 2 parts core and addon-modules.
Opensips Core part is only a proxy stateless SIP server . It contains
SIP transport layer which supports UDP, TCP, TLS and WS for SIP. As per the listener in routing script transport protocols is selected .
SIP factory — the message parser and builder which can be used to add new headers or remove existing ones.
Routing script parser and interpreter for the routing script which loads it to the memory at the startup time. To load a new script server restart is required.
Memory and locking manager for the memory allocation and locking to prevent deadlocks and starvation. Although these arn’t accesible by route scripting, it can be configured at compile time.
Core script functions and variables which can be used in routing scripts in addition to the functions exported by add-on modules.
Interfaces
Events Interface
Used to notify external applications about events triggered internal to OpenSIPS such as
core events – E_CORE_THRESHOLD ,E_CORE_PKG_THRESHOLD , E_CORE_SHM_THRESHOLD , modules events , or even a custom event using raise_event() command
Statistics Interface
Provide insights to statistics of opensips in numerical results which could be used for services like monitoring, load evaluation, realtime integration etc. The statictsics can be of two kinds :
1. counter like – variables that keep counting things that happened in OpenSIPS, like received requests, processed dialogs, failed DB queries, etc
2. computed values – variables that are calculated in realtime, like how much memory is used, the current load, active dialogs, active transactions, etc
These variable would reset form 0 at start sometimes even during runtime.
Binary Internal Interface
Provider communication between individual OpenSIPS instances. Used in cases such as failovers where dialogs needs to persist for service continuity. Hence with this interface one can replicate all the events related to the runtime data (creation / updating / deletion) to a backup OpenSIPS instance.
SQL interface and NoSQL interface
SQL interfaces provides interaction with Sql DB drivers and services such as MySQL, Postgres, Oracle, Berkeley, unixODBC etc , while NoSQL interface provides access to Redis, CouchBase, Cassandra, MongoDB, Memcached, and other databases which are more frequently implemented as external caches.
AAA interface definition
Currently, OpenSIPS supports the RADIUS driver for the AAA interface with upcoming support for DIAMETER.
Management interface
Allows the external applications to trigger predefined commands
Push data like setting a debug level, registering a contact etc
Fetch data like registered users, ongoing calls, get statistics etc
Trigger an internal action as reloading the data, sending a message so on
1. Functional SIP modules
SIP signalling modules such as B2B_ENTITIES , B2B_LOGIC , CALL CENTER ( for Inbound call center system ) , DIALOG , NAT_TRAVERSAL , NATHELPER
OPTIONS , REGISTRAR ,SIGNALING , UAC_REGISTRANT
TM (Transaction/stateful module) , SL (Stateless replier ) , SMS (SIP-to-SMS IM gateway)
A config file opensips.config has 3 main logical parts :
1.global parameters – network listeners, available transport protocols, forking (and number of processes), the logging
2.modules section – the modules that are to be loaded with path to their .so file
3.routing logic – logic for routing sip traffic
Routes
OpenSIPS routing logic uses several types of routes. Each type of route is triggered by a certain event and allows you to process a certain type of message (request or reply).
route SIP requests routing. The main ‘route’ block identified by ‘route{…}’ or ‘route[0]{…}’ is executed for each SIP request. To send a reply or forward the request, explicit actions must be called inside the route block. in example below which sends 200 ok reply for each options request.
branch_route Handles different branches of a SIP request. if the branch is not dropped the branch will be automatically sent out. It is executed only by TM module after it was armed via t_on_branch(“branch_route_index”).
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
or lookup location and discard branches where uri matches ip 1.2.3.4 by using drop()
failure_route Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches which completes the transaction. The ‘failure_route’ is executed only by TM module after it was armed via t_on_failure(“failure_route_index”).
if (is_method("INVITE")) {
if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
}
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
}
onreply_route Reply routing block. It can be stateful (if bound to a transaction) or stateless (if global reply route). If the reply is not dropped (only provisional replies can be), it will be injected and processed by the transaction engine. There are three types of onreply routes:
global – catches all replies and uses simple definition ‘onreply_route {…}’ or ‘onreply_route[0] {…}’.
Exmaple for “global” reply route set the whole transaction
route {
seturi("sip:bob@opensips.org"); first branch
append_branch("sip:alice@opensips.org"); second branch
t_on_reply("global");
t_on_branch("1");
t_relay();
}
onreply_route {
xlog("OpenSIPS received a reply from $si\n");
}
onreply_route[global] {
if (t_check_status("1[0-9][0-9]")) {
setflag(1);
log("provisional reply received\n");
if (t_check_status("183"))
drop;
}
}
per request/transaction – it catches all received replies belonging to a certain transaction and uses “t_on_reply()” at request time, in REQUEST ROUTE – named ‘onreply_route[N] {…}’.
per branch – it catches only the replies that belong to a certain branch from a transaction via “t_on_reply()” ) at request time, but in BRANCH ROUTE, when a certain outgoing branch is processed – named ‘onreply_route[N] {…}’.
Certain ‘onreply_route’ blocks can be executed by TM module for special replies. For this, the ‘onreply_route’ must be armed for the SIP requests whose replies should be processed within it, via t_on_reply(“onreply_route_index”).
Exmaple of reply route set for this branch only
branch_route[1] {
if ($rU=="alice")
t_on_reply("alice");
}
onreply_route[alice] {
xlog("received reply on the branch from alice\n");
}
error_route
executed automatically on meeting and error such as parsing error in SIP request processing, script assert failure. Performs error handling . The Default action is to discard request. In error_route, the following pseudo-variables are available to get access to error details:
$(err.class) - the class of error (now is '1' for parsing errors)
$(err.level) - severity level for the error
$(err.info) - text describing the error
$(err.rcode) - recommended reply code
$(err.rreason) - recommended reply reason phrase
error_route {
xlog("--- error route class=$(err.class) level=$(err.level)
info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
sl_send_reply("$err.rcode", "$err.rreason");
exit;
}
local_route
executed automatically as TM created a new request, internally (no UAC side). This is a route intended to be used for message inspection, accounting and for applying last changes on the message headers. Routing and signaling functions are not allowed.
startup_route Executed only once when OpenSIPS is started and before the processing of SIP messages begins. Used in initilization cases cases such as loading some data in the cache.
startup_route {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
cache_store("local", "rule1", "$avp(i:100)");
}
timer_route Route executed periodically at a configured interval of time specified next to the name(in seconds).
timer_route[gw_update, 300] {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
$shv(i:100) =$avp(i:100);
}
event_route execute script code when an event is triggered. If no way to handle the event specified, default will be synchronously. Triggered by the event_route module when an event is raised by the OpenSIPS Event Interface such as event raised by the pike module when it decides an ip should be blocked called E_PIKE_BLOCKED or E_SCRIPT_EVENT etc ( checke events interface for more events)
event_route[E_PIKE_BLOCKED] {
xlog("The E_PIKE_BLOCKED event was raised\n");
}
event_route[E_PIKE_BLOCKED, async] {
xlog("The E_PIKE_BLOCKED event was raised\n");
}
Scripting Language
Opensips scripting provided more advanced controls
1. Core Keywords
Keywords specific to SIP messages which can be used mainly in ‘if’ expressions. af – address family of the received SIP message. It is INET if the message was received over IPv4 or INET6 if the message was received over IPv6.
if(af==INET6) {
log("Message received over IPv6 link\n");
};
dst_ip – IP of the local interface where the SIP message was received.
if(dst_ip==127.0.0.1) {
log("message received on loopback interface\n");
};
dst_port – local port where the SIP packet was received
if(dst_port==5061)
{
log("message was received on port 5061\n");
};
from_uri – reference to the URI of ‘From’ header.
if(is_method("INVITE") && from_uri=~".*@opensips.org")
{
log("the caller is from opensips.org\n");
};
method – SIP method of the message.
if(method=="REGISTER")
{
log("this SIP request is a REGISTER message\n");
};
msg:len – the size of the message
if(msg:len>2048)
{
sl_send_reply("413", "message too large");
exit;
};
$retcode – value returned by last function executed like $?. If tested after a call of a route, it is the value retuned by that route.
route {
route(1);
if($retcode==1)
{
log("The request is an INVITE\n");
};
}
route[1] {
if(is_method("INVITE"))
return(1);
return(2);
}
proto – transport protocol of the SIP message.
if(proto==UDP)
{
log("SIP message received over UDP\n");
};
status – status code of the reply.
if(status=="200")
{
log("this is a 200 OK reply\n");
};
1.10 src_ip – source IP address
if(src_ip==127.0.0.1)
{
log("the message was sent from localhost!\n");
};
1.11 src_port – source port of the SIP message (from which port the message was sent by previous hop).
if(src_port==5061)
{
log("message sent from port 5061\n");
}
1.12 to_uri – URI from To header.
if(to_uri=~"sip:.+@opensips.org")
{
log("this is a request for opensips.org users\n");
};
1.13 uri – request URI.
if(uri=~"sip:.+@opensips.org")
{
log("this is a request for opensips.org users\n");
};
2. Core Values
Values that can be used in ‘if’ expressions to check against Core Keywords
if(msg:len>max_len)
{
sl_send_reply("413", "message too large to be forwarded over UDP without fragmentation");
exit;
}
myself – reference to the list of local IP addresses, hostnames and aliases that has been set in OpenSIPS configuration file. This lists contain the domains served by OpenSIPS.
if(uri==myself) {
log("the request is for local processing\n");
};
null – reset the value of a per-script variable or to delete an avp.
$avp(i:12) = null;
$var(x) = null;
3. Core parameters
abort_on_assert – Set to true in order to make OpenSIPS shut down immediately in case a script assert fails.
abort_on_assert = true // default is false
advertised_address – address advertised in Via header and other destination lumps (e.g RR header).
advertised_port – port advertised in Via header and other destination lumps (e.g. RR).
db_max_async_connections – Maximum number of TCP connections opened from a single OpenSIPS worker to each individual SQL backend. Default value is 10. Individual backends are determined from DB URLs as follows: [ scheme, user, pass, host, port, database ]
disable_503_translation – If ‘yes’, OpenSIPS will not translate the received 503 replies into 500 replies . disable_core_dump – By default core dump limits are set to unlimited or a high enough value. Set this config variable to ‘yes’ to disable core dump-ing (will set core limits to 0).
disable_core_dump=yes //Default value is 'no'.
disable_dns_blacklist– DNS resolver, when configured with failover, can automatically store in a temporary blacklist the failed destinations. This will prevent (for a limited period of time) OpenSIPS to send requests to destination known as failed. So, the blacklist can be used as a memory for the DNS resolver.
The temporary blacklist created by DNS resolver is named “dns” and it is by default selected for usage (no need use the use_blacklist()) function. The rules from this list have a life time of 4 minutes – you can change it at compile time, from resolve.c . Can be ‘yes’ or ‘no’. By default the blacklist is disabled (Default value is ‘yes’).
disable_dns_failover – By default DNS-based failover is enabled. Set this config variable to ‘yes’ to disable the DNS-based failover. This is a global option, affecting the core and the modules also.
disable_stateless_fwd – controls the handling of stateless replies:
yes – drop stateless replies if stateless fwd functions (like forward) are not used in script
no – forward stateless replies
dns – controls if the SIP server should attempt to lookup its own domain name in DNS. Default is no.
dns_retr_time – Time in seconds before retrying a dns request. Default value is system specific, depends also on the ‘/etc/resolv.conf’ content (usually 5s).
dns_retr_no – Number of dns retransmissions before giving up.
dns_servers_no – How many dns servers from the ones defined in ‘/etc/resolv.conf’ will be used. Default value is to use all of them.
dns_try_ipv6 – If it is set to ‘yes’ and a DNS lookup fails, it will retry it for ipv6 (AAAA record). Default value is ‘no’.
dns_try_naptr – Disables the NAPTR lookups when doing DNS based routing for SIP requests – if disabled, the DNS lookup will start with SRV lookups. By default it is enabled, value ‘yes’.
dns_use_search_list
dst_blacklist – static (read-only) IP/destination blacklist. These lists can be selected from script (at runtime) to filter the outgoing requests, based on IP, protocol, port, etc.
test patter – is a filename like matching (see “man 3 fnmatch”) applied on the outgoing request buffer (first_line+hdrs+body)
enable_asserts – Set to true in order to enable the assert script statement.
event_pkg_threshold – A number representing the percentage threshold above which the E_CORE_PKG_THRESHOLD event is raised, warning about low amount of free private memory. It accepts integer values between 0 and 100. Default value is 0 ( event disabled ).
event_pkg_threshold = 90
event_shm_threshold A number representing the percentage threshold above which the E_CORE_SHM_THRESHOLD event is raised, warning about low amount of free shared memory. It accepts integer values between 0 and 100. Default value is 0 ( event disabled ).
event_shm_threshold = 90
exec_dns_threshold – A number representing the maximum number of microseconds a DNS query is expected to last. Anything above the set number will trigger a warning message to the logging facility. Default value is 0 ( logging disabled ).
exec_dns_threshold = 60000
exec_msg_threshold – A number representing the maximum number of microseconds the processing of a SIP msg is expected to last. Anything above the set number will trigger a warning message to the logging facility. Aside from the message and the processing time, the most time consuming function calls from the script will also be logged. Default value is 0 ( logging disabled ).
exec_msg_threshold = 60000
include_file – load additional routes/blocks with file path
include_file "proxy_regs.cfg"
import_file – Same as include_file but will not throw an error if file is not found.
import_file "proxy_regs.cfg"
listen – Set the network addresses the SIP server should listen to. syntax is protocol:address[:port]
The listen definition may accept several optional parameters for:
configuring an advertised IP and port only for an interface. Syntax “AS 11.22.33.44:5060”
setting a different number of children for this interface only (for UDP, SCTP and HEP_UDP interfaces only). This will override the global “children” parameter. Syntax “use_children 5”
Remember that the above parameters only affect the interface they are configured for; if they are not defined for a given interface, the global values will be used instead.
listen = udp:* listen = udp:eth1 listen = tcp:eth1:5062 listen = tls:localhost:5061 listen = hep_udp:10.10.10.10:5064 listen = ws:127.0.0.1:5060 use_children 5 listen = sctp:127.0.0.1:5060 as 99.88.44.33:5060 use_children 3 On startup, OpenSIPS reports all the interfaces that it is listening on. The TCP engine processes will be created regardless if you specify only UDP interfaces here. 3.41 log_facility – control the facility for logging in syslog. Default value is LOG_DAEMON.
log_facility=LOG_LOCAL0
3.42 log_level – logging level (how verbose OpenSIPS should be). Higher values make OpenSIPS to print more messages.
log_level=1 — print only important messages (like errors or more critical situations) recommended for running proxy as daemon
log_level=4 — print a lot of debug messages use it only when doing debugging sessions
Actual values are:
-3 – Alert level
-2 – Critical level
-1 – Error level
1 – Warning level
2 – Notice level
3 – Info level
4 – Debug level
The ‘log_level’ parameter is usually used in concordance with ‘log_stderror’ parameter.
Value of ‘log_level’ parameter can also be get and set dynamically using log_level Core MI function or $log_level script variable.
3.43 log_name – Set the id to be printed in syslog. The value must be a string and has effect only when OpenSIPS runs in daemon mode (fork=yes), after daemonize. Default value is argv[0].
log_name=”osips-5070″
3.44 log_stderror – write log messages to standard error. Possible values are: – “yes” – write the messages to standard error – “no” – write the messages to syslog , also the default
max_while_loops – maximum loops that can be done within a “while”. Comes as a protection to avoid infinite loops in config file execution. Default is 100.
max_while_loops=200
maxbuffer – size in bytes not to be exceeded during the auto-probing procedure of discovering the maximum buffer size for receiving UDP messages. Default value is 262144.
maxbuffer=65536
mem-group – Defines a group of modules (by name) to get separate memory statistics.In order for the feature to work you have to run “make generate-mem-stats” and complile with the variable SHM_EXTRA_STATS defined and complile with the variable SHM_SHOW_DEFAULT_GROUP definedwill generate the statistics for the default group
mem_warming – Only relevant when the HP_MALLOC compile flag is enabled. If set to “on”, on each startup, OpenSIPS will attempt to restore the memory fragmentation pattern it had before the stop/restart. Memory warming is useful when dealing with high volumes of traffic (thousands of cps on multi-core machines – the more cores, the more useful), because processes must mutually exclude themselves when chopping up the initial big memory chunk. By performing fragmentation on startup, OpenSIPS will also behave optimally in the first minute(s) after a restart. Fragmentation usually lasts a few seconds (e.g. ~5 seconds on an 8GB shm pool and 2.4Ghz CPU) – traffic will not be processed at all during this period.
mem_warming = on
mem_warming_percentage – How much of OpenSIPS’s memory should be fragmented with the pattern of the previous run, upon a restart.
mem_warming_percentage = 50 //Default value: 75
mem_warming_pattern_file – Default value: “CFG_DIR/mem_warming_pattern”.The memory fragmentation pattern of a previous OpenSIPS run. Used at startup, if mem_warming is enabled.
memdump | mem_dump – Log level to print memory status information (runtime and shutdown). Default: memdump=L_DBG (4)
memlog | mem_lo – Log level to print memory debug info. It has to be less than the value of ‘log_level’ parameter if you want memory info to be logged. Default: memlog=L_DBG (4)
mcast_loopback – If set to ‘yes’, multicast datagram are sent over loopback. Default value is ‘no’.
mcast_loopback=yes
mcast_ttl – Set the value for multicast ttl. Default value is OS specific (usually 1).
mhomed – Set the server to try to locate outbound interface on multihomed host. By default is not (0) – it is rather time consuming.
mhomed=1
mpath – Set the module search path. This can be used to simplify the loadmodule parameter
open_files_limit – If set and bigger than the current open file limit, OpenSIPS will try to increase its open file limit to this number. Note: OpenSIPS must be started as root to be able to increase a limit past the hard limit (which, for open files, is 1024 on most systems).
open_files_limit=2048
poll_method – (deprecated post 2.2) poll method to be used by the I/O internal reactor – by default the best one for the current OS is selected. The available types are: poll, epoll_lt, sigio_rt, select, kqueue, /dev/poll.
Starting with version 2.2, epoll_et is deprecated and if it is used in the script, it will be automatically replaced by epoll_lt.
poll_method=select
port – port the SIP server listens to. The default value for it is 5060.
reply_to_via – If it is set to 1, any local reply is sent to the address advertised in top most Via of the request. Default value is 0 (off).
reply_to_via=0
query_buffer_size -If set to a value greater than 1, inserts to DB will not be flushed one by one. Rows to be inserted will be kept in memory until until they gather up to query_buffer_size rows, and only then they will be flushed to the database.
query_buffer_size=5
query_flush_time – If query_buffer_size is set to a value greater than 1, a timer will trigger once every query_flush_time seconds, ensuring that no row will be kept for too long in memory.
query_flush_time=10
rev_dns – should the SIP server attempt to lookup its own IP address in DNS. If this parameter is set to yes and the IP address is not in DNS a warning is printed on syslog and a “received=” field is added to the via header. Default is no.
server_header – The body of Server header field generated by OpenSIPS when it sends a request as UAS. It defaults to “OpenSIPS (<version> (<arch>/<os>))”.
server_header="Server: My Company SIP Proxy"
server_signature – control “Server” header in any locally generated message. If it is enabled (default=yes) a header is generated as Server: OpenSIPS (0.9.5 (i386/linux))
shm_hash_split_percentage – Only relevant when the HP_MALLOC compile flag is enabled. It controls how many memory buckets will be optimized. (e.g. setting it to 2% will optimize the first 81 most used buckets as frequency). The default value is 1.
shm_secondary_hash_size – Only relevant when the HP_MALLOC compile flag is enabled. It represents the optimization factor of a single bucket (e.g. setting it to 4 will cause the optimized buckets to be further split into 4). The default value is 8.
sip_warning – Can be 0 or 1. If set to 1 (default value is 0) a ‘Warning’ header is added to each reply generated by OpenSIPS. The header contains several details that help troubleshooting using the network traffic dumps.
sip_warning=0
tcp_children – Number of children processes to be created for reading from TCP connections. If no value is explicitly set, the same number of TCP children as UDP children (see “children” parameter) will be used.
tcp_accept_aliases – If enabled, OpenSIPS will enforce RFC 5923 behaviour when detecting an “;alias” Via header field parameter and will reuse any TCP (or TLS, WS, WSS) connection opened for such SIP requests (source IP + Via port + proto) when sending other SIP requests backwards, towards the same (source IP + Via port + proto) pair. Default value 0 (disabled).
tcp_listen_backlog – maximum length for the queue of pending connections for the TCP listeners. Default configured value is 10.
tcp_connect_timeout – Time in milliseconds before an ongoing blocking attempt to connect will be aborted. Default value is 100ms.
tcp_connection_lifetime – Lifetime in seconds for TCP sessions. Default value is defined in tcp_conn.h: define DEFAULT_TCP_CONNECTION_LIFETIME 120.
tcp_connection_lifetime = 3600
tcp_max_connections – maximum number of tcp connections. Default is defined in tcp_conn.h: define DEFAULT_TCP_MAX_CONNECTIONS 2048
tcp_max_connections = 4096
tcp_max_msg_time – maximum number of seconds that a SIP message is expected to arrive via TCP. Default value is 4
tcp_max_msg_time = 8
tcp_no_new_conn_bflag -A branch flag to be used as marker to instruct OpenSIPS not to attempt to open a new TCP connection when delivering a request, but only to reuse an existing one (if available). If no existing conn, a generic send error will be returned.
This is intended to be used in NAT scenarios, where makes no sense to open a TCP connection towards a destination behind a NAT (like TCP connection created during registration was lost, so there is no way to contact the device until it re-REGISTER). Also this can be used to detect when a NATed registered user lost his TCP connection, so that opensips can disable his registration as useless.
tcp_no_new_conn_bflag = TCP_NO_CONNECT<br> ...<br> route {<br> ...<br> if (isflagset(DST_NATED) && $proto == "TCP")<br> setbflag(TCP_NO_CONNECT);<br> ...<br> t_relay("0x02"); // no auto error reply<br> $var(retcode) = $rc;<br> if ($var(retcode) == -6) {<br> xlog("unable to send request to destination");<br> send_reply("404", "Not Found");<br> exit;<br> } else if ($var(retcode) < 0) {<br> sl_reply_error();<br> exit;<br> }<br> }
3.77 tcp_threshold – A number representing the maximum number of microseconds sending of a TCP request is expected to last. Anything above the set number will trigger a warning message to the logging facility. Default value is 0 ( logging disabled ).
tcp_threshold = 60000
tcp_keepalive – Enable or disable TCP keepalive (OS level). Enabled by default.
tcp_keepcount -Number of keepalives to send before closing the connection (Linux only). Default value: 0 (not set). Setting tcp_keepcount to any value will enable tcp_keepalive.
tcp_keepidle – Amount of time before OpenSIPS will start to send keepalives if the connection is idle (Linux only). Default value: 0 (not set)
tcp_keepidle = 30
tcp_keepinterval – Interval between keepalive probes, if the previous one failed (Linux only).Default value: 0 (not set). Setting tcp_keepinterval to any value will enable tcp_keepalive.
tcp_keepinterval = 10
tls_ca_list
tls_certificate
tls_ciphers_list
tls_domain
tls_handshake_timeout
tls_log
tls_method
tls_port_no
tls_private_key
tls_require_certificate
tls_send_timeout
tls_verify
tos – TOS (Type Of Service) to be used for the sent IP packages (both TCP and UDP).
user_agent_header – The body of User-Agent header field generated by OpenSIPS when it sends a request as UAC. It defaults to “OpenSIPS (<version> (<arch>/<os>))”.
user_agent_header=”User-Agent: My Company SIP Proxy”
wdir – working directory used by OpenSIPS at runtime.
wdir="/usr/local/opensips"
xlog_buf_size – Default value: 4096
Size of the buffer used to print a single line on the chosen logging facility of OpenSIPS. If the buffer is too small, an overflow error will be printed, and the concerned line will be skipped.
xlog_buf_size = 8388608 #given in bytes
xlog_force_color
xlog_default_level -Default value for the logging level of the xlog core function, when the log_level parameter is omitted.
OpenSIPS routing logic uses several types of routes. Each type of route is triggered by a certain event and allows you to process a certain type of message (request or reply).
route SIP requests routing. The main ‘route’ block identified by ‘route{…}’ or ‘route[0]{…}’ is executed for each SIP request. To send a reply or forward the request, explicit actions must be called inside the route block. in example below which sends 200 ok reply for each options request.
branch_route Handles different branches of a SIP request. if the branch is not dropped the branch will be automatically sent out. It is executed only by TM module after it was armed via t_on_branch(“branch_route_index”).
if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) {
if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH");
}
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
or lookup location and discard branches where uri matches ip 1.2.3.4 by using drop()
failure_route Failed transaction routing block. It contains a set of actions to be taken each transaction that received only negative replies (>=300) for all branches which completes the transaction. The ‘failure_route’ is executed only by TM module after it was armed via t_on_failure(“failure_route_index”).
if (is_method("INVITE")) {
if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE");
}
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
}
onreply_route Reply routing block. It can be stateful (if bound to a transaction) or stateless (if global reply route). If the reply is not dropped (only provisional replies can be), it will be injected and processed by the transaction engine. There are three types of onreply routes:
global – catches all replies and uses simple definition ‘onreply_route {…}’ or ‘onreply_route[0] {…}’.
Exmaple for “global” reply route set the whole transaction
route {
seturi("sip:bob@opensips.org"); first branch
append_branch("sip:alice@opensips.org"); second branch
t_on_reply("global");
t_on_branch("1");
t_relay();
}
onreply_route {
xlog("OpenSIPS received a reply from $si\n");
}
onreply_route[global] {
if (t_check_status("1[0-9][0-9]")) {
setflag(1);
log("provisional reply received\n");
if (t_check_status("183"))
drop;
}
}
per request/transaction – it catches all received replies belonging to a certain transaction and uses “t_on_reply()” at request time, in REQUEST ROUTE – named ‘onreply_route[N] {…}’.
per branch – it catches only the replies that belong to a certain branch from a transaction via “t_on_reply()” ) at request time, but in BRANCH ROUTE, when a certain outgoing branch is processed – named ‘onreply_route[N] {…}’.
Certain ‘onreply_route’ blocks can be executed by TM module for special replies. For this, the ‘onreply_route’ must be armed for the SIP requests whose replies should be processed within it, via t_on_reply(“onreply_route_index”).
Exmaple of reply route set for this branch only
branch_route[1] {
if ($rU=="alice")
t_on_reply("alice");
}
onreply_route[alice] {
xlog("received reply on the branch from alice\n");
}
error_route
executed automatically on meeting and error such as parsing error in SIP request processing, script assert failure. Performs error handling . The Default action is to discard request. In error_route, the following pseudo-variables are available to get access to error details:
$(err.class) - the class of error (now is '1' for parsing errors)
$(err.level) - severity level for the error
$(err.info) - text describing the error
$(err.rcode) - recommended reply code
$(err.rreason) - recommended reply reason phrase
error_route {
xlog("--- error route class=$(err.class) level=$(err.level)
info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
sl_send_reply("$err.rcode", "$err.rreason");
exit;
}
local_route
executed automatically as TM created a new request, internally (no UAC side). This is a route intended to be used for message inspection, accounting and for applying last changes on the message headers. Routing and signaling functions are not allowed.
startup_route Executed only once when OpenSIPS is started and before the processing of SIP messages begins. Used in initilization cases cases such as loading some data in the cache.
startup_route {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
cache_store("local", "rule1", "$avp(i:100)");
}
timer_route Route executed periodically at a configured interval of time specified next to the name(in seconds).
timer_route[gw_update, 300] {
avp_db_query("select gwlist where ruleid==1",$avp(i:100));
$shv(i:100) =$avp(i:100);
}
event_route execute script code when an event is triggered. If no way to handle the event specified, default will be synchronously. Triggered by the event_route module when an event is raised by the OpenSIPS Event Interface such as event raised by the pike module when it decides an ip should be blocked called E_PIKE_BLOCKED or E_SCRIPT_EVENT etc ( checke events interface for more events)
event_route[E_PIKE_BLOCKED] {
xlog("The E_PIKE_BLOCKED event was raised\n");
}
event_route[E_PIKE_BLOCKED, async] {
xlog("The E_PIKE_BLOCKED event was raised\n");
}
opensipsctlrc
opensipsctlrc file controls the opensipsctl and osipsconsole utilities. It is a shell script utility to manage opensips from command line
opensipsctl can manage
Start, stop, and restart
Show, grant, and revoke ACLs Add, remove, and list aliases
Add, remove, and configure an AVP
Low Cost Route (LCR)
Remote Party Identity (RPID)
Add, remove, and list subscribers
Add, remove, and show the usrloc table in-Random Access Memory (RAM)
Unified communication services build around WebRTC should be vendor agnostic and multi-tenant and be supported by other Communication Service Providers (CSPs), SIP trunks, PBXs, Telecom Equipment Manufacturers (TEMs), and Communication Platform as a Service (CPaaS). This can happen if all endpoints adhere to SIP standards in most updated RFC. However since not all are on the boat , Session border controllers are a great way to mitigate the differences and provide seamless connectivity to signalling and media , which could be between WebRTC, SIP or PSTN, from TDM to IP .
Session Border Controllers ( SBC ) assist in controlling the signalling 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.
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 .
Security
Connectivity
Qos
Regulatory
Media Services
Statistics and billing information
Explaining the functions of SBC in detail
1. Security
SBCs provide security features such as encryption, authentication, and firewall capabilities to protect the network from unauthorized access and attacks. 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
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.
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 translationsSBCs can bridge WebRTC calls with other communication protocols such as SIP, H.323, and PSTN to enable communication between different systems and networks.
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 .
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
SBCs can log call information and statistics, and provide real-time monitoring capabilities to troubleshoot and diagnose issues with WebRTC calls.
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.
Network Address Translation (NAT)
SBCs can handle Network Address Translation (NAT) to allow WebRTC clients behind a NAT to connect to other clients outside of the NAT.
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.
SBCs act as a security gateway and traffic manager for WebRTC sessions, ensuring that the communication is secure, of good quality, and can traverse different networks and protocols.
Session Border Controller for WebRTC , SIP , PSTN , IP PBX and Skype for business .
Diagram Component Description
Gateways vs SBC
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
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.
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.
Source : Unknonw. Figure describes an IP based communication system catering to various endpoints and networks
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.
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
MAN (Metropolitan area networks) connected ~30 miles of LAN (local networks) with a BN (backbone network). WAN(Wide Area Network) connected these MANs for longer distances ~100 miles. The telco were carriers with these larger internetworks and connections such as At&T or BellSouth. This led to development of PSTN.
PSTN were Circuit – Switching telephone network which were designed to carry analog data. Connnecting over PSTN required a modem convertor which converted analog to digital at 28/56 Kbps. During the set up portion of a telephone call, a special circuit is created, which is then torn down when the call is completed.
TDM was designed to provide continuous, compact and orderly data transfer for voice and video. It does so using a constant bandwidth over a secure connection.
ISDN can provide end-to-end digital communications for Fax, Data, audio, image and video transmission. It is a switched digital telecommunication line that can be delivered over regular copper wires. Speed for a single ISDN line is 128 Kbps. Multiple ISDN lines can be combined together to achieve higher communication speeds. It was mostly used to provide remote access to LANs.
Digital lines with ISDN
Basic Rate Interface or BRI are used for home or SOHO connection
2B + D channel
Primary Rate Interface or PRI is used for large businesses
23 B channels and 1 D channel
B channels are known as bearer channels and is used to carry information D channel is known as the Delta channel used for signalling purposes
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.
The Unified Communication Solution leads to Network Agnostic, Agile, Cost Effective & Customer Experience Centric Services Platform.
The Way from Copper -> Fiber -> 2nd Generation -> 3rd Generation -> LTE , depicts evolution of Telecommunications over the decades , in the Network layer Infrastructure area
The Sevice Layer Infrastructure is built using techniques as Switching , Home Location Register (HLR) , Authetication ( AuC) etc . The Services vary over ranges such as IN , Voice , SMS , VOIP , IM , IPTV , IMS , Presence , MMS etc .
Top of this lies the Harmonization layer that performs the inter networking between different platforms and protocols .
The Application Layer consists of various usecases as Enhanced Screening , Social Networking Integration , Education Trade etc .
There has been rapid evolution of telecom platform over the last few decades. Starting from the the mobile phone network-enabled universal communication agnostic to actual location to present day high bandwidth high data rate entertainment/ streaming like applications. The affordable, personal communication system has converged to enterperise level secure communication systems that cater to low latency and highly secure end to end encrypted scenarios.
Some of the positive aspects of using IP communication over traditional communication systems are :
HigherROI( Return of investment)
ROI 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%.
Third party Interations
It is often a necessaity to integrate communication system with CRM (content realationship management ) systems or Sales management systems or other lead gtracking systesm which are driven from communications with possible clients or investors ( called leads). Since most web portals are on IP protocl as HTTP, VOIP fits very well, with the click to call on webpage itself among other features such as directory integration , notofoication , call scripts etc.
VAS ( Value Added Service)
Value Added Services , refer to services build on top of existing underlying mobile communication call and sms. These could be innovation usecases build using -IVR / DTMF such as cricket score, astrology updates or call recoring , find-me-follow-me applicatoion for multiple devices , voicemail/ visual voice mail , re-routing to home phone or assiatnt phone, called ID etc. In short it can add intelligence to the way calls are managed .
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 , 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.
For a provider of IP telephony system, number of factors come into picture such as :
Bandwidth : Low bandwidth has always been a big concern for IP calls especially due to packet loss and thus high noise. 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 causes congestion and lags too.
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 is a challenging considering the underlying OS and networking support.
Traffic: Maximum simultaneous call or peak traffic rate can create bottlenecks in communication 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.
QoS (Quality of service ) :
Call drops ,
prioritization of important calls ,
Security preventing the attacks and hacks ,
keeping information secure by encryption end to end
AAA : managing Authentication, Authorization and accounting
Reuse existing Hardware :
Replacing old hardware or installing softphone apps on mobiles etc .
Reuse old servers . Manage setup between datacentres and cloud deployments
Administravtive hurdles between different counteries and geographies for using hardware
Scaling
How quickly can it scale up or scale down ?
Will the communication system grow horizontly or vertically ?
How to ensure that the growing system can accommodate new users , physical office location , remote centers , call centres etc ?
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 ) .
Other factors such as privacy , accounability , Lawful interception ( legal requirnments in many enterprises ) , Auditing , SLA ( Service Level Agreements) to ensure the system is up 99.99 % of time and agrreeing to pay compensation if system is down for longer duration than 0.01 % of time so on.
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 .
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(UC) 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 (BYOD) 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.
Image Source unknown. Represents the convergence of IMS subsystem with various access types
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.
picture courtesy – unknown
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.
Business benefits of IMS
Delivering Services: Delivering services and applications on a “wherever, however, whenever” basis.
Multimedia services: Enabling service providers to offer multimedia services across both next-gen, packet-switched networks and traditional circuit-switched networks.
Protocol stack: IMS architecture provides pipes and protocols onto which service providers can attach no. of applications very conveniently.
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.
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.
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.
Telecom R & D 