Video relay services (VRS) have been a godsend for making phone calls accessible for people who use ASL. However, a recent ordeal has me made think that the industry has lost sight of the fundamental principle underpinning relay services: functional equivalence. 1/
Functional equivalence is a slippery concept, but in its most essential form can be boiled down to being able to make the same types of calls, under the same circumstances, with the same flexibility as a hearing person can. 2/
So, here is a totally normal situation that any hearing mom or dad would find themselves in. Our twin kids have to make a decision about which middle school to go to. Our son, in particular, is torn between two schools. 3/
Thankfully, a helpful mom offered to have her son talk to mine about his experience. And just like any parent at that age, we want to monitor the call. Easy for a hearing person. Just put the phone on speakerphone. Using VRS? Not so much. Oh no, nope. That was a major ordeal. 4/
Sure, all services are required to offer what anachronistically is called voice carry over and hearing carry over. As for me, just like calling it audio passthrough. So, the idea is that my son speaks and listens for himself, and we get the call through the VRS interpreter. 5/
We start the VRS app on our Mac and call. Video Relay Provider A – which mercifully shall remain unnamed – first pushes back against us making the call, because our son is in the same room with us. 6/
Um. Nope. That’s a distortion of the FCC rule against abuse of the system, where in the past some bad apples have used relay services as a free in-person interpreter service. 7/
There is a very simple litmus test for what should be permitted under the principle of functional equivalence. And that is: would a hearing person place a phone call under the same circumstances? 8/
The answer would be most assuredly no for two people sitting next to each other, but most assuredly yes for a mom, a dad, and a son sitting next to each other while calling someone else. So, why do we need to argue with Provider A about this instead of placing the call? 9/
That’s not the end of our troubles. Provider A utterly fails to figure out that they need to pass the audio both ways. Let’s be clear – having audio both ways is logical and natural. 10/
The end result of making the call is that we can hear the remote side, but the remote side can’t hear us. And is utterly confused by what is going on. We tell him, via the interpreter, to sit tight and hang up in disgust. 11/
Enter Provider B, who likewise shall mercifully remain unnamed. Provider B has a simple option for placing a VCO/HCO call, and unlike Provider A always passes through audio both ways without asking. 12/
Except … that when we test to make sure we’re all ready to go, the VRS interpreter can’t hear us. We try different things both on our end and the interpreter’s end to no avail.
Finally the interpreter says to try two-line VCO. 13/
Finally the interpreter says to try two-line VCO. 13/
That simply means that instead of passing the audio via our Mac, the provider will call me back on my cell phone to connect the audio. Unfortunately, this doesn’t work, because I have my iPhone set up to reject all calls from unknown numbers as an anti-spam call measure. 14/
Trying to lift this block does not take effect immediately. So, that’s a dead end. We hang up again, and try one more time with Provider B. Again, the interpreter can’t hear us. The interpreter finally transfers us to Provider B’s customer service. 15/
The customer rep says that they need to enable VCO in their settings for my profile. Uh, what? Why on Earth do I need the provider’s permission to use VCO in the first place? That’s a choice that is 100% under the consumer’s purview, not the provider’s, thank you very much. 16/
Rep tells us that it may take up five minutes for the setting to take effect, and to try calling again at that time. And to call the rep back if things still don’t work. By this time, we’re pretty much stewing, and now wait for those five minutes that seem like an eternity. 17/
Cue the call, and surprise: VCO still doesn’t work. The interpreter can’t hear us. Again we get transferred to customer service, where we run into the same rep as before. The rep, visibly exasperated, tells us that they are deaf and have no way to troubleshoot the issue. 18/
There is some behind-the-scenes talk, and then the verdict comes back from a supervisor: the version of the OS X app that is distributed by Provider B broke VCO, and it is a known problem. (Known to the supervisor, that is, not to front-line reps and VRS interpreters.) 19/
The customer rep tells us that the only way to fix the issue is for us to completely uninstall the offending latest version of the VRS app and to have them email us a private link to a downgraded version where VCO is known to work. 20/
I won’t go into the contortions that we had to go through to transfer the call with the customer rep to my iPhone while getting rid of the OSX version, but suffice it to say that it is nowhere near as easy as transferring a voice call. 21/
We finally got the app downgraded, and ended the call with an admonishment by the customer rep of Provider B not to upgrade the app. By now an hour has passed from the time we originally wanted to place the call. VCO worked after the downgrade. 22/
Except that the interpreter initially didn’t interpret my son’s voice. So … that’s like hearing dad making a call together with his son, and hearing dad can only hear what the remote side is saying to his son, and he has no clue what his son is saying to the remote side. 23/
Again, what is it with the literal interpretation of rules, instead of applying some common sense about what actually is functionally equivalent? Something is rotten in VRS land. 24/
And broken VCO is unequivocally a safety issue, too. When you call 9-1-1, you don’t have the luxury of taking 60 minutes of figuring out why audio is not working. I won’t name the providers involved, but all four should take heed and learn from this story. 25/25
