SIP debugging

This chapter includes some information to help with debugging SIP configurations.

SIP debug log format

Assuming that diagnose debug console timestamp is enabled then the following shows the debug that is generated for an INVITE if diag debug appl sip -1 is enabled:

2010-01-04 21:39:59 sip port 26 locate session for 192.168.2.134:5061 -> 172.16.67.192:5060

2010-01-04 21:39:59 sip sess 0x979df38 found for 192.168.2.134:5061 -> 172.16.67.192:5060

2010-01-04 21:39:59 sip port 26 192.168.2.134:5061 -> 172.16.67.192:5060

2010-01-04 21:39:59 sip port 26 read [(0,515)

(494e56495445207369703a73657276696365403139322e3136382e322e3130303a35303630205349502f322e300d0a5669613a2

05349502f322e302f554450203132372e302e312e313a353036313b6272616e63683d7a39684734624b2d363832372d3632302d3

00d0a46726f6d3a2073697070203c7369703a73697070403132372e302e312e313a353036313e3b7461673d36383237534950705

4616730303632300d0a546f3a20737574203c7369703a73657276696365403139322e3136382e322e3130303a353036303e0d0a4 3616c6c2d49443a203632302d36383237403132372e302e312e310d0a435365713a203120494e564954450d0a436f6e746163743 a207369703a73697070403132372e302e312e313a353036310d0a4d61782d466f7277617264733a2037300d0a5375626a6563743 a20506572666f726d616e636520546573740d0a436f6e74656e742d547970653a206170706c69636174696f6e2f7364700d0a436 f6e74656e742d4c656e6774683a20203132390d0a0d0a763d300d0a6f3d757365723120353336353537363520323335333638373 6333720494e20495034203132372e302e312e310d0a733d2d0d0a633d494e20495034203132372e302e312e310d0a743d3020300 d0a6d3d617564696f2036303031205254502f41565020300d0a613d7274706d61703a302050434d552f383030300d0a)(INVITE sip:service@192.168.2.100:5060 SIP/2.0..Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-6827-620-0..From: sipp

%lt;sip:sipp@127.0.1.1:5061>;tag=6827SIPpTag00620..To: sut

%lt;sip:service@192.168.2.100:5060>..Call-ID: 620-6827@127.0.1.1..CSeq: 1

INVITE..Contact: sip:sipp@127.0.1.1:5061..Max-Forwards: 70..Subject: Performance

Test..Content-Type: application/sdp..Content-Length: 129….v=0..o=user1 53655765 2353687637 IN IP4 127.0.1.1..s=-..c=IN IP4 127.0.1.1..t=0 0..m=audio 6001 RTP/AVP

0..a=rtpmap:0 PCMU/8000..)]

2010-01-04 21:39:59 sip port 26 len 515

2010-01-04 21:39:59 sip port 26 INVITE ‘192.168.2.100:5060’ addr 192.168.2.100:5060

2010-01-04 21:39:59 sip port 26 CSeq: 1 INVITE

2010-01-04 21:39:59 sip port 26 Via: UDP 127.0.1.1:5061 len 14 received 0 rport 0 0 branch ‘z9hG4bK6827-620-0’

2010-01-04 21:39:59 sip port 26 From: ‘sipp ;tag=6827SIPpTag00620’ URI ‘sip:sipp@127.0.1.1:5061’ tag ‘6827SIPpTag00620’

2010-01-04 21:39:59 sip port 26 To: ‘sut ‘ URI ‘sip:service@192.168.2.100:5060’ tag ”

2010-01-04 21:39:59 sip port 26 Call-ID: ‘620-6827@127.0.1.1’

2010-01-04 21:39:59 sip port 26 Contact: ‘127.0.1.1:5061’ addr 127.0.1.1:5061 expires 0

2010-01-04 21:39:59 sip port 26 Content-Length: 129 len 3

2010-01-04 21:39:59 sip port 26 sdp o=127.0.1.1 len=9

2010-01-04 21:39:59 sip port 26 sdp c=127.0.1.1 len=9

