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

[Ted Nugent]

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****
>
>  ****
>
>  ****
>
>  ****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130124/a19bf8a0/attachment.html>