RCS ( Rich Communication Suite )


RCS ( Rich Communication Suite )

For the past few weeks, I’ve been trying to find the answer to this one. After much information gathering, I understood that majority of communication platform provider’s mostly OTT such as iMessage from apple, RBM(RCS Business Messaging) already supports these features. And it is partially a term coined by Google to bring smart communication features in Android and other smartphones. In essence, RCSe is a part of the broader IMS architecture published by GSMA.

Update: after 2019 plenty of carriers also already provide RCSe as a replacement for SMS. OEM providers like Samsung also have RCS feature inbuild in phones.

Rich Communications should be viewed as technology upgrade that will transition SMS and voice capabilities from Circuit Switched technologies into the all-IP world, including VoLTE. RCS and VoLTE are build over IMS technology. The RCS wil benifit from Standardization of the technical environment, shared by all industry players, to offer these services on a wide range of handsets

The Rich Communication Services programme is a global initiative to deploy inter-operator services within an industry ecosystem.

Marketed by the GSMA under the brand name joyn,  RCS is an upgrade that marks the transition of messaging and voice capabilities from Circuit Switched technology to an all-IP world.

Wider and large scale IMS deployment, interoperability between different terminal vendor RCS clients and RCS service interworking between operators are the key aims of the RCS Initiative.

What is special about RCS ?

In the face of new and innovative over the top messaging applications, mobile operators are experiencing declining SMS usage. With the launch of WiFi and VoIP enabled voice calling applications, similar declines in voice revenues are increasing, RCS presents and opportunity for telecom providers to rebrand their messaging solutions as a better product to compete against the growing influence of “Over-The-Top” (OTT) communications services providers.

  • Enhanced Phonebook: service capabilities and enhanced contacts information such as presence and service discovery.
  • Enhanced Messaging: enables a large variety of messaging options including chat, emoticons, location share and file sharing.
  • Enriched Calls: enables multimedia content sharing during a voice call, video call and video sharing (see what I see).

RCS releases

Five releases of the RCS specifications have been made to date. Each release expanded the scope of its predecessor.

  • Release 1 : Offered the first definitions for the enrichment of voice and chat with content sharing, driven from an RCS enhanced address book.
  • Release 2 : Added broadband access to RCS features: enhancing the messaging and enabling sharing of files.
  • Release 3: Focused on the broadband device as a primary device.
  • Release 4: Included support for LTE.
  • Release 5: The most recent release, global interoperability is a key aspect of these specifications.

As the team developed a web client for making and receiving SIP calls over websockets through a proxy SIP server , I felt its an  achievement big enough. To integrate it with RCS ( Rich Communication Suite ) stack appeared as a very complicated job .

I began by adding RCS specific standards modules one by one instead of importing the whole stack / library all together. The modules for XCAP for buddylist, MSRP for file transfer, geolocation  mapping , cloud sync of phonebook and message book have begun taking shape . In essence following features set are expected out of a RCS enabled Client ( short outline ) Provisioning

  • OAUTH integration with operator customer portal
  • RCS HTTP Auto-Configuration
  • Manual IMS credentials, typically reserved for testing / troubleshooting

RCS services

  • Service Discovery
    • OPTIONS and Presence supported
    • Address book polling
  • Delivery & display notifications o Message composing indication
  • 1-1 Chat
    • IMDN
    • Is-Composing
    • Store & forward / deferred message and notification delivery
    • Hotfixes compliant
  • Group Chat
    • Hotfixes compliant
    • Is-Composing
    • IMDN
    • Geo-location Push
    • Start and end a group chat session
    • Add or remove participants
    • Broadcast / Send messages to all participants
  • File Transfer
    • Send file via URL or as MIME attachment o Accept or Reject file transfer
    • MSRP based
    • HTTP based
    • Store & forward
    • Geo-location push via FT
    • vCard sharing
    • Thumbnail support
  • Voice & video
    o Best effort voice
    o Transcode
  • Network Address Book Support
    • Synchronization to SyncML based network address book
    • Contact import from Google, Facebook etc.

RCS APIs

Pblished under Joyn in GSMS RDC Developer documents. There are many individual RCS APIs available. Brief details are as follows.

  1. Log user in and out of the RCS server : Allows address book contacts to receive periodic updates of user availability for chat, file transfer and other services. This is essential for use of the RCS services.

2. Subscribe application to server-originated notifications :This is one of the most important aspects of RCS as events are asynchronous; the notifications channel is used by your application to know how an API call is proceeding and to receive updates from other users such as messages, files and status updates. You can subscribe to certain types of notifications if your application is focused on particular RCS services.

3. Network address book access and management : RCS provides each registered user with a server managed address book. Though the other APIs are not restricted to contacts in the network address book this makes it much more convenient to connect with other users. The network address book can have contacts added, removed, attributes changed, and is available to any application the user signs in to.