2010-01-04 21:39:59 sip port 26 sdp m=6001 len=4

2010-01-04 21:39:59 sip port 26 find call 0 ‘620-6827@127.0.1.1’

2010-01-04 21:39:59 sip port 26 not found

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 open (collision (nil))

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 open txn 0x979f7f8 INVITE dir 0

2010-01-04 21:39:59 sip port 26 sdp i: 127.0.1.1:6001

2010-01-04 21:39:59 sip port 26 policy id 1 is_client_vs_policy 1 policy_dir_rev 0

2010-01-04 21:39:59 sip port 26 policy 1 not RTP policy

2010-01-04 21:39:59 sip port 26 learn sdp from stream address

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 sdp 172.16.67.198:43722

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 txn 0x979f7f8 127.0.1.1:5061 find new address and port

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 txn 0x979f7f8 127.0.1.1:5061 find new address and port

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 txn 0x979f7f8 127.0.1.1:5061 find new address and port

2010-01-04 21:39:59 sip port 30 write 192.168.2.134:5061 -> 172.16.67.192:5060 (13,539) 2010-01-04 21:39:59 sip port 30 write [(13,539)

(494e56495445207369703a73657276696365403137322e31362e36372e3139323a35303630205349502f322e300d0a5669613a2 05349502f322e302f554450203137322e31362e36372e3139383a35323036353b6272616e63683d7a39684734624b2d363832372 d3632302d300d0a46726f6d3a2073697070203c7369703a73697070403137322e31362e36372e3139383a34333732343e3b74616 73d363832375349507054616730303632300d0a546f3a20737574203c7369703a73657276696365403137322e31362e36372e313

9323a353036303e0d0a43616c6c2d49443a203632302d36383237403132372e302e312e310d0a435365713a203120494e5649544

50d0a436f6e746163743a207369703a73697070403137322e31362e36372e3139383a34333732350d0a4d61782d466f727761726 4733a2037300d0a5375626a6563743a20506572666f726d616e636520546573740d0a436f6e74656e742d547970653a206170706 c69636174696f6e2f7364700d0a436f6e74656e742d4c656e6774683a20203133380d0a0d0a763d300d0a6f3d757365723120353 3363535373635203233353336383736333720494e20495034203137322e31362e36372e3139380d0a733d2d0d0a633d494e20495

034203137322e31362e36372e3139380d0a743d3020300d0a6d3d617564696f203433373232205254502f41565020300d0a613d7 274706d61703a302050434d552f383030300d0a)(INVITE sip:service@172.16.67.192:5060 SIP/2.0..Via: SIP/2.0/UDP 172.16.67.198:52065;branch=z9hG4bK-6827-620-0..From: sipp ;tag=6827SIPpTag00620..To: sut ..Call-ID: 6206827@127.0.1.1..CSeq: 1 INVITE..Contact: sip:sipp@172.16.67.198:43725..Max-Forwards: 70..Subject:

Performance Test..Content-Type: application/sdp..Content-Length: 138….v=0..o=user1 53655765 2353687637 IN IP4 172.16.67.198..s=-..c=IN IP4 172.16.67.198..t=0 0..m=audio 43722 RTP/AVP 0..a=rtpmap:0

PCMU/8000..)]

SIP-proxy filter per VDOM

You can use the diagnose sys sip-proxy xxx command in a VDOM to get info about how SIP is operating in each VDOM.

SIP-proxy filter command

Use the diagnose system sip-proxy filter to filter diagnose information for the SIP ALG. The following filters are available:

diag sys sip-proxy filter vd diag sys sip-proxy filter dst-addr4 diag sys sip-proxy filter dst-addr6 diag sys sip-proxy filter dst-port diag sys sip-proxy filter identity-policy diag sys sip-proxy filter negate diag sys sip-proxy filter policy diag sys sip-proxy filter policy-type diag sys sip-proxy filter profile-group diag sys sip-proxy filter src-addr4 diag sys sip-proxy filter src-addr6 diag sys sip-proxy filter src-port diag sys sip-proxy filter vd diag sys sip-proxy filter voip-profile

