Quote Originally Posted by VOIPoTim View Post
The reason we handle it server side and do not use the ATA is that since we don't get the raw data if the ATA manipulates it, it affects other features and can cause issues with either it not working properly and transmitting the CID or calls to fail if it's not sent out to a carrier with a correct ANI.

... snip ...

We try not to rely on the devices for anything unless we absolutely have to to keep things flexible and consistent in terms of delivering service vs it potentially having issues if we ever make any changes.
Tim,

You may recall that I completely support this philosophy. When you're trying to offer reliable service, the one thing you absolutely must have is control. You lose control when you depend on the device to pass a certain header, etc. One control element that's been strongly supported by NY Tel and myself are solid methods and procedures that document all proposed changes, investigations into potential conflicts, etc., and must be followed. Think Good Manufacturing Practices, but for a service--Good Service Practices? While it adds a lot of overhead, it gives a level of control and quality assurance to the final product. Regarding the recommendation I made, though, I want to be clear as to how it works, because it allows you to control/process the features server-side but gives the users the call progress tones they expect.

If you enter a dial sequence (could be *xx or any sequence of digits, any length) into that "referral services codes" box on the ATA, the only thing the PAP does with that is look for that sequence to be dialed and present a second dialtone when that sequence is matched. From the second dialtone, the ATA then matches the subsequent digits against the dial plan. Once it finds a match, it connects the "feature code" with the dial plan match as the dialed sequence to the VoIP server. Using *67 as the "referral service code" and US dialing as the dial plan that is matched, here are some examples of how it would work:
[LIST=1][*]User in western CT wants to respond to a Craigslist ad to NY-based phone# (212-555-1234) and wants to block CID:
  • User dials *67 and immediately hears the 2nd dialtone (higher pitch than standard dialtone).
  • User continues dialing, adding the 212-555-1234.
  • After pressing the '4', the PAP matches the 10-digit number to the dialplan, and sends the following string to the Voipo server: *672125551234.
  • Otherwise, the header info transmitted is the same as if the user had simply dialed 2125551234.
[*]User in Raleigh, NC area wants to respond to Craigslist ad in Durham, NC (same area code) - phone# is 919-313-4567, and user prefers 7-digit dialing.
    • User dials *67 and immediately hears the 2nd dialtone (higher pitch than standard dialtone).
    • User continues dialing, adding the 3134567.
    • After pressing the '7', the PAP matches the 7-digit number to the dialplan, and sends the following string to the Voipo server: *673134567.
    • Otherwise, the header info transmitted is the same as if the user had simply dialed 3134567.

Where it gets interesting is that the server then has to be able to interpret all of the dialing options (7, 10, and 11-digit) with *67, as well as knowing to ignore it for calls to, say, 911.

Regardless, the server is handling all of the signal manipulation as required to activate/deactivate such a feature code, because it's sent as part of the dial string. The only thing the ATA is doing is to play a new dialtone when that code is matched.