4. Chat API : Unlike SMS, which is broadly a ‘fire and forget’ service, the RCS chat services allow much more sophisticated messaging services to be built. Depending on user configuration you can check out whether the user has received the message, and displayed it.

RCS chat also allows feedback to other parties when a user is composing a message. There are also group chat services allowing multiple parties to collaboratively message. RCS provides API features for setting up a group chat session, adding or removing chat participants.

5. File Transfer : These APIs allow applications to send content between users – whether this is a picture or a document, and whether it is stored originally on the user’s device or elsewhere located on the Internet. They allow the recipient to receive information about the file separately from the file itself so the recipient can choose whether or not to accept the file.

6. User capabilities API : Enables the application to retrieve and amend system managed common capabilities of the user.

At this stage I will also put in a bit more about RCSe.

RCSe ( enhanced )

What is the difference between RCS-e and RCS?

RCS-enhanced (RCS-e) is the currently available version of RCS, developed to speed time to market. It offers enhanced features such as instant messaging, live video sharing, and file transfer across any device on any network operator

RCSe Features

  • Focus on advanced communication
    chat , file transfer , video sharing
  • Easy to Use
    zero touch from end user perspective
    minimal setup for subscribers
    Interoperability across devices , infrastructure components and service providers
  • Low barrier to entry / simplify networks
    Capability discovery using SIP OPTIONS
    Less impact on network elements and handset battery
    Lack of presence server reduces cost and time to market
  • Universal
    Allows implementation in lower range devices
    One common device specification

RCS-e Customer Value Proposition

New IP Communication Services, Profile Sharing, Native Device Integration

rcs5

RCSe Characteristics

  • Dynamic Capability Discovery
  • User Perspective
  • network detects when user attaches with RCs e device
  • detection triggers network provisioning and client configuration
rcs6
  • Security
    • authentication by network
    • SSO / GIBA in 3G coverage
    • SIP Digest in Wifi
    • Encryption for Wifi access
    • TLS for SIP and TCP media or IPsec
    • SRTP for UDP or IPsec
    • NAT traversal and Keep-alives

RCSe Releases

  • RCS-e (1.2.2) : RCS-e defined the initial IM/Chat functionality, File transfer, Image Share and Video share functionality over mobile packet switched networks, trusted and untrusted broadband networks.  It has gained wide acceptance in Europe as an initial deployment to be followed by future deployment phases.
  • RCS 5.0 is completely backward compatible with V1.2.2 specifications and adds new features such as best efforts IP video calls, Geo-location exchange, Social Presence, Standalone Messaging, and a network based blacklist. Global interoperability is a key aspect of these specifications, and as a result this version supports both OMA CPM and OMA SIMPLE IM, which are more widely requested in North America.
  • RCS 5.1 is also backward compatible with the V1.2.2 and 5.0 specifications.  It introduces additional new features such as Group Chat Store & Forward, File Transfer in Group Chat, File Transfer Store & Forward, and Best Effort Voice Call.

WebRTC/RCS Client

WebRTC Communication Client can meet the requiremnets of RCS and serve as a telco based platform for using TSP backened network to provide call and messaging to web users.

REST and SOAP Based Client
Integration with RCS features like MSRP, XCAP
Cloud Hosted Solution
Technical Expertise in HTML5,J2EE,SIP,WebRTC & IMS

WebRTC RCS Addon Features

  1. Integrated charging: Users already have mobile service. WebRTC with session-based charging can be added onto existing service plans.
  2. Bundling: Messaging APIs can augment WebRTC apps with RCS and other messaging services developers
    Already know and implement.
  3. Reliability: QoS can provide assurance to users and priority services (enterprise, emergency, law enforcement, eHealth) that a WebRTC service will work as well as they need it to.

Realted Terms

MSRP

  • File Transfer using  MSRP (or Message Session Relay Protocol) is an instant messaging or chat protocol, defined by the IETF in RFC4975. MSRP is a text-based, connection-oriented protocol for exchanging  arbitrary (binary) MIME content, especially instant messages.

References

WebRTC SIP / IMS solution

We started in winters on 2012 with Webrtc . At time time it just looked like a new tech jargon that might fade away when new ones comes . In many many WebRTC’s buzz has died down since its massive adoption. But i nevertheless still see a lot of potential and development around it.

What really is WebRTC ? I made an entry on it  here .

Around nov – dec 2012 , team and I spend the time learning the nitty-grities of HTML5 based media operation and Javascript sip stack of SIPML. I remember toward the end of the year ie before Christmas , We were done with the explanation and education aspects of WebRTC , a technology that will revolutionise communication in ages to come , at-least so says the numerous other blogs ,  and documents i read so far .


Usecases for WebRTC range across a wide variety , of them the most revenue generating ones are around video conferencing with realtime HD audio-video-data streams ,

To bridge the flow between a webrtc client to a PSTN endpoint via IMS , interworking between webrtc media standards and codecs with that of gateways in IMS is critical . For instance WebRTC mandates secure RTP ( SRTP) the media engine / gateway should be able to support and connect with RTP from PSTN endpoints.