You can clear, view and negate/invert the sense of a filter using these commands:

diag sys sip-proxy filter clear diag sys sip-proxy filter list diag sys sip-proxy filter negate

SIP debug setting

Control of the SIP debug output is governed by the following command diagnose debug application sip <debug_level_int>

Where the <debug_level_int> is a bitmask and the individual values determine whether the listed items are logged or not. The <debug_level_int> can be:

Display SIP rate-limit data

You can use the diagnose sys sip-proxy meters command to display SIP rate limiting data.

For the following command output rate 1 shows that the current (over last second) measured rate for INVITE/ACK and BYTE was 1 per second, the peak 1 shows that the peak rate recorded is 1 per second, the max 0 shows that there is no maximum limit set, the count 18 indicates that 18 messages were received and drop 0 indicates that none were dropped due to being over the limit.

diag sys sip-proxy meters

sip

sip vd: 0 sip policy: 1 sip identity-policy: 0 sip policy-type: IPv4 sip profile-group: sip dialogs: 18

sip dialog-limit: 0

sip UNKNOWN: rate 0 peak 0 max 0 count 0 drop 0 sip ACK: rate 1 peak 1 max 0 count 18 drop 0 sip BYE: rate 1 peak 1 max 0 count 18 drop 0 sip CANCEL: rate 0 peak 0 max 0 count 0 drop 0 sip INFO: rate 0 peak 0 max 0 count 0 drop 0 sip INVITE: rate 1 peak 1 max 0 count 18 drop 0 sip MESSAGE: rate 0 peak 0 max 0 count 0 drop 0 sip NOTIFY: rate 0 peak 0 max 0 count 0 drop 0 sip OPTIONS: rate 0 peak 0 max 0 count 0 drop 0 sip PRACK: rate 0 peak 0 max 0 count 0 drop 0

sip PUBLISH: rate 0 peak 0 max 0 count 0 drop 0 sip REFER: rate 0 peak 0 max 0 count 0 drop 0 sip REGISTER: rate 0 peak 0 max 0 count 0 drop 0 sip SUBSCRIBE: rate 0 peak 0 max 0 count 0 drop 0 sip UPDATE: rate 0 peak 0 max 0 count 0 drop 0 sip PING: rate 0 peak 0 max 0 count 0 drop 0 sip YAHOOREF: rate 0 peak 0 max 0 count 0 drop 0

SIP and IPS

You can enable IPS in security policies that also accept SIP sessions to protect the SIP traffic from SIP-based attacks. If you enable IPS in this way then by default the pinholes that the SIP ALG creates to allow RTP and RTCP to flow through the firewall will also have IPS enabled.

This inheritance of the IPS setting can cause performance problems if the RTP traffic volume is high since IPS checking may reduce performance in some cases. Also if you are using network processor (NP) interfaces to accelerate VoIP performance, when IPS is enabled for the pinhole traffic is diverted to the IPS and as a result is not accelerated by the network processors.

You can use the following CLI command to disable IPS for the RTP pinhole traffic.

config voip profile edit VoIP_Pro_Name config sip set ips-rtp disable

end end

SIP and HA–session failover and geographic redundancy

FortiGate high availability supports SIP session failover (also called stateful failover) for active-passive HA. To support SIP session failover, create a standard HA configuration and select the Enable Session Pick-up option.

SIP session failover replicates SIP states to all cluster units. If an HA failover occurs, all in progress SIP calls (setup complete) and their RTP flows are maintained and the calls will continue after the failover with minimal or no interruption.

SIP calls being set up at the time of a failover may lose signaling messages. In most cases the SIP clients and servers should use message retransmission to complete the call setup after the failover has completed. As a result, SIP users may experience a delay if their calls are being set up when an HA a failover occurs. But in most cases the call setup should be able to continue after the failover.

SIP HA session failover

