This clearly wasn't designed by telephony people. It's very web-like. The authentication info is bigger than the call data required to set up a call.
Mostly this is for VOIP. Telcos with TDM or CDMA transmission have serious backwards compatibility problems. Ones who peer only with SS7 have problems but those can probably be overcome.
One big problem is that there are off-brand telcos who specialize in services for call centers. "The Dialer Hardware is being hosted in our premises at Los Angeles - USA, where we have our own switch and termination facility with over 100 Carriers. We also have a redundant switch in New York connected to LA through a fat Fibre pipe."[1] Do those guys get to sign calls? Or what?
The authentication info is bigger than the call data required to set up a call.
That's not a counter-argument, it's a cop out. SSL negotiation uses more bandwidth than a vanilla HTTP GET request too, but sometimes a secure channel is more important than preserving bandwidth.
Telcos with TDM or CDMA transmission have serious backwards compatibility problems.
More cop outs. In order to resolve problems, you have to make changes. You can't show up to the solutions meeting and proclaim that a problem can't be solved because "the old system doesn't work that way." Sometimes you must abandon the legacy systems to solve new problems.
One of the current problems is a ban on robocalls exists (for calls to cell phones without consent, at least), as does a ban on IRS scam calls, Microsoft scam calls etc, but the bans can't be enforced because when a victim complains there's no way to trace the guilty party. After all, the caller ID was faked.
So the call signing doesn't have to be "a body that will block all robocalls and scams" it only has to be "a body that can be sued and fined". You rotate certificates weekly and issue a certificate to any company willing to make a deposit of $X against possible fines. Then adjust $X until robocalls and scam calls with fake caller IDs stop happening.
Of course, even if that stopped robocalls/scam calls with faked caller ID, profitable scams and robocalls would be able to use burner cell phones. So it's not a perfect solution by any means.
Comments
This clearly wasn't designed by telephony people. It's very web-like. The authentication info is bigger than the call data required to set up a call.
Mostly this is for VOIP. Telcos with TDM or CDMA transmission have serious backwards compatibility problems. Ones who peer only with SS7 have problems but those can probably be overcome.
One big problem is that there are off-brand telcos who specialize in services for call centers. "The Dialer Hardware is being hosted in our premises at Los Angeles - USA, where we have our own switch and termination facility with over 100 Carriers. We also have a redundant switch in New York connected to LA through a fat Fibre pipe."[1] Do those guys get to sign calls? Or what?
[1] http://www.callcentersindia.com/showall-orig.php?value1=1126...
That's not a counter-argument, it's a cop out. SSL negotiation uses more bandwidth than a vanilla HTTP GET request too, but sometimes a secure channel is more important than preserving bandwidth.
More cop outs. In order to resolve problems, you have to make changes. You can't show up to the solutions meeting and proclaim that a problem can't be solved because "the old system doesn't work that way." Sometimes you must abandon the legacy systems to solve new problems.
So the call signing doesn't have to be "a body that will block all robocalls and scams" it only has to be "a body that can be sued and fined". You rotate certificates weekly and issue a certificate to any company willing to make a deposit of $X against possible fines. Then adjust $X until robocalls and scam calls with fake caller IDs stop happening.
Of course, even if that stopped robocalls/scam calls with faked caller ID, profitable scams and robocalls would be able to use burner cell phones. So it's not a perfect solution by any means.
Surely the telco can trace who made the call?
Usually, the only available information is the immediately adjacent carrier through which the call came.
Well, VoLTE and VoWiFi (urgh, that makes my eyes and pinky hurt) are using SIP already... Does this apply to end-to-end SIP calls only?