Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
Are the SIP options above still the only real way to achieve this on
the voice side of things? Helping someone with a anonymous mailbox
need on a CUC SCCP setup and hit same limitations with the Restricted
settings. Thinking of moving to SIP integration with LUA script
perhaps matching on this one mailbox extension.
Or mail server rule to change subject line, this isn't single inbox
but SMTP relay of the message. I'd like to handle this on the voice
side though as it is still possible to play back through the phone so
would need to the conservation settings locked down to, to not play
back those details of caller.
Thanks, Erick
On Wed, Jun 24, 2015 at 12:34 PM, Justin Steinberg <jsteinb...@gmail.com> wrote:
> i'm not sure if this is the right way to handle this, but I wrote a SIP
> normalization script to remove the info on the CUCM side before the call is
> sent over to CUC and in initial testing this seems to do the job.
>
> for the archives...
>
> M = {}
> function M.outbound_INVITE(msg)
> if msg:getHeader("Diversion")
> then
> local privacy = msg:getHeaderValueParameter("Remote-Party-ID", "privacy")
> if string.find(privacy, "full")
> then
> msg:applyNumberMask("Remote-Party-ID", "0")
> local rpid = msg:getHeader("Remote-Party-ID")
> local rpiduri = string.match(rpid, "(<.+>)")
> msg:modifyHeader("Remote-Party-ID", rpiduri)
> msg:applyNumberMask("P-Asserted-Identity", "0")
> local pai = msg:getHeader("P-Asserted-Identity")
> local paiuri = string.match(pai, "(<.+>)")
> msg:modifyHeader("P-Asserted-Identity", paiuri)
> end
> if string.find(privacy, "name")
> then
> local rpid = msg:getHeader("Remote-Party-ID")
> local rpiduri = string.match(rpid, "(<.+>)")
> msg:modifyHeader("Remote-Party-ID", rpiduri)
> local pai = msg:getHeader("P-Asserted-Identity")
> local paiuri = string.match(pai, "(<.+>)")
> msg:modifyHeader("P-Asserted-Identity", paiuri)
> end
> if string.find(privacy, "uri")
> then
> msg:applyNumberMask("Remote-Party-ID", "0")
> msg:applyNumberMask("P-Asserted-Identity", "0")
> end
> end
> end
> return M
>
> On Tue, Jun 23, 2015 at 11:47 AM, Justin Steinberg <jsteinb...@gmail.com>
> wrote:
>>
>> 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 <ryanh...@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 <jsteinb...@gmail.com>
>>> Sent: Tuesday, June 23, 2015 11:06 AM
>>> To: Ted Nugent <tednugen...@gmail.com>
>>> Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via
>>> single inbox
>>> CC: Cisco VoIPoE List <cisco-voip@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 <tednugen...@gmail.com>
>>> wrote:
>>>>
>>>&
Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
i'm not sure if this is the right way to handle this, but I wrote a SIP
normalization script to remove the info on the CUCM side before the call is
sent over to CUC and in initial testing this seems to do the job.
for the archives...
M = {}
function M.outbound_INVITE(msg)
if msg:getHeader(Diversion)
then
local privacy = msg:getHeaderValueParameter(Remote-Party-ID, privacy)
if string.find(privacy, full)
then
msg:applyNumberMask(Remote-Party-ID, 0)
local rpid = msg:getHeader(Remote-Party-ID)
local rpiduri = string.match(rpid, (.+))
msg:modifyHeader(Remote-Party-ID, rpiduri)
msg:applyNumberMask(P-Asserted-Identity, 0)
local pai = msg:getHeader(P-Asserted-Identity)
local paiuri = string.match(pai, (.+))
msg:modifyHeader(P-Asserted-Identity, paiuri)
end
if string.find(privacy, name)
then
local rpid = msg:getHeader(Remote-Party-ID)
local rpiduri = string.match(rpid, (.+))
msg:modifyHeader(Remote-Party-ID, rpiduri)
local pai = msg:getHeader(P-Asserted-Identity)
local paiuri = string.match(pai, (.+))
msg:modifyHeader(P-Asserted-Identity, paiuri)
end
if string.find(privacy, uri)
then
msg:applyNumberMask(Remote-Party-ID, 0)
msg:applyNumberMask(P-Asserted-Identity, 0)
end
end
end
return M
On Tue, Jun 23, 2015 at 11:47 AM, Justin Steinberg jsteinb...@gmail.com
wrote:
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 ryanh...@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 jsteinb...@gmail.com
Sent: Tuesday, June 23, 2015 11:06 AM
To: Ted Nugent tednugen...@gmail.com
Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via
single inbox
CC: Cisco VoIPoE List cisco-voip@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 tednugen...@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) chrw...@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
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
Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
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 jsteinb...@gmail.com Sent: Tuesday, June 23, 2015 11:06 AM To: Ted Nugent tednugen...@gmail.com Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox CC: Cisco VoIPoE List cisco-voip@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 tednugen...@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) chrw...@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 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:tednugen...@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) chrw...@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:tednugen...@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 (*) VM profile which is CFWDAll to VM on a CTI-RP. For example 7999 is translated to *7999*CTIRPCFwdALL 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) chrw...@cisco.com wrote: Ted
Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
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 tednugen...@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) chrw...@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 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:tednugen...@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) chrw...@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:tednugen...@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 (*) VM profile which is CFWDAll to VM on a CTI-RP. For example 7999 is translated to *7999*CTIRPCFwdALL 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) chrw...@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
Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox
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 ryanh...@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 jsteinb...@gmail.com Sent: Tuesday, June 23, 2015 11:06 AM To: Ted Nugent tednugen...@gmail.com Subject: Re: [cisco-voip] Making a message appear anonymous/unknown via single inbox CC: Cisco VoIPoE List cisco-voip@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 tednugen...@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) chrw...@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 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:tednugen...@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) chrw...@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:tednugen...@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 (*) VM profile which is CFWDAll to VM on a CTI-RP. For example 7999 is translated