client BOB -> webrtc2sip Gateway -> SIP server -> client Alice

can be  understood with the callflow of a simple SIP Invite initiated from one html page towards another which passes through the configuration of gateway to IMS world ,  SIP Telecom Application server , Database , nodes of IMS environment etc.

For the purpose of a simple Explanation a simplified call flow ca be depicted as ,

webrtccallflow

A very high level architecture of solution deployment in IMS world could be

solution arch2

As the solution matures into a full fleshed project . The alpha version has been released with the following feature set . The WebRTC platform Suite offers a easily deploy-able solution to enable communication

Alpha Release WebRTC platform Suite

  • Single Sign On
  • Login with id and password to access all services
  • Audio / Video Call
    • Call Hold / Call Transfer
  • Messaging:
    • SIP Instant Messaging
    • Message to Facebook Messenger
    • Message delivered as Email
  • Chatroom
    • group chat between multiple users . Room is created for set of users .
  • Video Conferencing
    • video chat between multiple parties . Room is created for set of users .
  • File Transfer
    • Sharing of files from local to remote , in peer-to-peer and broadcasting fashion .
  • Third party Webservices
    • Widgets like calendar , weather , stocks , twitter are embedded.
  • Visual Voice Mail
    • Record and deliver voice message to recipients voice mail inbox which can be accessed/ played from web client .
  • Phonebook
    • cloud integration
    • add new entries
    • add photos to contacts identity
    • import contacts from google account
  • Click to Call :
    • Drop down list of contacts form mail call console
    • 2 step Click to call from Phonebook
  • Presence :
    • Publish online / offline status
    • Use Subscribe / notify requests of SIP
  • Web Ssocket to SIP Gateway
    • Conversion between the signal coming from the WebRTC and SIP client to the IMS core
    • Conversion of “voice/video ” media between sRTP and RTP
    • Conversion of other media (data channel) towards MSRP and Transcoding.
    • Support of ICE procedure
    • Implementation of a STUN server
  • QoS Support

Beta Release WEBRTC PLATFORM SUITE

  • Logs
    • calls logs
    • Message logs
  • User Profile
    • user details like address , email and social networking accounts
    • Phonenumber for GSM integration through SMS
    • User’s Media storage like Pictures , profile picture , Audio , video
    • File sharing documents storage for future access in the same format
  • Real Time and Offline Analytics
  • service usage with graphical and tabular history trends
  • Session Management
    • Single Sign-on
    • Forgot password regeneration using secure question
    • Registration of new user account
    • Logout and clearance of session parameters
  • Security
    • No redirection to any page through url entry without valid session
    • No going back to home page after logout by back button on browser
    • No data vulnerability
    • Multiple login through different devices handled
  • OAuth
    • Login via IMAP / token through facebook and Google
  • Phonebook with Presence functionality inbuilt
  • Directory Service based on country / region
  • Geolocation of approximate location detection of device logged in and visibility to others
webrtc solution
WebRTC client deployment view , accessible devices , network elements
WebRTC deploymenet overview and inetraction with other network elemets such as gateway , cloud storage ,  sipserver , IMS
WebRTC deploymenet overview and inetraction with other network elemets such as gateway , cloud storage , sipserver , IMS

Commercial release features specs for WebRTC over IMS

  • Integration with new age CSP deployments like VoLTE, ViLTE, VoWiFi
  • Multi vendor support
  • Interactive webrtc services
  • Media Services
    • Automated Natural language Speech recognition
    • Semantic processing via ML
    • Enhanced incall services replacing IVR ( touch -tone)
    • VQE (voice Quality Enhancements)
    • Encoding and Decoding – Multiple Codec Support
    • Transcoding
    • Silence Suppression
  • Security via TLS, encryption and AAA
  • Http, NFS caching
  • NAT using Xirsys TURN
  • Recording, playback and media file compression
  • active frame selection
  • DTMF (Dual Tone Multi Frequency)
    • SIP info messages (out-of-band)
    • SIP notify messages (out-of-band)
    • Inband DTMF not supported yet
  • Audio
    • mixing
    • announcements ( VXML, MSML )
    • filters
    • gain control ( AGC using webrtc stack)
    • noise suppresesion ( webrtc stack)
    • speakers notification
    • Narrowband, Wideband, and Super Wideband
    • dynamic sample rate
  • Video
    • continuous presence ( Face detetion )
    • floor control
    • video lipsync (sync)
    • speaker tile selection
  • VQE (Voice Quality Enhancement )
    • Acoustic Echo Cancelation
    • noise reduction
    • noise line detection
    • noise gating
    • Packet Loss concealment
  • Call analyics
    • progress analysis
    • MOS , R-factor ( derived from latency , jitter , packet loss )
  • CDR (Call detail records ) and accounting
  • Lawful interception

Updating this article 2019