In some cases, failover during call teardown can result in hanging RTP connections which can accumulate over time and use up system memory. If this becomes a problem, you can set a time for the call-keepalive SIP VoIP profile setting. The FortiGate will then terminate calls with no activity after the time limit is exceeded. Range is 1 to 10,080 seconds. This options should be used with caution because it results in extra FortiGate CPU overhead and can cause delay/jitter for the VoIP call. Also, the FortiGate terminates the call without sending SIP messages to end the call. And if the SIP endpoints send SIP messages to terminate the call they will be blocked by the FortiGate if they are sent after the FortiGate terminates the call.

SIP geographic redundancy

Maintains a active-standby SIP server configuration, which even supports geographical distribution. If the active SIP server fails (missing SIP heartbeat messages or SIP traffic) FortiOS will redirect the SIP traffic to a secondary SIP server. No special configuration is required for geographic redundancy, just standard HA configuration.

Supporting geographic redundancy when blocking OPTIONS messages

Geographic redundancy

SIP and HA–session failover and geographic redundancy

Supporting geographic redundancy when blocking OPTIONS messages

For some geographic redundant SIP configurations, the SIP servers may use SIP OPTIONS messages as heartbeats to notify the FortiGate that they are still operating (or alive). This is a kind of passive SIP monitoring mechanism where the FortiGate isn’t actively monitoring the SIP servers and instead the FortiGate passively receives and analyzes OPTIONS messages from the SIP servers.

If FortiGates block SIP OPTIONS messages because block-options is enabled, the configuration may fail to operate correctly because the OPTIONS messages are blocked by one or more FortiGates.

However, you can work around this problem by enabling the block-geo-red-options application control list option. This option causes the FortiGate to refresh the local SIP server status when it receives an OPTIONS message before dropping the message. The end result is the heartbeat signals between geographically redundant SIP servers are maintained but OPTIONS messages do not pass through the FortiGate.

Use the following command to block OPTIONS messages while still supporting geographic redundancy:

config voip profile edit VoIP_Pro_Name config sip set block-options disable set block-geo-red-options enable

end

end

Support for RFC 2543-compliant branch parameters

RFC 3261 is the most recent SIP RFC, it obsoletes RFC 2543. However, some SIP implementations may use RFC 2543-compliant SIP calls.

The rfc2543-branch VoIP profile option allows the FortiGate to support SIP calls that include an

RFC 2543-compliant branch parameter in the SIP Via header. This option also allows FortiGates to support SIP calls that include Via headers that are missing the branch parameter.

config voip profile edit VoIP_Pro_Name config sip set rfc2543-branch enable

end end

Inspecting SIP over SSL/TLS (secure SIP)

Some SIP phones and SIP servers can communicate using SSL or TLS to encrypt the SIP signaling traffic. To allow SIP over SSL/TLS calls to pass through the FortiGate, the encrypted signaling traffic has to be unencrypted and inspected. To do this, the FortiGate SIP ALG intercepts and unencrypts and inspects the SIP packets. The packets are then re-encrypted and forwarded to their destination.

Normally SIP over SSL/TLS uses port 5061. You can use the following command to change the port that the FortiGate listens on for SIP over SSL/TLS sessions to port 5066:

config system settings set sip-ssl-port 5066

end

The SIP ALG supports full mode SSL/TLS only. Traffic between SIP phones and the FortiGate and between the FortiGate and the SIP server is always encrypted.

You enable SSL/TLS SIP communication by enabling SSL mode in a VoIP profile. You also need to install the SIP server and client certificates on your FortiGate and add them to the SSL configuration in the VoIP profile.

SIP over SSL/TLS between a SIP phone and a SIP server

Other than enabling SSL mode and making sure the security policies accept the encrypted traffic, the FortiGate configuration for SSL/TLS SIP is the same as any SIP configuration. SIP over SSL/TLS is supported for all supported SIP configurations.

Adding the SIP server and client certificates

A VoIP profile that supports SSL/TLS SIP requires one certification for the SIP server and one certificate that is used by all of the clients. Use the following steps to add these certificates to the FortiGate. Before you start, make sure the client and server certificate files and their key files are accessible from the management computer.

