In a different thread I posed the above question (to which VRSEngineer replied), so as not to derail the previous thread I'm going to follow-up here...
What I was told is that if the VP-200 local number is ported to another provider the VP-200 reconfigures itself and switches into some sort of compatibility mode so that it can be used with another company’s gatekeeper. Supposedly, this is why one can’t then use any of the Sorenson services (call logs, phonebook, video center, etc -which makes sense if the phone isn’t registering with Sorenson for service). Anyway, I don’t have a clue if this is correct, but the person I have been speaking with says this is what a representative from another provider told him. In other words, the claim is that one can use VP-200 hardware with another provider after you port the number from Sorenson to that provider.
Basically, the background is that this person is the director of a very public place and they have a VP-200 for deaf/hoh use. 95% of the time it’s used only for outgoing calls, but every so often the VP-200 will receive a return call shortly after the deaf/hoh caller walked away from the VP-200. The calls either go unanswered or some other person (who usually doesn’t sign) sees the blinking light and figures out how to answer it. Thus, he would like to also have incoming calls also ring his smartphone so he can take the call and act upon it accordingly. To complicate matters further, it has to be a VP-200 (at least at this time, long story, but there are many factors that dictate using VP-200 hardware). 1Number would be a perfect solution, if it wasn’t for the fact that they want the outbound VP-200 caller id to be the current published phone number (the concept of each VP with its own 10-digit number is more stupidity, but that’s how it is so I’ll digress). Thus, my question is can the VP-200 be used in this manner with ZVRS?
Actually, the primary reason for dictating that it "must be a VP200" is mostly because some of the other provider's videomail systems tend to interfere with their participation in a 1Number setup. As the VP200 doesn't have P2P videomail when called from a non-VP200, this is ideal. It also doesn't hurt that Sorenson is 80% of the market, so it was easier just to say "only a VP200". In reality, any 10 digit number in iTRS _can_ be used with 1Number, it's just that having a phone like a Purple P3 setup as a 1Number member really prevents proper ringing (as Purple's gateway will try to answer the call and roll to videomail even though other phones might still need to ring). See the problem? There is actually nothing special that the VP200 does or must do to be that 1Number member. Anyone who said as much is mistaken (and I'd love to educate them properly).
The reality here, however, is that ZVRS wants you to port your number to our platform so that you use our phone by default. If our competitors want a 1Number like feature, they should build it to differentiate their service offering. While that is a primary motivator, there are technical details (as mentioned above) why it is problematic at best to integrate videophones not under the control of your own federated network.
As to the VP200 "compatibility mode", it is anything but.
You see, years ago, the smaller providers were concerned about Sorenson's tactic of modifying their videophones so that it couldn't dial-around to non-Sorenson VRS interpreters. When 80% of your userbase suddenly dries up when the market leader changes their firmware, you really become concerned that they shouldn't be able to do that.
So, enter the FCC and Neustar: while debating 10 digit dialing with the FCC, the providers (CSDVRS included) thought it was a wise idea to have some kind of device portability standard.
I, for one, was never keen on the idea, seeing as how it's a company's amortized capital asset, and phone numbers are perfectly portable - and the hearing world already had functional business models based around these two basic business tenants.
Anyway, Sorenson convinced the FCC that they would lead the charge of a "device portability protocol" that every VRS videophone would be required to implement. If you were the market leader, and you controlled the sourcecode and firmware to your videophone device, wouldn't you leverage that to ensure that no other videophones could enter the market?
Enter Sorenson's "device portability protocol": essentially, it is a unholy marriage of SIP's "REGISTER" and "INVITE" methods over the SIP signalling port with h323: URIs. That's pretty much it. You point the "broken" VP200 at a daemon listening on 5060 that handles SIP REGISTER requests, and you use that to track the IP address of the videophone in question. Whenever it attempts to place a call, it sends an "INVITE" with a sip: URI, and the gateway responds with a 302 redirect with an h323: URI (not a sip: URI) of what it really needs to directly connect to.
It didn't hurt that at the time Sorenson's competitors were using SIP for their new phones (while Sorenson was stuck using direct H.323 on theirs), and that by doing this they would effectively break all VRS phones from being SIP standard interoperable.
The problem here is that the IETF and ITU simply don't interwork like that. SIP and H.323 signalling are mutually exclusive, neither signalling protocol concerns itself with the other at that level. No common off-the-shelf (COTS) videophone is ever going to support Sorenson's new protocol. You will never convince Cisco (or anyone else for that matter0 to produce a videophone that can do the above simply to place point-to-point H.323 IP-to-IP calls. Simply put: it's wrong at an engineering level, and no other VRS provider was willing to go down that blind alley with Sorenson.
On the server side: you couldn't use Asterisk, or FreeSwitch, or Yate, or even SER/Kamailio/OpenSIPS to do that. In fact, there isn't even a mechanism in SER/Kamailio/OpenSIPS to allow anything but a sip: URI. If you try, it simply blows up and tells you "don't do that". To get it to work, you would need to seriously hack those opensource projects with the "protocol" above, and even then, no other videophone on the planet is going to support it.
So, to answer your question: No. There is no way to do what you're trying to do with tools that exist today. You would need to write new tools, and embrace Sorenson's protocol for the thing that it is: an attempt to lock the VRS industry into non-standard "deaf" videophone hardware that each VRS provider would need to develop themselves, and as a side effect destroy SIP interoperability of the same videophones.
I can't think of many other people who could have answered this question for you at this level of detail. What I've said above is pretty much all you are going to find about the matter.
Hope this helps.
Ok, point taken, it’s rather clear that this won’t come close to working!
It certainly would be nice to see the other VRS companies working to solve some of these real world problems!
)whatsoever with ZVRS (I'm not even a customer -YET).