Block incoming anonymous calls

pjcatranis_87 · ‎02-13-2012

Hi,

I'm trying to block incoming blocked/unknown/anonymous callers over a sip trunk? I've creaed a translation rule and applied it:

voice translation-rule 5000

rule 1 reject /^$/

voice translation-profile CallBlock5000

translate calling 5000

dial-peer voice xxxx voip

call-block translation-profile incoming CallBlock5000

call-block disconnect-cause incoming invalid-number

To try it out, I'm dialing (from a normal/off network cell and landline) *67 and then the number. This does not work; only if I match the exact number I'm calling from, then it does get blocked.

When I show sip calls during the *67 call I see the calling number is blank.

Calling Number :

When I show sip calls during the regular call, I see the proper Calling Number.

As I understand it, with Call Manager and phones running SCCP, I cannot enable/use anonymous call blocking; so I do have to enforce the call blocking policy at this gateway device (UC520).

I'm very new to Cisco voice, so sorry I'f I'm missing something obvious. Thanks in advance!

Daniele Giordano · ‎02-14-2012

What is the anonymization method used by your isp provider?

In SIP you can set CLIR in various ways:

- set the display info of from header to anonymous but not the user part;

- set the user part of from to anonymous but not domain;

- use the form anonymous@anonymous.invalid in the from header;

- set the privacy option in Remote Party ID;

- set the option Privacy in P-Asserter-ID;

- remove identity omitting the number;

etc.

Can you add the output of debug ccsip messages?

In this way we can find what methods are used.

In the meantime you can test this rule:

rule 1 reject /^.*/ type reserved

Regards.

pjcatranis_87 · ‎02-14-2012

Thanks, I tried the rule--still private gets through.

*Feb 14 21:52:37.457: //394/0B18CF2B8382/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 207.2.123.180:5060;branch=z9hG4bK71b5401f596084541bb0894ae16bbbc8

From: <6103506982>;tag=3538245046-512161

To: <>3023522325@aa.aa.aa.aa(CUBE external IP)>

Date: Tue, 14 Feb 2012 21:52:37 GMT

Call-ID: 461523831-3538245046-512158@msc7.mydomain.com

CSeq: 1 INVITE

Allow-Events: telephone-event

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

*Feb 14 21:52:37.457: //395/0B18CF2B8382/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:3023522325@xx.xx.xx.xx(UCMBE IP):5060 SIP/2.0

Via: SIP/2.0/UDP yy.yy.yy.yy(UC500/CUBE IP)>;:5060;branch=z9hG4bK2B4F4E

Remote-Party-ID: <>6103506982@yy.yy.yy.yy(UC500/CUBE IP)>;party=calling;screen=no;privacy=full

From: "anonymous" ;tag=4C78DEC-1E4B

To: <>3023522325@xx.xx.xx.xx>

Date: Tue, 14 Feb 2012 21:52:37 GMT

Call-ID: B1B3FCA-568D11E1-83889F30-EB9D8BD5@192.168.20.5

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 0186175275-1452085729-2206375728-3952970709

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Timestamp: 1329256357

Contact:

Expires: 180

Allow-Events: telephone-event

Max-Forwards: 69

Session-Expires: 3600;refresher=uac

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 246

v=0

o=CiscoSystemsSIP-GW-UserAgent 2063 472 IN IP4 yy.yy.yy.yy(UC500/CUBE IP)

s=SIP Call

c=IN IP4 yy.yy.yy.yy(UC500/CUBE IP)

t=0 0

m=audio 19566 RTP/AVP 0 101

c=IN IP4 192.168.20.5

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:20

*Feb 14 21:52:37.465: //395/0B18CF2B8382/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 100 Trying

Date: Tue, 14 Feb 2012 21:50:47 GMT

From: "anonymous" ;tag=4C78DEC-1E4B

Allow-Events: presence

Content-Length: 0

To: <>3023522325@xx.xx.xx.xx(UCMBE IP)>

Call-ID: B1B3FCA-568D11E1-83889F30-EB9D8BD5@192.168.20.5

Via: SIP/2.0/UDP yy.yy.yy.yy(UC500/CUBE IP):5060;branch=z9hG4bK2B4F4E

CSeq: 101 INVITE

*Feb 14 21:52:37.469: //395/0B18CF2B8382/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 180 Ringing

Date: Tue, 14 Feb 2012 21:50:47 GMT

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

From: "anonymous" ;tag=4C78DEC-1E4B

pjcatranis_87 · ‎02-16-2012

So, I tried tried the rule /^.*/, and adding a rule to the sip profile to convert the anonymous@ip to anonymous@anonymou.invalid, but the calls still get through. Any comment on the debug output? Thanks

paolo bevilacqua · ‎02-16-2012

Try a SIP profile, eliminating Remote-party-ID altogether.

rpagaduan · ‎03-09-2012

Try the following:

voice translation-rule 5000

rule 1 reject /^$/

rule 2 reject /[^0-9]/

nyciscotech · ‎03-14-2012

Have the same request and followed along but also not having success with getting it to work.

rule 1 reject /^$/ - Does not seem to match the unknown/private/anonymous calls

rule 2 reject /[^0-9]/ - Matches, however once the rule is put in any/all calls are rejected/blocked

Also, if a rule is added with a specific number, then that number will match and the call is rejected.

Thanks for any additional info!

rpagaduan · ‎03-14-2012

The command "rule 2 reject /[^0-9]/" matches any CID that contains anything but a number. A similar command would be "rule 2 reject /^[^0-9]/", which means match CID that does not begin with a number. Try that.

For SIP calls, when a call is passed with no calling party number, the calling party number is set to anonymous, which does not match the "rule 1 reject /^$/" command because the calling party number is not null. Check the debugs to see exactly what the calling party number is.

nyciscotech · ‎03-15-2012

Thanks for the super quick response.

rule 2 reject /^[^0-9]/ also appears to match any/all calls, but looking at the SIP debugs, it would seem that's happening because the SIP provider is sending inbound calls with a + mark before the number.

Here's an example of a non private call:

From: "CID-Name" <>

An example of a private/anonymous call (*67 before dialing):

From: "Anonymous"

Any possible suggestions to work around that? Thanks!

rpagaduan · ‎03-15-2012

Try "rule 2 reject /[^0-9]$/".

Here is a good link to read up on regarding translation rules:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080325e8e.shtml

nyciscotech · ‎03-15-2012

That worked, thanks!!

rpagaduan · ‎03-09-2012

Also, try modifying the disconnect cause to call-reject if the above doesn't work.