Telecom Service Broking supplements value-added telecom services ( VAS) by blending several existing services. For example Call Screening with Find me follow me service, or Call Forwarding with Voice Mail etc, or a logical combination of all of them.
Service Broker combining 4 services inot a single calloflow
Service Broker is part of a unified platform for allowing carriers, mobile operators, and cable operators to rapidly create, manage, and deliver converged video, voice, and data service bundles across multiple networks and devices. Service Broker works as mediator layer between Network Environment and Application environment layer. It manage the new services, existing services & combine them with each other in loose coupling. I have defined Service Broker , Service Harmonization and Servic orchestration here – Service Broker 1
It contains detailed and full fleshed architecture diagrams of Service Broker and how service provider acts as a central Node for Services invocation and services composition. It clearly shows Service Broker provides Services Orchestration / Interaction , service development, third party integration and acts like a protocol gateway .
Today’s voice services are predominantly delivered via Service Control Points (SCP) or Intelligent Network (IN) Application Servers that rely on IN protocols (such as INAP and CAMEL) for complex call control. Those services tend to be highly stable and profitable and also highly customized, and are therefore not easily moved to SIP-based application servers.
Recreating the functionality of deployed IN-based applications requires a exhaustive survey, documentation, and duplication of used features and capabilities, a task that may not be easily achieved. CSPs will need to deliver these same services (down to feature sets and even quirky behavior) on LTE subscribers to ensure migrated users have the same level of service and experience.
As CSPs evolve their networks for LTE, the resulting networks present tremendous challenges in voice services and application delivery. Realizing this opportunity, the telecom software industry has come forward with a purpose-built network element: the Service Broker, a solution specifically designed to overcome network architecture challenges and ensure voice service delivery from any network domain to any other network domain.
Service Brokers are placed between the application layer and the control layer, with the purpose of delivering and extending the reach of applications to all network domains of the CSP. They do this by performing the signaling, media and call control interworking between the applications and different network domains. Implicit in the successful deployment of service brokers is the capability of delivering the required interworking without necessitating changes to either the applications or the networks.
Service Brokers provide many functionality. Among them the most often delivered features are:
• IMS Service Broker • IN-IN Trigger Management • Real-Time Charging • Protocol/Call Flow Management/Call Screening Management • Subscriber Data Management Interaction • Media Resource Brokering • Service Orchestration
The Service Broker’s ability to perform orchestration and combination of discrete voice applications and services into new combined offerings (voice mash-ups) is particularly exciting. With this capability CSPs are able of creating new revenue-producing offers to subscribers where they previously were not available: CRBT ( Ring Back Tome ) and Pre Paid, Find Me / Follow Me combined with Voice VPNs, etc.
Service Brokers also provide the capability of generating Real-Time Charging events, either programmatically (via an API) or automatically as part of service delivery. The challenge facing CPSs is delivering new, innovative services that seamlessly integrate into existing billing platforms. Doing so often means normalizing charging events or even transforming charging events from one technology to another, as is the case in IN to IMS migration.
In conclusion, the Service Broker is responsible for orchestrating and delivering combinational services and generating a charging event upon successful start/completion of those enhanced services.
Convergence : Telephone networks and computer networks converging into single digital network using Internet standards. Components in a Network Client computer Server computer Network interfaces (NICs) Connection medium Network operating system Hub or switch Routers- Device used to route packets of data through different networks, ensuring that data sent gets to the correct address Figure :simple computer … Continue reading Internet Telephony Convergence- JAINSLEE Platform
Packet Switched and/or Circuit swicthed Communication The earlier models were distributed between legacy circuit switched networks and evolving packet switched networks With the massive improvents in quality of network srevices packet switched comunication protocls became more resilent and replaced the circuit swicthed protcols for realtime communication. LTE ( Long Term Evolution ) LTE evolved its … Continue reading IMS in EPC ( Evolved Packet Core )
There is a strong evolution being seen in CSP space. Now operators are looking forward to implement the open standard for intelligent networks. It reduces their dependency on proprietary platforms and on vendor’s road maps. Open –source platform gives operator flexibility to develop their own applications without being dependent on vendor. An open, standards based, service logic execution environment (SLEE) that integrates with current and future networks is the key to providing innovative and revenue generating services. Providing one (standards based) carrier grade execution environment that integrates SS7, SIP, OSA/Parlay, OSS/BSS and J2EE environments offers significant benefits to operator.
Business benefits of SIP JAINSLEE based platform
Network Independence: The JAIN SLEE framework is independent of any particular network protocol, API or network topology. This is supported through the resource adaptor architecture
Portable Services: Application components can be developed and then deployed on JAIN SLEE compliant platforms from different vendors without recompilation or source code modification.
Supports Complex Applications: JAIN SLEE application components can have state, can be composed from other components, can create and destroy other application components, can invoke other application components both synchronously and asynchronously, and can invoke resource adaptors.
Industry Standard: JAIN SLEE is specified via the Java Community Process which allows multiple companies and individuals to collaborate in developing Java technology specifications.
In order to reduce the operating cost of legacy infrastructure more and more operators are investing and implementing open source platform. These new platforms bring agility and new service delivery capability to CSP.
The JAINSLEE based platform can be used to develop and deploy carrier-grade applications that use SS7-based protocols such as INAP and CAP, IP protocols such as SIP and Diameter, and IT / Web protocols, such as HTTP Servlet, XML and Service Orientated Architectures (SOA).
Fundamental Concepts :
Application can be written once and run on many different implementations of JAIN SLEE.
Applications can access resources and protocols across multiple networks from within the JAIN SLEE environment.
Follows the ACID transaction .
component model for structuring the application logic of communications applications as a collection of reusable
object-orientated components, and for composing these components into higher level and more sophisticated services.
SLEE specification also defines the management interfaces used to administer the application environment and also
defines set of standard Facilities (such as the Timer Facility, Trace Facility, and Alarm Facility so on )
Extension framework to allow new external protocols and systems (such as MSCs, MMSCs, SMSCs, Softswitchs, CSCFs, HLRs) to be integrated.
Characteristics of SLEE specification
• Event based model, asynchronous, support for composition
• Container manages component state
• Container manages garbage collection of components
• Transaction boundaries for demarcation and semantics of state replication
• Management of lifecycle of Server, Services, Provisioned state
• Versioned services, upgrade of services, existing activities stay on existing service instances, new activities are directed to instances of upgraded services
• Independent of network technology/ protocols/elements through resource adaptor architecture
Entities :
Service
A service in JAIN SLEE terminology is a managed field replaceable unit.
The system administrator of a JAIN SLEE controls the life cycle (including deployment, undeployment and on-line upgrade) of a service. The program code can include Java classes Profiles, and Service Building Blocks.
Profile
A JAIN SLEE Profi le contains provisioned service or subscriber data.
Service Building Blocks running inside the JAINSLEE may access profiles as part of their application logic.
Service Building Block
The element of re-use defined by JAINSLEE is the Service Building Block (SBB).
An SBB is a software component that sends and receives events and performs computational logic based on the receipt of events and its current state. SBBs are stateful.
The program code for an SBB is comprised of Java classes.
Event
An event represents an occurrence that may require application processing.
An event may originate from a number of different sources, for example, an external resource such as a communications protocol stack, from the SLEE itself, or from application components within the SLEE.
Resources and Resource ADAPTERS
Resources are external entities that interact with other systems outside of the SLEE, such as network elements (HLR, MSC, etc), protocol stacks, directories and databases.
A Resource Adaptor implements the interfacing of a Resource into the JAINSLEE environment.
Historically, RTC has been corporate and complex, requiring expensive audio and video technologies to be licensed or developed in house. Integrating RTC technology with existing content, data and services has been difficult and time consuming, particularly on the web.
OTT ( Over The Top ) Applications
Now with WebRTC the operator finally gets a chance to take the shift the focus from OTT ( Over The Top service providers like SKype , Google chat WebEx etc that were otherwise eating away the Operators revenue ) to its very own WebRTC client Server solution , hence making the VOIP calls chargeable , while at the same time being available from any client ( web or softphone based )
In simple words, it’s a phenomenal change in decentralizing communication platforms from proprietary vendors who heavily depended on patented and royalty bound technologies and protocols. It will revolutionize internet telephony. Also it will emerge to be platform-independent ( ie any browser, any desktop operating system any mobile Operating system).
WebRTC allows anybody to introduce real-time communication to their web page as simple as introducing a table.
Where are we now with WebRTC ?
WebRTC has now implemented open standards for real-time, plugin-free video, audio and data communication. Many web services already use RTC, but need downloads, native apps or plugins. These includes Skype, Facebook (which uses Skype Flash ) and Google Hangouts (which use the Google Talk plugin).
Downloading, installing and updating plugins can be complex, error prone and annoying , such as Flash , Java.,etc. Plugins can be difficult to deploy, debug, troubleshoot, test and maintain—and may require licensing and integration with complex, expensive technology. It’s often difficult to persuade people to install plugins in the first place/ bookmark it or keep it activated at all times.
2015
update 2021
WebRTC support across various browsers , pic source : caniuse.com
The APIs and standards of WebRTC can democratize and decentralize tools for content creation and communication—for telephony, gaming, video production, music making, news gathering and many other applications.
In 2015, edge and Safari were the most difficult to work with around WebRTC.
(2015) pic source: iswebrtcreadyyet.com
Now (2021) almost all the browser have support for WebRTC basic API and advanced API support such as mediaStreamRecorder is in progress as well.
WebRTC is a flexible, free lightweight tool that can be used to quickly build p2p real-time communication applications. Due to the easy to programmable nature of WebRTC API, many applications have switched to using the media streaming and communication capabilities of browser-based WebRTC user agents such as conferencing and web dialling, telemedicine and e-learning applications. even innovative use cases such as broadcasting, gaming, IPTV based applications integrate with WebRTC for the royalty free codecs and media stack. WebRTC endpoints can also integrate with telecom endpoints ( PSTN, GSM, 3G, LTE phone and 5G phones) using gateways and trunks.
WebRTC (Web Real-Time Communication) is an API definition drafted by the World Wide Web Consortium (W3C) that supports browser-to-browser applications for voice calling, video chat, and P2P file sharing without the need for either internal or external plugins.
Enables browser to browser media streaming over secure RTP profile
Standardization, on an API level at the W3C and at the protocol level at the IETF.
Enables web browsers with Real-Time Communications (RTC) capabilities
written in c++ and javascript
BSD style license
free, open project available in all major browsers
VideoEngine is a framework video media chain for video, from camera to the network, and from network to the screen.
VP8 : Video codec from the WebM Project. Designed for low latency Real time Comm.
Video Jitter Buffer: conceal the effects of jitter and packet loss on overall video quality.
Image enhancements : removes video noise
Transport
Transport / Session Layer of WebRTC stack provide Session Management for WebRTC media streams .
It consists of network stack for Secure RTP, the Real Time Protocol.
STUN/ICE for NAT , Network Address Traversal across various types of networks.
Session Management which is an abstracted session layer for call setup.
Standardization by IETF and W3C
As of the 2019 update the W3C defines it as
a set of ECMAScript APIs in WebIDL to allow media to be sent to and received from another browser or device implementing the appropriate set of real-time protocols. The specification being developed in conjunction with a protocol specification developed by the IETF RTCWEB group and an API specification to get access to local media devices.
W3C contribution to WebRTC standardization
Media Stream Functions : API for connecting processing functions to media devices and network connections, including media manipulation functions.
Audio Stream Functions : An extension of the Media Stream Functions to process audio streams (e.g. automatic gain control, mute functions and echo cancellation).
Video Stream Functions : An extension of the Media Stream Functions to process video streams (e.g. bandwidth limiting, image manipulation or “video mute“).
Functional Component : API to query presence of WebRTC components in an implementation, instantiate them and connect them to media streams.
P2P Connection Functions : API functions to support establishing signalling protocol-agnostic peer-to-peer connections between Web browsers
API specification Availability
WebRTC 1.0: Real-time Communication Between Browsers – Draft 3 June 2013 available
Implementation Library: WebRTC Native APIs
Media Capture and Streams – Draft 16 May 2013
Supported by Chrome , Firefox, Opera in desktop of all OS ( Linux, Windows , Mac )
Supported by Chrome , Firefox in Mobile browsers ( android )
IETF contribution to to WebRTC standardization
Communication model
Security model
Firewall and NAT traversal
Media functions
Functionality such as media codecs, security algorithms, etc.,
Media formats
Transport of non media data between clients
Input to W3C for APIs development
Interworking with legacy VoIP equipment
Open and Free Codecs
Codecs signifies the media stream’s compession and decompression. For peers to have suceesfull excchange of media, they need a common set of codecs to agree upon for the session . The list codecs are sent between each other as part of offeer and answer or SDP in SIP.
WebRTC uses bare MediaStreamTrack objects for each track being shared from one peer to another. Codecs associated in those tracks is not mandated by webrtc soecification.
For video as per RFC 7742 WebRTC Video Processing and Codec Requirements , the manadatory codesc to be supported by webrtc clients are : VP8 and H.264‘s Constrained Baseline profile.
For Audio as per RFC 7874 WebRTC Audio Codec and Processing Requirements, browser must support Opus codec as well as G.711‘s PCMA and PCMU formats.
Unless the SDP specifically signals otherwise, the web browser receiving a WebRTC video stream must be able to handle video at at least 20 FPS at a minimum resolution of 320 pixels wide by 240 pixels tall.
In the best scenarios ( avaible bandwidth and media devices ) VP8 had no upper mark set on resolution of vdieo stream hence the stream can even go asfar as maximum resolution of 16384×16384 pixels.
Webrtc does not specify any signalling / telecommunication protocl and it is upto the adoptor to perform ofeer/answer exchaneg in any way deemed fit for the usecase . For ex maple for a web only application on may use only plain websockets, whereas for a teelcom endpoints compatible app one should SIP as the protocol.
NAT-traversal ( ICE, STUN, and TURN)
The post describe ICE (Interactive Connectivity Establishment ) framework which is mandatory by WebRTC standards. It is find network interfaces and ports in Offer / Answer Model to exchange network based information with participating communication clients. ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). I have written in detail about TURN based WebRTC flow diagrams in post below.
Learn about hosting / integrating different TURN servers for WebRTC in the article on “TURN server for WebRTC – RFC5766-TURN-Server , Coturn , Xirsys “.
WebRTC video quality is noticeably better than Flash.
(+) Up to 6x faster connection times
Using JavaScript WebSockets, also an HTML5 standard, improves session connection times and accelerates delivery of other OpenTok events.
(+) Reduced audio/video latency
WebRTC offers significant improvements in latency through WebRTC, enabling more natural and effortless conversations.
(+) Freedom from plugins like Flash
With WebRTC and JavaScript WebSockets, you no longer need to rely on Flash for browser-based RTC.
(+) Native HTML5 elements
Customize the look and feel and work with video like you would any other element on a web page with the new video tag in HTML5.
The major players behind the conception and advancement of WebRTC standards and libraries are IETF, W3C, Java community, GSMA. The idea is to develop a Lightweight browser-based call console, to make SIP calls from a Web page. This was successfully achieved using fundamental technologies – Javascript, html5, web-sockets and TCP /UDP, open-source sip server. It is good to note that there is no extra extension, plugin or gateway required, such as flash support. Also, it bears cross-platform support, including Mozilla, chrome so on.
Bottlnecks
Although WebRTC is a great technology and holds very good potential it is not devoid of problems
(-) Secure networks and Firewalls block RTP (-) Security in VPN and topology hiding (-) Cross-platform concerns and codecs incompatible (-) Late adopters like Microsoft and Apple
WebRTC forms a p2p communication channel between all the peers . that means as the participant count grows , it converts to a mesh networking topology with incoming and outgoing stream towards direction of each of its peers .
Two party call p2p
Peer to peer calling
p2p call
Multiparty Call and mesh network
Mesh based arrangement .
Mesh based webrtc video confeerncing
In special case of broadcasting or large number of viewers ( without outgoing media stream ) it is recommended to setup a Media Control Unit ( MCU) which will replay the incoming stream to large number of users without putting traffic load on the clients from where the stream is actually originating . Important note :
It should be noted that these diagrams do not depict the ICE and NAT traversal and have been simplified for better understanding. In real-world scenarios, almost all the time STUN and TURN servers are involved.
Also, the webrtc mandates the use of secure origin ( HTTPS ) on the webpage which invoke getusermedia to capture user media devices like audio, video and location.
navigator.mediaDevices.getUserMedia({ audio: true, video: true })
.then(function(stream) {
var video = document.querySelector('video');
// Older browsers may not have srcObject
if ("srcObject" in video) {
video.srcObject = stream;
} else {
// Avoid using this in new browsers, as it is going away.
video.src = window.URL.createObjectURL(stream);
}
video.onloadedmetadata = function(e) {
video.play();
};
})
.catch(function(err) {
console.log(err.name + ": " + err.message);
});
DOMException Error on getusermedia
Rejections of the returned promise are made by passing a DOMException error object to the promise’s failure handler. Possible errors are:
AbortError : Although the user and operating system both granted access to the hardware device, problem occurred which prevented the device from being used.
NotAllowedError : One or more of the requested source devices cannot be used at this time. This will happen if the browsing context is insecure( http instead of https) or if the user has specified that the current browsing instance /sessionis not permitted access to the device or has denied all access to user media devices globally.
NotFoundError : No media tracks of the type specified were found that satisfy the given constraints.
NotReadableError : Although the user granted permission to use the matching devices, a hardware error occurred at the operating system, browser, or Web page level which prevented access to the device.
OverconstrainedError : no candidate devices which met the criteria requested. String value is the name of a constraint which was not meet, and a message property containing a human-readable string explaining the problem. Exmaple conatraints :
SecurityError : User media support is disabled on the Document on which getUserMedia() was called.
TypeError : The list of constraints specified is empty, or has all constraints set to false.
Pan/Tilt/Zoom camera controls
RTCPeerConnection
enables audio and video communication between peers. It performs signal processing, codec handling, peer-to-peer communication, security, and bandwidth management.
stable : There is no offer/answer exchange in progress. This is also the initial state, in which case the local and remote descriptions are empty.
have-local-offer : Local description, of type “offer”, has been successfully applied.
have-remote-offer : Remote description, of type “offer”, has been successfully applied.
have-local-pranswer : Remote description of type “offer” has been successfully applied and a local description of type “pranswer” has been successfully applied.
have-remote-pranswer : Local description of type “offer” has been successfully applied and a remote description of type “pranswer” has been successfully applied. closed The RTCPeerConnection has been closed; its [[IsClosed]] slot is true.
RTCSDPType
offer : SDP offer.
pranswer : RTCSdpType of pranswer indicates that a description MUST be treated as an [SDP] answer, but not a final answer.
answer : treated as an [SDP] final answer, and the offer-answer exchange MUST be considered complete. A description used as an SDP answer may be applied as a response to an SDP offer or as an update to a previously sent SDP pranswer.
rollback : canceling the current SDP negotiation and moving the SDP [SDP] offer back to what it was in the previous stable state.
RTCPeerConfiguration
Defines a set of parameters to configure how the peer-to-peer communication established via RTCPeerConnection
iceServers of type sequence : array of objects describing servers available to be used by ICE, such as STUN and TURN servers.
iceTransportPolicy of type RTCIceTransportPolicy : bundle policy affects which media tracks are negotiated if the remote endpoint is not bundle-aware, and what ICE candidates are gathered. If the remote endpoint is bundle-aware, all media tracks and data channels are bundled onto the same transport.
relay : ICE Agent uses only media relay candidates such as candidates passing through a TURN server.
all : The ICE Agent can use any type of candidate when this value is specified.
bundlePolicy of type RTCBundlePolicy. media-bundling policy to use when gathering ICE candidates. Types :
balanced : Gather ICE candidates for each media type in use (audio, video, and data). If the remote endpoint is not bundle-aware, negotiate only one audio and video track on separate transports.
max-compat : Gather ICE candidates for each track. If the remote endpoint is not bundle-aware, negotiate all media tracks on separate transports.
max-bundle : Gather ICE candidates for only one track. If the remote endpoint is not bundle-aware, negotiate only one media track.
rtcpMuxPolicy of type RTCRtcpMuxPolicy. rtcp-mux policy to use when gathering ICE candidates.
certificates of type sequence A set of certificates that the RTCPeerConnection uses to authenticate.
iceCandidatePoolSize of type octet, defaulting to 0 Size of the prefetched ICE pool as defined in [JSEP]
RTCDataChannel
Allows bidirectional communication of arbitrary data between peers. It uses the same API as WebSockets and has very low latency.
(+) DataChannel is p2p and is also ened to end encrypted leader to higher privacy
(+) build in security due to p2p transfer
(+) high throughput than text transfer via a messaging server
(+) lower latency as p2p transfer takes shortest route
getStats
allows the web application to retrieve a set of statistics about WebRTC sessions. These statistics data are being described in a separate W3C document.
Basics for building a WebRTC based communication solution :-
Websockets for signalling / Offer Answer
TURN server like xirsys(paid), CoTURN(opensource , self hosted)
Js library for WebRTC wrappers
Https served webpage
WebRTC enabled Browser
Approaches to develop webrtc unified communication system
1. Pluggable module or npm
Source code for the WebRTC project is shipped as a pluggable library or npm module.
2. collaboration as a Service ie CaaS
Clients redirect users to our WebRTC platform for communication.
3. Communication Platform
We provider all communication and related Services as a standalone platform
Updates in W3C 13 Dec , 2019
Over the years since its adoption many of the associated tech were depricated from the Webrtc based platforms and enviornments , some of which are: OAuth as a credential method for ICE servers Negotiated RTCRtcpMuxPolicy (previously marked at risk) voiceActivityDetection RTCCertificate.getSupportedAlgorithms() RTCRtpEncodingParameters: ptime, maxFrameRate, codecPayloadType, dtx, degradationPreference RTCRtpDecodingParameters: encodings RTCDatachannel.priority
Some of the newly added features include:
restartIce() method added to RTCPeerConnection Introduced the concept of “perfect negotiation”, with an example to solve signalling races. Implicit rollback in setRemoteDescription to solve races. Implicit offer/answer creation in setLocalDescription to solve races.
References :
[1] WebRTC 1.0: Real-time Communication Between Browsers – W3C Candidate Recommendation 13 December 2019 https://www.w3.org/TR/webrtc/
webrtcdevelopment Open Source WebRTC SDK and its implementation steps 
Telecom R & D 
