February 27, 2017

Draft Peering Proposal

Download the latest version of this draft in PDF format.


This page outlines a very basic proposal for creating a settlement free carrier neutral not-for-profit voice over IP (VoIP) peering exchange similar to the TORIX data exchange[1] to enable delivery of enhanced voice and video services between participating providers. This exchange would allow for the termination of calls from one ITSP to another ITSP directly using SIP signaling and as a result allow for the establishment of high definition voice, video, and messaging sessions between providers. The goal of this document is to be a starting point for discussion between interested parties and nothing within should be treated as final.

When connecting to disparate networks there are many challenges that can arise due to the nature of the incongruous elements involved.   This draft intends to cover some of those challenges, including:

  • Interoperability
  • Compatibility with signaling or call setup procedures
  • Security
  • Telephone number to provider lookups
  • Signaling, or call setup (establishment) and teardown (disconnect)
  • Registry services & Location services
  • Quality of Service metrics and concerns
  • Preventing unwelcome calls, known as Spam over Internet Telephony (SPIT)

Exchange Requirements


This service will run as a centralized VoIP peering point which will utilize an ENUM capable DNS infrastructure as well as a SIP redirect server to handle calls and redirect them to the appropriate peer network. When an ENUM query or INVITE is sent to the exchange, the peering exchange will query the peering database to see if there is a match. If a match is found the peering exchange will respond with the appropriate NAPTR record for ENUM queries or a SIP 302 “Temporarily Moved” message in the case of SIP based queries. If no match is found, the server will reply with a NXDOMAIN or SIP 404 Not Found error so that the requesting party can continue looking for a route for the call.

When a route is found for a call, the exchange will provide itself as the termination point for the call, ensuring that all inter-peer signaling is set via the exchange and creating a single routing point for exchange members to originate and terminate calls to.  We currently envision the SIP media path going directly between connected peers to reduce overhead on the exchange and remove potential latency from the media path.

To ensure a standard format between all parties in the exchange the E.164 format will be used.  For further details and links to the ITU-T recommendations please see http://en.wikipedia.org/wiki/E.164

Call Flow

Below is an example call flow of a call from Peer A to 4165551212:

Peering Security

The SIP and ENUM services will be protected by an IP access list – all peers must provide a list of IP addresses or IP address ranges that will be used to initiate queries.  This ensures that all requests come from known peer endpoints and protects the exchange from internet based SIP and DNS attacks and also protects the exchange from internet based unsolicited calls, or SPIT.

At a network level all SIP traffic will be routed via the exchange, ensuring that peers only need to configure one trusted set of IPs to receive calls from.  It is expected that media channels will be setup directly between peers, however, as a fall back the peering fabric will proxy media.

We are also investigating the possibility of using dedicated IP space for the exchange with a small point-to-point network block assigned to each peer for routing and interconnection purposes.


The service will have a HTTP RESTful API that authenticated peers can use to interact with the service as well as a standard web based portal for peers to execute management functions.  Both interfaces will allow a peer to add / remove / modify phone number inventory as well as access any other administrative functions as required.  The goal of the REST based API is to allow easy integration and automation with existing provider BSS/OSS systems and provisioning flows.

Number Validation

The exchange will employ two different methods to validate routes added by peers – one for LECs (Local Exchange Carrier) and one for ITSPs and enterprises.  When a LEC submits a number to the exchange, a query will be performed against the NPAC database[2] to verify the number is current routed to the carrier.  To ensure a number continues to be routed to a carrier after provisioning, this lookup will continue to be performed every 30-45 days.

For ITSPs and enterprise users, a more involved verification process is required.  For these users, the exchange will place a call from the PSTN to the submitted number from a pre-defined caller ID.  It is expected that exchange members will configure their termination equipment to recognize these calls and forward them back to a pre-defined number which belongs to the exchange.  Once this test call is established, the verification system will transmit a validation code via DTMF to ensure the legitimacy of the call.  Here is a diagram showing the call flow and DTMF flow for number validation:

While there are other proposed systems for doing number validation without relying upon NPAC, such as the VIPR internet draft standard[3] we believe that this call back method is the easiest for carriers to implement while providing the required level of validation.  As is the case with NPAC validated numbers, all numbers validated this way will be periodically checked at random intervals to ensure the target carrier is still the valid owner of a number.


All participants must support the G711u codec to ensure a basic level of interoperability between members of the exchange.  Peers are welcome to announce any other codec, however, support and negotiation of those codecs will be optional.

The requirement for a baseline codec steams from the fact that it is not possible to determine what media formats a peer may support in advance of call setup.  It is highly undesirable to have a call routed between providers using the exchange only to find out during call setup that a media session cannot be established.

It is also important to remember that some peers may advertise non-audio codec’s, such as video and instant messaging.  The exchange will place no limits on the type of media a peer can announce beyond the basic requirement to support G711u for any voice call termination.

The peering web interface will also allow peers to create a list of allowed codecs which they wish to accept and the exchange will endeavor on a best effort basis to strip any unwanted codecs from SIP invites.  This will be accomplished by using SIP manipulation rules on the session border controllers (SBCs) deployed for the peering fabic.

Quality Testing

All peers must have a milliwatt test number[4] and/or SIP URI that is publicly available to all peers 24/7/365.  This number will be periodically checked by the exchange as well to ensure connectivity, network functionality, and end-to-end call quality.  To achieve this automated testing a call will be placed, recorded and then automatically analyzed to ensure quality stays up to par throughout the network.  Test results will be available to authenticated peers via a web GUI.

Allowed Number Announcements

The “last carrier before termination” will be allowed to announce numbers into the exchange.  In the case of non-LEC entities participating in the exchange they must attest that they possess a letter or authorization (LOA) to route this number on a customer’s behalf.  For example, if ITSP “BobTel” buys a PRI from AliceTel that includes the DID 4165551212 then for the purposes of this exchange BobTel shall have the right to announce the number for purposes of peering.  This does not preclude AliceTel from also announcing the number, however, the announcement from BobTel shall take prescience.

For further discussion, please see section 4.2 – Legal requirements as there are no guidelines in place currently for a non-LEC to announce routes for PSTN numbers.


Number Security

One of the major drawbacks of other VoIP peering systems such as DuNDI[5] is that a full list of numbers that a provider services are passed from peer to peer. This system avoids that issue by ensuring that only the peering server itself, run by a trusted third party, knows which number belongs to which provider.

As was seen with the Canadian Do-Not-Call registry allowing anyone to receive a full list of valid phone numbers opens the system up to scammers, marketing by one peer to another’s customer base, and a host of other issues.

Given the number validation methods proposed above we do not foresee any major issues with numbers being incorrectly routed, however, if a peer does discover a number is incorrectly routed via the exchange the API as well as the web interface will support a function call that will allow peers to report issues with numbers.  When an issue is reported the number will stay in the peering database but will be flagged as “under review” and calls to that number will not be routed via the exchange until the flag is cleared. This review system will initially support the following types of reports:

Number routed to incorrect destination
Call quality issue
Codec / SIP negotiation issue
Number not in service
Transit / IP layer issue


The party responsible for the number will be emailed (or notified by some other method) and a resolution process will need be created to determine when a route can be re-added to the system.

[1] http://torix.ca/

[2] https://www.npac.com/

[3] https://tools.ietf.org/html/draft-petithuguenin-vipr-reload-usage-02

[4] https://en.wikipedia.org/wiki/Milliwatt_test

[5] http://www.voip-info.org/wiki/view/DUNDi