Sorenson Communications, Inc. filed Note of Exparte letter in response to CSDVRS’ and Todd Elliott’s Ex Parte Letters that was filed at FCC.
Sorenson submitted 23-page document, including exhibits showing how Sorenson products are interoperable with ZVRS products.
Check this link here that will take you to the FCC’s website. You may want to download these documents there.
Sheesh, Sorenson would do ANYTHING to defend themselves. On this letter, Sorenson claimed:
Sorenson agrees with ZVRS that certain matters can best be settled between providers without the need to involve the Commission, and has cooperated with ZVRS to do so in the past.
When I got my new Z20 videophone, I experienced at least FOUR interoperability problems with another caller who uses Sorenson videophone.
Three calls were made at home, and I cannot connect with them. It comes with a black screen and it says, “This number is not registered”, and thus causing problems with my Z20 videophone which I had to restart again.
One is from the workplace where I use VP200 and someone else who has ZVRS product, we cannot connect. That was affecting my ability to work.
I don’t think they have not solved this problem. I know it because I am the CUSTOMER and I experience these problems! I don’t care that the company think otherwise.
Sorenson nTouch products has different kind of codecs, including H.263 and H.264, plus H.323 signaling. Other VRS who has PS, Z4, Z4 Mobile (Mirial), and Z-20 uses a set of SIP-based industry equipment interface standards. Don’t tell me what these mean, because it apparently mean that there are two different technologies, and Sorenson acknowledged that.
Sorenson continues to be willing to work with all industry players – necessarily including the manufacturers of “off-the-shelf” equipment – to develop a set of SIP-based industry equipment interface standards, and is eager to participate in the Neustar-sponsored iTRS engineering event in January to begin defining future SIP-based compatibility.
Do you know why we have ‘off-the-shelf’ equipment? Because we, as the customers, want a CHOICE to choose an equipment! Sorenson, you must work with all of us. You didn’t for a long time.
That is going to be a very interesting event, and I would love to learn bit more about that iTRS engineering event. I hope someone will go there and do an independent reporting.
Sorenson, if you are willing to work with ZVRS, then you should have this fixed before sending out your nTouch products, and having customers faced with so much trouble trying to connect with their friends who has different videophones.
It was YOU who started with lack of interoperability until the FCC mandates that. Now, you are willing to work with ZVRS?
Show me that you can…
Rolling my eyes,
Amy Cohen Efron
Try again with your Z20; call a VP-200 unit and a nTouch unit. Also, did you try calling (800) numbers on the Sorenson units, or the ten-digit numbers? Let us know the results.
Sorenson, in their response today, asserted that “Sorenson’s testing shows that the VP-200 and nTouch VP […]– are fully capable of conducting point-to-point communications with the P3, Z4, Z4 Mobile (Mirial) and Z-20.” What is not immediately clear is whether competitor’s products can initiate and maintain p2p connections with Sorenson’s VP-200 and nTouch units. Sorenson’s statement sounds like their products can initiate and maintain connections, when interoperability is a two-way street.
For now, I’m satisfied with Sorenson’s response on this issue, and thank them for responding. I will be commenting on interoperability issues generally, in response to FCC’s latest NPRM governing VRS reform.
This industry-wide SIP-Interoperability meeting in January certainly bears coverage! I assume that it would be open to the public? I mean, industry participants can comment, discuss, hash out the details, etc. But certainly the public can watch, take notes, etc.? If so, any volunteers in the DC area? Sorry, industry participants need not apply. I would appreciate an independent coverage of this important meeting.
myVRS Relay Central
I contacted FCC in regarding the Neustar-sponsored iTRS engineering event and waiting for the reply to see if I can be able to attend and provide all live updates to the deaf community. I hope I am allowed to attend.
I’ll keep everyone updated 🙂
First, a heads-up: Unfortunately, we are not allowed to talk about what happens at the SIP-Interoperability meeting in January. As part of attending, you can’t talk about what happens there. These are the rules. They apply to all attendees.
Sorenson is claiming that calls need to go point-to-point. That only works with IP dialing. Once you add phone numbers to the mix, the H.323 and SIP standards switch to a model called “server based routing”, where the phones “register” to a SIP Registrar or to an H.323 gateway.
Sorenson and the FCC seem stuck on the idea that those registrars need to reply with a “redirect” and have the phones signal directly point-to-point.
Unfortunately, this breaks some important things:
1. It makes NAT traversal with SIP+TURN or with H.323+H460.18/19 impossible. This means that firewalls get in the way of calls.
2. It flies in the face of stateful inspection firewalls and pinhole NAT which establish connections outbound through firewalls. You don’t need to “punch holes out” through anything but stringent enterprise firewalls if you register to a server.
3. Per the new NPRM’s suggestion about their SIP plan, both your phone, and the phone of the person you are calling, are both registered to your default VRS provider’s servers, but the FCC and Sorenson are saying that instead of your message being relayed through the other VRS provider’s server down to the phone to the phone that is registered to it, the person you are calling must have a phone exposed to the public Internet. That’s just silly.
3. It forces you to forward an inbound signaling port (TCP 1720 or TCP/UDP 5060) on your router from the public Internet into your phone. If you want more than one phone on your home network, you need more than one public IP or you need to use a different port mapping for each phone. It is cumbersome, tedious, and un-necessary to need to configure routers to do this stuff.
4. It prevents any hope of redirection to videomail or any hope of advanced network features like 1Number that allow many phones to ring at the same time when called.
5. It flies in the face of SIP and H.323 standards.
I’m not going to go into great detail here, but the gist is simple: Sorenson and the FCC are going down a blind path here by continuing to insist that calls be direct point-to-point.
Expect a full response from ZVRS on this matter, in response to the latest “NPRM” that the FCC has put out.
Thank you for your detailed explanation. However, I am not readily familiar with the technologies involved in handling relay calls. I have some questions and clarifications that you could shed light upon…
From my understanding, a user dials a number via p2p. Behind the scenes, the VP hardware would call the iTRS database of the number dialed, and find its IP address. Then the VP hardware communicates with this IP address, and finds out that it’s a gateway/registrar, and gets a new IP address. Finally, it contacts the other user’s VP hardware and a p2p call is established. Right understanding?
The better approach… A user dials a number via p2p. Behind the scenes, a VP hardware would call the iTRS database of the number dialed, and finds the gateway/registar’s IP address. A reverse lookup is performed, where the caller’s gateway/registar’s IP address is located. Then a connection is estabiished between two gateways/registars on the behalf of the phone numbers being used. Then a p2p call is established, with the gateways/registrars handling the actual communications traffic. That would be the better approach in p2p calls and as well as VRS calls?
Any further additional clarification/explanations is appreciated. I feel clumsy when trying to discuss interoperability issues as I feel this is the domain best left to experts. However, there have been interoperability issues, so I feel the need to comment on this issue in the pending FCC NPRM. Who knows? Maybe a laymen’s argument and/or explanation can help clear up the muddy waters of interoperability.
Can you speak English? I barely understood a word you said! 😉
I think it is selfishness on Sorenson’s part. NO OTHER VRS COMPANIES experience this part. Not Purple. Not Snap. Sorenson is playing the part of the spoiled child. A child that once was #1 via manipulation, And now its popularity is being threatened. And because of that, it doesn’t want to be the “bigger person” and “play nice”. But guess what? This will be their downfall. Their refusal to play nice. Of course they’ll spin it to the public to make it appear it is us not them. When they got the nTouch to distribute—they could’ve used the same software Purple and ZVRS did (mirial) to promote ineroperability and play nice. But they didn’t.
This is interesting one. A million of times, I have made/received calls from someone using z150 and z20 devices (through my VP200 device). Never had any that kind of problem, but one time one of those z150 callers had experienced the similar problem as you had due to the corrupted registry file on her device. It got resolved with the help of the zVRS support. I agree all of devices settings and compatibility should be standardized and interoperability. Good luck.
Same here, DonG.
I was able to decipher VRSEngineer’s first paragraph, but after that my eyes glazed over.
Cousin Vinny, et al
Behind the scenes, the VP contacts the VRS default provider and asks it to process a call to a phone number. The VRS default provider then does a lookup against their own dialplan database to see if it is one of their phones, and then to the iTRS database to see if there is an entry there. There is no public access to the iTRS database.
How the call proceeds beyond that point depends on whether the call is “direct” or “server-base routed”.
To initiate a “direct” call, the VRS default provider would send a redirect signalling message back to the VP. It would then stop signalling to the VRS default provider and make a new connection directly to wherever it was redirected to. This means that the called party must have a VP that is exposed on the public internet to allow direct inbound IP packets to its signaling port.
To initiate a “server-base routed” call, the phone simply keeps signaling to the same server it sent the initial signaling call setup to. From that point forward, it is told by the server when the remote party’s phone starts ringing, and when the remote party picks up the call. The media setup process (SDP or H.245) might negotiate that the media be relayed through an upstream server (which helps NAT traversal), or it may be able to reply with the called party’s IP information and have the media setup directly if it detects that this is technically feasible for that call.
A phone deployed in the “server-routed” way does not need to have inbound ports mapped to it, or be exposed to the public internet directly. Because the phone is making outbound network connections through a NATting firewall, no return traffic is allowed to that VP that it did not initiate in the first place.
The funny part here is that Sorenson states that their software endpoints don’t need to support the same “direct” dialing requirements as their hardware endpoints. Technically, the FCC orders aren’t clear at all when it comes to interoperability requirements between software videophones, which also makes Facetime, Skype, GTalk, and other non-H.323 and non-SIP standards based VRS calls possible today.
The unfortunate bit there is that their endpoints are given 10 digit numbers in the iTRS database. This, in itself, suggests that they need to be dial-able point-to-point and VRS to/from any other VRS endpoint, and backward interoperable. Unfortunately, the rules don’t appear to say that.
As for IP address direct dialing:
Neustar initially had a platform called SIP-IX that hosted ENUM records. These NAPTR records can hold any URI, and many different protocol types. The specification for E2U+h323 records allow for “email@example.com” DNS style records.
This is how the VoIP world handles dialing to ENUM zones like “enum.arpa”, “enum.us”, “enum.org”, “nrenum.net”, etc. There are many of these, none which are truly “golden” authorative representations of what are in the Neustar NPAC database, or the LERG database which makes up the 10 digit NANPA PSTN dialplan that everyone here in the US knows.
The key point here is that “@domain.com” routing is How It Is Done in the rest of the VoIP industry.
When the FCC contracted Neustar, they were told to use IP addresses instead of “@domain.com” DNS style records. The FCC later had Neustar implement a “reverse lookup API” be exposed for VRS providers to be able to look up a phone number for a given IP address. Their thought was that every customer needed to be validated for VRS calls for dial-around.
Unfortunately, many providers point tens of thousands of phone numbers at their server’s IP addresses, which means that other VRS providers can really only tell that a phone call originated from another VRS provider’s gateway.
ZVRS assigns every customer a ZConnect IP address in the cloud that represents that Z phone whenever it places calls to non-Z phones. It is this unique IP address that is put into the iTRS database for each Z phone so that non-Z phones (even those from before 10 digit numbering) can be assured that they are reaching the correct Z phone, even when all of those Z phones are “server-based routed”.
The entire origin of this direct IP based dialing nonsense stems from early industry fears (before 10 digit numbering) that a server-based routed topology would somehow incentivize VRS providers to somehow degrade or somehow de-prioritize video traffic for dial-around so that the quality would suffer when someone tried to use someone else’s VRS service. This was back when the only VRS videophone was the VP100, and all of the other VRS providers were really making their money off of Sorenson customers doing dial-around to them for VRS service.
These fears have led to an abomination against what the rest of the VoIP world does.
The reality is that building a videophone hardware device from the ground up and writing the firmware for that device is a very expensive proposition. Economies of scale just aren’t there to make it financially viable for a business to attempt. This is why there are VoIP hardware vendors that people buy videophones from. The standards are what make videophones interoperable between these different videophone manufacturers. This helps create competition between vendors, yet keeps the price of equipment low due to economies of scale in production of the hardware. This is why there is a Telepresence industry…
Why, then, would we be asking a tiny VRS industry, who can’t seem to come to a consensus themselves, to specify some new standard that they themselves can’t possibly convince the rest of the Telepresence industry to implement?
The better approach here would be for the FCC to approach the rest of the VoIP/Telepresence industry and ask THEM to work between themselves to support some new standard that allows the FCC to do whatever it is they want to do. By doing this, any VRS provider, or even the lowest cost government bid winner (should it come to that) will enjoy the low prices for common off-the-shelf hardware that economies of scale produce.
The better approach should have been to allow DNS based domain names in the iTRS database, pointing to VRS provider’s gateways.
That is, unless the deaf community really does want an expensive “special deaf-only videophone” hardware platform that is NOT interoperable with the rest of the VoIP/Telepresence industry.
I just can’t bring myself to believe that this is the case.
Thank you for your detailed explanation. I also touch on the same argument you make; that a ‘deaf-designed’ videophone solution is suboptimal.
Actually, Sorenson knew all about those issues because they just posted a job opening for a software engineer. http://www.careerbuilder.com/JobSeeker/Jobs/JobDetails.aspx?job_did=J3G66V6YYTXRC103ZV6. Eventually, their next product may be compatible then.
They intentionally make their phones interoperable. It is because of them that FCC created a mandate that all phones be interoperable as of Nov 2009 if memory serves me correct. Further more, it is within the last few weeks that they are “blocking” calls to/from Z videophones. Prior to that-no problems at all.
Have you seen my FB photo of my workplace cafeterria vp 200 have no picture of my home z-20 vp while I tried to call my hubby at home last Saturday?? If yes, you can have my permission to download my photo to share. Thanks for your posting. I wonder that too. I learn that FCC requires alll kinds of vp devices should call each other without any conflicts just like hearing cell phone users.
Pls I don’t know if my workplace cafeteria vp phone nbr is fcc registered. Will find out asap from my Sorenson friend.
I’m concerned about Deaf Joplin missouri Sorenson vp users + wonder if their vp nbrs are registers also??? Wonder abt this since last night.
Thank you for your blog post. Happy holidays to you!
myVRS Relay Central
“First, a heads-up: Unfortunately, we are not allowed to talk about what happens at the SIP-Interoperability meeting in January. As part of attending, you can’t talk about what happens there”
Do you have the fact in writting that they say this? I need proof. I want to believe facts than your own words.
Please show us facts before you say it.
Can’tHelpIt: That is news to me. As an engineer at ZVRS, I’m not aware of any “new” blocking happening on Sorenson’s side with any more frequency than normal.
By normal blocking, I mean that sometimes Sorenson “forgets” to delete a phone number from their dial-plan when a number ports away from them. That’s perfectly understandable. Most of the time, they appear to have an automated system and/or a decent crew of employees addressing numbering changes. While a number remains live on the Sorenson dial-plan, this makes it impossible for another Sorenson phone to call that number until they fully delete it from their own system. Sorenson is usually pretty good about responding to requests to fix numbers they no longer own. Usually. Sometimes they take a bit longer than appears necessary, but rarely given the volume of port-outs from them.
This isn’t unique to Sorenson. All VRS providers that assign videophones to customers have this same issue. ZVRS tries hard to make sure numbers do not remain in our dial-plan if they have been ported-out. We run a report from our carriers and compare the terminating numbers our carriers say we have with the numbers in our live dial-plan, and remove any numbers that are no longer routed to us by our carriers.
If you run into problems where a losing provider isn’t removing the number from their dial-plan in a timely manner, you can always complain with a Form2000C, which has a wonderful way of getting the lawyers to club engineers over the head to take immediate action:
If you have any examples where you know numbers are being proactively “blocked” for some reason, particularly if it involves ZVRS, I ask that you please contact me directly at firstname.lastname@example.org and let me know about it.
Joseph (myVRS Relay Central),
On December 13th, 2011, we had a conference call with Brian Rosen at Neustar who verbally told us what to expect at the SIP Interoperability event. Unfortunately, that wasn’t presented to us in a written form.
As Brian Rosen isn’t with the FCC, there is no need for an exparte filing in this case.
Unfortunately, nothing has been published by the FCC officially in a public forum.
Aside from contacting Brian Rosen or the FCC and asking directly, you’re going to have to take my word for it.
I threw in the towel after reading this blogpost in that the engineers’ responces are as confusing as The Tower of Babel!
Well, this reminds me back in the days of dail up on 1200 baud modems, usrobotics led the charge at the fcc to maintain interoperability between modem standards. Its like hayes and usrobotics all over again. Those who r computer engineers long enough would know what I’m talking about.. if not, then u r young to computer science industry. Meanwhile, my take on this touchy subject,
First I do know each provider maintains their own data base on fone numbers to ip addresses for their clients. So in that aspect, what is stopping a shady ass company from messing up the access to the database? They will follow standards, but in other ways add a dfferent obtacle, that the regular public
Would not know about? There’s more than just interoperability!
Unfortiontely I feel other than zvrs, the competitors don’t have the ethics to mainain a service deafies NEED. I been watching from distance and am digusted how the ethics hve washed away in deaf culture and carried over to vrs providers and hurt the users in th long run.
I have actively and successflly lobbied my IT departmnt at a fortune 100 corporation to remove sorenson booths from the company, and replace with a simple pc, and video camera, and choice of 5 vrs providers.
For some reason all the deaf workers uses zvrs exclusively because of the vco feature.
I can’t wait for the day when the jokers at the non-ethical providers, wake up, and start thinking of the customers instead of their prvider’s sucess.
Much love to everyone and happy holidays.
Scuse my typos as I entered this from my android fone.
True interoperability would mean not only ANY vp unit being compatible with ANY OTHER vp unit, it would also mean being able to:
-Call anyone P2P with no message “unregistered number” or any such failure to connect.
-Call a hearing person using free downloaded software on their computer webcam system.
-Call any business that advertises its webcam software as compatible with the Deaf VP system.
See how liberating this would be for all of us? Imagine being able to call hearing family members, friends who can sign or use lipreading methods, hearing teachers, and Deaf-friendly businesses. Without them having to purchase expensive equipment from the VRS companies.
On another note, thank goodness for Deaf engineers being involved with this interoperability and protocols business. I certainly can’t get a handle on it. You go, guys, and may you keep the end consumer in view because you are consumers too.
Good morning Amy-
FYI: just did sent my video msg for Sorenson VRS this am + don’t know it works??? Here’s my msg (copied + pasted from Sorenson VRS FB Wall): Good morning dear Sorenson VRS!
Since I respect both my Deaf son + Deaf hubby are heavy Sorenson user or Sorenson Syndrome as I am a long time Z user + me still an authority of taking care of (paying) both internet + phone bills under my own name (not my hubby). So now they both beg me to go back Sorenson but I prefer wait + take my own time. Here’s my video msg for you, dear Sorenson VRS. Happy Peace Holidays with our own free choice. Thank you, Mrs Elfrink
This link, http://transition.fcc.gov/Daily_Rele…C-11-184A1.pdf, is an excellent resource for the VRS industry to implement the latest standard protocol per FCC’s request. As far as I know, ZVRS (also known as CSDVRS) is already ahead of other all VRS providers in that area.
Please resend the complete link. I cannot access.
This link, http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1215/FCC-11-184A1.pdf, is an excellent resource for the VRS industry to implement the latest standard protocol per FCC’s request. As far as I know, ZVRS (also known as CSDVRS) is already ahead of other all VRS providers in that area.
myVRS Relay Central
The new proposed FCC is outergous, it will KILL VRS business that is for sure. NAD is working to submit to tell FCC keep the same old VRS system but improved and more stricter.
That’s all I know of right now 🙂
myVRS Relay Central,
Would you care to explain what will kill the VRS business if we want to have a full access to anyone’s VP? I believe that SIP (session initiation protocol) is the best solution for everybody.
myVRS Relay Central
FCC proposed that VRS shall be paid per customer instead per minute using tired level plans. This will not fit because we all deaf use VRS more than often.
For exm… If FCC passed say $50 per customer. Then VRS will only get $50 per customer PER month. So if I use that VRS 800 times, they will get $50… Not the per minute pay…
That what I mean. It will KILL VRS business out for sure.
FCC needs your feedback on the VRS industry dispute.
i was thinking if I happen got tornado strike here in St. Louis, my home damaged and my video phone damaged, will Sorenson or Z give me another free video phone in case if my video phone damaged????
which one is the best deal with ETF (early termination fee) ??? http://www.sorenson.com/assets/pdf/Legal/ntouch_Software_Service_and_Product_Agreement_VP.pdf or
just go straight to a lawyer in case if my video phone was damaged by hurricane or tornado or flood : http://www.lawyersandsettlements.com/case/cell_phone_early_termination_fees.html or this: http://www.consumeraffairs.com/cable_tv/dish_network.html it will be so unfair if I have to pay 2 ETF early termination on both cable and video phone which it costs me and other Deaf victims of tornado + or hurricane more DOUBLE!!!
Just thinking about it… oh well- I just wish the video phone company will give us 30 days of free trial before we go sign on 2 yrs contract… That’s suks that we have to pay both dish or cable + video phone ETF with mother nature strike us our home!!! eeeccch!!!!
myVRS Relay Central
I dont trust VRSCA, why? Its funded and supported by Sorenson.
Well, if you can recall old tty technology that uses baudot code. It was replaced with ascii code as modernized. ZVRS is already modernizing the VRS system with session initiation protocol technology over H.323 technology.