We used Brekeke SIP server to run our SIP applications . Although there are newer versions of Brekeke SIP server out now . More awesome than before , we prefer using the old one for the sake of not messing with legacy SIP applications . The official site for brekeke is – http://www.brekeke.com/sip/ .
A general architecture of Brekeke SIP server is .
Here are the steps of installing and configuring a Brekeke SIP server .
Step 5 : Once the license is activates , we can goto the console screen after loggin with default username and password sa .
Step 6 : Once we are at console , we could add/ delete / modify parameters like port , start/shutdown status etc . Step 7 : Once the server is all setup , just add the IP and port of SIP server to SIP clients server filed . Now all the SIP request and response will be catered by this SIP Server
Bea server is a old SIP servlet container ie application server which is used to embed control logic in a program . It is supported on jdk1.5 hence the system’s environment variables must match . Otherwise in later stages deploying applications throw class version error .
1. Install Bea Weblogic
2. Follow the Installation steps
Make domain
3. Goto the installation directory . Usually C:/bea/user_projects/mydomain/ .
click on startweblogic.cmd in windows. In case the system is linux run startweblogic.sh script
6. Build it with ant . For this go inside the application folder and run ant. Output will either be “failed to build “ or “build successfully” .
The ant command generates the war file from SIP servlet Web application .
7. Incase of successful build . Add the application to Weblogic web console install section and activate it .
I will demonstrate this process in step by step manner . First click on “ Lock and Edit “ Button on the left panel . Then goto Install button in the centre area and browser to the location of application war or sar we have build through ant ,
8. We can delete an application in exactly the same way . click on “ Lock and Edit “ Button on the left panel . Then goto the delete button after selecting the radio button alongside the application we want to delete.
8. For enhanced application building we can also refer to sample provided along with bea weblogic . file:///C:/bea/sipserver30/samples/sipserver/examples/src/index.html
A VOIP 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 network providers , enterprise applications ( Skype , Microsoft Lync ), Trunks etc .
A sufficiently capable SIP platform should consist of following features :
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
Backend support like Redis, MySQL, PostgreSQL, Oracle, Radius, LDAP, Diameter
serial and parallel forking
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 :
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
Security considerations :
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 :
from Infrastructure standpoint
from core voice engineering perspective
and accompanying 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 resiliency of data.
WORM compliant NAS for storing voice archives over a retention period.
Racks, power supplies, battery backups, cages etc.
Networking
DMZs ( Demilitarised Zones) which are interfacing areas between internal servers in 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 security of internal IPs and port
Integral Components of a VOIP SIP based architecture
SIP platform components
Call Controller
Media Manager
Recording
Softclients
logs and PCAP archives
CDR generators
Session Borer Controllers ( SBCs)
Detailing some of the protocols apart from SIP used in VOIP solution
RTP ( Real Time Transport Protocol )
RTP handles realtime multimedia transport between end to end network components . RFC 3550 .
Packet structure of RTP
RTP Header contain timestamp , name of media source , codec type and sequence number .
RTCP
– tbd
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.
Types of SIP servers are listed below . It is important to understand the roles a SIP server can be moulded to take up which in turn defines its placement in overall voip communication platform such as stateless proxy servers on the border , application and B2BUA server at the core etc
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 PSTN for telephony inter-working
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 .
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 as used for building call routing scripts to be mounted on SIP servers or endpoints such as : – PJSIP in C – JSSIP Javascript – Sofia in kamailio
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
Adding Media Management
Media processing is usually provided by media servers in accordance to the SIP signalling. Brideges, call recording, Voicemail, audio conferencing, and interactive voice response (IVR) are commomly used.
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.
SIP platform Development
A sufficiently capable SIP platform shoudl consist of following features :
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
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
Add NAT and DNS components
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 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.
Cross platform and integration to External Telecommunication provider landscape
connection to 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
Database Integration
Need backend , cache , databse integration to npt only store routing rules with temporary varaible values but also account details , call records details, access control lists etc. Should therefore extend integartion with text based db, redis, MySQL, PostrgeSQL, OpenLDAP, and OpenRadius.
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 a IP telephony PBX kamailio , freeswitch , asterisk , Elastix , SipXecs
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
Step 7 : Once the server is all setup , just add the IP and port of SIP server to SIP clients server filed . Now all the SIP request and response will be catered by this SIP Server
