Posts Tagged ‘acme’

Oracle SBC: prevent OPTIONS forwarding

Thursday, May 6th, 2021

A quick howto with illustrations of what you need to do to prevent OPTIONS requests from being forwarded by your OracleSBC/AcmePacket from outside to the core of your VoIP network.


Just specify correct SIP methods in the policy-attributes of local-policy and add one more policy-attribute for OPTIONS.


Specifying ‘next-hop’ as ‘0.0.0.0’ will make SBC to reply 404.

Specifying ‘next-hop’ as ‘*’ will make SBC to reply 403.


Without these settings your SBC will forward OPTIONS sent by session-agents in the Internet (e.g. VoIP providers with which you configured SIP trunking) to your next-hops, usually this is your core network. Finally, such OPTIONS requests are answered not by SBC, but by your inner VoIP servers. These replies are not just undesirable, they also contain User-Agent header of your core equipment and the Contact header indicates their IP address.


You may also skip the creation of a separate policy-attribute for OPTIONS method, just leaving the one for every other methods you need (e.g. INVITE, PRACK, REFER, UPDATE). In this case your SBC will reply “480 No Routes Found”:

AcmePacket: go on rejecting!

Thursday, May 19th, 2016

One more post about INVITE rejecting.

The task: reject malicious SIP traffic coming from some country to our number. All INVITEs contain a From: header with 12-digits number starting with 666. The may also contain a plus sign at the beginning or 810, or +810.

It is also important to set a ‘new-value’ parameter, containing a status code and SIP description (in form of “Code:Description”), as some (or maybe most) PBXses/softswitches/proxies go on sending INVITEs if we just do ‘action reject’. After answering from AcmePacket with something like “403 Forbidden” the remote side stops sending endless INVITEs to AcmePacket.

acme_reject_with_prefix

Part of sip-manipulation:

        header-rule
                name                                    dropHACKERS
                header-name                             From
                action                                  manipulate
                comparison-type                         pattern-rule
                msg-type                                any
                methods                                 INVITE
                match-value                             
                new-value                               
                element-rule
                        name                                    dropHACKERS1
                        parameter-name                          From
                        type                                    uri-phone-number-only
                        action                                  reject
                        match-val-type                          any
                        comparison-type                         pattern-rule
                        match-value                             666[0-9]{9}$
                        new-value                               403:Forbidden

This is how it looks like after rejecting malicious INVITE with “403 Forbidden”:
acme_reject_with_prefix2

acmepacket: import/export HMR

Tuesday, February 9th, 2016
conf t -> session-router -> sip-manipulation

Select some HMR and then do:

export %filename%

After that a %filename%.gz will appear under /code/imports/ directory. And you can download it via FTP/SFTP.

It is also possible to import sip-manipulation rules. Put your .gz file with the same structure to /code/imports/ , then go to conf t -> session-router -> sip-manipulation and do:

import %filename%.gz

AcmePacket: Reject calls from subscribers with hidden cell number

Thursday, February 26th, 2015

Depending on GSM operator the values in SIP headers may vary. In my case if a subscriber activated the ability to hide cell number, the ‘uri-user’ parameter in SIP-header ‘From’ contains not cell number but ‘anonymous’. I had a task to reject such calls.

There already were 2 header-rules – one doing storing of ‘To’ headers’ values with VoIP provider’s DIDs inside , and the second – manipulating the ‘From’ headers, according to the stored values.

If I added the 3rd header-rule (last in the list) trying to reject anonymous calls, it haven’t worked, so it was necessary to keep it on the top of header-rules. (the ‘move’ command doesn’t work for me, though I’ve read in one Oracle/AcmePacket HMR guide that it’s possible, maybe my firmware does not support it)

Here’s the rule itself:

header-rule
		name                           rejectAnonymous
		header-name                    From
		action                         manipulate
		comparison-type                case-insensitive
		msg-type                       request
		methods                        INVITE
		match-value                    
		new-value                      
		element-rule
			name                           rejAnonymous
			parameter-name                 From
			type                           uri-user
			action                         reject
			match-val-type                 any
			comparison-type                case-insensitive
			match-value                    Anonymous
			new-value                      

Have a look at these nice screenshots demonstrating the initial INVITE from anonymous:

invite_anonymous

… and rejecting this call by AcmePacket 4250 with ‘400 Bad Request’ response:

400_bad_request