We all hate these annoying, unsolicited calls. FCC has been trying to alleviate the problem by various means. They introduced “Do not call list”. It even ran a “challenge”, in the spirit of crowdsourcing a solution. And now the bright and smart people of IETF are trying to form a group to address this problem using technology. In the kickoff meeting, Henning Schulzrinne, CTO at FCC is quoted as saying, “Number spoofing is root of (almost) all phone evil”. If this is so, then there is a simple procedural solution and it starts with “me”.
I subscribe to Caller ID feature. I pay for it directly or indirectly. So I expect this information to be verified. My carrier claims it is offering this feature, So it stands to reason that its expected to deliver verified information. But this information is generated by yet another carrier and this second carrier has no incentive to deliver a verified information. So the crux of the proposal is to incentivize the upstream chain of carriers.
I suggest that my carrier identify its confidence in the caller id in a three point scale: “verified”, “unverified, but can be challenged”, “unverified and can not be challenged”. The idea is if I answer a call from the second group and conclude that the number was spoofed, I challenge my carrier which propagates upstream. If it is concluded that number was indeed spoofed, a financial payoff follows the reverse path. Since termination charges follows this path, this is not an additional burden. It is recognized that this challenge is resource intensive. So to control my trigger happy nature, I am given a limited number of free challenges, just like we do in sporting events.
There are some potential gotchas. Current Caller ID spec has a way to signify two groups. It is not clear whether the spec can be extended to carry the third group as well. It is not clear how many caller ID devices can display the group. Initiating the challenge process is not difficult. This is just a variation on “last call return”.
I suspect that under this scheme, most of the evil spoofers will not be agreeable to this form of challenge. So those calls will belong to the third group, which I will not answer. But well intentioned spoofers will be agreeable to challenges and over a period of time, the public will gain confidence in this characterization and the number of challenges will decline.
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
In a recent post Chris Kranky on the need “to move on” and the need for expediency in wrapping up the first iteration of the API. Personally I would have benefited if the first iteration had been a low level spec. For I could have easily ported a custom Java applet. But given the passage of time, it is more important that there is an agreed standard. But this point is not the objective of this post. Instead I would like to focus on another of his points:
[WebRTC] wasn’t designed to be federated (namely that 2 WebRTC applications aren’t in fact supposed to talk to each other.
He makes this observation to explain the motivation for seeking low level control. My quibble is not with this explanation, but I want to take this sentence in isolation, interpret it literally and discuss it. (It is not fair to Chris, but I am just using his sentence as a prop. So it should be OK with him.)
In my interpretation, if WebRTC is not designed to be federated, then there is some deficiency and need to be addressed. If not immediately, but at some future time. But with WebRTC construct there is no need for federation. Let me explain.
Following are four main reasons why we need federation and how WebRTC handles them without requiring federation:
In my opinion the fact that WebRTC does away with federation is one of the important benefits and why it is going to disrupt communications industry.
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
By now it is quite passe to claim that WebRTC will be a huge disruptive technology. Indeed, there has been a predictable backlash. In all these back and forth, very often we miss to note an important aspect of this technology: there has been a deliberate attempt to avoid specifying any messages and procedures that go across the wire to an intermediate point like server. This gives enormous flexibility to app developer in designing a signaling procedure that suits the needs of the app and at the same time do not have to worry about interoperability issues between arbitrary peers and the app. This is almost true, except for NAT/FW traversal. The objective of this post is to suggest a way to overcome this as well.
The recommended procedure for NAT/FW traversal is to use ICE, which in turn uses two servers - STUN and TURN. More importantly, ICE specifies the procedure and message format that these servers have to follow. Of course Google makes available a STUN server and free, open source TURN server implementations are available. But if for some reason an app wants to avoid these external dependencies, then the app developer has to develop them and then have to test compatibility with browsers. This takes away one of the main benefits of WebRTC.
Instead of fully developing STUN and TURN servers, the idea is to develop a simple “Twice NAT” and a clever use of Trickle ICE procedure that the browsers already support to bootstrap ICE procedure. Here, let us recall that Twice NAT maps both the origination and destination addresses, instead of just the origination (destination, resp) address on the outgoing (incoming, resp.) flow.
As part of Peer Connection procedure, Peer A will generate an SDP offer containing its host address. The app server can append to this SDP offer an address as a “fake” server reflexive address of Peer A before forwarding it to Peer B. In response to this, Peer B will generate an SDP accept containing its host address. The app server can append to this SDP accept another address as a “fake” server reflexive address of Peer B before forwarding it to Peer A. As part of ICE connectivity check procedure, Peers A and B will send connectivity check messages to these “fake” server reflexive addresses. From these the app server can deduce the real server reflexive addresses of the peers. Also, the app server can allocate two addresses at the Twice NAT as relay addresses. With these addresses at hand the app server can generate SDP offer messages to the two peers containing server reflexive and relay addresses of the other peer. Of course the peers will respond with accept messages that the app server can ignore. Since the peers have new candidates, they will perform connectivity checks on these new set of addresses.
If a peer is multihomed, then that peer will conduct connectivity check from each of the interfaces to the “fake” server reflexive address, yielding true server reflexive address of each of those interfaces.
Thus, the app server facilitates NAT/FW traversal without developing conforming STUN and TURN servers and placing the burden of compatibility solely on the peers.
This procedure is adopted from a modified procedure we were using in the Java-based RTC system in EnThinnai. It was developed during 2008.