There was a long journey from traditional telecom architectures to NFV cloud based architectures ( like openstack). supported over web , 4G , LTE or other upcoming networks. Many OTT providers prefer using the public cloud over a NFV data centre.

Multinode / Multiedge computing platforms like Media Resource Function are expected to meet the need for quick delivery with additional features like hardware accelerated media , algorithms for optimised data flow (packetization, decongesting , security ) etc . With th decomposed architecture they can better utilise the

  • CPU – contains couple of cores optimised for sequential serial processing such as   graphics or video processing
  • GPU – contains many smaller cores to accelerate creation of images for computer display . Can include texture mapping, image rotation, translation, shading or more enhanced features like motion compensation, calculation of inverse DCT, etc. for accelerated video decoding.
  • DSP- processing data representing analog signals

Although IMS based solutions are more suited to telephony applications and CSPs ( Communication service providers like telecom companies ) but similar or same architectures are widely finding their into newer developed cloud communications solutions supporting tens of millions of subscribers and hyper scale deployment . It could be around applications such as

  • HD (High Definition ) calls
  • UCC ( conf , draw-board, speech recognition , realtime streaming)
  • immersive experiences ( Augmented reality , virtual reality , face recognition , tracking )
  • contextual communication ( transcription etc)
  • video content delivery with deep media analytics

Demand these says is for a decentralised system of pool of servers ( media and signalling ) that can scale independently to match up to peak traffic at any moment , with ofcourse carrier class performance . Not only these flexible solutions reduce complexity but also OpEX .

Ref:

Unified Communicator and Collaborator for Enterprise

Modular enterprise communicator solution for enterprise based communication and collaboration . Use sipml5 client side library to provide webRTC based media stream capture and propagation from client side without external plugins.

Github Repo – https://github.com/altanai/unifiedCommunicator

Unified Communications and Collaborations ( UC&C ) – https://telecom.altanai.com/2013/07/12/unified-communication/

VPN ( Virtual Public Network ) over SIP


People working at differing locations need a fast, secure and reliable way to share information across computer networks. This is where a way to connect private networks over and top of the public network becomes necessary and Virtual Private Network comes into the picture.

vpn

 

SIP ( Session Initiation Protocol ) for VPN

VOIP across an SSL-based VPN is achieved in good quality by encapsulating the UDP VOIP packets ( SIP and RTP ) in TCP/IP. Data used for defining a VPN like its Groups, its Members and the associated profiles are organized hierarchically. It includes information like who is the operator, subscriber of VPN, group ID and member ID.

vpn+ service broker
VPN and Service Borker

Grouping for VPN Users

Groups created to implement policies and restrictions common to a set of users.These include:

  • Apply permissions to call between the Groups and to the outside world
  • Apply pricing between distinct types of of PNP (Mobile, Fixed, Privileged list)
  • Some numbers assigned a preferential tariff plan. These numbers are not part of the VPN ( Virtual On-Net) .
  • privileged list within a VPN across multiple groups

Service Overview

Lets see how would a SIP based VPN services over telecom application server with Service Broker works. Leveraging the Service Broker to offer voice VPN service to existing Subscribers is an arduous task. The Subscriber shall benefit from reduced charging rates for VPN calls (ON-Net), improved employee connectivity (within the VPN scope) and a consistent user experience across fixed and mobile phones.

VPN services shall be integrated with the R-IM-SSF( reverse IMS gateway to IN) component of the service broker. R-IM-SSF shall provide mediation as well as session and state management capabilities that shall make VPN service available over multiple networks including SS7 and IMS networks.

The subscriber base can be interfaces via a SMP that might also be used to add groups and assign right and privilege to member

Features of VPN application

1.Private numbering plan for both mobile and fixed subscribers (Short number dialing).

2.Distribution of subscriber under a hierarchical Data Model :

  • Subscriber VPN( Enterprise Level)
  • Group of Users ( Group level. Can be either of type Mobile or PABX )
  • State (End user of service)

3.Grouping of a short number on the basis of following types:

  • Member of mobile VPN
  • Privileged user
  • PABX user

4. Forced On-Net call handling, which shall allow user to dial the public number of another On-Net user with On-Net call Features.

5. Virtual On-Net Call Handling which allocates On-Net extension to non VPN users( Privileged list)

6. Off-Net call Handling via exhaust code which shall allow vpn users to access non-vpn public numbers

7.  Prohibit the call based on a set of rules like ( all off-net calls barred).

8. Allow calls based on destination numbers. For example allow off-net calls for numbers provisioned in the white list(allowed list)

9. Outgoing call screening on the basis of time( Time based barring)

VPN voice application on SIP

This solution  describes the service logic design for the new VPN voice application providing the feature set and service data for the Global VPN service. The new application will replace the Ericsson VPN application running on the legacy IN platform with the new SIP based  VPN services being hosted on the Rhino TAS.

Virtual Public Network - voice Application over SIP RA on SLEE
Virtual Public Network – voice Application over SIP RA on SLEE

Service Logic Structure

