ITSP Technical Policy
(AKA VSP Technical Policy, skip to the bottom if you are after API details.)
Below is our proposed technical requirements for all ITSPs that want block access in our system;
- We plan to do INVITE probes to verify routes are still valid.
- We plan to do INVITE probes to verify only routes listed are accepted to help with database accuracy.
- ITSPs will only be able to list SIP routing information.
- ITSPs must ensure only numbers they currently route return a valid response, otherwise 404 or similar error should be returned.
- ITSPs that return valid responses for routes they no longer route could loose block access to our systems.
- ITSPs are responsible for removing routes from our systems they no longer route, this could for example be due to porting numbers away.
Definitions
ITSP
Our definition of an ITSP is any legal entity that has direct routing control over 10 or more e.164 numbers directly or indirectly allocated from or by the ITU. We currently allow any ITSP that currently controls 10 or more numbers to be given block access, however there is no checks presently made to ensure route data can be used. There is also a potential for ITSPs not to remove routes they no longer control and we are trying to build a policy and technical infrastructure to work around this perceived problem.
SIP
Session Initiated Protocol, RFC standards based protocol for transportation for routing and transportation of voice chat across the internet.
SIP Errors
Any ITSP unwilling to route calls on certain prefixes listed in our system should return 404 error or user not found.
Notes
What is the purpose of this policy?
This is a proactive solution to ensure better quality of results of data returned from our system, which should hopefully be in everyone's interest. We are planning to add requirements on ITSPs in the near future to require some potential technical changes to be implemented on their systems to enable automatic verification of route information.
Why SIP only?
The general consensus on voice traffic seems to indicate the majority is still H323, however no one is planning to roll out further deployments of H323, most are using a H323-SIP gateways to integrate old and new networks, so we think restricting ITSPs to SIP listings only would be best. We feel strongly about getting as many people to interconnect as possible and so for this reason promoting a RFC standard is in everyone's interest. Currently only SIP is standardised and inter-vendor testing is performed unlike H323 or IAX2 which isn't covered by RFC standards and is a complete crap shoot as to what products work with other products.
Automating Adding and Removing Routes for ITSPs
ITSPs are able to access our HTTP API interface, which allows people to highly automate additions and removals of phone numbers listed in our zone, in addition to the existing block number web interface. Please see ProviderAPI for more details on accessing and taking advantage of this feature.
Probe Details
We are planning to send a number of random INVITE probes against block information, and out of block information. Replies to the probes will be used to determine accuracy and consistency with our database.
All accounts can and should list both time zone information and best times to call, for businesses the best time might be out of hours to reduce problems with our probes causing phones to ring.
Provider API
We provide an API interface for VSPs/ITSPs to automatically update their routing information they store in our systems, please see ProviderAPI for more details on this.