diehardbiker
Active Member
- Joined
- Mar 22, 2004
- Messages
- 16,190
- Reaction score
- 16
Sounds good.
Sorenson problem
- Thread starter dkf747
- Start date
VRSEngineer
Member
- Joined
- Mar 29, 2010
- Messages
- 95
- Reaction score
- 0
I'll chime in and support the folks that suggest the person calling has a phone number that isn't in iTRS.
When a "server routed" VP calls another VP, it first goes through the calling VP's VRS provider's call routing platform. All providers do things differently, but the usual process is to look up the calling party first against their local database of their customer phone numbers, and then against the iTRS database, to see if either the calling party or the called party phone numbers aren't deaf VPs. If either of them seem to be hearing calls, the call is usually routed to an interpreter to bridge ASL to a voice call.
When a "direct" VP call is placed (like on a VP200), it makes a request to the VRS provider's platform to find the H.323 IP of the called party by doing a the VRS provider's customer database and/or an iTRS lookup, and then makes a direct point-to-point H.323 call.
The NVP uses SIP for calls, but is also capable of taking H.323 calls directly.
iTRS usually responds in a timely manner. Sometimes it takes a bit for Neustar's modified SIP-IX servers in Chicago and Charlotte to respond. All VRS providers peer with Neustar over IPSEC VPNs to both sites. This delay can exceed the DNS timeout threshold of many resolver libraries, which may manifest as either a delayed or as a misrouted call.
It's not that DNS is somehow "corrupted", so much as the queries may be "delayed".
It also has nothing to do with DNS resolution on your home networks behind your ISP routers.
These iTRS lookups only occur within VRS provider routing servers, as only they have direct access to the iTRS database servers over VPN.
Given the high availability of the Neustar iTRS database service, it is more likely that a VRS provider's servers are having problems doing the DNS queries than it is that the iTRS database servers are having a problem responding.
If you find that your phone number and the person calling you (or that you are calling) definitely _are_ in iTRS, it is likely one of the above things.
Disclaimer: I've been out of the VRS industry now for a couple of years, but I've been keeping up with things like the SIPForum VRS working group mailing list to know what is coming.
When a "server routed" VP calls another VP, it first goes through the calling VP's VRS provider's call routing platform. All providers do things differently, but the usual process is to look up the calling party first against their local database of their customer phone numbers, and then against the iTRS database, to see if either the calling party or the called party phone numbers aren't deaf VPs. If either of them seem to be hearing calls, the call is usually routed to an interpreter to bridge ASL to a voice call.
When a "direct" VP call is placed (like on a VP200), it makes a request to the VRS provider's platform to find the H.323 IP of the called party by doing a the VRS provider's customer database and/or an iTRS lookup, and then makes a direct point-to-point H.323 call.
The NVP uses SIP for calls, but is also capable of taking H.323 calls directly.
iTRS usually responds in a timely manner. Sometimes it takes a bit for Neustar's modified SIP-IX servers in Chicago and Charlotte to respond. All VRS providers peer with Neustar over IPSEC VPNs to both sites. This delay can exceed the DNS timeout threshold of many resolver libraries, which may manifest as either a delayed or as a misrouted call.
It's not that DNS is somehow "corrupted", so much as the queries may be "delayed".
It also has nothing to do with DNS resolution on your home networks behind your ISP routers.
These iTRS lookups only occur within VRS provider routing servers, as only they have direct access to the iTRS database servers over VPN.
Given the high availability of the Neustar iTRS database service, it is more likely that a VRS provider's servers are having problems doing the DNS queries than it is that the iTRS database servers are having a problem responding.
If you find that your phone number and the person calling you (or that you are calling) definitely _are_ in iTRS, it is likely one of the above things.
Disclaimer: I've been out of the VRS industry now for a couple of years, but I've been keeping up with things like the SIPForum VRS working group mailing list to know what is coming.