This section gives the complete flow in the Service from the instance the INVITE is generated in the network till a Session Connected or Session Disconnected is being sent back to the network.

S.NoDescription
1INVITE is sent from rim-ssf to SIP Resource Adaptor
2Message is processed by the SIP Resource Adaptor.

RA is configured with a Rate Limiter to enable Overload protection for the TQAS Node.Rate Limiter checks if the Overflow threshold has been reached.If the threshold is reached, RA will not send the message to the service.

3SLEE will check the Service Selector of the VPN service if the message can be processed by it. VPN Service has an initial event selector which checks the service key in the SIP Request.
4Service is configured with a rate limiter to protect the platform from overload protection, for even distribution of calls from different networks etc.

Rate Limiter checks if the Overflow threshold has been reached.If the threshold is reached, Service will close the dialog with a prearranged end.This will not send any message back to the network. This will allow a SIPmessage timeout at rim-ssf. If the threshold is not reached the call is further processed by the Service Ingress

layer of the service
5Service Ingress:  This layer of the Service will do call pre-processing based on the Service key.  This layer identifies the originating network of the call and applies any processing to be done, like number formatting, on the data received from the network before it is used by the core application.
6Service Core: This is the layer where Service processing is carried out.  Service identifies the routing plan associated with Application configured for Service key and executes the routing plan. Routing plan contains features to be executed which will further enable the execution of Subscribed feature set.
7Service Deliver: This layer is where the features corresponding to delivery of the call, like destination number formatting are performed.
8Service Egress: This layer is concerned with all network related functions that need to be performed to setup the call, like manipulating the network message parameters.
9Connect Session or  Discontinue session message is sent back to the network

Overflow Protection

Overflow protection aims at allowing the platform to take only the load that is capable of. This can be achieved by defining the Rhino Rate Limiters at the Resource Adaptor and Service Layers. Rate Limiters at Resource Adaptor are generic in that it counts all the SIP messages that are passing through the Resource Adaptor and can respond with only 4xx response in case the call is not allowed. Limiters at Service level have got greater flexibility in that they can count the messages, dialogs etc and can respond with any message to the network like 403 Forbidden or 406 Not Acceptable etc.

Rate Limiters

Limiters can optionally be linked to a single parent limiter and/or multiple child limiters. A limiter only allows a piece of work if all of its ancestors (its parent, and its parent’s parent, and so on) also allow the work. VPN service has got Rate Limiters defined at both Resource Adaptor and Service layers.

  1. RA Limiter

RA Limiter will help protecting the Rhino node from being throttled with too many messages. Threshold should be captured considering the peak load of all the SIP messages for all the services running in the platform.

2. Service Limiter

Service Limiter will be used to allow the configured number of calls for a particular service. Once the threshold is reached Calls are rejected as dialog close with pre-arranged end. This will close the dialog and release the SLEE resources but will not send any message back to the network. This will allow the dialog to time out at rim-SSF. This prevents the callers from too many re-tries/re-dials on the platform.

Call Barring

According to the business needs of the Bouygues Telecom TCS proposes call barring application which can offer the possibility of limiting the calls for each group of a Company depending on the day and time.

When a subscriber VPN is subjected to a barring 1994/96 him certain destinations are always allowed for the subscriber:

  • Off-net: rights that are identical to the rights of calls to “no destination outside the VPN”, as defined in Error! reference Source not found.
  • On-net: no right to call

The same application can be deployed along with the VPN logic at the Service Core block of the VPN service to barr the call of the subscriber as per the Time, Location , Preveliges of the user of VPN group.

VPN performance issues

VPN has less influence on latency, jitter and packet loss. However VPN overhead is high with enabling authentication, encryption, HMAC, anti-replay attack, and initialization vector, and use small RTP size for Codec, the

Counter Metrics for VPN Quality Assurance

For developing a VPN application counters are employed, some of which could be as follows

  • Number of calls On-Net and Off-Net
  • Numbers of Calls VPN
  • Number of calls with Forced On-Net

Calls between endpoints

  • MS to MS Normal (mobile)
  • MS to MS Privilege
  • MS toward PABX

Success Fail rate

  • Number of calls successful without rerouting
  • Number of calls with successful rerouting
  • Number of calls with Failure (Failed = No answer, Busy, Not reachable, Congestion)
  • Number of calls on non-response (No Answer)
  • Number of calls on Not Reachable
  • Number of calls Route Select Failure
  • Number of calls on busy
  • Number of calls barred by VPN service.

other parameters

  • Total number of queries
  • Number of States created/modified
  • Number of change in the rights of calls
  • Number of issuance of observation Reports

terminology :

R-IM-SSF = reverse IMS gateway to IN

SMP is the Provisioning interface for VPN service subscriber

WebRTC


webrtc draft

WebRTC 1.0: Real-time Communication Between Browsers – W3C Candidate Recommendation 13 December 2019 https://www.w3.org/TR/webrtc/

