[cisco-voip] Making a message appear anonymous/unknown via single inbox

Tue Jun 23 11:47:50 EDT 2015

in addition to the PSTN, they also want to have caller id blocked on calls
on-net to other Cisco phones.   So we have certain CSS on Cisco phones that
route calls through translation patterns to set the restricted CLID flag
before the call rings the other Cisco phones.    When we do this, the Cisco
phone called party does see 'Private' but if they don't answer the call and
it goes into voicemail then the voicemail message will still show the
calling party number.

On Tue, Jun 23, 2015 at 11:12 AM, Ryan Huff <ryanhuff at outlook.com> wrote:

> Justin,
>
> For clarification, you have a user(s) that makes an outbound call from
> call manager to the pstn (via a sip trunk to an itsp?) And some of them
> want to block their Caller ID or mask it to anon?
>
> Thanks,
>
> Ryan
>
>
> -------- Original Message --------
> From: Justin Steinberg <jsteinberg at gmail.com>
> Sent: Tuesday, June 23, 2015 11:06 AM
> To: Ted Nugent <tednugent73 at gmail.com>
> Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via
> single inbox
> CC: Cisco VoIPoE List <cisco-voip at puck.nether.net>
>
> Apologies for resurrecting an old thread here, but I was curious if there
> was fixed in more recent versions of Unity Connection.   I'm trying this
> with 10.5(2)su1 with SIP trunk between UCM and UCXN and having the problem
> where UCXN ignores the restriction settings configured on CUCM.
>
> I'm thinking maybe I could make a LUA script on the UCM sip trunk to UCXN,
> but looking for an easier solution.
>
> In my situation, I have certain callers that want to have their CLID
> blocked.   So it is based on the placing the call, not the phone that
> receives the call and I think this prevents me from using the two options
> discussed here earlier.
>
> Justin
>
> On Thu, Jan 24, 2013 at 4:28 PM, Ted Nugent <tednugent73 at gmail.com> wrote:
>
>> Thanks Chris
>> I like option 2 as well since they only have 24 ports as it stands. I'll
>> give it a shot and let you know how it turns out. Thanks again!
>>
>> On Thu, Jan 24, 2013 at 3:16 PM, Chris Ward (chrward) <chrward at cisco.com>
>> wrote:
>>
>>>  Hi Ted,
>>>
>>>
>>>
>>> Seems like you are hitting some known limitations. The settings in CUCM
>>> for restricting Calling Party Information don’t really eliminate it, it
>>> seems to just mark it as “Restricted” so the information remains and CUC
>>> seems hell-bent on finding calling party information.
>>>
>>>
>>>
>>> I did find 2 solutions for you, both of which use SIP:
>>>
>>>
>>>
>>> 1)      Setup an additional integration between CUCM and CUC that is
>>> meant only for this anonymous line. In the SIP trunk config, you have to
>>> uncheck the “Remote-Party-Id” under the “Call Routing Information”
>>> section and make sure “Calling Line ID Presentation” is set to
>>> Restricted under the “Outbound Calls” section. This will result in an
>>> “Unknown CallerID” message in Outlook.
>>>
>>> 2)      Setup a Loopback SIP trunk for calls to this specific Anonymous
>>> DID. You only need one SIP trunk to point to CUCMs own IP address, it acts
>>> as the outbound and inbound SIP trunk in this scenario. Under the “Outbound
>>> Calls” section, you would need define a Calling Party Transformation CSS
>>> that would have access to a transformation pattern that matches all Calling
>>> parties (remembering that only calls to this anonymous DID are affected)
>>> and mask the calling party with some obscure mask like 0000 or you can put
>>> a . at the end of the pattern you match and then drop all pre-dot if you
>>> want it blank. On the route pattern that points to this loopback SIP trunk,
>>> you would modify the called party so that once the call re-enters CUCM, it
>>> will be destined for the *7999 number (pulled from you example before) and
>>> continues through the normal process to be forwarded to voicemail.
>>>
>>>
>>>
>>> Neither solution is super-attractive, but both will work. I personally
>>> like #2 since it means you won’t have split up your CUC ports for a
>>> separate SIP integration. Let me know if you have any questions. It is
>>> probably a little more involved than the description I provided.
>>>
>>>
>>>
>>> +Chris
>>>
>>> Unity Connection TME
>>>
>>>
>>>
>>> *From:* Ted Nugent [mailto:tednugent73 at gmail.com]
>>> *Sent:* Wednesday, January 23, 2013 6:47 PM
>>>
>>> *To:* Chris Ward (chrward)
>>> *Cc:* Cisco VoIPoE List
>>> *Subject:* RE: [cisco-voip] Making a message appear anonymous/unknown
>>> via single inbox
>>>
>>>
>>>
>>> Will do thanks!
>>>
>>> On Jan 23, 2013 5:57 PM, "Chris Ward (chrward)" <chrward at cisco.com>
>>> wrote:
>>>
>>> Let me try it out in my lab tomorrow and get back to you. Remind me
>>> Friday morning if you don’t hear from me. J
>>>
>>>
>>>
>>> +Chris
>>>
>>> Unity Connection TME
>>>
>>>
>>>
>>> *From:* Ted Nugent [mailto:tednugent73 at gmail.com]
>>> *Sent:* Wednesday, January 23, 2013 5:09 PM
>>> *To:* Chris Ward (chrward)
>>> *Cc:* Cisco VoIPoE List
>>> *Subject:* Re: [cisco-voip] Making a message appear anonymous/unknown
>>> via single inbox
>>>
>>>
>>>
>>> Chris thanks for the reply, Yes it is stripping the info washing it
>>> through a TP, the phone I'm calling shows "Private". While using the TP
>>> method I'm basically using the Direct to voicemail  (*XXXX) VM profile
>>> which is CFWDAll to VM on a CTI-RP.
>>>
>>> For example 7999 is translated to *7999>*XXXX>CTIRP>CFwdALL VM
>>>
>>>
>>>
>>> However using the Huntpilot way, I have a HP going directly to HL/LG
>>> containing the VM Ports and a Directed routing rule going to the subscriber
>>> greeting. The HP is configured calling party name/line presention to
>>> restricted, same as i did with the TP
>>>
>>>
>>>
>>> As mention both have the same affect?
>>>
>>>
>>>
>>> This is an SCCP integration with CUC and we get the same results via
>>> external calls from an MGCP controlled PRI and SIP/SCCP phones
>>>
>>>
>>>
>>> Any thoughts?
>>>
>>> Thanks
>>>
>>> Ted
>>>
>>> On Wed, Jan 23, 2013 at 1:55 PM, Chris Ward (chrward) <chrward at cisco.com>
>>> wrote:
>>>
>>> Ted,
>>>
>>>
>>>
>>> Removing the calling party information from the call before it gets to
>>> CUC is definitely the way to do this. So, I think you are on the right
>>> track.
>>>
>>>
>>>
>>> Now, as to why it’s not working, there are a few things you could try.
>>> As a test, I would setup a translation pattern to strip the calling
>>> information and then forward it to your desk phone (making sure you don’t
>>> receive calling party information) so you can make sure that the
>>> translation pattern is doing what you think it is.
>>>
>>>
>>>
>>> Also, how are you routing this specific call to CUC? Are you using a
>>> dummy CTI RP and just setting it to CFA to CUC? And is the integration SCCP
>>> or SIP to CUC?
>>>
>>>
>>>
>>> +Chris
>>>
>>> Unity Connection TME
>>>
>>>
>>>
>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Ted Nugent
>>> *Sent:* Wednesday, January 23, 2013 12:37 PM
>>> *To:* Cisco VoIPoE List
>>> *Subject:* [cisco-voip] Making a message appear anonymous/unknown via
>>> single inbox
>>>
>>>
>>>
>>> CM 8.6, Unity Connection 8.6 and Exchange 2010
>>>
>>> Customer has an anonymous tip line that is using single inbox and would
>>> like the messages to showup as anonymous or unknown as opposed to showing
>>> the callers name and/or phone number.
>>>
>>> I've attempted to strip off the calling party info by washing it through
>>> a translation pattern and setting the calling party name/line presention to
>>> restricted and that doesn't work, I also attempted to setup a Hunt Pilot
>>> and setting the calling party presention to restricted as well and in both
>>> scenarios the email arrives displaying the callers info. Does anyone have
>>> any ideas to accomplish this? Either via CM, Unity Connection or Exchange?
>>>
>>> TIA Ted
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150623/67661eb4/attachment.html>