1. Go to System > Certificates and select
2. Set Type to Certificate.
3. Browse to the Certificate file and the Key file and select OK.
4. Enter a password for the certificate and select OK.

The certificate and key are uploaded to the FortiGate and added to the Local Certificates List.

5. Repeat to upload the other certificate.

The certificates are added to the list of Local Certificates as the filenames you uploaded. You can add comments to make it clear where its from and how it is intended to be used.

Adding SIP over SSL/TLS support to a VoIP profile

Use the following commands to add SIP over SSL/TLS support to the default VoIP profile. The following command enables SSL mode and adds the client and server certificates and passwords, the same ones you entered when you imported the certificates:

config voip profile edit default config sip set ssl-mode full set ssl-client-certificate “Client_cert” set ssl-server-certificate “Server_cert” set ssl-auth-client “check-server” set ssl-auth-server “check-server-group”

end

end

Other SSL mode options are also available:

SIP logging

You can enable SIP logging and logging of SIP violations in a VoIP profile.

config voip profile edit VoIP_Pro_Name config sip set log-call-summary enable set log-violations enable

end

end

To view SIP log messages go to Log & Report > Forward Traffic.

SIP rate limiting

Configurable threshold for SIP message rates per request method. Protects SIP servers from SIP overload and DoS attacks.

SIP rate limiting

FortiGates support rate limiting for the following types of VoIP traffic:

l Session Initiation Protocol (SIP) l Skinny Call Control Protocol (SCCP) (most versions) l Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE).

You can use rate limiting of these VoIP protocols to protect the FortiGate and your network from SIP and SCCP

Denial of Service (DoS) attacks. Rate limiting protects against SIP DoS attacks by limiting the number of SIP REGISTER and INVITE requests that the FortiGate receives per second. Rate limiting protects against SCCP

DoS attacks by limiting the number of SCCP call setup messages that the FortiGate receives per minute.

SIP rate limiting

You configure rate limiting for a message type by specifying a limit for the number of messages that can be received per second. The rate is limited per security policy. When VoIP rate limiting is enabled for a message type, if the a single security policy accepts more messages per second than the configured rate, the extra messages are dropped and log messages are written when the messages are dropped.

Use the following command to configure a VoIP profile to limit the number of INVITE messages accepted by each security policy that the VoIP profile is added to 100 INVITE messages a second:

config voip profile edit VoIP_Pro_Name config sip set invite-rate 100

end

end

If you are experiencing denial of service attacks from traffic using these VoIP protocols, you can enable VoIP rate limiting and limit the rates for your network. Limit the rates depending on the amount of SIP and SCCP traffic that you expect the FortiGate to be handling. You can adjust the settings if some calls are lost or if the amount of SIP or SCCP traffic is affecting FortiGate performance.

The table below lists all of the VoIP profile SIP rate limiting options. All of these options are set to 0 so are disabled by default.

Blocking SIP OPTIONS messages may prevent a redundant configuration from operating correctly. See Supporting geographic redundancy when blocking OPTIONS messages on page 113 for information about resolving this problem.

Options for SIP rate limiting

Limiting the number of SIP dialogs accepted by a security policy

In addition to limiting the rates for receiving SIP messages, you can use the following command to limit the number of SIP dialogs (or SIP calls) that the FortiGate accepts.

config voip profile edit VoIP_Pro_Name config sip set max-dialogs 2000

end

end

This command sets the maximum number of SIP dialogs that can be open for SIP sessions accepted by any security policy that you add the VoIP profile to. The default setting of 0 does not limit the number of dialogs. You can add a limit to control the number of open dialogs and raise and lower it as required. You might want to limit the number of open dialogs for protection against SIP-based attackers opening large numbers of SIP dialogs. Every dialog takes memory and FortiGate CPU resources to process. Limiting the number of dialogs may improve the overall performance of the FortiGate. Limiting the number of dialogs will not drop calls in progress but may prevent new calls from connecting.