webrtc_development_logowebrtcdevelopment Open Source WebRTC SDK and its implementation steps https://github.com/altanai/webrtc

Read more in the layers of webrtc  and their functionalities here :  WebRTC layers

What is WebRTC ?

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 

Media Stack in Browser

The following is the browser side stack for webrtc media .  

WebRTC media stack Solution Architecture
WebRTC Media Stack

Voice Engine

  • iSAC: wideband and super wideband audio codec for streaming audio
  • iLBC: narrowband speech codec for streaming audio
  • Opus: constant and variable bitrate encoding 
  • NetEQ: Net Equalizer
  • Dynamic jitter buffer + error concealment algorithm
  • Acoustic Echo Canceler (AEC) : remove acoustic echo
  • Noise Reduction (NR) : remove background noise

Video engine

  • 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

w3c

  • 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

ietf
  • 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.

Video Resolution handling

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.

Independant of Signalling 

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.

NAT and TURN Relay

Learn about hosting / integrating different TURN servers for WebRTC in the article on “TURN server for WebRTC – RFC5766-TURN-Server , Coturn , Xirsys “.

Why is WebRTC so importatnt ?

(+) Significantly better video qualityWebRTC video quality is noticeably better than Flash.
(+) Up to 6x faster connection timesUsing JavaScript WebSockets, also an HTML5 standard, improves session connection times and accelerates delivery of other OpenTok events.
(+) Reduced audio/video latencyWebRTC offers significant improvements in latency through WebRTC, enabling more natural and effortless conversations.
(+) Freedom from plugins like FlashWith WebRTC and JavaScript WebSockets, you no longer need to rely on Flash for browser-based RTC.
(+) Native HTML5 elementsCustomize 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

 Peer to peer Communication

 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

two party call
p2p call

Multiparty Call and mesh network

Mesh based arrangement .

Multiparty party call
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 :    

  1. 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. 
  2. 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.

Browser Adoption

As of March 2020 , webrtc is supported on following client’s browsers

  • Desktop PC
    Microsoft Edge 12+[25]
    Google Chrome 28+
    Mozilla Firefox 22+[26]
    Safari 11+[27]
    Opera 18+[28]
    Vivaldi 1.9+
  • Android
    Google Chrome 28+ (enabled by default since 29)
    Mozilla Firefox 24+[29]
    Opera Mobile 12+
  • Chrome OS
  • Firefox OS
  • BlackBerry 10
  • iOS
    MobileSafari/WebKit (iOS 11+)
  • Tizen 3.0

Furthermore, read about the Steps for building and deploying WebRTC solution.

TURN based media Relay

WebRTC APIs are the Javascript functions to access and process the browser media stack.

getUserMedia

acquires the audio and video media (e.g., by accessing a device’s camera and microphone)

Properties

ondevicechange

Methods

enumerateDevices()
getDisplayMedia()
getSupportedConstraints()
getUserMedia()

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 :

var constraints = { video: { facingMode: (front? "user" : "environment") } };

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.

Properties

canTrickleIceCandidates
connectionState
getDefaultIceServers()
iceConnectionState
iceGatheringState
onsignalingstatechange
onconnectionstatechange
ondatachannel

onicecandidate
oniceconnectionstatechange
onicegatheringstatechange
onidentityresult
onnegotiationneeded
onremovestream onaddstream
ontrack

peerIdentity currentLocalDescription
currentRemoteDescription
pendingLocalDescription
pendingRemoteDescription
localDescription remoteDescription
sctp
signalingState

Methods

addIceCandidate()
addStream()
addTrack()
close()
createAnswer()
createDataChannel()
createOffer()

getIdentityAssertion()
getReceivers()
getSenders()
getStats()
getStreamById()
getTransceivers()
removeStream() removeTrack()

restartIce()
setConfiguration()
setIdentityProvider()
setLocalDescription()
setRemoteDescription() generateCertificate()
getConfiguration()

 signalling state transitions diagram , source W3C

RTC Signalling states

  • 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.

Call Setup betweeb WebRTC Endpoints

WebRTC CPaaS Solutions

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
two party chat.png

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 :

IP Multimedia Subsystem (IMS)

  • Why IMS ?
  • What benefits does IMS bring ?
  • Features of IMS Network
  • IMS Layers
    1. Transport / Media Endpoint Layer
      • Backhaul network
      • Border Gateways
    2. Session & Control Layer
      • HSS (Home Subscriber Server)
      • SCF (Call Session Control Function)
      • MGw (Media Gateway Control Function)
    3. Application Services Layer
      • TAS (Telephony Application Server)
      • IM-SSF ( IP Multimedia Services Switching Function)
      • OSA-GW (Open Service Access Gateway)
  • IMS-architecture
    • IMS standalone architecture
    • Interoperable IMS core for heterogeneous access networks

IMS is a an architectural framework for IP based multimedia rich communications. It was standardized by a group called 3GPP formed in 1999. It started as an enabler for 3rd generation mobile networks in European market and later spread to wirelne networks too. IMS became the key to Fixed Mobile Convergence (FMC).

