Limitations of the existing setup

We saw how to develop a WebRTC client, install an SIP server, and configure a WebRTC to SIP environment. A sky view of our final, existing client-server solution setup for SIPWS signaling and WebRTC media so far is shown as follows:

As per our current setup status, only the WebRTC-enabled client and servers can participate in the communication flow in an offer/answer (O/A) model.

There are, however, numerous limitations of the existing solution, some of which are mentioned in the following sections. In the upcoming chapters, we shall do away with most of the limitations.

Firewall and NAT issues

The existing architecture does not provide the Network Address Translation (NAT) technique to overcome the blockage due to firewalls and enterprise policies. As a solution, we must see the alternative for public IP discovery in the WebRTC client server setup. NAT is possible in the Kamailio server through RTP proxy modules and STUN.

Media transcoding

If the codecs on two endpoints do not match for audio and video communication, then it could lead to a session failure with an abrupt termination of calls when a user picks up a ringing call. There is where the media transcoder is required to support communication with non-WebRTC devices such as SIP phone and softphones. As a solution, we can either use the RTCWeb Breaker, which converts SDP and media streams for WebRTC and other UAs, or configure the media server such as FreeSWITCH, which provides the functionality. The following diagram shows the complete architecture with the STUN server and RTCWeb Breaker:

A call flow that depicts the flow of media from the WebRTC client to the non-WebRTC client (SIP phone) through the RTCWeb Breaker is shown as follows:

Call flow with Media Transcoder to connect WebRTC and non-WebRTC endpoints

Real time-Transport Protocol (RTP), which is the media flow mechanism in most SIP clients, including SIP-based WebRTC, comprises two parts: the RTP data transfer protocol and the RTP Control Protocol (RTCP). In addition to this, WebRTC also mandates the use of Secure RTP Profile (RTP/SAVP) for RTCP-based feedback. An RTP profile defines media parameters such as compression and encoding.

The RTP/SAVPF profile, as depicted in the following diagram, is the combination of the basic RTP/AVP profile, the RTP profile for RTCP-based feedback (RTP/AVPF), and the RTP/SAVP. The RTCP-based feedback extensions are needed for the improved RTCP timer that enables features such as more flexible transmission and report of congestion.

After fulfilling the limitations, there are some recommended enhancements in the existing architecture; they contribute to making a robust, secure communication platform. The limitations are described as follows:

• Media should not be free flowing between peer to peer but passing through a media relay mechanism. A media relay mechanism involves a media server to be in the path of the media flow. This way, the media server receives the audio/video from one end and relays it to the other end. This leads to a better control on the communication by centralized network nodes.
  
• Ipv4 and Ipv6 must be supported.
• The Telecom Application server is needed to embed the logic of SIP services such as call waiting, call forwarding, and call screening.
  
• Database implementation must happen to keep track of calls, user authentication, user profile, and so on.
• The monitoring tools allow for real-time statistics that, in turn, help the service provider to make predictive judgments and review the status at real time. This also aids in charging and billing if the service provider opts to bill the customer.

We will overcome these and a few more limitations when integrating with the IP Multimedia Subsystem (IMS) environment. They will be discussed in detail in the next chapter.