Blocking SIP request messages

You may want to block different types of SIP requests:

• to prevent SIP attacks using these messages.
• If your SIP server cannot process some SIP messages because of a temporary issue (for example a bug that crashes or compromises the server when it receives a message of a certain type). l Your SIP implementation does not use certain message types.

When you enable message blocking for a message type in a VoIP profile, whenever a security policy containing the VoIP profile accepts a SIP message of this type, the SIP ALG silently discards the message and records a log message about the action.

Use the following command to configure a VoIP profile to block SIP CANCEL and Update request messages:

config voip profile edit VoIP_Pro_Name config sip set block-cancel enable set block-update enable

end

end

SIP uses a variety of text-based messages or requests to communicate information about SIP clients and servers to the various components of the SIP network. Since SIP requests are simple text messages and since the requests or their replies can contain information about network components on either side of the FortiGate, it may be a security risk to allow these messages to pass through.

The following table lists all of the VoIP profile SIP request message blocking options. All of these options are disabled by default.

Blocking SIP OPTIONS messages may prevent a redundant configuration from operating correctly. See Supporting geographic redundancy when blocking OPTIONS messages on page 113 for information about resolving this problem.

Options for blocking SIP request messages

Deep SIP message inspection

Deep SIP message syntax inspection (also called Deep SIP header inspection or SIP fuzzing protection) provides protection against malicious SIP messages by applying SIP header and SDP profile syntax checking. SIP Fuzzing attacks can be used by attackers to discover and exploit vulnerabilities of a SIP entity (for example a SIP proxy server). Most often these attacks could crash or compromise the SIP entity.

Deep SIP message inspection

• Checks the SIP request message Request-line
• Checks the following SIP header fields:
• Allow, Call-id, Contact, Contentlength, Content-type, CSeq, Expires, From, Max-Forwards,

P-asserted-identity, Rack,

Record-Route, Route, Rseq, To, Via

• Checks all SDP profile lines
• Configurable header and body length checks
• Optional logging of message violations

Deep SIP message inspection checks the syntax of each SIP header and SDP profile line to make sure they conform to the syntax defined in the relevant RFC and IETF standard. You can also configure the SIP ALG to inspect for:

• Unknown SIP message types (message types not defined in a SIP RFC) this option is enabled by default and can be disabled. When enabled unknown message types are discarded. Configured using the block-unknown
• Unknown line types (message line types that are not defined in any SIP or SDP RFC). Configured using the unknown-header
• Messages that are longer than a configured maximum size. Configured using the max-body-length
• Messages that contain one or more lines that are longer that a set maximum line length (default 998 characters).

Configured using the max-line-length option.

Actions taken when a malformed message line is found

Actions taken when a malformed message line is found

When a malformed message line or other error is found the SIP ALG can be configured to discard the message containing the error, pass the message without any other actions, or responding to the message with a 400 Bad Request or 413 Request entity too large client error SIP response message and then discard the message. (For information about client error SIP response messages, see Client error on page 27.)

If a message line is longer than the configured maximum, the SIP ALG sends the following message:

SIP/2.0 413 Request Entity Too Large, <optional_info>

If a message line is incorrect or in an unknown message line is found, the SIP ALG sends the following message:

SIP/2.0 400 Bad Request, <optional_info>

The <optional_info> provides more information about why the message was rejected. For example, if the SIP ALG finds a malformed Via header line, the response message may be:

SIP/2.0 400 Bad Request, malformed Via header

If the SIP ALG finds a malformed message line, and the action for this message line type is discard, the message is discarded with no further checking or responses. If the action is pass, the SIP ALG continues parsing the SIP message for more malformed message lines. If the action is respond, the SIP ALG sends the SIP response message and discards the message containing the malformed line with no further checking or response. If only malformed message line types with action set to pass are found, the SIP ALG extracts as much information as possible from the message (for example for NAT and opening pinholes, and forwards the message to its destination).