Based on IETF Protocols (such as SIP, RTP, RTSP, COPS, DIAMETER, etc), IMS is now crucial for controlling conmmunication in a IP based Next Genration Network (NGN).

Communication service providers and telecom operators are migrating from circuit-switched networks to IMS technology with the increasing bandwidth (5G) and user expectations.

Why IMS ?

Early days TDM networks were not robust enough to support emerging technologies and data networking. There was a need to migrate from voic eonly network to Triple play network ( voice , video and data ). Other factors included :

  • rapid service development
  • service availiability in both home and roaming network
  • wireline and wireless convergence

Due to these above mentioned reasons TDM was outdated and IMS gained support .

What benefits does IMS bring ?

It offers counteless applications around rich multimedia services on wireless , packet swtched and even tradional circuit switched networks.

Easier to Create and Deploy New Applications and Services

  • (+)Enhanced applications are easier to develop due to open APIs and common network services.
  • (+) Third-party developers can offer their own applications and use common network services, sharing profits with minimal risk
    New services involving concurrent sessions of multimedia (voice, video, and data) during the same call are now possible.
  • (+) Reduced time-to-market for new services is possible because service providers are not tied to the timescales and functions of their primary NEPs

Capture New Subscribers,Retain Current Subscribers

  • (+) Better voice quality for business applications, such as conferencing, is possible
  • (+) Wireless applications (like SMS, and so on) can be offered to wire line or broadband subscribers.
  • (+) Service providers can more easily offer bundled services.

Lower Operating and Capital Costs

  • (+) Cost-effective implementation of services across multiple transports, such as Push-To-Talk (PTT), presence and Location-Based Services (LBS), Fixed-Mobile Convergence (FMC), mobile video services, and so on.
  • (+) Common provisioning, management and billing systems are supported for all networks.
  • (+) Significantly lower transport costs result when moving from time-switched to packet-switched channels.
  • (+) Service providers can take advantage of competitive offerings from multiple NEPs for most network elements.
  • (+) Reduced expenses for delivering licensed content to subscribers of different types of devices, encodings, or networks.

The strongest argument for adoption of IMS is that it follows established standards and open interfaces from 3GPP and ETSI. This makes it suited for interoperability, policy control accross networks, streamlined OSS/BSS, Value Added Services etc.

ims

Features of IMS network

  1. Abstraction from Underlying Network : IMS is essentially leading towards an open and standardized network and interface,irrespective of underlay network.
  1. Fixed /Mobile Convergence : Inter operability with Circuit Switched (CS) Mobile application Part (MAP)
  1. Roaming : Location awareness between home and visiting network.
  1. Application layer Call Control : IMS application layer has the provision for defining proxy or B2BUA based call flow completion . This leads to operator being able to introduce business logic into call sessions.

IMS is supplemented by SIP (IETF), Diameter (IETF) and H248(ITU-T).The release cycle of IMS is as follows

  • 2002-03-14 Rel-5  : IMS was introduced with SIP. Qos voice over MGW.
  • 2004-12-16 Rel-6 : Services like emergency , voice call continuity , IPCAN ( IP connectivity Access Network )
  • 2005-09-28 Rel-7 : Single Radio Voice Call Continuity , multimedia telephony,eCall ,ICS
  • 2008-12-11 Rel-8 : IMS centralized services , supplementary services and internetworking between  IMS and  Circuit Switched Networks,charging , QoS
  • 2009-12-10 Rel-9 : IMS emergency numbers on GPRS , EPS(Enhanced packet system) , Custom alert tone , MM broadcast/Multicast
  • 2011-3-23 Rel-10 : home NodeB, M2M, Roaming and Inter UE transfer
  • 2012-09-12 Rel-11 :-tbd
  • 2014-09-17 Rel-12 :- tbd
  • 2015-12-11 Rel-13 :- tbd

IMS Layers

Majorly IMS is divided into 3 horizontal layers given below :

2014-05-24_0015

Transport / Media Endpoint Layer

Unifies transports and media from analog, digital, or broadband formats to Real-time Transport Protocol (RTP) and SIP protocols. This is accomplished by media gateways and signaling gateways.

It also includes media servers with media processing elements to allow for announcements, in-band signaling, and conferencing. These media servers are shared across all applications (voicemail, interactive response systems, push-to-talk, and so on), maximizing statistical use of the equipment and creating a common base of media services without “hard-coding” these services into the applications.

Session & Control Layer

This layer arranges logical connections between various other network elements. It provides registration of end-points, routing of SIP messages, and overall coordination of media and signaling resources.

IMS core which is part of this layer primarily contains 2 important elements Call Session Control Function (CSCF) and Home Subscriber Server (HSS) database. These are explained below 

HSS ( Home Subscriber Server)

It is a database of user profiles and location information . It is responsible for name/address resolution and also authorization/authentication .

