In this article by Altanai Bisht, the author of the book, WebRTC Integrator's Guide, has discussed about the interaction of WebRTC client with important IMS nodes and modules. IP Multimedia Subsystem (IMS) is an architectural framework for IP Multimedia communications and IP telephony based on Convergent applications. It specifies three layers in a telecom network:
Transport or Access layer: This is the bottom-most segment responsible for interacting with end systems such as phones.
IMS layer: This is the middleware responsible for authenticating and routing the traffic and facilitating call control through the Service layer.
Service or Application layer: This is the top-most layer where all of the call control applications and Value Added Services (VAS) are hosted.
(For more resources related to this topic, see here.)
IMS standards are defined by Third Generation Partnership Project (3GPP) which adopt and promote Internet Engineering Task Force (IETF) Request for Comments (RFCs). Refer to http://www.3gpp.org/technologies/keywords-acronyms/109-ims to learn more about 3GPP IMS specification releases.
This article will walk us through the interaction of WebRTC client with important IMS nodes and modules. The WebRTC gateway is the first point of contact for the SIP requests from the WebRTC client to enter into the IMS network. The WebRTC gateway converts SIP over WebSocket implementation to legacy/plain SIP, that is, a WebRTC to SIP gateway that connects to the IMS world and is able to communicate with a legacy SIP environment. It also can translate other REST- or JSON-based signaling protocols into SIP. The gateway also handles the media operation that involves DTLS, SRTP, RTP, transcoding, demuxing, and so on.
In this article, we will study a case where there exists a simple IMS core environment, and the WebRTC clients are meant to interact after the signals are traversed through core IMS nodes such as Call Session Control Function (CSCF), Home Subscriber Server (HSS), and Telecom Application Server (TAS).
The Interaction with core IMS nodes
This section describes the sequence of steps that must be followed for the integration of the WebRTC client with IMS. Before you go ahead, set up a Session Border Controller (SBC) / WebRTC gateway / SIP proxy node for the WebRTC client to interact with the IMS control layer.
Direct the control towards the CSCF nodes of IMS, namely, Proxy-CSCF, Interrogating-CSCF, and Serving-CSCF.
The subscriber details and the location are updated in the HSS.
Serving-CSCF (SCSCF) routes the call through the SIP Application Server to invoke any services before the call is processed. The Application Server, which is part of the IMS service layer, is the point of adding logic to call processing in the form of VAS.
Additionally, we will uncover the process of integrating media server for an inter-codec conversion between legacy SIP phones and WebRTC clients.
The setup will allow us to support all SIP nodes and endpoints as part of the IMS land-scape.
The following figure shows the placement of the SIPWS to SIP gateway in the IMS network:
The WebRTC client is a web-based dynamic application that is run over a Web Application Server. For simplification, we can club the components of the WebRTC client and the Web Application Server together and address them jointly as the WebRTC client, as shown in the following diagram:
There are four major components of the OpenIMS core involved in this setup as described in the following sections. Along with these, two components of the WebRTC infrastructure (the client and the gateway) are also necessary to connect the WebRTC endpoints. Three optional entities are also described as part of this setup.
The components of Open IMS are CSCF nodes and HSS. More information on each component is given in the following sections.
The Call Session Control Function
The three parts of CSCF are described as follows:
Proxy-CSCF (P-CSCF) is the first point of contact for a user agent (UA) to which all user equipments (UEs) are attached. It is responsible for routing an incoming SIP request to other IMS nodes, such as registrar and Policy and Charging Rules Function (PCRF), among others.
Interrogating-CSCF (I-CSCF) is the inbound SIP proxy server for querying the HSS as to which S-CSCF should be serving the incoming request.
Serving-CSCF (S-CFCS) is the heart of the IMS core as it enables centralized IMS service control by defining routing paths that act like the registrar, interact with the Media Server, and much more.
Home Subscriber System
IMS core Home Subscriber System (HSS) is the database component responsible for maintaining user profiles, subscriptions, and location information. The data is used in functions such as authentication and authorization of users while using IM services.
The components of the WebRTC infrastructure primarily comprises of WebRTC Web Application Servers, WebRTC web-based clients, and the SIP gateway.
WebRTC Web Application Server and client: The WebRTC client is intrinsically a web application that is composed of user interfaces, data access objects, and controllers to handle HTTP requests. A Web Application Server is where an application is hosted. As WebRTC is a browser-based technique, it is meant to be an HTML-based web application. The call functionalities are rendered through the SIP JavaScript files. The browser's native WebRTC capabilities are utilized to capture and transmit the data. A WebRTC service provider must embed the SIP call functions on a web page that has a call interface. It must provide values for the To and From SIP addresses, div to play audio/video content, and access to users' resources such as camera, mic, and speakers.
WebRTC to IMS gateway: This is the point where the conversion of the signal from SIP over WebSockets to legacy/plain SIP takes place. It renders the signaling into a state that the IMS network nodes can understand. For media, it performs the transcoding from WebRTC standard codecs to others. It also performs decryption and demux of audio/video/RTCP/RTP.
There are other servers that act as IMS nodes as well, such as the STUN/TURN Server, Media Server, and Application Server. They are described as follows:
STUN/TURN Server: These are employed for NAT traversals and overcoming firewall restrictions through ICE candidates. They might not be needed when the WebRTC client is on the Internet and the WebRTC gateway is also listening on a publicly accessible IP.
Media Server: Media server plays a role when media relay is required between the UEs instead of a direct peer-to-peer communication. It also comes into picture for services such as voicemail, Interactive Voice Response (IVR), playback, and recording.
Application Server (AS): Application Server is the point where developers can make customized logic for call control such as VAS in the form of call redirecting in cases when the receiver is absent and selective call screening.
The IP Multimedia Subsystem core
IMS is an architecture for real-time multimedia (voice, data, video, and messaging) services using a common IP network. It defines a layered architecture. According to the 3GPP specification, IMS entities are classified into six categories:
Session management and route (CSCF, GGSN, and SGSN)
Database (HSS and SLF)
Interworking elements (BGCF, MGCF, IM-MGW, and SGW)
Service (Application Server, MRFC and MRFP)
Strategy support entities (PDF)
Billing
Interoperability with the SIP infrastructure requires a session border controller to decrypt the WebRTC control and media flows. A media node is also set up for transcoding between WebRTC codecs and other legacy phones. When a gateway is involved, the WebRTC voice and video peer connections are between the browser and the border controller. In our case, we have been using Kamailio in this role. Kamailio is an open source SIP server capable of processing both SIP and SIPWS signaling.
As WebRTC is made to function over SIP-based signaling, it is applicable to enjoy all of the services and solutions made for the IMS environment. The telecom operators can directly mount the services in the Service layer, and subscribers can avail the services right from their web browsers through the WebRTC client. This adds a new dimension to user accessibility and experience. A WebRTC client's true potential will come into effect only when it is integrated with the IMS framework.
We have some readymade, open IMS setups that have been tested for WebRTC-to-IMS integration. The setups are as follows:
3GPP IMS: This is the IMS specification by 3GPP, which is an association of telecommunications group
OpenIMS: This is the open source implementation of the IMS CSCFs and a lightweight HSS for the IMS core
DubangoIMS: This is the cross-platform and open source 3GPP IMS/LTE framework
KamailioIMS: Kamailio Version 4.0 and above incorporates IMS support by means of OpenIMS
We can also use any other IMS structure for the integration. In this article, we will demonstrate the use of OpenIMS. For this, it is required that a WebRTC client and a non-WebRTC client must be interoperable by means of signaling and media transcoding. Also, the essential components of IMS world, such as HSS, Media Server, and Application Server, should be integrated with the WebRTC setup.
The OpenIMS Core
The Open IMS Core is an open source implementation for core elements of the IMS network that includes IMS CSCFs nodes and HSS. The following diagram shows how a connection is made from WebRTC to CSCF:
The following are the prerequisites to install the Open IMS core:
Make sure that you have the following packages installed on your Linux machine, as their absence can hinder the IMS installation process:
Git and Subversion
GCC3/4, Make, JDK1.5, Ant
MySQL as the database
Bison and Flex, the Linux utilities
libxml2 (Version 2.6 and above) and libmysql with development versions
Install these packages from the Synaptic package manager or using the command prompt.
For the LoST interface of E-CSCF, use the following command lines:
The Domain Name Server (DNS), bind9, should be installed and run. To do this, we can run the following command line:
sudo apt-get install bind9
We need a web browser to review the status of the connection on the web console. To download a web browser, go to its download page. For example, Chrome can be downloaded from https://www.google.com/intl/en_in/chrome/browser/.
We must verify that the Java version installed is above 1.5 so as to not break the compilation process in between, and set the path of JAVA_HOME as follows:
The output of the command line that checks the Java version is as follows:
The following are the steps to install OpenIMS. As the source code is preconfigured to work from a standard file path of /opt, we will use the predefined directory for installation.
Go to the /opt folder and create a directory to store the OpenIMS core, using the following command lines:
mkdir /opt/OpenIMSCore cd /opt/OpenIMSCore
Create a directory to store FHOSS, check out the HSS, and compile the source using the following command lines:
mkdir FHoSS
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS
cd FHoSS
ant compile deploy
Note that the code requires Java Version 7 or lower to work.
Also, create a directory to store ser_ims, check out the CFCs, and then install ser_ims using the following command lines:
mkdir ser_ims
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_ims
cd ser_ims
make install-libs all
After downloading and installing the OpenIMS installation directory, its contents are as follows:
By default, the nodes are configured to work only on the local loopback, and the default domain configured is open-ims.test. The MySQL access rights are also set only for local access. However, this can be modified using the following steps:
Run the following command line:
./opt/ser_ims/cfg/configurator.sh
Replace 127.0.0.1 (the default IP for the local host) with the new IP address that is required to configure the IMS Core server.
Replace the home domain (open-ims.test) with the required domain name.
Change the database passwords.
The following figure depicts the domain change process through configurator.sh:
To resolve the domain name, we need to add a new IMS domain to bind the configuration directory. Change to the system's bind folder (cd /etc/bind) and copy the open-ims.dnszone file there after replacing the domain name.
Open the name.conf file and include open-ims.dnszone in the list that already exists:
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/open-ims.dnszone";
One can also add a reverse zone file, which, contrary to the DNS zone file, converts an address to a name.
Restart the naming server using the following command:
sudo bind9 restart
On occasion of any failure or error note, the system logs/reports can be generated using the following command line:
tail -f /var/log/syslog
Open the MySQL client (sudo mysql) and add the SQL scripts for the creation of database and tables for HSS operations:
mysql -u root -p -h localhost<ser_ims/cfg/icscf.sql
mysql -u root -p -h localhost<FHoSS/scripts/hss_db.sql
mysql -u root -p -h localhost<FHoSS/scripts/userdata.sql
The following screenshot shows the tables for the HSS database:
Users should be registered with a domain (that is, one needs to make changes in the userdata.sql file by replacing the default domain name with the required domain name). Note that while it is not mandatory to change the domain, it is a good practice to add a new domain that describes the enterprise or service provider's name.
The following screenshot shows user domains changed from the default to the personal domain:
Copy the pcscf.cfg, pcscf.sh, icscf.cfg, icscf.xml, icscf.sh, scscf.cfg, scscf.xml, and scscf.sh files to the /opt/OpenIMSCore location.
Start the Policy Call Session Control Function (PCSCF) by executing the pcscf.sh script. The default element port assigned for P-CSCF is 4060.
A screenshot of the running of PCSCF is as follows:
Start the Interrogating Call Session Control Function (I-CSCF) by executing the icscf.sh script.
The default element port assigned to I-CSCF is 5060. If the scripts display a warning about connection, it is just because the FHoSS client still needs to be started. A screenshot of the running I-CSCF is as follows:
Start SCSCF by executing the scscf.sh script. The default element port assignment for S-CSCF is 6060.
A screenshot of the running SCSCF is as follows:
Start the FOKUS Home Subscriber Server (FHoSS) by executing FHoss/deploy/startup.sh.
The HSS interacts using the diameter protocol. The ports used for this protocol are 3868, 3869, and 3870.
A screenshot of the running HSS is shown as follows:
Go to http://<yourip>:8080 and log in to the web console with hssAdmin as the username and hss as the password as shown in the following screenshot.
To register the WebRTC client with OpenIMS, we must use an IMS gateway that performs the function of converting the SIP over WebSocket format to SIP. In order to achieve this, use the IP port or domain of the PCSCF node while registering the client.
The flow will be from the WebRTC client to the IMS gateway to the PCSCF of the IMS Core. The flow can also be from the SIPML5 WebRTC client to the webrtc2sip gateway to the PCSCF of the OpenIMS Core.
The subscribers are visible in the IMS subscription section of the portal of OpenIMS. The following screenshot shows the user identities and their statuses on a web-based admin console:
As far as other components are concerned, they can be subsequently added to the core network over their respective interfaces.
The Telecom server
The TAS is where the logic for processing a call resides. It can be used to add applications such as call blocking, call forwarding, and call redirection according to the predefined values. The inputs can be assigned at runtime or stored in a database using a suitable provisioning system. The following diagram shows the connection between WebRTC and the IMS Core Server:
For demonstration purposes, we can use an Application Server that can host SIP servlets and integrate them with IMS core.
The Mobicents Telecom Application Server
Mobicents SIP Servlet and Java APIs for Integrated Networks-Service Logic Execution Environment (JAIN-SLEE) are open platforms to deploy new call controller logic and other converged applications. The steps to install Mobicents TAS are as follows:
Unzip the contents. Make sure that the Java environment variables are in place.
Start the JBoss container from mobicentsjboss-5.1.0.GAbin
In case of MS Windows, click on run.bat, and for Linux, click on run.sh. The following figure displays the traces on the console when the server is started on JBoss:
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at $19.99/month. Cancel anytime
The Mobicents application can also be developed by installing the Tomcat/Mobicents plugin in Eclipse IDE. The server can also be added for Mobicents instance, enabling quick deployment of applications.
Open the web console to review the settings. The following screenshot displays the process:
In order to deploy Resource Adaptors, enter:
ant -f resources/<name of resource adapter>/build.xml deploy
To undeploy the resource adapters, execute antundeploy with the name of the resource adapter:
ant -f resources/<name of resource adapter>/build.xml undeploy
Make sure that you have Apache Ant 1.7. The deployed instances should be visible in a web console as follows:
To deploy and run SIP Servlet applications, use the following command line:
ant -f examples/<name of application directory>/build.xml deploy-all
Configure CSCF to include the Application Server in the path of every incoming SIP request and response.
With the introduction of TAS, it is now possible to provide customized call control logic to all subscribers or particular subscribers. The SIP solution and services can range from simple activities, such as call screening and call rerouting, to a complex call-handling application, such as selective call screening based on the user's calendar. Some more examples of SIP applications are given as follows:
Speed Dial: This application lets the user make a call using pre-programmed numbers that map to actual SIPURIs of users.
Click to Dial: This application makes a call using a web-based GUI. However, it is very different from WebRTC, as it makes/receives the call through an external SIP phone.
Find me Follow Me: This application is beneficial if the user is registered on multiple devices simultaneously, for example, SIP phone, X-Lite, and WebRTC. In such a case, when there is an incoming call, each of the user's devices rings for few seconds in order of their recent use so that the user can pick the call from the device that is nearest to him.
These services are often referred to as VAS, which can be innovative and can take the user experience to new heights.
The Media Server
To enable various features such as Interactive Voice Respondent (IVR), record voice mails, and play announcements, the Media Server plays a critical role. The Media Server can be used as a standalone entity in the WebRTC infrastructure or it can be referenced from the SIP server in the IMS environment.
The FreeSWITCH Media Server
FreeSWITCH has powerful Media Server capabilities, including those for functions such as IVR, conferencing, and voice mails. We will first see how to use FreeSWITCH as a standalone entity that provides SIP and RTP proxy features.
Let's try to configure and install a basic setup of FreeSWITCH Media Server using the following steps:
Download and store the source code for compilation in the /usr/src folder, and run the following command lines:
cd usr/src
git clone -b v1.4 https://stash.freeswitch.org/scm/fs/freeswitch.git
A directory named freeswitch is made using the following command line and binaries will be stored in this folder. Assign all permissions to it.
sudo chown -R <username> /usr/local/freeswitch
Replace <username> with the name of the user who has the ownership of the folder.
Go to the directory where the source will be stored, that is, the following directory:
cd /usr/src/freeswitch
Then, run bootstrap using the following command line:
./bootstrap.sh
One can add additional modules by editing the configuration file using the vi editor. We can open our file using the following command line:
vi modules.conf
The names of the module are already listed. Remove the # symbol before the name to include the module at runtime, and add # to skip the module. Then, run the configure command:
./configure --enable-core-pgsql-support
Use the make command and install the components:
make && make install
Go to the Sofia profile and uncomment the parameters defined for WebSocket binding. By doing so, the WebRTC clients can register with FreeSWITCH on port 443.
Sofia is an SIP stack used by FreeSWITCH. By default, it supports only pure SIP requests. To get WebRTC clients, register with FreeSWITCH's SIP Server.
<!-- uncomment for SIP over WebSocket support --> <!-- <param name="ws-binding" value=":443"/>
Install the sound files using the following command line:
make all cd-sounds-install cd-moh-install
Go to the installation directory, and in the vars.xml file under freeswitch/conf/ make sure that the codec preferences are set as follows:
We can later add more codecs such as vp8 for video calling/conferencing.
To start FreeSWITCH, go to the /freeswitch/bin installation directory and run FreeSWITCH.
Run the command-line console that will be used to control and monitor the passing SIP packets by going to the /freeswitch/bin installation directory and executing fs_cli.
The following is the screenshot of the FreeSWITCH client console:
Go to the /freeswitch/conf/SIP_profile installation-directory and look for the existing configuration files.
Load and start the SIP profile using the following command line:
sofia profile <name of profile> start load
Restart and reload the profile in case of changes using the following command line:
sofia profile <name of profile>restart reload
Check its working by executing the following command line:
Sofia status
We can check the status of the individual SIP profile by executing the following command line:
sofia status profile <name of profile> reg
The preceding figure depicts the status of the users registered with the server at one point of time.
Media Services
The following steps outline the process of using the FreeSWITCH media services:
Register the SIP softphone and WebRTC client using FreeSWITCH.
Use sample values between 1000 and 1020 initially. Later, we can configure for more users as specified by the /freeswitch/conf/directory installation directory.
The following are the sample values to register Kapanga:
Username: 1002
Display name: any
Domain/ Realm: 14.67.87.45
Outbound proxy: 14.67.87.45:5080
Authorization user: 1002
Password: 1234
The sample value for WebRTC client registration, if, for example, we decide to use the Sipml5webrtc client, for example, will be as follows:
Display name: any
Private identity: 1001
Public identity: SIP:1001@14.67.87.45
Password: 1234
Realm: 14.67.87.45
WebSocket Server URL: ws://14.67.87.45:443
Note that the values used here are arbitrary for the purpose of understanding.
IP denotes the public IP of the FreeSWITCH machine and the port is the WebSocket configured port in the Sofia profile. As seen in the following screenshot, it is required that we tick the Enable RTCWeb Breaker option in Expert settings to compensate for the incompatibility between the WebSocket and SIP standards that might arise:
Make a call between the SIP softphone and WebRTC client. In this case, the signal and media are passing through FreeSWITCH as proxy.
Call from a WebRTC client is depicted in the following screenshot, which consists of SIP messages passing through the FreeSWITCH server and are therefore visible in the FreeSWITCH client console. In this case, the server is operating in the default mode; other modes are bypass and proxy modes.
Make a call between two WebRTC clients, where SIP and RTP are passing through FreeSWITCH as proxy.
We can use other services of FreeSWITCH as well, such as voicemail, IVR, and conferencing.
We can also configure this setup in such a way that media passes through the FreeSWITCH Media Server, and the SIP signaling is via the Telecom Kamailio SIP server.
Use the RTP proxy in the SIP proxy server, in our case, Kamailio, to pass the RTP media through the Media Server. The RTP proxy module of Kamailio should be built in a format and configured in the kamailio.cfg file. The RTP proxy forces the RTP to pass through a node as specified in the settings parameters. It makes the communication between SIP user agents behind NAT and will also be used to set up a relaying host for RTP streams. Configure the RTP Engine as the media proxy agent for RTP. It will be used to force the WebRTC media through it and not in the old peer-to-peer fashion in which WebRTC is designed to operate. Perform the following steps to configure the RTP Engine:
Go to the Kamailio installation directory and then to the RTPProxy module. Run the make command and install the proxy engine:
cd rtpproxy
./configure && make
Load the module and parameters in the kamailio.cfg file:
Go to the daemon folder in the installation directory and run the make command as follows:
sudo make
Start rtpengine in the default user space mode on the local machine:
sudo ./rtpengine --ip=10.1.5.14 --listen-ng=12334
Check the status of rtpengine, which is running, using the following command:
ps -ef|grep rtpengine
Note that rtpengine must be installed on the same machine as the Kamailio SIP server.
In case of the sipml5 client, after configuring the modules described in the preceding section and before making a call through the Media Server, the flow for the media will become one of the following:
In case of Voicemail/IVR, the flow is as follows:
WebRTC client to RTP proxy node to Media Server
In case of a call through media relay, the flow is as follows:
WebRTC client A to RTP proxy node to Media Server to RTP Proxy to WebRTC client B
The following diagram shows the MediaProxy relay between WebRTC clients:
The potential of media server lies in its media transcoding of various codecs. Different phones / call clients / softwares that support SIP as the signaling protocol do not necessarily support the same media codecs. In the situation where Media Server is absent and the codecs do not match between a caller and receiver, the attempt to make a call is abruptly terminated when the media exchange needs to take place, that is, after invite, success, response, and acknowledgement are sent.
In the following figure, the setup to traverse media through the FreeSWITCH Media Server and signaling through the Kamailio SIP server is depicted:
The role of the rtpproxyng engine is to enable media to pass via Media Server; this is shown in the following diagram:
WebRTC over firewalls and proxies
There are many complicated issues involved with the correct working of WebRTC across domains, NATS, geographies, and so on. It is important for now that the firewall of a system, or any kind of port-blocking policy, should be turned off to be able to make a successful audio-video WebRTC call across any two parties that are not on the same Local Area Network (LAN).
For the user to not have to switch the firewall off, we need to configure the Simple Traversal of UDP through NAT (STUN) server or modify the Interactive Connectivity Establishment (ICE) parameter in the SDP exchanged. STUN helps in packet routing of devices behind a NAT firewall. STUN only helps in device discoverability by assigning publicly accessible addresses to devices within a private local network.
Traversal Using Relay NAT (TURN) servers also serve to accomplish the task of inter-connecting the endpoints behind NAT. As the name suggests, TURN forces media to be proxied through the server.
To learn more about ICE as a NAT-traversal mechanism, refer to the official document named RFC 5245.
The ICE features are defined by sipML5 in the sipml.js file. It is added to SIP SDP during the initial phase of setting up the SIP stack. Snippets from the sipml.js file regarding ICE declaration are given as follows:
var configuration = {
...
websocket_proxy_url: 'ws://192.168.0.10:5060',
outbound_proxy_url: 'udp://192.168.0.12:5060',
ice_servers: [{ url: 'stun:stun.l.google.com:19302'}, {
url:'turn:user@numb.viagenie.ca', credential:'myPassword'}],
...
};
Under the postInit function in the call.htm page add the following function:
oConfigCall = {
...
events_listener: { events: '*', listener: onSipEventSession },
SIP_caps: [
{ name: '+g.oma.SIP-im' },
{ name: '+SIP.ice' },
{ name: 'language', value: '"en,fr"' }
]
};
Therefore, the WebRTC client is able to reach the client behind the firewall itself; however, the media displays unpredicted behavior.
In the need to create our own STUN-TURN server, you can take the help of RFC 5766, or you can refer to open source implementations, such as the project at the following site:
When setting the parameters for WebRTC, we can add our own STUN/TURN server. The following screenshot shows the inputs suitable for ICE Servers if you are using your own TURN/STUN server:
If there are no firewall restrictions, for example, if the users are on the same network without any corporate proxies and port blocks, we can omit the ICE by entering empty brackets, [], in the ICE Servers option on the Expert settings page in the WebRTC client.
The final architecture for the WebRTC-to-IMS integration
At the end of this article, we have arrived at an architecture similar to the following diagram. The diagram depicts a basic WebRTC-to-IMS architecture.
The diagram depicts the WebRTC client in the Transport Layer as it is the user end-point. The IMS entities (CSCF and HSS), WebRTC to IMS gateway, and Media Server nodes are placed on the Network Control Layer as they help in signal and media routing. The applications for call control are placed in the top-most Application Layer that processes the call control logic. This architecture serves to provide a basic IMS-based setup for SIP-based WebRTC client interaction.
Summary
In this article, we saw how to interconnect the WebRTC setup with the IMS infrastructure. It included interaction with CSCF nodes, namely PCSCF, ICSCF, and SCSCF, after building and installing them from their sources. Also, FreeSWITCH Media Server was discussed, and the steps to build and integrate it were practiced. The Application Server to embed call control logic is Kamailio. NAT traversal via STUN / TURN server was also discussed and its importance was highlighted.
To deploy the WebRTC solution integrated with the IMS network, we must ensure that all of the required IMS nodes are consulted while making a call, the values are reflected in the HSS data store, and the incoming SIP request and responses are routed via call logic of the Application Server before connecting a call.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Canary Islands
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
