*67 issue

[VOIPoTim]

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.

We tried that back in the early days with the 502s and it was a mess with people saying calls not completing randomly (since it didn't come in a proper format or completely stripped the ANI altogether). If we make any system changes, we can't account for what the device does to correct it.

Then if a firmware update is or a new device is used in the future, it could change how it sends it and all the fun starts over again with needing to redesign how our system takes the info from it and call accounting, etc.

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.

[Xponder1]

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.

We tried that back in the early days with the 502s and it was a mess with people saying calls not completing randomly (since it didn't come in a proper format or completely stripped the ANI altogether). If we make any system changes, we can't account for what the device does to correct it.

Then if a firmware update is or a new device is used in the future, it could change how it sends it and all the fun starts over again with needing to redesign how our system takes the info from it and call accounting, etc.

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.

Sounds like your well prepared for the future
Personally as long as it works I do not care how. My biggest concern in this case was that I had my mother who just signed up here visiting and she asked about this feature. I said it works like it does with AT&T and went to prove it and got the fast busy. Awkward... So I can tell her how to use it but I was concerned about others who are switching from pots as well.

I do hope that you all go ahead and change everyones setting to at least 3 seconds for the time out. I mean they adjusted it for me but what about everyone else? The default seems to be if you dial a *code you have 1.5 seconds (aprox) to dial or you get a fast busy. In comparison its like 7 seconds between tones to dial a number. You start dialing and look down to read the number its a fast busy if you used *67.

Does that make since? It's really hard to describe it.

[burris]

I really have to agree with the concept that Tim has.

In my eyes, VOIP is not POTS and to expect everything to be the same isn't going to happen.
POTS didn't have and still doesn't have the multitude of features that VOIP has.

It's certainly more difficult for the older crowd to understand this, and that's why it has always been difficult for me to convince them to join in. They would all like to save the money, but they aren't all ready for the transition. Most of my friends whose PCs I maintain for free, haven't deleted cache or temp files, some for years, and you want me to teach them how *67 works.

I am from the old generation, but spent my life in the electronics/computer/telephony field. It took me some time to 'train' my wife, who is very intelligent, to use her PC and get used to the quirks that VOIP has. To me, they're minor blips, but to a good part of the world, they're totally disconcerting...

[ptrowski]

In your eyes maybe, but almost every voip provider tried to show how much you can save over your current "phone bill" or calls it "phone service". Any provider should expect that as more and more people tighten their belts these days, young and old, that there are people who expect it to be the same as what they had because it says "phone service" in it.

That's why I have friends that ask about it and I tell them to keep what they know. They expect it to operate the same but just be cheaper, which is not the case.

[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.

[VOIPoBrandon]

PAP2T's behavior when dialing / utilizing internal *67 functionality:

John picks up phone, dials *67 [sound clicks and you get a new dial tone]

Now behind the scenes what happens to the SIP traffic / header data sent from PAP2T to our network:

INVITE sip:digits_dialed_with_out_*67 prefix (is stripped).
From: "Anonymous" <sip:restricted@x.y.z>

This has always been the behavior I've seen, but it wouldn't be the first time I have been wrong, if you guys have seen otherwise? Perhaps there is some kind of toggle / setting / method.

As for us requiring 10 digit dialing for *67 -- you can use 7,10,11 digit with *67, perhaps earlier this was a bug, however should not have any issues with it currently, please advise if otherwise!

Thanks!

[burris]

Just tried it...7 digits with no pause and all is well here..