When we do a *67 it makes the Call Private. Is there a feature that will Permanently make a voice user Private when placing an outbound call?
Kurt,
Do you want all outbound calls to have Caller-ID blocked or only calls from a particular user blocked. If it is all outgoing calls and your provider allows it you could do something along the lines of the following:
conf t
voice trunk T02 type sip
match dnis "NXX-NXX-XXXX" substitute "*67NXX-NXX-XXXX"
exit
exit
wr mem
It will have the affect of adding *67 to all outbound calls.
Otherwise you may need to configure an HMR Ruleset that will add the *67 based on the matching rules you need.
John Wable
We have tried to do the match dnis Substitution but that did not work. The customer could not call out at all. i have attached a copy of our configuration for the customer. You will see that the Match DNIS is not there and that is b/c I have removed it so the customer can call out.
Kurt,
It sounds like your upstream SIP provider is not providing that service and they are denying the calls which include the extra SPRE codes. If they are blocking the SPRE codes I do not know of a way you can block the caller ID. You may check with the provider and see if they offer that service. Or maybe someone else here can think of a different method. My thought on the HMR Ruleset would not help since all it would do is re-write the to field and add the *67 as well, but it would allow you to control individual users with the setting instead of the all users.
John Wable
Kurt,
Just thought of one possibility. If you upstream provider does not require authenication you may just be able to do the following for each of the users:
caller-id-override external-name Anonymous
caller-id-override external-number 555-5555
Kurt,
Thanks for posting! If your SIP provider supports sending *67 in the dial string, then you may be able to use our Source and ANI Based Routing (SABR) feature along with two separate SIP trunks to have a specified subset of your voice users send *67 for all calls. Below is an example of just voice user 1002 using *67 for all calls. Voice user 1001 uses the SIP trunk without any DNIS substitution.
voice ani-list normal_users
ani 1001
!
voice ani-list private_users
ani 1002
!
voice trunk T01 type sip
sip-server primary x.x.x.x
!
voice trunk T02 type sip
sip-server primary x.x.x.x
match dnis $ substitute *67$
!
voice grouped-trunk SIP
trunk T01
accept $ cost 0
permit list normal_users
!
voice grouped-trunk SIP2
trunk T02
accept $ cost 0
permit list private_users
!
voice user 1001
connect fxs 0/1
!
voice user 1002
connect fxs 0/2
This configuration can be done in many ways, including just denying the private users from the main trunk and allowing all other ANI. I wrote the configuration to be as clear as possible. Also, the ANI lists at the top can be extended to include however many voice users apply to your scenario.
Thanks!
David
This is kind of tricky as it involves ensuring that your SIP provider handles privacy correctly. It sounds like they don't like the star code but they may honor a privacy header.
Try the following:
In the Voice - System Parameters tab, set SPRE handling mode to "Local".
In the Voice - VoIP settings - SIP settings tab, check the "Privacy Enabled" box. You may also need "Session", Header" or both under "Restricted Privacy Levels".
Insert the *67 DNIS match. Note that the instructions given above assume calls normalized to 10 digits. Depending on your dialplan, you may also/instead need something like:
match dnis "1-NXX-NXX-XXXX" substitute "*67-1-NXX-NXX-XXXX"
match dnis "NXX-XXXX" substitute "*67-NXX-XXXX"
jayh thanks for your advice. Setting the Privacy Enabled allowed us to block the Caller ID and Number for our customer.
Kurttsc,
I went ahead and flagged this post as "Assumed Answered". If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons. This will make them visible and help other members of the community find solutions more easily. If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.
Thanks!
David