- Infrastructure-requirements
- Integral Components of a VOIP SIP based architecture
- SIP Gateways
- Registrar Server
- Proxy Server
- Stateless Proxy Server
- Stateful Proxy Server
- Forking Proxy Server
- Redirect Server
- Application Server
- Adding Media Management
- DTMF( Dual tone Multi Frequency )
- TTS ( Text to Speech )
- Developing SIP based applications
- Basic SIP methods
- Extending SIP headers
- Call routing Scripts
- SIP platform Development
- Performance factors
- Security considerations
- Collecting and Processing PCAPS
- NAT and DNS
- Near End NAT traversal
- STUN
- TURN
- ICE
- Far End NAT traversal
- Near End NAT traversal
- CDR processing and Billing
- Data Streams for billing service
- Call Rate and Accounting
- Cross platform and integration to External Telecommunication provider landscape
- Adhere to Standard
- Database Integration
- Call RatConsistency of Call Records and duplicated charging records at various endpoints
A VOIP/CPaaS solution is designed to accommodate the signalling and media both along with integration leads to various external endpoints such as various SIP phones ( desktop, softphones, webRTC ), telecom carriers, different VoIP networks providers, enterprise applications ( Skype, Microsoft Lync ), Trunks etc.
A sufficiently capable SIP platform should have
- Audio calls ( optionally video ) service using SIP gateways
- Media services (such as recording , conferencing, voicemail, and IVR )
- Messaging and presence ( could be using SIP SIMPLE, SMS , messahing service from third parties)
- Developing SIP based applications : Programmable services through standardized APIs and development of new modules
- NAT and DNS near-end and far-end NAT traversal for signalling and media flows
- Telemetry for Sessions , Registry, Location and lookup service
- CDR Processing and Billing : Backend for CDR and accounts ( can use Redis, Kafka , MySQL, PostgreSQL, Oracle, Radius, LDAP, Diameter)
- Serial and parallel forking, load balancing , proxying
- Cross platform and integration to External Telecommunication provider landscape
- Interconnectivity with other IP multimedia systems, VoLTE ( optional interconnection with other types of communications networks as GSM or PSTN/ISDN).
- support for VoIP signalling protocols (SIP, H,323, SCCP, MGCP, IAX) and telephony signalling protocols ( ISDN/SS7, FXS/FXO, Sigtran ) either internally via pluggable modules or externally via gateways .
| Performnace factors : | Security considerations : |
| High availability using redundant servers in standby Load balancing IPv4 and IPv6 network layer support TCP , UDP , SCTP transport layer protocol support DNS lookups and hop by hop connectvity | authentication, authorization, and accounting (AAA) Digest authentication and credentials fetched from backend Media Encryption TLS and SRTP support Topology hidding to prevent disclosing IP form internal components in via and route headers Firewalls , blacklist, filters , peak detectors to prevent Dos and Ddos attacks |
The article only outlines SIP system architecture from 3 viewpoints :
- Infrastructure standpoint
- Vore voice engineering perspective
- External components required to run and system
Infrastructure Requirements
- Data Centers with BCP ( Business Continuity Planning ) and DR ( Disaster Recovery )
- Servers and Clusters for faster and parallel calculating
- Virtualization
VMs to make a distributed computing environment with HA ( high availability ) and DRS ( Distributed Resource Scheduling ) - Storage
SAN with built-in redundancy for the resiliency of data.
WORM compliant NAS for storing voice archives over a retention period. - Racks, power supplies, battery backups, cages etc.
- Networking
DMZs ( Demilitarized Zones) which are interfacing areas between internal servers in the green zone and outside network
VLANs for segregation between tenants.
Connectivity through the public Internet as well as through VPN or dedicated optical fibre network for security. - Firewall configuration
- Load Balancer ( Layer 7 )
- Reverse Proxies for the security of internal IPs and port
- Security controls In compliance with ISO/IEC 27000 family – Information security management systems
- PKI Infrastructure to manage digital certificates
- Key management with HSM ( hardware security module )
- truster CA ( Certificate Authority ) to issue publicly signed certificate for TLS ( Https, wss etc)
- OWASP ( Open Web Application Security Project ) rules compliance
Integral Components of a VOIP SIP based architecture
- Call Controller
- Media Manager
- Recording
- Softclients
- logs and PCAP archives
- CDR generators
- Session Borer Controllers ( SBCs)
A SIP server can be moulded to take up any role based on the libraries and programs that run on it such as gateway server, call manager, load balancer etc. This in turn defines its placement in overall VoIP communication architecture. For example
– stateless proxy servers are placed on the border,
– application and B2BUA server at the core
SIP Gateways
A SIP gateway is an application that interfaces a SIP network to a network utilising another signalling protocol. In terms of the SIP protocol, a gateway is just a special type of user agent, where the user agent acts on behalf of another protocol rather than a human. A gateway terminates the signalling path and can also terminate the media path .
To H.323 for IP Telephony inter-working
Client – originates message
Server – responds to or forwards message
Logical SIP entities are:
- User Agent Client (UAC): Initiates SIP requests ….
- User Agent Server (UAS): Returns SIP responses ….
- Network Servers ….
Registrar Server
A registrar server accepts SIP REGISTER requests; all other requests receive a 501 Not Implemented response. The contact information from the request is then made available to other SIP servers within the same administrative domain, such as proxies and redirect servers. In a registration request, the To header field contains the name of the resource being registered, and the Contact header fields contain the contact or device URIs.
Proxy Server
A SIP proxy server receives a SIP request from a user agent or another proxy and acts on behalf of the user agent in forwarding or responding to the request. Just as a router forwards IP packets at the IP layer, a SIP proxy forwards SIP messages at the application layer.
Typically proxy server ( inbound or outbound) have no media capabilities and ignore the SDP . They are mostly bypassed once dialog is established but can add a record-route .
A proxy server usually also has access to a database or a location service to aid it in processing the request (determining the next hop).
1. Stateless Proxy Server
A proxy server can be either stateless or stateful. A stateless proxy server processes each SIP request or response based solely on the message contents. Once the message has been parsed, processed, and forwarded or responded to, no information (such as dialog information) about the message is stored. A stateless proxy never retransmits a message, and does not use any SIP timers
2. Stateful Proxy Server
A stateful proxy server keeps track of requests and responses received in the past, and uses that information in processing future requests and responses. For example, a stateful proxy server starts a timer when a request is forwarded. If no response to the request is received within the timer period, the proxy will retransmit the request, relieving the user agent of this task.
3 . Forking Proxy Server
A proxy server that receives an INVITE request, then forwards it to a number of locations at the same time, or forks the request. This forking proxy server keeps track of each of the outstanding requests and the response. This is useful if the location service or database lookup returns multiple possible locations for the called party that need to be tried.
Redirect Server
A redirect server is a type of SIP server that responds to, but does not forward, requests. Like a proxy server, a redirect server uses a database or location service to lookup a user. The location information, however, is sent back to the caller in a redirection class response (3xx), which, after the ACK, concludes the transaction. Contact header in response indicates where request should be tried .
Application Server
The heart of all call routing setup. It loads and executes scripts for call handling at runtime and maintains transaction states and dialogs for all ongoing calls . Usually the one to rewrite SIP packets adding media relay servers, NAT . Also connects external services like Accounting , CDR , stats to calls .
Adding Media Management
Media processing is usually provided by media servers in accordance to the SIP signalling. Bridges, call recording, Voicemail, audio conferencing, and interactive voice response (IVR) are commomly used. Read more about Media Architecture here
RFC 6230 Media Control Channel Framework decribes framework and protocol for application deployment where the application programming logic and media processing are distributed.
Any one such service could be a combination of many smaller services within such as Voicemail is a combitional of prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording. RFC 6231 Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework.
DTMF( Dual tone Multi Frequency )
delivery options:
- Inband – With Inband digits are passed along just like the rest of your voice as normal audio tones with no special coding or markers using the same codec as your voice does and are generated by your phone.
- Outband – Incoming stream delivers DTMF signals out-of-audio using either SIP-INFO or RFC-2833 mechanism, independently of codecs – in this case, the DTMF signals are sent separately from the actual audio stream.
TTS ( Text to Speech )
Alexa Text-to-Speech (TTS) + Amazon Polly
Ivona – multiple language text to speech converter with ssml scripts such as below
<speak>
<p>
<s><prosody rate="slow">IVONA</prosody> means highest quality speech
synthesis in various languages.</s>
<s>It offers both male and female radio quality voices <break/> at a
sampling rate of 22 kHz <break/> which makes the IVONA voices a
perfect tool for professional use or individual needs.</s>
</p>
</speak>
check ivona status
service ivona-tts-http status tail -f /var/log/tts.log
Developing SIP based applications
Basic SIP methods
SIP defines basic methods such as INVITE, ACK and BYE which can pretty much handle simple call routing with some more advanced processoes too like call forwarding/redirection, call hold with optional Music on hold, call parking, forking, barge etc.
Extending SIP headers
Newer SIP headers defined by more updated SIP RFC’s contina INFO, PRACK, PUBLISH, SUBSCRIBY, NOTIFY, MESSAGE, REFER, UPDATE. But more methods or headers can be added to baseline SIP packets for customization specific to a particular service provider. In case where a unrecognized SIP header is found on a SIP proxy which it either does not suppirt or doesnt understand, it will simply forward it to the specified endpoint.
Call routing Scripts
Interfaces for programming SIP call routing include :
– Call Processing Language—SIP CPL,
– Common Gateway Interface—SIP CGI,
– SIP Servlets,
– Java API for Integrated Networks—JAIN APIs etc .
Some known SIP stacks :
SailFin – SIP servlet container uses GlassFish open source enterprise Application Server platform (GPLv2), obsolete since merger from Sun Java to Oracle.
Mobicents – supports both JSLEE 1.1 and SIP Servlets 1.1 (GPLv2)
Cipango – extension of SIP Servlets to the Jetty HTTP Servlet engine thus compliant with both SIP Servlets 1.1 and HTTP Servlets 2.5 standards.
WeSIP – SIP and HTTP ( J2EE) converged application server build on OpenSER SIP platform
Additionally SIP stacks are supported on almost all popular SIP programming lanaguges which can be imported as lib and used for building call routing scripts to be mounted on SIP servers or endpoints such as :
PJSIP in C
JSSIP Javascript
Sofia in kamailio , Freswitch
Some popular SIP server also have proprietary scripting language such as –
Asterisk Gateway Interface (AGI) , application interface for extending the dialplan with your functionality in the language you choose – PHP, Perl, C, Java, Unix Shell and others
SIP platform Development
- audio calls ( optionally video )
- media services such as conferencing, voicemail, and IVR,
- messaging as IM and presence based on SIMPLE,
- programmable services through standardized APIs and development of new modules
- near-end and far-end NAT traversal for signalling and media flows
- interconnectivity with other IP multimedia systems, VoLTE ( optional interconnection with other types of communications networks as GSM or PSTN/ISDN)
- Registry, location and lookup service
- Serial and parallel forking
A sufficiently capable SIP platform shoudl consist of following features :
Performance factors :
- High availability using redundant servers in standby
- Load balancing
- IPv4 and IPv6 support
Security considerations :
- digest authentication and credentials fetched from backend
- Media Encryption
- TLS and SRTP support
- Topology hiding to prevent disclosng IP form internal components in via and route headers
- Firewalls , blacklist, filters , peak detectors to prevent Dos and Ddos attacks .
Collecting and Processing PCAPS
- VoIP monitor – network packet sniffer with commercial frontend for SIP RTP RTCP SKINNY(SCCP) MGCP WebRTC VoIP protocols
it uses a passive network sniffer (like tcpdump or wireshark) to analyse packets in realtime and transforms all SIP calls with associated RTP streams into database CDR record which is sent over the TCP to MySQL server (remote or local). If enabled saving SIP / RTP packets the sniffer stores each VoIP call into separate files in native pcap format (to local storage).
- sngrep
- tcpdump
- custom made pcap capture and uploader
NAT and DNS
To adapt SIP to modern IP networks with inter network traversal ICE, far and near-end NAT traversal solutions are used. Network Address traversal is crtical to traffic flow between private public network and from behind firewalls and policy controlled networks
One can use any of the VOVIDA-based STUN server, mySTUN , TurnServer, reStund , CoTURN , NATH (PJSIP NAT Helper), ReTURN, or ice4j
Near-end NAT traversal
STUN (session traversal utilities for NAT) – UA itself detect presence of a NAT and learn the public IP address and port assigned using Nating. Then it replaces device local private IP address with it in the SIP and SDP headers. Implemented via STUN, TURN, and ICE.
limitations are that STUN doesnt work for symmetric NAT (single connection has a different mapping with a different/randomly generated port) and also with situations when there are multiple addresses of a end point.
TURN (traversal using relay around NAT) or STUN relay – UA learns the public IP address of the TURN server and asks it to relay incoming packets. Limitatiosn since it handled all incoming and outgong traffic, it must scale to meet traffic requirments and should not become the bottle neck junction or single point of failure.
ICE (interactive connectivity establishment) – UA gathers “candidates of communication” with priorities offered by the remote party. After this client pairs local candidates with received peer candidates and performs offer-answer negotiating by trying connectivity of all pairs, therefore maximising success. The types of candidates :
– host candidate who represents clients’ IP addresses,
– server reflexive candidate for the address that has been resolved from STUN
– and a relayed candidate for the address which has been allocated from a TURN relay by the client.
Far-end NAT traversal
UA is not concerned about NAT at all and communicated using its local IP port. The border controller implies a NAT handling components such as an application layer gateway (ALG) or universal plug and play (UPnP) etc which resolves the private and public network address mapping by act as a back to back user agent (B2BUA).
Far end NAT can also be enabled by deploying a public SIP server which performs media relay (RTP Proxy/Media proxy).
Limitations of this approach
(-) security risks as they are operating in the public network
(-) enabling reverse traffic from UAS to UAC behind NAT.
A keep-alive mechanism is used to keep NAT translations of communications between SIP endpoint and its serving SIP servers opened , so that this NAT translation can be reused for routing. It contains client-to-server “ping” keep-alive and corresponding server-to-client “pong” messages. The 2 keep-alive mechanisms: a CRLF keep-alive and a STUN keep-alive message exchange.
The 3 types of SIP URIs,
- address of record (AOR)
- fully qualified domain name (FQDN)
- globally routable user agent (UA) URI
SIP uniform resource identifiers (URIs) are identified based on DNS resolution since the URI after @ symbol contains hostname , port and protocl for the next hop.
Adding record route headers for locating the correct SIP server for a SIP message can be done by :
– DNS service record (DNS SRV)
– naming authority pointer (NAPTR) DNS resource record
Steps for SIP endpoints locating SIP server
- From SIP packet get the NAPTR record to get the protocl to be used
- Inspect SRV record to fetch port to use
- Inspect A/AAA record to get IPv4 or IPv6 addresses
ref : RFC 3263 – Locating SIP Servers
Can use BIND9 server for DNS resolution supports NAPTR/SRV, ENUM, DNSSEC, multidomains, and private trees or public trees.
CDR Processing and Billing
CDR store call detail records along with proof of call with tiemstamps, orignation, destination, duaration, rate etc. At the end of month or any other term, the aggregated CDR are cumulatively processed to generate the bill for a user. This heavy data stream needs to be accurately processed and this can be achived by using data-pipelines like AWS kinesis or Kafka eventstore.
The prime requirnment for the system is to handle enormous amount of call records data in relatime , cater to a number of producers and consumers.
For security the data is obfuscated into blob using base 64 encoding.
For good consistency only a single shard should be rsponsible to process one user account’s bill.
Data Streams for billing service
AWS Kinesis – Kinesis Data Streams is sued for for rapid and continuous data intake and aggregation. The type of data used can include IT infrastructure log data, application logs, social media, market data feeds, and web clickstream data. It supports data sharding (ie number of call records grouped) and uses a partition Key ( string MD5 hash) to determine which shard the record goes to.
(+) This system can handle high volume of data in realtime and produce call uuid specfic reults which can be consumed by consumers waiting for the processed results
(-) If not consumed with a pre-specified time duration the processed results expire and are irretrivable . Self implement publisher to store teh processed reults from kisesis stream to data stores like Redis / RDBMS or other storge locations like s3 , dynamo DB. If pieline crashes during operation , data is lost
(-) Data stream should have low latency igesting contnous data from producer and presenting data to consumer.
Call Rate and Accounting
Generally data streams proecssing are used for crtical and voluminious service usage like for
– metering/billing
– server activity,
– website clicks,
– geo-location of devices, people, and physical goods
Call Rates are very crticial for billing and charging the calls . Any updates from the customer or carriers or individuals need to propagate automatically and quickly to avoid discrpencies and neagtive margins. CDRs need to be processed sequentially and incrementally on a record-by-record basis or over sliding time windows, and used for a wide variety of analytics including correlations, aggregations, filtering, and sampling.
To acheieve this the follow setup is ideal to use the new input rate sheet values via web UI console or POST API and propagate it quickly to main DB via AWS SQS which is a queing service and AWS lamda which is a serverless trigger based system . This ensures that any new input rates are updates in realtime and maintin fallback values in s3 bucket too
Cross platform and integration to External Telecommunication provider landscape
It is an advantage to plan for ahead for connection with IMS such as openIMS, support for Voip signalling protocols (SIP, H,323, SCCP, MGCP, IAX) and telephony signalling protocls ( ISDN/SS7, FXS/FXO, Sigtran ) either internally via pluggable modules or externally via gateways or for SIP trunking integration via OTT providers/ cloud telephony.
Adhere to Standard
The obvious starting milestone before making a full-scale carrier-grade, SIP-based VoIP system is to start by building a PBX for intra-enterprise communication. There are readily available solutions to make an IP telephony PBX Kamailio, FreeSWITCH, asterisk, Elastix, SipXecs. It is important to use the standard protocol and widely acceptable media formats and codecs to ensure interoperability and reduce compute and delay involved in protocol or media transcoding.
Database Integration
Need backend , cache , databse integration to npt only store routing rules with temporary varaible values but also aNeed backend, cache, database integration to not only store routing rules with temporary variable values but also account details, call records details, access control lists etc. Should therefore extend integration with text-based DB, Redis, MySQL, PostgreSQL, OpenLDAP, and OpenRadius.
Consistency of Call Records and duplicated charging records at various endpoints
In current Voip scenarios a call may be passing thorugh various telco providers , ISP and cloud telephony serviIn current VoIP scenarios, a call may be passing through various telco providers, ISP and cloud telephony service providers where each system maintains its own call records and billing. This in my opinion is duplication and can be avoided by sharing a consistent data store possible in the blockchain. This is an experimental idea that I have further explored in this article
There are other external components to setup a VOIP solution apart from Core voice Servers and gateways like the ones listed below, I will try to either add a detailed overall architecture diagram here or write about them in an seprate article. Keep watching this space for updates
- Payment Gateways
- Billing and Invoice
- Fraud Prevention
- Contacts Integration
- Call Analytics
- API services
- Admin Module
- Number Management ( DIDs ) and porting
- Call Tracking
- Single Sign On and User Account Management with Oauth and SAML
- Dashboards and Reporting
- Alert Management
- Continuous Deployment
- Automated Validation
- Queue System
- External cache
References :
- [1]AWS kinesis –https://docs.aws.amazon.com/streams/latest/dev/introduction.html
- [2]AWazon docs streaming data – https://aws.amazon.com/streaming-data/
- [3]VOIP monitor Archietcture – https://www.voipmonitor.org/doc/Architecture
- [4]TTS Ivona – http://developer.ivona.com/en/ttsresources/ssml/ssml.html
SIP solutioning and architectures is a subsequent article after SIP introduction, which can be found here.
Read about VoIP/ OTT / Telecom Solution startup’s strategy for Building a scalable flexible SIP platform which includes :
- Scalable and Flexible SIP platform building
- Cluster SIP telephony Server for High Availability
- Failure Recovery
- Multi-tier cluster architecture
- Role Abstraction / Micro-Service based architecture
- Distributed Event management and Event-Driven architecture
- Containerization
- Autoscaling Cloud Servers
- Open standards and Data Privacy
- Flexibility for inter-working – NextGen911 , IMS , PSTN
- security and Operational Efficiencies
Telecom R & D 