CSCF ( Call Session Control Function)

Handles most routing, session and security related operation for SIP messages . It is further divided into 3 parts :

  • Proxy CSCF: P_CSCF is the first point of contact from any SIP UA. It proxies UE requests to subsystem.
  • Serving CSCF: S-CSCF is a powerful part of IMS Core as it decides how UE request will be forwarded to the application servers.
  • Interrogating CSCF: I-CSCF initiates the assignment of a user to an S-CSCF (by querying the HSS) during registration.

Application Services Layer

The Application Services Layer contains multiple Application Servers (AS), such as:

  • Telephony Application Server (TAS) – for defining custom call flow logic
  • IP Multimedia Services Switching Function (IM-SSF)
  • Open Service Access Gateway (OSA-GW), and so on.

IMS Architecture

The IMS standalone architecture is suited for an all IP network

The IMS standalone archietcture is suited for an all IP network

Interoperable IMS core for heterogeneous access networks

Interoperable IMS core for heterogeneous access networks

References

  • IMS service Switching function and reverse service Switching function read here.

Update on IMS :

IMS has been mandated as the control architecture for Voice over LTE (VoLTE) networks. Also IMS is being widely adopted to mange traffic for Voice over WiFi (VoWiFi) systems.

Service Broker 1

What is Service Broker ?

Service broker is a service abstraction layer between the network and application layer in  telecom environment. SB( Service Broker ) enables us to make use of existing applications and services from Intelligent Network’s SCP ( Service control Point ) , IMS’s Application Server as well as other sources  in a harmonized manner.

The Service Broker Application Server provides the services in various permutations and combinations. Examples:  Mobicents / Rhino TAs for Jainslee SBB , or Weblogic / Sailfin for Sip servlets.

What is Service Orchestration ?

The Process of Orchestrating various service to provide a single flow control is refereed to as Service Orchestration.

What is Service Harmonization  ?

I have tried to simplify the concept by visualizing different boxes of various communication platforms as SIP, HTTP , CAP 1/2/3/4 , SMTP etc and then imagining a system that caters to all of these .  It is primarily important that the billing and chagrining system remains common to all the sources and protocols be it 2G , 3G or 4G based. A post on service harmonization between various telecom generations is at

Service Harmonization between generations of telecom

service harmonization3

The next writeup Service broker 2 is :

Service Broker 2

This contains the Defination and purpose of using a Service broker as well as its role in network enviornment. It also contains service broker functions like Real-Time Charging , Protocol/Call Flow Management/Call Screening Management , Subscriber Data Management Interaction, Media Resource Brokering.

Details of Service Broker implementation in IN and IMS is at article below. Details on Service Broker and how service provider acts as a central Node for Services invocation and services composition is described in this. It clearly shows Service Broker provides Services Orchestration / Interaction, service development, third party integration and acts as a protocol gateway.


SIP Presence

We have already learned about Sip user agent and sip network server. SIP clients initiates a call and SIP server routes the call . Registrar is responsible for name resolution and user location. Sip proxy receives calls and send it to its destination or next hop. Presence is user’s reachability and willingness to communicate its … Continue reading SIP Presence

Legacy Telecom Networks

I use the term legacy telecom system many a times , but have not really described what a legacy system actually is . In my conferences too I am asked to just exactly define a legacy system . Often my clients are surprised to hear what they have in current operation is actually fitted in … Continue reading Legacy Telecom Networks

Internet Telephony Convergence- JAINSLEE Platform

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

IMSSF and RIMSSF

This post particularly describes the gateways in IMS which communication back and forth with a legacy endpoints.To get a overview of IMS itself click here  and to get a detailed description of IMS and its architecture click here . What is IM-SSF  ? IP Multimedia Service Switching Function is a  gateway to provide IN service such … Continue reading IMSSF and RIMSSF

IP Multimedia Subsystem (IMS)

Why IMS ? What benefits does IMS bring ? Features of IMS Network IMS Layers Transport / Media Endpoint Layer Backhaul network Border Gateways Session & Control Layer HSS (Home Subscriber Server) SCF (Call Session Control Function) MGw (Media Gateway Control Function) Application Services Layer TAS (Telephony Application Server) IM-SSF ( IP Multimedia Services Switching … Continue reading IP Multimedia Subsystem (IMS)

IMS in EPC ( Evolved Packet Core )

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 )

Telecommunications convergence – VoIP , PBX and IMS

The signalling protocols migration like from signalling system 7 (SS7) to session initial protocol (SIP) have been taking place in Telco-Industry. Similarly nodes of legacy network like signal transfer point (STP) of legacy network are being migrated to call session control function (CSCF) of IMS that allows the rapid development and deployment of enhanced, revenue-generating multimedia services for fixed, mobile and cable operators.

IMS architecture enables operators to seamlessly run a plethora of next-generation converged services over their fixed, mobile and cable networks, achieve a faster time-to-market for new services and have fewer performance bottlenecks.