Posts Tagged ‘oracle’

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 ‘’ 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: 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:

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

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


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