If a SIP message containing a malformed line is discarded the SIP ALG will not use the information in the message for call processing. This could result in the call being terminated. If a malformed line in a SIP message includes information required for the SIP call that the SIP ALG cannot interpret (for example, if an IP address required for SIP NAT is corrupted) the SIP ALG may not be able to continue processing the call and it could be terminated. Discarded messages are counted by SIP ALG static message counters.

Logging and statistics

To record a log message each time the SIP ALG finds a malformed header, enable logging SIP violations in a VoIP profile. In all cases, when the SIP ALG finds an error the FortiGate records a malformed header log message that contains information about the error. This happens even if the action is set to pass.

If, because of recording log messages for deep message inspection, the CPU performance is affected by a certain amount, the FortiGate records a critical log message about this event and stops writing log messages for deep SIP message inspection.

The following information is recorded in malformed header messages:

• The type of message line in which the error was found.
• The content of the message line in which the error was found (it will be truncated if it makes the log message too long) l The column or character number in which the error was found (to make it easier to determine what caused the error) Deep SIP message inspection Deep SIP message inspection best practices

Deep SIP message inspection best practices

Because of the risks imposed by SIP header attacks or incorrect data being allowed and because selecting drop or respond does not require more CPU overhead that pass you would want to set all tests to drop or respond. However, in some cases malformed lines may be less of a threat or risk. For example, the SDP i= does not usually contain information that is parsed by any SIP device so a malformed i= line may not pose a threat.

You can also used the pre-defined VoIP profiles to apply different levels of deep message inspection. The default VoIP profile sets all deep message inspection options to pass and the strict VoIP profile sets all deep message inspection options to discard. From the CLI you can use the clone command to copy these pre-defined VoIP profiles and then customize them for your requirements.

Configuring deep SIP message inspection

You configure deep SIP message inspection in a VoIP profile. All deep SIP message inspection options are available only from the CLI.

Enter the following command to configure deep SIP message inspection to discard messages with malformed Request-lines (the first line in a SIP request message):

config voip profile edit VoIP_Pro_Name config sip set malformed-request-line respond

end

end

The following table lists the SIP header lines that the SIP ALG can inspect and the CLI command for configuring the action for each line type. The table also lists the RFC that the header line is defined in.

SIP header lines that the SIP ALG can inspect for syntax errors

The table below lists the SDP profile lines that the SIP ALG inspects and the CLI command for configuring the action for each line type. SDP profile lines are defined by RFC 4566 and RFC 2327.

SDP profile lines that the SIP ALG can inspect for syntax errors

Discarding SIP messages with some malformed header and body lines

Enter the following command to configure deep SIP message inspection to discard SIP messages with a malformed Via line, a malformed route line or a malformed m= line but to pass messages with a malformed i= line or a malformed Max-Forwards line

config voip profile edit VoIP_Pro_Name config sip set malformed-header-via discard set malformed-header-route discard set malformed-header-sdp-m discard set malformed-header-sdp-i pass set malformed-header-max-forwards pass

end

end

Discarding SIP messages with an unknown SIP message type

Enter the following command to discard SIP messages with an unknown SIP message line type as defined in all current SIP RFCs:

config voip profile edit VoIP_Pro_Name config sip set unknown-header discard

end

end

Discarding SIP messages that exceed a message size

Enter the following command to set the maximum size of a SIP message to 200 bytes. Messages longer than 200 bytes are discarded.

config voip profile edit VoIP_Pro_Name config sip set max-body-length 200

end

end

The max-body-length option checks the value in the SIP Content-Length header line to determine body length. The Content-Length can be larger than the actual size of a SIP message if the SIP message content is split over more than one packet. SIP message sizes vary widely. The size of a SIP message can also change with the addition of Via and Record-Route headers as the message is transmitted between users and SIP servers.

Discarding SIP messages with lines longer than 500 characters

Enter the following command to set the length of a SIP message line to 500 characters and to block messages that include lines with 500 or more characters:

config voip profile edit VoIP_Pro_Name config sip set max-line-length 500 set block-long-lines enable

end end