Filtering
Under Filtering, you can filter out SIP requests based on various criteria. Filter based on sender IP address (Proxy rules), sending and receiving SIP user (Header filter rules), or content type (Content types). You can also select to filter out status messages sent to the client during a SIP negotiation.
Proxy rules
Here, you set all the rules for SIP requests from different networks. Requests that do not match any rule are handled according to the Default policy for requests below.
From network
The network name that the SIP request originates from. You can select between the networks defined on the Networks and Computers page under Network.
Action
Under Action, you select what to do with a SIP request from the selected network. The choices are Process all, which handles all requests regardless of destination, Local only, which only handles requests to Locally handled domains (entered on the Registrar and Users page), and Reject all, which doesn't handle any requests at all.
Delete row
If you select this box, the row is deleted when you click on Add new rows or Save.
Add new rows
Enter the number of new rows you want to add to the table, and then click on Add new rows.
Default policy for requests
Select what to do with SIP requests that do not match any of the Proxy rules above. The choices are Process all, which handles all requests regardless of destination, Local only, which only handles requests to Locally handled domains (entered on the Registrar and Users page), and Reject all, which doesn't handle any requests at all.
Header filter rules
Header filter rules lets you filter out SIP requests based on the contents of the To and From headers. This could be useful if you want to prevent groups of users to make calls through the firewall.
Wild cards can be used: * for any number (zero or more) characters, ? for exactly one character.
Requests that do not match any rule are handled according to the Default header filter policy set below the table.
No.
The No. field determines the order of the rules. Rules are used in the order in which they are displayed in the table; rule number 1 is first. To change order for a rule, enter the new number in the field and press Save.
From header
Enter an expression which the From header should match. If this rule should match all From headers, enter *.
To header
Enter an expression which the To header should match. If this rule should match all To headers, enter *.
Action
Select if this rule should Allow or Reject the matching requests. Rejected requests get a code 403 packet in reply.
Delete row
If you select this box, the row is deleted when you click on Add new rows or Save.
Add new rows
Enter the number of new rows you want to add to the table, and then click on Add new rows.
Default header filter policy
Select what to do with SIP requests that do not match any of the Header filter rules above. The choices are Allow and Reject. Rejected requests get a code 403 packet in reply.
Content types
The SIP packets present information in different ways, using content types (MIME types). Enter here which types the SIP proxy should accept. The most common MIME types are predefined and you only have to activate them.
The content types application/sdp (used for SIP requests), application/xpidf+xml (used for Presence) and text/x-msmsgsinvite (used by Messenger) are always accepted - you don't have to enter them into the table. You can find a complete list of MIME types at ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types/.
Content type
Enter the content type (only one in each row). The format is category/type, e.g. text/plain. You can also allow all content types by entering */* in a row and allow it.
Allow
Select if the firewall should allow (On) or reject (Off) the content type in SIP media streams.
Delete row
If you select this box, the row is deleted when you click on Add new rows or Save.
Add new rows
Enter the number of new rows you want to add to the table, and then click on Add new rows.
Class 1xx messages processing
Sometimes during negotiation for a connection, status messages about this process will be sent. Class 1xx messages inform about the progress of a connection attempt. The messages could for example tell you that the request was forwarded or that it was queued due to the recipient being temporarily busy.
Here you select whether to forward these messages to the client or keep them in the firewall.
The choices are All, which forwards all class 1xx messages to the client, Higher than before, which only forwards messages which state that the connection progress has come further, and No, which keeps all class 1xx messages in the firewall.
Save
Saves the Filtering configuration to the preliminary configuration.
Undo
Reverts all of the above fields to their previous configuration.