*67 issue

[fisamo]

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.

[VOIPoTim]

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.

If that's how the PAP2s handle it, we can look into it, but with the 502s they literally change the headers and strip the Caller ID information out before sending to server.

I've just been basically against relying on anything at all equipment wise since the Grandstream devices changed constantly with firmware updates, etc. Relying on GS cost me a ton of money in terms of replacing them, so I'm very hesitant to ever depend on a hardware manufacturer for anything now.

[Xponder1]

In a very lengthy way he is saying what I was trying to say

So if it were used it could be used with at least a few of the *codes

[fisamo]

Tim,

The PAP2 offers two options - you can activate the call privacy "vertical service code" (which you should also make sure is set to 'no' in your provision files), which will likely behave as the 502 did, stripping the information from the header. The referral service code box is designed to pass codes to be handled server-side.

Again, I completely agree with the philosophy of not trusting the devices--it potentially opens up a can of worms that you have no real control over. In this case, however, since the effect is essentially on the user interface (how the call progress tones are presented to the user) and not on any back-end issues (such as header content), you should be able to implement such a change. You will need to remember, though, that you would likely get dial commands such as *67 preceding a 7-digit number, and you'll need to make sure your servers can interpret that correctly. (As I recall, you require 10-digit dialing with *67 right now.) So, making this change wouldn't be entirely seamless, but IMO it's worth doing.