<div dir="ltr">After some more testing we ultimately found the combination of changing labels on the calling device itself and changing the calling party transformation patterns to include spoofed numbers rather than restricting them entirely is our solution.<div><br></div><div>I assumed the name and numbers may have been dictated by CUC as Evgeny Isetov suggests, but that is not the case at least in this deployment running 12.5 and a SIP integration.</div><div><br></div><div>Removing the Remote Party Id from the integration SIP trunk also does not set the caller to unknown as the design guides suggest.</div><div><br></div><div>While setting  the calling party transformation patterns to restrict calling ID entirely works great in this environment for handling CLID during phone to phone calls, the restriction didn't apply to the CUC trunk. The full +E164 DN was being shown in the CUC Single inbox message.  Changing the calling number rather than restricting it entirely does work on the SIP integration trunk though.</div><div><br></div><div>As a nice bonus, after convinced the number in the inbox was dictated by CUCM rather than CUC, we also found relabeling the DN allowed us control the name display in Single Inbox as well.</div><div><br></div><div>Hope this helps someone.  Thanks Mark and Evengy for the suggestions regardless.</div><br class="gmail-Apple-interchange-newline"><br><table cellpadding="0" class="gmail-cf gmail-ix" style="border-collapse:collapse;table-layout:fixed;width:669px"></table><table cellpadding="0" class="gmail-cf gmail-gJ" style="border-collapse:collapse;margin-top:0px;width:auto;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:0.875rem;letter-spacing:0.2px;display:block"></table></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 26, 2019 at 4:03 PM Evgeny Izetov <<a href="mailto:eizetov@gmail.com">eizetov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The following kind of sort of works in my quick testing but it's a bit convoluted.</div><div><br></div><div>The logic that CUC uses is when a call comes in it tries to match the calling number to an extension in its database. If extension is found, then CUC uses the Display Name and the Extension fields on 'User Basics' page to construct the email for Single Inbox. So you could move the executive's real extension from the User Basics page to Alternate Extension in CUC and configure a fake extension and a generic Display Name on the User Basics page.</div><div><br></div><div>When the executive leaves a voicemail, CUC determines the target voicemail box using the first diversion header as usual (we are not messing with this part). Then CUC matches the executive's calling number to the alternate extension and uses the information on the 'User Basics' of the executive to construct the "From" information in the email.</div><div><br></div><div>The obvious caveat is the fake extension still has to be unique in CUC, you can't assign a generic main number to multiple voicemail boxes.</div><div><br></div><div>-E</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 26, 2019 at 2:51 PM Mark H. Turpin <<a href="mailto:mturpin@covene.com" target="_blank">mturpin@covene.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_5253153056448506087gmail-m_-8039701784590794281WordSection1">
<p class="MsoNormal">Ray,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I haven’t tested this, but a back of the napkin design might be:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Use a route next hop by calling party translation for your VM pilot.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If a call matches the extensions of executives, then it could goto a different route pattern, like *XXXX.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Then you can mask at the route pattern or RL/RG level.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> cisco-voip <<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>>
<b>On Behalf Of </b>Ray Maslanka<br>
<b>Sent:</b> Tuesday, March 26, 2019 10:38 AM<br>
<b>To:</b> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> [cisco-voip] Mask caller ID of some message senders in Unity Connection Single inbox<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">*** EXTERNAL EMAIL - DO NOT CLICK LINKS ***
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Gents, <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Running CUCM and a SIP integration to Unity Connection with Single Inbox to O365.  Normally if a CUC user is forwarded to a voice mailbox of another CUC user, the Identified User Messaging feature provides the name and number of the caller
 in the Outlook message.  The ask is now to have the numbers of a small subset of users masked in the Outlook message when they leave voice messages.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The use case is when executives, support staff, call center agents, etc. want to make calls and leave voicemail but avoid providing direct call back information.  Caller ID is masked currently from phone to phone using Calling Party Transformation
 Patterns in CUCM, but this doesn't mask caller information when the call reaches Unity Connection.  <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The Remote Party Id on the integration SIP trunk can be removed to make all callers over that trunk unknown, but we only want a small subset of users to be masked.  Alternatively, the Identified User Messaging feature can be turned off
 to prevent name and number in the message, but that is system wide.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Does anyone have a decent solution to mask the caller ID of a relatively few users in Unity Connection Single Inbox messages?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>

_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</blockquote></div>
</blockquote></div>