*67 issue

[Xponder1]

Tried to block my number with *67 and every time I dialed the *67 I would get a busy tone. Submitted a ticket about it at 4:26PM but never received anything more than the automatic response.
Ticket #LAU-313221

I have experimented and it works if I dial quickly and all at once *675555055 but any delay after *67 results with a busy tone.

Does anyone else have this issue?

Thanks,

[burris]

Tried to block my number with *67 and every time I dialed the *67 I would get a busy tone. Submitted a ticket about it at 4:26PM but never received anything more than the automatic response.
Ticket #LAU-313221

I have experimented and it works if I dial quickly and all at once *675555055 but any delay after *67 results with a busy tone.

Does anyone else have this issue?

Thanks,

I never tried it the way you described, but it does it as well.

Never noticed it because all my house phones behave the same as my cell phones. I simply dial the number...then hit talk and away it goes. I haven't dialed after getting a dial tone for years..

[Xponder1]

I never tried it the way you described, but it does it as well.

Never noticed it because all my house phones behave the same as my cell phones. I simply dial the number...then hit talk and away it goes. I haven't dialed after getting a dial tone for years..

Well I had this problem before and they changed something that fixed it in just a few minutes. Still have not heard anything on this ticket. Could someone in support please let me know if its supposed to work like it does on every other system *67, pause 2 sec, dial tone, dial or is it now supposed to be *67dial.

I find it odd because if I dial *67 and wait I hear a busy tone after about 1.5 seconds. In comparison if I act like I am calling someone and just dial 66 there is about 7 seconds for you to finish dialing the number before hearing the same busy tone.

[VOIPoTim]

It should be *67Number without waiting.

[Xponder1]

It should be *67Number without waiting.

Thanks for clearing that up. :)

[fisamo]

It's likely that the PAP recognizes *67 as a "feature code" that's been disabled. So if you dial it and pause, it matches something 'known' to be invalid. If you dial 66 and pause, that is not recognized until the PAP figures out that you're not going to dial any more digits and then sends what you've dialed (in case you had set it up as an outbound route).

[Xponder1]

It's likely that the PAP recognizes *67 as a "feature code" that's been disabled. So if you dial it and pause, it matches something 'known' to be invalid. If you dial 66 and pause, that is not recognized until the PAP figures out that you're not going to dial any more digits and then sends what you've dialed (in case you had set it up as an outbound route).

Support says that its all handled on their end and they do not use any features of the ATA. As Tim said above you dial *67number and it works. What they did fix was the time out. When I dialed *67 before in about 1.5 seconds it would give a fast busy. So if you dialed *67 and then looked down to read a number it was at a fast busy. They set the timeout to 3 seconds instead of that 1.5.

Tim, you need to remember that anyone coming from a pots line is going to expect it to go back to a dial tone after dialing *67. In fact when I had the 502 it worked that way. So any documentation on the feature should say that you dial it all at once.

I found this post http://www.dslreports.com/forum/r19162131-67-Call-Privacy-not-working. that I found of interest in this discussion. I understand what works for one company may not work for another but the last reply there seems to indicate there is a feature in the PAP2 that if put to use would allow it to work like most people are used to (while still working the current way as well) and still send it to VOIPo's servers all at once. Might at least be worth looking in to. Less confusing = more satisfied customers. Having it return to a dial tone to me confirms that you used the feature and would be what most folks would expect.

[burris]

This is what makes me believe that this may be run by the server.

Looking at my backup SPA2102 that mirrors the provisioning config on the PAP2T, I see the following...

The Vertical Service Activation Codes field although almost totally filled, don't have a *67 in that field...
The Supplementary Service Subscription fields all show the server activation fields set to yes...with the exception of Block CID Ser set to 'no'.
With this as it is, my *67 works as Tim indicated, and all the other services work as well..

As I indicated, I haven't used the wait for dial tone POTS routine for the 5 years I have had VOIP because I have always had cordless phones and was used to the cell phone procedure..

For me, I don't know how it could be any better.

[bill875]

I would like to see it work the way I was used to it on my old POTS line. If what Xponder1 says is true, I would like to see this functionality enabled on my PAP2T. Remember, people don't like change. It's a big enough change that they are switching from POTS to VOIP. Try to keep the features the same as they are on a typical POTS line and the new converts will be satisfied with the service.

[fisamo]

Check out the last post in the dslreports.com thread mentioned above (also linked here: http://www.dslreports.com/forum/remark,19182875 ). If you want a 2nd dial tone immediately after dialing *67 but have the ATA send the dial string (including the *67) to the server, this is the way to program the ATA.

Tim--you might consider reconfiguring your default provisioning file to include *67 and other appropriate * codes (those that require entering another number, such as call forwarding) into the field mentioned there.

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

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.

[LIST]
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:

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.


[LIST]
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 :p

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

[Xponder1]

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!

http://www.dslreports.com/forum/r19162131-67-Call-Privacy-not-working
Read the very last reply.;)

[VOIPoBrandon]

http://www.dslreports.com/forum/r19162131-67-Call-Privacy-not-working
Read the very last reply.;)

Read, and testing..... :).
________
Toyota wiki history (http://www.toyota-wiki.com/wiki/Toyota_Wiki)

[Xponder1]

Read, and testing..... :).

Testing is fun...

[VOIPoBrandon]

Testing is complete -- looks like it works as expected, passes SIP headers through un-altered. I come from the 'Cell Phone - Era' so the dial tone it clicks over to sounds a bit funny, however this dial tone frequency can be changed as well, however if this is expected behavior? I'd assume we could leave that alone.

Provisioning has been updated for everyone -- this should now be available to you and automatically update within the hour, if not -- please do a power-cycle on your PAP2T device and allow for 2-3 minutes to elapse while it pulls down its new provisioning settings.

Thanks guys, and apparently I stand corrected!

[fisamo]

Glad to see you implementing that. In POTS-land, the "second dialtone" is a stutter dialtone, similar to when you have voicemail waiting. If you want the PAP2T to emulate that (stutter tone instead of high-pitched dialtone), I think there's a "message waiting" tone entry you can copy the tone sequence from. To me, even though the default second dialtone is 'odd', it's fairly obvious that it is a second dialtone. OTOH, if your userbase would rather see the stutter tone, (I recommend against making the 2nd dialtone the same as the default dialtone), you can switch the tonescript as mentioned.

It's also worth noting that if you make a 3-way call, the second call you make (with the first party on hold) gets that same high-pitched dialtone. :)

[Xponder1]

Tested and it works :)
Dial tone is pretty high pitched like you said but it does the job.
Edit- Tested 7 digit as well as 10 digit. Both work.

[Russell]

Testing is complete -- looks like it works as expected, passes SIP headers through un-altered. I come from the 'Cell Phone - Era' so the dial tone it clicks over to sounds a bit funny, however this dial tone frequency can be changed as well, however if this is expected behavior? I'd assume we could leave that alone.

Provisioning has been updated for everyone -- this should now be available to you and automatically update within the hour, if not -- please do a power-cycle on your PAP2T device and allow for 2-3 minutes to elapse while it pulls down its new provisioning settings.

Thanks guys, and apparently I stand corrected!

Excellent!

My preference would be to make it similar to what's in POTS land. However, we can live with the "funny" sounding dial tone as the new behavior with the dial tone a la POTS is definitely preferable.