Anywhere anytime Telemedicine communication tool accessible on any device. The solution provides a low eight signalling server which drops out as soon as call is connected thus ensuring absolutely private calls without relaying or involving any central server in any call related data or media . This ensure doctor patient details are not processed , stored or recorded by our servers.
The solution enables doctors / nurses / medical practitioners and patients to do
High definition Audio/video calls
End to end encrypted p2p chats
Integration with HMS ( hospital management system ) to fetch history of the patients
Screens sharing to show reports without transferring them as files
Include more concerned people of doctors using Mesh based peer to peer conferencing feature.
Confidentialty and Privacy
For privacy and security of certain health information only HIPAA (Health Insurance Portability and Accountability Act of 1996) compliant video-conferencing tools can only be used for Telemedicine in US.
Telemedicine scenario Callflow
Calllfow for Attended Call Transfer and 2 way conference in a Telemedicine scenario between Patient , hospital attendant , doctor and a nurse
Metrics for monitoring a VOIP call can be obtained from any node in media path of the call flow . Essentially used for analysis via calculation and aggregation , and sometimes used for realtime performance tracking and rectification too .
Rating Factor (R-Factor) and Mean Opinion Score (MOS) are two commonly-used measurements of overall VoIP call quality.
R-Factor: A value derived from metrics such as latency, jitter, and packet loss per ITU‑T Recommendation G.107. It assess the quality-of-experience for VoIP calls on your network. Typical scores range from 50 (bad) to 90 (excellent).
R factor of 90 , Mos is 4.3 ( Excellent )
R factor 50 , Mos is 2.6 ( Bad)
MOS: It is derived from the R-Factor per ITU‑T Recommendation G.10 which measures VoIP call quality. PacketShaper measures MOS using a scale of 10-50. To convert to a standard MOS score (which uses a scale of 1-5), divide the PacketShaper MOS value by 10.
ITU ? The International Telecommunication Union is the United Nations specialised agency in the field of telecommunications, information and communication technologies (ICTs).
ITU-T ? TU Telecommunication Standardisation Sector is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardising telecommunications on a worldwide basis.
RTP provides real time media stream , payload type identification , packet sequencing and timestamping headers .
sequence num : tracks incremental succession of incoming packets by sendor and tracls out of order delivery
timestamp : used by the receiver to play back the received samples at appropriate time and interval.
Note that all Synchronization source (SSRC) identifiers fields denote the synchronization source within the RTP session such as both legs of a call session
leg A between Caller and RTP proxy ,
leg B between RTPproxy and Callee
RTCP provides detailed monitoring of stream to participants in an ongoing session with statistical data and enhanced metrices for QoS ( quality of service ) and synchronisation using it SR ( senders Report ) and RR ( Receivers report) segments .
Packet loss rate
Packet discard rate
round trip delay
R factor which is voice quality carried over RTP ssession
mos lq for listening quality and mos cq for conversation qualityy
End device processing delay such as CPU of the end device
It should be noted that in addition to these values which can be caluvulated algorithimically and with high precsiion , there are more subjective quality parameters which can be only evaluted manually ( ie witha person listening on both ends ) such as
Perceptible sound but annoying speech quality
MOS ( Mean Opinion Score )
MOS is terminology for audio, video and audiovisual quality expressions as per ITU-T P.800.1. It refers to listening, talking or conversational quality, whether they originate from subjective or objective models.
Very Good: 4.3-5.0
Not Recommenced : 2.6-3.1
Very Bad: 1.0-2.6
It provides provisions for identifiers regarding the audio bandwidth, the type of interface (electrical or acoustical) and the video resolution too , such as
MOS-AVQE for audiovisual quality;
MOS-CQE is for estimated conversational quality;
MOS-LQE for listening quality;
MOS-TQE is used for talking quality;
MOS-VQE depicts video quality;
For Audio Signal Speech Quality/ AV
– N denotes audio signals upto narrow-band (300-3400 Hz)
– W is for audio signals upto wideband (50-7000 Hz)
– S for upto super-wideband (20-14000 Hz)
– F is obtained for fullband (10-20000 Hz)
For Listening quality LQO
performed at electrical interfaces only. In order to predict the listening quality as perceived by the user, assumptions for the terminals are made in terms of intermediate reference system (IRS) or corrected IRS frequency response. A sealed condition between the handset receiver and the user’s ear is assumed.
performed at acoustical interfaces. In order to predict the listening quality as perceived by the user, this measurement includes the actual telephone set products provided by the manufacturer or vendor. In combination with the choice of the acoustical receiver in the laboratory test , there will be a more or less leaky condition between the handset’s receiver and the artificial ear.
Conversational Quality / CQ
Arithmetic mean value of subjective judgments on a 5-point ACR quality scale, is calculated.
Talking Quality / TQ
This describes the quality of a telephone call as it is perceived by the talking party only. Factors affecting TQ include echo signal , background noise , double talk etc. It is calculated based on the arithmetic mean value of judgments on a 5-point ACR quality scale.
Video Quality / VQ
To account for differentiation in perceived quality for mobile and fixed devices and to allow for proper handling of different use-cases as
– M for mobile screen such as a smartphone or tablet (approximately 25 cm or less)
– T for PC/TV monitors
It is calculated based on the arithmetic mean value of subjective judgments, typically on a 5-point quality scale
Audio Visual Quality / AVQ
Refers to quality of audio visual stream under corresponding networking conditions. It is also calculated based on the arithmetic mean value of judgments on a 5-point ACR quality scale.
Other parameters also contributing to VoIP metric Analysis
It is the time required for packets to travel from one end to another, in milliseconds. If the sum of measured latency is 800 ms and the number of latency samples is 20, then the average latency is 40 ms. Header of the RTP packets carry timestamps which later can also be used to calculate round-trip time.
The Terrestrial coaxial cable or radio-relay system over FDM and digital transmissioor subamrine coaxial cables add upto 4- 6 micro seconds of delay per km. Simillarly even the optical fibre cable using digital transmission added aroud 5 micro seceond per km delay which also accounts for the delay in repeaters and regenrators
On the other ahnd satelltie communicatio system varries the delay based on altitude ( propagation delay thorugh space abd between earth statiosn) 400 km above earths surfaec adds 12 ms delay , 14000 km above earth adds 110 ms and much higher 36000 km of altitude adds 260 ms
Devices FDM modem adds upto 0.75 ms delay Transmultiplexer – 1.5 ms delay Exchanges ( analog , digital , transit ..) add 0.45 – 0.825 ms delay Echo cancellers 0.5 ms DCME ( Circui manjipulation, signal compression) – 30 ms to 200 ms
Round Trip Time
Time taken for data to travel to the target destination and back . In terms of SIP calls it is the time for a transaction to complete between calleer/client and callee/server . It is calculated as when the packet was sent and when acknowledgment for it was received.
Measured in milliseconds (ms), high RTT indicates a poor network quality and would result in the audio lag issue. The media stream especially audio must not suffer a delay higher than 150 ms including all the processing delays at intermediate nodes and network latency . Any valye above it is poor quality.
RTT can represent full path network latency experienced by the packets and can do away with frequent ICMP ping/echo requests/probes to check network health . although it should be noted that while pings happen in lower transport layers protocol , RTT happens at high up application layer .
They are used to calculates RTO ( Request transmission timeouts )in TCP transmission ie how much time the sender should wait before retrying to send an unacknowledged packet.
Factors affecting RTT can include delays in propagation , processing , queuing and/or encoding delay.
Porpogation delay can correlate to the
physical distance ( inter country/continents or intra ) ,
mediaum of tramsission ( copper cables , fiber , wireless)
Simillarly propagation delay can occur due to large num of network hops like routers / servers . It should be noted that server respose time also plays a critical role in RTT as it depends on server’s processing caapcity and nature of request.
Star based network topology like MCU , SFU or TURN servers can introduce processing delays too for activities such as mixing, encdoing , NATing etc .
Network congestion can amplify the RTT the most.Traffic level must be monitored when RTT spikes such as during DDos attacks
Overcoming large RTT can be achieved by
identifying the choke points of network
ditributing the load evenly
ensuring scalaibility of the server side resources
ensuring points of presence(PoP) into geographic regions where caller/ callee is present and routing through it rather than unreliable open public network
Note : avg RTT of the session is misleading denotaion of latency as there maybe be assymetrically RTT between the two legs of the call
In RTPengine int eff_rtt = ssb->rtt / 1000 + ssb->jitter * 2 + 10;
Thus for RTT = 11338 and jitter =0 eff_RTT = 11338/1000 + 0*2 +10 = 11.651 + 10 = 21.651 , which is a good score as it is way below 150ms of latency
But for RTT = 129209 and jitter =7 eff_RTT = 129209/1000 + 7*2 +10 = 153.209 , which is a bad score > 150 ms
When packet does not successfully make it to the destination , it is a lost packet.
It could happen due to multiple reasons such as
network bandwidth unavailable or network congestion
overloading of the buffer such that they do not have enough space to queue the packets or high priority preferences
intentionally configuring ACL or firewalls to drop the packets or discarding packets above rate limit by internet service provider
CPU unable to cope up with high security networks encryption and decryption speed requirements
Low battery on device may cause cause underworking of devices and hence lead to packet loss
limitation on physical device like softphone , hardphone or bluetooth headsets or if the hardware is broken at router , switch or cabling
for bluetooth headsets distance range could also be problem for weak signals and consequently packets drops
network errors as shown under Simple Network Management Protocol (SNMP) issues like FCS Errors, Alignment Errors, Frame Too Longs, MAC Receive Errors, Symbol Errors, Collisions, Carrier Sense Errors, Outbound Errors, Outbound Discards, Inbound Discards, Inbound Errors, and Unknown Protocol errors.
radio frequency interference from high voltage systems or microwaves can also cause packet drop in wireless networks
such that the packet can either not arrive or arrive late and be dropped out by the codec . To the listener it would appear like chopped voice or complete dropout for moments .
Obtaining packet loss details
Packet loss percentage is performed as per RFC 3550 using RTP header sequence numbers. If packets are missing sequence the media stream monitors flags that as lost packet.
It can also be concluded from the difference between total packets and received packets from CDR
RTP-XR (RFC-3611) records report real-time drops
The variation in the delay of received packets in a flow, measured by comparing the interval when RTP packets were sent to the interval at which they were received. For instance, if packet #1 and packet #2 leave 30 milliseconds apart and arrive 50 milliseconds apart, then the jitter is 20 milliseconds or if packets transmitted every 15ms and reach destination at every 15ms then there is no variability and the jitter is 0.
Frame bigger than jitter buffer size
algorithms to back-of collision by introducing delays in packet transmission in half duplex interfaces
even small jitter can get exponentially worse on slow or congestion links
jitter can be introduced due to bottlenecks near router buffer, rerouting / parallel routes to the same destination, load-sharing, or route tables changing the path
Handling jitter :
Jitter below 30ms is manageable with the help of jitter buffers in codecs however above that the codec starts to drop the late arrived packets and cannot reassemble / splice up the packets for a smooth media stream effectively, hence causing media quality issues like clipped audio
looking at inter packet gap in the direction of RTP stream in wireshark
RTP-XR (RFC-3611 & RFC-7005) for real-time jitter buffer usage and drops.
Methods for objective and subjective assessment of speech and video quality.
Scheduling for low bandwidth networks
The ability of the end application or the RTP proxy to deal with packet loss or delays depends on its processing techniques , particularly with encoding and buffering techniquee to deal with high pac ket loss rate .
Mapping R-value to calculate MOS
To map MOS from R value using above defined metrics , a standard formula is used. First the latency and jitter are added and defined value for computation time is also added , resulting in effective latency
R = R – (lostPackets * impact)
MOS = ( (R - 60) * (100 – R) * 0.000007R) + 0.035R + 1)
Media Stats and MOS on RTP engine Kamailio
Minimum edge Values
mos_min_pv minimum encountered MOS value for the call. range – 1.0 to 5.0.
mos_min_at_pv timestamp of when the minimum MOS value was encountered during the call
mos_min_packetloss_pv amount of packetloss in percent at the time the minimum MOS value was encountered
mos_min_roundtrip_pv packet round-trip time in milliseconds at the time the minimum MOS value was encountered
mos_min_jitter_pv amount of jitter in milliseconds at the time the minimum MOS value was encountered
Maximum edge Values
mos_max_pv maximum encountered MOS value for the call.
mos_max_at_pv timestamp of when the maximum MOS value was encountered during the cal
mos_max_packetloss_pv amount of packetloss in percent at maximum MOS moment
mos_max_roundtrip_pv packet round-trip time in milliseconds at maximum MOS moment
mos_max_jitter_pv amount of jitter in milliseconds at maximum moment
mos_average_pv average (median) MOS value for the call. Range – 1.0 through 5.0.
mos_average_packetloss_pv average (median) amount of packetloss in percent present throughout the call.
mos_average_jitter_pv average (median) amount of jitter in milliseconds present throughout the call.
mos_average_samples_pv number of samples used to determine the other “average” MOS data points.
mos_A_label_pv custom label used in rtpengine signalling. If set, all the statistics pseudovariables with the A suffix will be filled in with statistics only from the call legs that match the label given in this variable.
A label’s min mos_min_A_pv mos_min_at_A_pv mos_min_packetloss_A_pv mos_min_jitter_A_pv mos_min_roundtrip_A_pv
A label’s max mos_max_A_pv mos_max_at_A_pv mos_max_packetloss_A_pv mos_max_jitter_A_pv mos_max_roundtrip_A_pv
A label’s average mos_average_A_pv mos_average_packetloss_A_pv mos_average_jitter_A_pv mos_average_roundtrip_A_pv mos_average_samples_A_pv
B labels’s min mos_B_label_pv mos_min_B_pv mos_min_at_B_pv mos_min_packetloss_B_pv mos_min_jitter_B_pv mos_min_roundtrip_B_pv
B label’s max mos_max_B_pv mos_max_at_B_pv mos_max_packetloss_B_pv mos_max_jitter_B_pv mos_max_roundtrip_B_pv
B label’s average mos_average_B_pv mos_average_packetloss_B_pv mos_average_jitter_B_pv mos_average_roundtrip_B_pv mos_average_samples_B_pv
Setting MOS collection on kamailio
set the kamailio config rtpengine params for names the variable the hold specific mos values
Gather the mos stats from the code . Given exmaple is in Lua. The values are filled in after invoking“rtpengine_delete”, “rtpengine_query”, or “rtpengine_manage” if the command resulted in a deletion of the call (or call branch).
KSR.log("info", " mos avg " .. KSR.pv.get("$avp(mos_average)"))
KSR.log("info", " mos max " .. KSR.pv.get("$avp(mos_max)"))
KSR.log("info", " mos min " .. KSR.pv.get("$avp(mos_min)"))
KSR.log("info", "mos_average_packetloss_pv" .. KSR.pv.get("$avp(mos_average_packetloss)"))
KSR.log("info", "mos_average_jitter_pv" .. KSR.pv.get("$avp(mos_average_jitter)"))
KSR.log("info", "mos_average_roundtrip_pv" .. KSR.pv.get("$avp(mos_average_roundtrip)"))
KSR.log("info", "mos_average_samples_pv" .. KSR.pv.get("$avp(mos_average_samples)"))
KSR.log("info", "mos_min_pv" .. KSR.pv.get("$avp(mos_min)"))
KSR.log("info", "mos_min_at_pv" .. KSR.pv.get("$avp(mos_min_at)"))
KSR.log("info", "mos_min_packetloss_pv" .. KSR.pv.get("$avp(mos_min_packetloss)"))
KSR.log("info", "mos_min_jitter_pv" .. KSR.pv.get("$avp(mos_min_jitter)"))
KSR.log("info", "mos_min_roundtrip_pv" .. KSR.pv.get("$avp(mos_min_roundtrip)"))
KSR.log("info", "mos_max_pv" .. KSR.pv.get("$avp(mos_max)"))
KSR.log("info", "mos_max_at_pv" .. KSR.pv.get("$avp(mos_max_at)"))
KSR.log("info", "mos_max_packetloss_pv" .. KSR.pv.get("$avp(mos_max_packetloss)"))
KSR.log("info", "mos_max_jitter_pv" .. KSR.pv.get("$avp(mos_max_jitter)"))
KSR.log("info", "mos_max_roundtrip_pv" .. KSR.pv.get("$avp(mos_max_roundtrip)"))
local mos_A_label = KSR.pv.get("$avp(mos_A_label)")
if not (mos_A_label == nil) then
KSR.log("info", "mos_average_packetloss_A_pv" .. KSR.pv.get("$avp(mos_average_packetloss_A)"))
KSR.log("info", "mos_average_jitter_A_pv" .. KSR.pv.get("$avp(mos_average_jitter_A)"))
KSR.log("info", "mos_average_roundtrip_A_pv" .. KSR.pv.get("$avp(mos_average_roundtrip_A)"))
KSR.log("info", "mos_average_A_pv" .. KSR.pv.get("$avp(mos_average_A)"))
local mos_B_label = KSR.pv.get("$avp(mos_B_label)")
if not (mos_B_label == nil) then
KSR.log("info", "mos_average_packetloss_B_pv" .. KSR.pv.get("$avp(mos_average_packetloss_B)"))
KSR.log("info", "mos_average_jitter_B_pv" .. KSR.pv.get("$avp(mos_average_jitter_B)"))
KSR.log("info", "mos_average_roundtrip_B_pv" .. KSR.pv.get("$avp(mos_average_roundtrip_B)"))
KSR.log("info", "mos_average_B_pv" .. KSR.pv.get("$avp(mos_average_B)"))
As the techinolgy for packet switching matured, the voice quality between circuit switched and packet switched network is mostly indistinguishable . However the flaws in VoIP communication system reappear under low network conditions and bad architecturing. Especially with applciation that are greedy for network bandwidth such as large scale conferencing or HD streaming , the need for monitoring and quality control are very high , which can be only meet by above described QoS parameters
CDR on freeswitch
ITU-T G.114 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (05/2003) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS , International telephone connections and circuits – General Recommendations on the transmission qua
Self driving tech includes Radar, Ultrasonic, Passive video, LIDAR (Light Detection and Radar) , IoT , sensors , advanced GPS so on . Machine learning models on Computer vision is disrupting automobile industry and likely to create a multi billion dollar market in near future..
To make the traffic and transportation infrastructure more robust, “connected cars” is an overlay technlogy which will enable vehicles to communicate when in vicinty and help mitigate accident and clogging risks.
Since each car will consume and process terabytes of data , enabling intercommunication between vehicles will help in resource sharing and auto syncing updates.
Inter vehicle communications – V2V
Vehicles can communicate wirelessly (Bluetooth, LTE, 5G ultra wideband, cellular-V2X, LoRA …) via vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I), including location, speed, direction. This imporves coordination among vehicular traffic and reduces congestion.
Inter car Connectivity enables automation by serving as an additional sensor for functions like acceleration , braking , streering with activated response.
Since its inception with google Waymo , Uber and Lyft in 2016-18 with CES show stoopers such as Drive.ai , nuTonomy the future of self driving cars looks bright indeed. Today ( at the time of writing this article -2020) , self -driving or autonomous cars are not only capturing personal vehicles market but also truck / transportaion service and even fleet management and cab services.
Advantages of connnected Cars
Allows drivers to be warned of emerging dangerous situations in envrionmnet
Vehicles can anonymously and securely exchange data with other vehicles
In additon to points above there are potential indirect benifits to connected vehicles too
Reduces accident fatalities and injuries
Increase vehicle effiency and decreased carbon emissions
Lower fright transportation costs and land use for mobility
intelligent parking and prioritization in checkouot lanes
Levels of autonomy in self driving cars
Level 0 – No Automation . Manually controlled while still enabling communication like warning and alrts for blind spots etc
Level 1 – Driver Assiatance . Vehicle can control streering or speed although human driver is reponsible for his saftey and operation. Adaptive cruise conrol and lane departure are an exmaple of this level .
Level 2 : Partial Automation . vehicle is able to detect the environment, control acceleration, breaking and steering, and navigate complex traffic situations without any driver intervention. Yet driver needs to take over instantly at any time when required.
Level 3 : Request to intervene . vehicles control all features of driving and can make informed decisions such as overtaking slower moving vehicles. The expectation is that the human driver will be ready to respond to a request to intervene when issued by the automated driving system. Traffic jam chauffeur is an example
Level 4 : High Automation . vehicle is capable of full automation in limited conditions ie operation design domain (ODD). this can include environmental, geographical and time-of-day restrictions and/or the requisite presence or absence of certain traffic or roadway characteristics.
Level 5 : Full Automation . specified automated driving features are engaged and a human driver is not necessary.
AutoDriving Car Features that require Communication
Adaptive cruise control (ACC) is an available cruise control advanced driver-assistance system for road vehicles that automatically adjusts the vehicle speed to maintain a safe distance from vehicles ahead. Also applied to Obstacle Aware Cruise control .
Blind Spot collision warning vehicle-based sensor device that detects other vehicles located to the driver’s side and rear. Warnings can be visual, audible, vibrating, or tactile
Auto steer / lane departure warning system (LDWS) warn the driver when the vehicle begins to move out of its lane on freeways or anterial roads.
Front collision warning of impending collisions with slower moving or stationary cars. Also applies tot Side collision warnings as well as emergency braking.
Emergency Lane Departure Avoidance
Real Time Media Streaming in Connected Cars and V2V
WebRTC is a robust , royality free , end to end encrypted p2p media streaming API . After its rapid adoption by all communication providers and CPaaS solutions , WebRTC also found many applications in IoT ( Internet of things ) especially creating low latency streams.
Tracking your destination on the map using edge computing
Initiate video chat with the guiding server
QT embedded based GUI development
On collision the impacted Cars notify other cars of collision ahead , if required can live stream the feed on WebRTC too so they can access teh situationa nd if required can provide emregncy reponse too . In addition the cars auto call the central communicationo server which will triger callflow to bring police , insurance , medical teams oncall with car and live stream from the cars cameras .
Connected Vehicle Solution using Next Generation Telematics Protocol ( NGTP)
NGTP is an open-source framework that allows over-the-air delivery of integrated data and services to a range of connected vehicles
Blockchain is essentially a decentralized algorithm for distributed storage and processing , using a non immutable data structures and securing them with signatures and keys . These sequential chain of records called blocks , can contains almost anything from timestamped transactions , metadata , contracts , files etc just as long as they are chained using hash pointers to previous blocks .
Proposed by Satoshi Nakamoto in 2008 , iti was deisgned to be a p2p system for electronic cash and took the form of digital btcoin currency in 2009 . This was in stark contrast to existing currency model since in bitcoin one could :
provide proof of who own what at any given momemt
payment history of every bitcoin in circulation
cryptographic validation of transaction thats theoritically impossoble to alter once registered
copies of data are distributed among various nodesin bitcoin network
independant consensus mechanicm that rpelaces the bank system of central ledger
Applications of block chain :
Market analysts and industry specialist have said that block-chain is a revolutionizing technology which will create a decentralized network for not just currency exchange but also many other aspects such as double spent problem , universal identities , document management etc .
Example : Bitcoin protocol , which contains a full record of every transaction ever executed with the currency at any time in past. It is also a remody to counter problems like black – money , double spending , tax evasions etc.
Beyong digital currency , applications of blockchain find use in –
Decentralizing document keeping such as government records , digital assets , equity information , medical and health records etc . The system also provide data ownership and Intellectual property protection .
Fintech as AML( Anti money laundering) , eKYC ( Know Your customer) , epay , loans, stock trading .
Smart contracts such as in ethereum . Allows to keep program code that would execute on an event.
Shared economy for a p2p payment system .
Crowdfunding , works on paradigm of token owner’s voting and cooperation in decisions for crowd-sourced venture capital funds .
Micro payments / fractional concurrency for small amounts suits power selling and buying such as on solar renewable power micro grid
What is a hash ?
function f (x) = y , takes an i/o and give a determined o/p .
Example heaxadecimeal output of my name , md5(altanai bisht) = 2b9e76d57842ebafaf19fd33bb3573a3.
These are irreversible ie one cant find the input from output . For this you’d need to try every combination using brute force. Hence these are generally used for cross verification without revealing the information itself .
Since a block chain is a ledger of facts shared across many peer nodes , all communication and inter node transaction uses the power of crypto to authenticate each other and validate each others requests from the genesis block .
What is a genesis block ?
First block of blockchain which needs to be hard-coded into software . It is the only block which does not reference a previous block .
As any peer wants to add a fact to the ledger , a consensus needs to be obtained from the network. This way of network agreement ensures that fraudulent behavior is prevented .
PoW ( proof of work ) is leveraging computing power to solve complex cryptographic problemsthat add block to chain and also validate the transactions . The updated chain then becomes the new reference for further transactions .
There is only one path from top block on chain to genesis root , however there can many forks upwards from genesis block . It is so because blocks may be created within a short span of time or be under processing . One of the two block will be added to main chain and other will be orphaned or added to pool of queued transactions or even be lost.
Blockchain integarted with Voice over IP platforms
To overcome the flaws of current cellular, LTE, SIP PBX and WebRTC CPaaS ( Communication as platform services ) with multiple sources of truth for call records to track conversations and maintain context, we are decentralising few components of VoIP platform and cloud communications such as registrar & CDR using smart contracts and delegated proof of stake. Part of blockchain algorithms. Boosting security and credibility in VOIP ecosystem by leveraging the power of blockchain algorithms for CDR (Call Detail Records).
If a call log is broadcasted to every node in the network, verified and a copy is maintained by peers, the call records are as secure as a monetary transaction made over a bitcoins. This is because they are added to ledger encrypted with digital security code, with the assurance of being unalterable and permanent.
Decentralised Call Record ( CDR ) system on blockchains
For the headless browser-based clients, the users maintain their call information in a distributed fashion and own the mutual responsibility to share, hash, sign and validate the records. There is no single point of failure. The cryptographic hashes and digital signatures on the chain structure of Merkel tree ensure that the Data layer, where the actual data structure and physical storage is made, is secured, while the p2p broadcast and local validation on network side ensure that all nodes approve of the incoming call setup. The consensus is obtained by proof of work and smart contracts are used for binding the call arrangement.
Advantages of Persistent, Distributed, Decentralized Algorithm based CDR system such as Blockchain
Advantages of this approach are manyfold. For the telephony architecture, no logging takes place at the central server as it only places the role of proxying the connection and exchanging SIP request/response based on SIP URI. Hence the backend servers no longer need to maintain resource-intensive Database operations or AAA ( authentication- authorization- accounting ). New call requests are propagated and advertised to other peer nodes. Peer nodes called miners accept the block, compute proof of work and broadcast back to other nodes. The rest of the nodes append the information to their blockchain using the previously accepted hash. The call receiver receives the confirmation and can now accept or reject the call.
Pros and cons of using blockcchain to maintain CDR in SIP/WebRTC CPaaS
If a call is broadcasted to every node in the network, verified and a copy is maintained by peers, the call records are as secure as a monetary transaction made over a bitcoins. This is because they are added to ledger encrypted with digital security code, with the assurance of being unalterable and permanent.
The world is fast moving towards the open and decentralised economy and it is but obvious that telephony needs to catch-up and be at par with the emerging trends with plenty of re-engineering and design changes. Creating a peer to peer secured network for VoIP communication will ensure trust and security between callers and prevent spammers or fraudulent call behaviour. Also once a call is made, the call history is permanently stored and protected against revision.
Steps to Programming a simple block-chain application :
Lets assume we are creating a block chain for call records.
Structure of a block which is an object which typically looks like
createNewBlock() : at first we need to create a genesis block
boolean isBlockValid ( newBlock , oldBlock) – checks if the oldblocks index is sequentially aligned with new block and whether old blocks hash is equal to new blocks previous hash . Also calculates whether hash of new block is actually same as the supplied hash value in new block ( give below) .
hashBlock( block ) – to create the hashes we need to add in block. Basically a SHA 256 hash of concatenated arguments as index, timestamp, message , previous hash and a nonce .
All block-chains a\re deterministic state machines and transactions act upon them . Consensus filters out the invalid ones and reaches on agreement with valid ones.
DPOS (Delegated Proof of Stake)
A consensus algorithm used for electing producers and scheduling them in a fair and democratic way . It works on the simple principle that longest chain wins therefore incases of multiple forks or network disruption also , if an honest peer finds out a valid strictly longer chain , it will switch from its current fork to the longer chain. We assume that in all conditions , no other chain forked can be longer if 2/3 of producers are honest as 2/3 + 1 confirmations are required .
In crypto we trust !
Block chain is primarily 3 things : p2p network, public key cryptography and distributed consensus .
The security and accountability of such a system is managed via mass surveillance of transactions and cryptographic evidence. Ensures that blocks are always in chronological order since meddling with the blocks will change the hash for preceding blocks
Verification of block uses ECDSA ( Elliptic Curve Digital Signature Algorithm) to ensure that tokens are spend by their rightful owners only.
An ellipsis is a derived from the second degree equation like ax^2 + bcy + cy^2 + dx + ey +f =0 . Depending on attributes this could be hyperbola , parabola or even a circle . However elliptic curve cryptography uses a third degree equation from either a pseudo -random curve ( such as over prime fields y^2=x^3+ax+b or binary fields y^2 + xy = x^3 + ax^2 + b ) or a special curve .
What is ECDSA ?
There are 2 types of auth schemes : Symmetric , relying on shared secret key and Asymmetric relying on private public keys . ECDSA is a asymmetric authentication scheme where in addition to sender and receiver , even 3rd party systems can be authenticated . In this the sender uses his private key to sign the message and receiver uses the senders public key to verify the message’s signature .
While publishing a block with pending facts to be appended to a chain , the owner sends it to other nodes for confirmation on its validity. Once its approved , other nodes called miners add it to their copy of chains. However the new block has to be published after fixed time interval for fraud prevention ( example : bitcoin blocks are published every 10 mins on avg ) . This duration is dynamically recalculated as the network miners grow or shrink . A difficulty is a number metric that represents how difficult is it to find a hash for given target.
To force increase time for calculating the matching hash , difficulty is increased for miners work harder and take longer to earn the block reward .
While in case of less miner participation , the block difficulty level is made lower
As digital transactions and open banks APIs like UPI have gained massive adoption , the backend communication system between these wallets managers, financial institutions and open banks providers has become critical to not only track fraudulent transactions but also provide dispute management and other KYC or document sharing processes .
With browser based netbanking or transfer today it is simpler than ever to offer personalised calls to users as he/she logs into their banking portal. A bank agent can connect with users over the call to assist in reviewing new loan policies, offers etc. This goal is realised with WebRTC API embedded in browser which enables agent – user communication to be embedded right inside the webpage of a laptop , tablet , mobile even Kiosk o smart TV.
We know the power of Internet protocol suit as it takes on the world of telecom . Alreday half of Communication has been transferred from legacy telecom signalling protocols like SS7 to IP based communication ( Skype , Hangouts , whatsapp , facebook call ) . The TV service providers too are largely investing in IP based systems like SIP and IMS to deliver their content over Telecom’s IP based network ( Packet switched ).
A consumer today wants HD media content anytime anywhere . The traditional TV solutions just dont match upto the expectations anymore . The IPTV provider in todays time must make investments to deliver content that is media-aware, and device-aware. Not only this it should be personal, social, and interactive . After all its all about user experience.
Few popular applications for IPTV solutions developers are
Menu overlay with detailed description of channels , categories , programs , movies
Replay option also referred to as timeshift . It allows a user to pause , resume and record the show in his absence and view it later
Video on demand which concerns paying and viewing music albums , movies etc on demand
Live streaming of events such as president speech , tennis match etc .
Application that can be build around the IPTV context
Record and Playback content
Information overlay on streaming content
Social networking services integrated with IPTV content
Parental Control to realtime view , monitor and control what your child is watching on the IPTV
Watch the surveillance footage from IP cameras anywhere
Real time communication on IPTV with advanced features like call continuity , content sync .
Video On Deamnd ( VoD)
Video on demand using Adaptive Multirate dispatch using AWS Transcoder
HTML5 webpage on chrome browser for WebRTC input
It contains the client side script to record the video and send the blob to server side for processing .
Amazon EC2 instance
The amazon ec2 instance hosts the web interface for login and video recording . It converts the incoming blob / webm format to mp4 . After the video conversion it uploads the video mp4 to s3 bucket.
Amazon S3 bucket
The s3 bucket is connected to the transcoder via pipeline and holds the video storage as well .
The transcoder provides adaptive multirate dispatch on viewer access .
RDS for any mysql storage ( optional )
Optional for record keeping credentials , storage links , linked information etc .