Category Archives: FortiOS 5.4 Handbook

The complete handbook for FortiOS 5.4

Conflicts between the SIP ALG and the session helper

Conflicts between the SIP ALG and the session helper

If you suspect that the SIP session helper is being used instead of the ALG, you can use the diagnose sys sip command to determine if the SIP session helper is processing SIP sessions. For example, the following command displays the overall status of the SIP sessions being processed by the SIP session helper:

The diagnose sys sip command only displays current status information. To see activity the SIP session helper has to actually be processing SIP sessions when you enter the command. For example, if the SIP session helper had been used for pro- cessing calls that ended 5 minutes ago, the command output would show no SIP ses- sion helper activity.

diagnose sys sip status dialogs: max=32768, used=0 mappings: used=0

dialog hash by ID: size=2048, used=0, depth=0 dialog hash by RTP: size=2048, used=0, depth=0 mapping hash: size=2048, used=0, depth=0 count0: 0

count1: 0 count2: 0 count3: 0 count4: 0

This command output shows that the session helper is not processing SIP sessions because all of the used and count fields are 0. If any of these fields contains non-zero values then the SIP session helper may be processing SIP sessions.

Also, you can check to see if some ALG-only features are not being applied to all SIP sessions. For example, FortiView pages displays statistics for SIP and SCCP calls processed by the ALG but not for calls processed by the session helper. So if you see fewer calls than expected the session helper may be processing some of them.

Finally, you can check the policy usage and session information dashboard widgets to see if SIP sessions are being accepted by the wrong security policies.

The SIP ALG

The SIP ALG

In most cases you should use the SIP Application Layer Gateway (ALG) for processing SIP sessions. The SIP ALG provides the same basic SIP support as the SIP session helper. Additionally, the SIP ALG provides a wide range of features that protect your network from SIP attacks, apply rate limiting to SIP sessions, check the syntax of SIP and SDP content of SIP messages, and provide detailed logging and reporting of SIP activity.

By default all SIP traffic is processed by the SIP ALG. If the policy that accepts the SIP traffic includes a VoIP profile the SIP traffic is processed by that profile. If the policy does not include a SIP profile the SIP traffic is processed by the SIP ALG using the default VoIP profile.

If a FortiGate unit or a VDOM has been configured to use the SIP session helper, you can change this behavior to the default configuration of using the SIP ALG with the following command:

config system settings

set default-voip-alg-mode proxy-based end

 

From the GUI you can only configure VoIP security profiles and add them to security policies if VoIP is turned on under System > Feature Select and if the Inspection Mode is set to Proxy-based. However, you can always configure VoIP profiles and add them to secuity profiles from the CLI. And if the default-voip-alg mode is set to proxy-based the default SIP profile will still be used even if VoIP security pro- files are not visible from the GUI.

As shown in the figure below, the FortiGate SIP ALG intercepts SIP packets after they have been routed by the routing module, accepted by a security policy and passed through DoS and IPS Sensors (if DoS and IPS are enabled). The ALG raises SIP packets to the application layer, analyzes the SIP and SDP addressing information in the SIP messages, makes adjustments (for example, NAT) to this addressing if required, and then sends the packets out the egress interface to their destination.

 

The SIP ALG provides:

  • All the same features as the SIP session helper including NAT and SIP and RTP Pinholes.
  • In addition for the ALG you can enable or disable RTP pinholing, SIP register pinholing and SIP contact pinholing.

In a signalling only environment where the RTP stream bypasses the FortiGate unit, you can disable RTP pinholing to improve performance.

  • SIP TCP and UDP support
  • SIP Message order checking
  • Configurable Header line length maximums

 

The SIP ALG works at the application level after ingress packets are accepted by a security policy

SIP

Egress

Router

  • IP Routing and forwarding
  • IPsec VPN encryption, decryption

 

SIP ALG

  • Rate limiting and message blocking
  • Stateful SIP tracking
  • Message, header, and SDP syntax checking
  • Network surveillance
  • NAT and IP topology Hiding
  • Logging and debugging

 

IPS Signatures Opt.

  •  Intrusion Detection and Prevention
  • Defined by Fortinet and Enterprise signatures
  • SIP decoder identifies SIP sessions

 

Firewall

  • Security Policy
  • IPsec VPN encryption, decryption
  • Access control

DoS Sensor

  • Native (D)DoS prevention
  • Anomaly Detection and Prevention

 

SIP

  • Message fragment assembly (TCP)
  • If SIP messages are fragmented across multiple packets, the FortiGate unit assembles the fragments, does inspection and pass the message in its entirety to the SIP server as one packet. This offloads the server from doing all the TCP processing of fragments.
  • L4 Protocol Translation
  • Message Flood Protection
  • Protects a SIP server from intentional or unintentional DoS of flooding INVITE, REGISTER, and other SIP methods by allowing control of the rate that these massages pass through the FortiGate unit.
  • SIP message type filtering
  • The FortiGate unit can prevent specified SIP message types from passing through the FortiGate unit to a SIP server. For example In a voice only SIP implementation, there may be no need to permit a SUBSCRIBE message to ever make it’s way to the SIP call processor. Also, if a SIP server cannot process some SIP message types you can use SIP message type filtering to block them. For example, a SIP server could have a bug that prevents it from processing certain SIP messages. In this case you can temporarily block these message types until problem with the SIP server has been fixed.
  • SIP statistics and logging
  • SIP over IPv6
  • SIP over SSL/TLS
  • Deep SIP message syntax checking (also called deep SIP header inspection or SIP fuzzing protection). Prevents attacks that use malformed SIP messages. Can check many SIP headers and SDP statements. Configurable bypass and modification options.
  • Hosted NAT traversal, Resolves IP address issue in SIP and SDP lines due to NAT-PT in far end firewall. Important feature for VoIP access networks.
  • SIP High Availability (HA), including active-passive clustering and session pickup (session failover) for SIP sessions.
  • Geographical Redundancy. In an HA configuration, if the active SIP server fails (missing SIP heartbeat messages or
  • SIP traffic) SIP sessions can be redirected to a secondary SIP server in another location.
  • SIP per request method message rate limitation with configurable threshold for SIP message rates per request method. Protects SIP servers from SIP overload and DoS attacks.
  • RTP Bypass, Supports configurations with and without RTP pinholing. May inspect and protect SIP signaling only.
  • SIP NAT with IP address conservation. Performs SIP and RTP aware IP Network Address translation. Preserves the lost IP address information in the SDP profile i= line for later processing/debugging in the SIP server. See NAT with IP address conservation on page 2794.
  • IP topology hiding
  • The IP topology of a network can be hidden through NAT and NAPT manipulation of IP and SIP level addressing.

For example, see SIP NAT scenario: destination address translation (destination NAT) on page 2782.

  • SIP inspection without address translation
  • The SIP ALG inspects SIP messages but addresses in the messages are not translated. This feature can be applied to a FortiGate unit operating in Transparent mode or in NAT/Route mode. In Transparent mode you add normal Transparent mode security policies that enable the SIP ALG and include a VoIP profile that causes the SIP ALG to inspect SIP traffic as required. For an example configuration, see Configuration example: SIP in Transparent Mode on page 2770.
  • For a FortiGate unit operating in NAT/Route mode, if SIP traffic can pass between different networks without requiring NAT because is supported by the routing configuration, you can add security policies that accept SIP traffic without enabling NAT. In the VoIP profile you can configure the SIP ALG to inspect SIP traffic as required.

 

SIP ALG configuration overview

SIP ALG configuration overview

To apply the SIP ALG, you add a SIP VoIP profile to a security policy that accepts SIP sessions. All SIP sessions accepted by the security policy will be processed by the SIP ALG using the settings in the VoIP profile. The VoIP profile contains settings that are applied to SIP, Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) and Skinny Call Control Protocol (SCCP) sessions. All SCCP sessions accepted by the security policy are also processed byt the ALG. You configure SIP and SCCP settings separately. SIP settings also apply to SIMPLE sessions.

 

Enabling VoIP support on the web-based manager

Before you begin to configure VoIP security options, including SIP, from the web-based manager you should go to System > Feature Select and turn on VoIP (under Additional Features). Also the Inspection Mode must be set to Proxy-based on the System Information dashboard widget.

From the CLI you can also enter the following command to enable VoIP support on the GUI:

config system settings

set gui-voip-profile enable end

 

VoIP profiles

You can customize the default VoIP profile or add new VoIP profiles.

To add a new VoIP profile from the web-based manager go to Security Profiles > VoIP and select Create New (the + button).

For SIP, from the web-based manager you can configure the VoIP profile to limit the number of SIP REGISTER and INVITE requests. Many additional options for configuring how the ALG processes SIP sessions are available from the CLI.

For SCCP you can limit the call setup time. Additional SCCP options are available from the CLI. Use the following command to add a VoIP profile named VoIP_Pro_1 from the CLI:

config voip profile

edit VoIP_Pro_1 end

FortiGate units include two pre-defined VoIP profiles. On the web-based manager these profiles look identical. However, the CLI-only settings result in the following functionality.

default                       The most commonly used VoIP profile. This profile enables both SIP and SCCP and places the minimum restrictions on what calls will be allowed to negotiate. This profile allows normal SCCP, SIP and RTP sessions and enables the following security set- tings:

  • block-long-lines to block SIP messages with lines that exceed maximum line lengths.
  • block-unknown to block unrecognized SIP request messages.
  • open-record-route-pinhole to open pinholes for Record-Route messages.
  • log-violations to write log messages that record SIP violations.
  • log-call-summary to write log messages that record SIP call progress (similar to DLP archiving).
  • nat-trace (see NAT with IP address conservation on page 2794).
  • contact-fixup perform NAT on the IP addresses and port numbers in SIP head- ers in SIP CONTACT messages even if they don’t match the session’s IP address and port numbers.
  • ips-rtp to enable IPS in security policies that also accept SIP sessions to protect the SIP traffic from SIP-based attacks.

 

strict

This profile is available for users who want to validate SIP messages and to only allow SIP sessions that are compliant with RFC 3261. In addition to the settings in the default VoIP profile, the strict profile sets all SIP deep message inspection header checking options to discard. So the strict profile blocks and drops SIP messages that contain malformed SIP or SDP lines that can be detected by the ALG. For more information about SIP deep header inspection, see Deep SIP message inspection on page 2808.

Neither of the default profiles applies SIP rate limiting. To apply more ALG features to SIP sessions you can clone (copy) the pre-defined VoIP profiles and make your own modifications to them. You can clone VoIP profiles from the GUI or the CLI. For example, from the CLI, to clone the default profile and configure the limit for SIP NOTIFY request messages to 1000 messages per second per security policy and block SIP INFO request messages.

config voip profile

clone default to my_voip_pro edit my_voip_pro

config sip

set notify-rate 1000 set block-info enable

end end

 

Changing the port numbers that the SIP ALG listens on

Most SIP configurations use TCP or UDP port 5060 for SIP sessions and port 5061 for SIP SSL sessions. If your SIP network uses different ports for SIP sessions you can use the following command to configure the SIP ALG to listen on a different TCP, UDP, or SSL ports. For example, to change the TCP port to 5064, the UDP port to 5065, and the SSL port to 5066.

config system settings set sip-tcp-port 5064 set sip-udp-port 5065 set sip-ssl-port 5066

end

You also configure the SIP ALG to listen in two different TCP ports and two different UDP ports for SIP sessions. For example, if you receive SIP TCP traffic on port 5060 and 5064 and UDP traffic on ports 5061 and 5065 you can enter the following command to receive the SIP traffic on all of these ports:

config system settings

set sip-tcp-port 5060 5064 set sip-udp-port 5061 5065

end

 

Disabling the SIP ALG in a VoIP profile

SIP is enabled by default in a VoIP profile. If you are just using the VoIP profile for SCCP you can use the following command to disable SIP in the VoIP profile.

config voip profile edit VoIP_Pro_2

config sip

set status disable end

 

SIP ALG diagnose commands

You can use the diagnose sys sip-proxy command to display diagnostic information for the SIP ALG. A number of options are avaialble including:

Use the following command to list all active SIP calls being processed by the SIP ALG. You can also use the clear option to delete all active SIP calls being processed by the SIP ALG, the idle option to list idle SIP calls, and the invite option to list SIP intive transations.

diagnose sys sip-proxy calls {clear | list | idle | invite}

Use the following commands to employ filters to display specific information about the SIP ALG and the session that it is processing. You can build up a filter by including a number of options such as source address, VoIP profile, policy, and so on.

diagnose sys sip-proxy filter <filter_options>

 

diagnose sys sip-proxy log-filter <filter_options>

Use the following command to display the active SIP rate limiting meters and their current settings.

diagnose sys sip-proxy meters list

Use the following command to display status information about the SIP sessions being processed by the SIP ALG. You can also clear all SIP ALG statistics.

diagnose sys sip-proxy stats {clear | list}

Configuration example: SIP session helper in Transparent Mode

Configuration example: SIP session helper in Transparent Mode

The figure below shows an example SIP network consisting of a FortiGate unit operating in Transparent mode between two SIP phones. Since the FortiGate unit is operating in Transparent mode both phones are on the same network and the FortiGate unit and the SIP session helper does not perform NAT. Even though the SIP session helper is not performing NAT you can use this configuration to apply SIP session helper security features to the SIP traffic.

The FortiGate unit requires two security policies that accept SIP packets. One to allow SIP Phone A to start a session with SIP Phone B and one to allow SIP Phone B to start a session with SIP Phone A.

 

SIP network with FortiGate unit in Transparent mode

 

o

Po                                                         P

rt2

SIP Phone A (PhoneA@10.31.101.20)

 

 

 

rt1                                                     P

FortiGate unit

in Transparent mode

SIP Phone B (PhoneB@10.31.101.30)

 

 

General configuration steps

The following general configuration steps are required for this SIP configuration that uses the SIP session helper. This example includes security policies that specifically allow SIP sessions using UDP port 5060 from Phone A to Phone B and from Phone B to Phone A. In most cases you would have more than two phones so would use more general security policies. Also, you can set the firewall service to ANY to allow traffic other than SIP on UDP port

5060.

 

This example assumes that you have entered the following command to enable using the SIP session helper:

config system settings

set default-voip-alg-mode kernel-helper-based end

1. Add firewall addresses for Phone A and Phone B.

2. Add a security policy that accepts SIP sessions initiated by Phone A.

3. Add a security policy that accepts SIP sessions initiated by Phone B.

 

Configuration steps – web-based manager

 

To add firewall addresses for the SIP phones

1. Go to Policy & Objects > Addresses.

2. Select Create New > Address to add the following addresses for Phone A and Phone B:

Category                                     Address

Name                                          Phone_A

Type                                            IP/Netmask

Subnet / IP Range                     10.31.101.20/255.255.255.255

Interface                                     port1

Category                                     Address

Name                                          Phone_B

Type                                            IP/Netmask

Subnet / IP Range                     10.31.101.30/255.255.255.255

Interface                                     port2

 

To add security policies to accept SIP sessions

1. Go to Policy & Objects > IPv4 Policy.

2. Select Create New to add a security policy.

3. Add a security policy to allow Phone A to send SIP request messages to Phone B:

Incoming Interface                   port1

Outgoing Interface                   port2

Source                                        Phone_A

Destination Address                 Phone_B

Schedule                                    always

Service                                       SIP

Action                                         ACCEPT

4. Select OK.

5. Add a security policy to allow Phone B to send SIP request messages to Phone A:

Incoming Interface                   port2

Outgoing Interface                   port1

Source Address                        Phone_B

Destination Address                 Phone_A

Schedule                                    always

Service                                       SIP

Action                                         ACCEPT

6. Select OK.

 

Configuration steps – CLI

To add firewall addresses for Phone A and Phone B and security policies to accept SIP sessions

1. Enter the following command to add firewall addresses for Phone A and Phone B.

config firewall address edit Phone_A

set associated interface port1 set type ipmask

set subnet 10.31.101.20 255.255.255.255 next

edit Phone_B

set associated interface port2 set type ipmask

set subnet 10.31.101.30 255.255.255.255 end

2. Enter the following command to add security policies to allow Phone A to send SIP request messages to Phone B

and Phone B to send SIP request messages to Phone A.

config firewall policy edit 0

set srcintf port1 set dstintf port2 set srcaddr Phone_A set dstaddr Phone_B set action accept set schedule always set service SIP

next edit 0

set srcintf port2 set dstintf port1 set srcaddr Phone_B set dstaddr Phone_A set action accept set schedule always set service SIP

set utm-status enable

end

The SIP session helper

The SIP session helper

The SIP session-helper is a high-performance solution that provides basic support for SIP calls passing through the FortiGate unit by opening SIP and RTP pinholes and by performing NAT of the addresses in SIP messages.

 

The SIP session helper:

  • Understands SIP dialog messages.
  • Keeps the states of the SIP transactions between SIP UAs and SIP servers.
  • Translates SIP header and SDP information to account for NAT operations performed by the FortiGate unit.
  • Opens up and closes dynamic SIP pinholes for SIP signalling traffic.
  • Opens up and closes dynamic RTP and RTSP pinholes for RTP and RTSP media traffic.
  • Provides basic SIP security as an access control device.
  • Uses the intrusion protection (IPS) engine to perform basic SIP protocol checks.

 

SIP session helper configuration overview

By default FortiOS uses the SIP ALG for SIP traffic. If you want to use the SIP session helper you need to enter the following command:

config system settings

set default-voip-alg-mode kernel-helper-based

end

The SIP session helper is set to listen for SIP traffic on TCP or UDP port 5060. SIP sessions using port 5060 accepted by a security policy that does not include a VoIP profile are processed by the SIP session helper.

You can enable and disable the SIP session helper, change the TCP or UDP port that the session helper listens on for SIP traffic, and enable or disable SIP NAT tracing. If the FortiGate unit is operating with multiple VDOMs, each VDOM can have a different SIP session helper configuration.

To have the SIP session helper process SIP sessions you need to add a security policy that accepts SIP sessions on the configured SIP UDP or TCP ports. The security policies can have service set to ANY, or to the SIP pre- defined firewall service, or a custom firewall service. The SIP pre-defined firewall service restricts the security policy to only accepting sessions on UDP port 5060.

If NAT is enabled for security policies that accept SIP traffic, the SIP session helper translates addresses in SIP headers and in the RDP profile and opens up pinholes as required for the SIP traffic. This includes security policies that perform source NAT and security policies that contain virtual IPs that perform destination NAT and port forwarding. No special SIP configuration is required for this address translation to occur, it is all handled automatically by the SIP session helper according to the NAT configuration of the security policy that accepts the SIP session.

To use the SIP session helper you must not add a VoIP profile to the security policy. If you add a VoIP profile, SIP traffic bypasses the SIP session helper and is processed by the SIP ALG.

In most cases you would want to use the SIP ALG since the SIP session helper provides limited functionality. However, the SIP session helper is available and can be useful for high-performance solutions where a high level of SIP security is not a require- ment.

 

Disabling and enabling the SIP session helper

You can use the following steps to disable the SIP session helper. You might want to disable the SIP session helper if you don’t want the FortiGate unit to apply NAT or other SIP session help features to SIP traffic. With the SIP session helper disabled, the FortiGate unit can still accept SIP sessions if they are allowed by a security policy, but the FortiGate unit will not be able to open pinholes or NAT the addresses in the SIP messages.

 

To disable the sip session helper

1. Enter the following command to find the sip session helper entry in the session-helper list:

show system session-helper

edit 13

set name sip set port 5060 set protocol 17

next

This command output shows that the sip session helper listens in UDP port 5060 for SIP sessions.

2. Enter the following command to delete session-helper list entry number 13 to disable the sip session helper:

config system session-helper delete 13

end

If you want to use the SIP session helper you can verify whether it is enabled or disabled using the show system session-helper command.

You do not have to disable the SIP session helper to use the SIP ALG.

If the SIP session helper has been disabled by being removed from the session-helper list you can use the following command to enable the SIP session helper by adding it back to the session helper list:

config system session-helper edit 0

set name sip set port 5060 set protocol 17

end

 

Changing the port numbers that the SIP session helper listens on

You can use the following command to change the port number that the SIP session helper listens on for SIP traffic to 5064. The SIP session helper listens on the same port number for UDP and TCP SIP sessions. In this example, the SIP session helper is session helper 13:

config system session-helper edit 13

set port 5064 end

 

The config system settings options sip-tcp-port, sip-udp-port, and sip-ssl-port control the ports that the SIP ALG listens on for SIP sessions. See Changing the port numbers that the SIP ALG listens on on page 2764.

 

Your FortiGate unit may use a different session helper number for SIP. Enter the following command to view the session helpers:

show system session-helper

edit 13

set name sip set port 5060 set protocol 17

end

Example SIP messages

Example SIP messages

The following example SIP INVITE request message was sent by PhoneA to PhoneB. The first nine lines are the SIP headers. The SDP profile starts with v=0 and the media part of the session profile is the last line, starting with m=.

INVITE sip:PhoneB@172.20.120.30 SIP/2.0

Via: SIP/2.0/UDP 10.31.101.50:5060

From: PhoneA <sip:PhoneA@10.31.101.20> To: PhoneB <sip:PhoneB@172.20.120.30> Call-ID: 314159@10.31.101.20

CSeq: 1 INVITE

Contact: sip:PhoneA@10.31.101.20

Content-Type: application/sdp

Content-Length: 124 v=0

o=PhoneA 5462346 332134 IN IP4 10.31.101.20 s=Let’s Talk

t=0 0

c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3

The following example shows a possible 200 OK SIP response message in response to the previous INVITE request message. The response includes 200 OK which indicates success, followed by an echo of the original SIP INVITE request followed by PhoneB’s SDP profile.

 

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.31.101.50:5060

From: PhoneA <sip:PhoneA@10.31.101.20> To: PhoneB <sip:PhoneB@172.20.120.30> Call-ID: 314159@10.31.101.20

CSeq: 1 INVITE

Contact: sip:PhoneB@10.31.101.30

Content-Type: application/sdp

Content-Length: 107 v=0

o=PhoneB 124333 67895 IN IP4 172.20.120.30 s=Hello!

t=0 0

c=IN IP4 172.20.120.30 m=audio 3456 RTP 0

SIP can support multiple media streams for a single SIP session. Each media steam will have its own c= and m=

lines in the body of the message. For example, the following message includes three media streams:

 

INVITE sip:PhoneB@172.20.120.30 SIP/2.0

Via: SIP/2.0/UDP 10.31.101.20:5060

From: PhoneA <sip:PhoneA@10.31.101.20> To: PhoneB <sip:PhoneB@172.20.120.30> Call-ID: 314159@10.31.101.20

CSeq: 1 INVITE

Contact: sip:PhoneA@10.31.101.20

Content-Type: application/sdp

Content-Length: 124 v=0

o=PhoneA 5462346 332134 IN IP4 10.31.101.20 s=Let’s Talk

t=0 0

c=IN IP4 10.31.101.20 m=audio 49170 RTP 0 3 c=IN IP4 10.31.101.20 m=audio 49172 RTP 0 3 c=IN IP4 10.31.101.20 m=audio 49174 RTP 0 3

The SIP message body and SDP session profiles

The SIP message body and SDP session profiles

The SIP message body describes the session to be initiated. For example, in a SIP phone call the body usually includes audio codec types, sampling rates, server IP addresses and so on. For other types of SIP session the body could contain text or binary data of any type which relates in some way to the session. The message body is included in request and response messages.

 

Two possible SIP message body types:

  • Session Description Protocol (SDP), most commonly used for SIP VoIP.
  • Multipurpose Internet Mail Extensions (MIME)

SDP is most often used for VoIP and FortiGate units support SDP content in SIP message bodies. SDP is a text- based protocol used by SIP to control media sessions. SDP does not deliver media but provides a session profile that contains media details, transport addresses, parameter negotiation, and other session description metadata for the participants in a media session. The participants use the information in the session profile to negotiate how to communicate and to manage the media session. SDP is described by RFC 4566.

An SDP session profile always contains session information and may contain media information. Session information appears at the start of the session profile and media information (using the m= attribute) follows.

SDP session profiles can include the attributes listed inthe following table.

 

SDP session profile attributes

Attribute                  Description

a=                              Attributes to extend SDP in the form a=<attribute> or a=<a- ttribute>:<value>.

b=                              Contains information about the bandwidth required for the session or media in the form b=<bandwidth_type>:<bandwidth>.

c=                              Connection data about the session including the network type (usually IN for Internet), address type (IPv4 or IPv6), the connection source address, and other optional inform- ation. For example:

c=IN IPv4 10.31.101.20

A text string that contains information about the session. For example:

i=

i=A audio presentation about SIP

k=                              Can be used to convey encryption keys over a secure and trusted channel. For example:

k=clear:444gdduudjffdee

 

Media information, consisting of one or more lines all starting with m= and containing details about the media including the media type, the destination port or ports used by the media, the protocol used by the media, and a media format description.

m=audio 49170 RTP 0 3 m-video 3345/2 udp 34

m-video 2910/2 RTP/AVP 3 56

 

Multiple media lines are needed if SIP is managing multiple types of media in one ses-

m=                             sion (for example, separate audio and video streams).

Multiple ports for a media stream are indicated using a slash. 3345/2 udp means UDP ports 3345 and 3346. Usually RTP uses even-numbered ports for data with the corresponding one-higher odd ports used for the RTCP session belonging to the RTP session. So 2910/2 RTP/AVP means ports 2910 and 2912 are used for RTP and 2911 and 2913 are used for RTCP.

 

Media types include udp for an unspecified protocol that uses UDP, RTP or RTP/AVP for standard RTP and RTP/SAVP for secure RTP.

 

Attribute                  Description

o=                              The sender’s username, a session identifier, a session version number, the network type (usually IN for Internet), the address type (for example, IPv4 or IPv6), and the sending device’s IP address. The o= field becomes a universal identifier for this ver- sion of this session description. For example:

o=PhoneA 5462346 332134 IN IP4 10.31.101.20

 

Repeat times for a session. Used if a session will be repeated at one or more timed intervals. Not normally used for VoIP calls. The times can be in different formats. For

r=                               example:

r=7d 1h 0 25h r=604800 3600 0 90000

 

s=                              Any text that describes the session or s= followed by a space. For example:

s=Call from inviter

 

The start and stop time of the session. Sessions with no time restrictions (most VoIP

t=                               calls) have a start and stop time of 0.

t=0 0

 

v=                              SDP protocol version. The current SDP version is 0 so the v= field is always:

v=0

 

Time zone adjustments. Used for scheduling repeated sessions that span the time

z=                               between changing from standard to daylight savings time.

z=2882844526 -1h 2898848070 0

SIP response messages

SIP response messages

SIP response messages (often just called SIP responses) provide status information in response to SIP request messages. All SIP response messages include a response code and a reason phrase. There are five SIP response message classes. They are described below.

There are also two types of SIP response messages, provisional and final. Final response messages convey the result of the request processing, and are sent reliably. Provisional responses provide information on the progress of the request processing, but may not be sent reliably. Provisional response messages start with 1xx and are also called informational response messages.

 

Informational (or provisional)

Informational or provisional responses indicate that a request message was received and imply that the endpoint is going to process the request. Information messages may not be sent reliably and may not require an acknowledgement.

If the SIP implementation uses Provisional Response Acknowledgement (PRACK) (RFC 3262) then informational or provisional messages are sent reliably and require a PRACK message to acknowledge that they have been received.

Informational responses can contain the following reason codes and reason phrases:

100 Trying

180 Ringing

181 Call is being forwarded

182 Queued

183 Session progress

 

Success

Success responses indicate that a request message was received, understood, and accepted. Success responses can contain the following reason codes and reason phrases:

200 OK

202 Accepted

 

Redirection

Redirection responses indicate that more information is required for the endpoint to respond to a request message. Redirection responses can contain the following reason codes and reason phrases:

300 Multiple choices

301 Moved permanently

302 Moved temporarily

305 Use proxy

380 Alternative service

 

Client error

Client error responses indicate that a request message was received by a server that contains syntax that the server cannot understand (i.e. contains a syntax error) or cannot comply with. Client error responses include the following reason codes and reason phrases:

400 Bad request              401 Unauthorized

402 Payment required         403 Forbidden

404 Not found                405 Method not allowed

406 Not acceptable           407 Proxy authentication required

408 Request time-out         409 Conflict

410 Gone                     411 Length required

413 Request entity too large 414 Request-URL too large

415 Unsupported media type   420 Bad extension

480 Temporarily not available

481 Call leg/transaction does not exist

482 Loop detected

484 Address incomplete       483 Too many hops

486 Busy here                485 Ambiguous

488 Not acceptable here      487 Request canceled

 

Server error

Server error responses indicate that a server was unable to respond to a valid request message. Server error responses include the following reason codes and reason phrases:

500 Server internal error

501 Not implemented

502 Bad gateway

502 Service unavailable

504 Gateway time-out

505 SIP version not supported

 

Global failure

Global failure responses indicate that there are no servers available that can respond to a request message. Global failure responses include the following reason codes and reason phrases:

600 Busy everywhere

603 Decline

604 Does not exist anywhere

606 Not acceptable

 

SIP message start line

The first line in a SIP message is called the start line. The start line in a request message is called the request- line and the start line in a response message is called the status-line.

 

Request-line             The first line of a SIP request message. The request-line includes the SIP message type, the SIP protocol version, and a Request URI that indicates the user or service to which this request is being addressed. The following example request-line specifies the INVITE message type, the address of the sender of the message (inviter-@example.com), and the SIP version:

INVITE sip:inviter@example.com SIP/2.0

 

Statusline

The first line of a SIP response message. The status-line includes the SIP protocol ver- sion, the response code, and the reason phrase. The example status-line includes the SIP version, the response code (200) and the reason phrase (OK).

SIP/2.0 200 OK

 

SIP headers

Following the start line, SIP messages contain SIP headers (also called SIP fields) that convey message attributes and to modify message meaning. SIP headers are similar to HTTP header fields and always have the following format:

<header_name>:<value>

SIP messages can include the SIP headers listed in the following table:

 

SIP headers

SIP Header              Description

Allow                         Lists the set of SIP methods supported by the UA generating the message. All meth- ods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. For example:

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

 

CallID

A globally unique identifier for the call, generated by the combination of a random string and the sender’s host name or IP address. The combination of the To, From, and Call-ID headers completely defines a peer-to-peer SIP relationship between the sender and the receiver. This relationship is called a SIP dialog.

Call-ID: ddeg45e793@10.31.101.30

 

Contact                     Included in SIP request messages, the Contact header contains the SIP URI of the sender of the SIP request message. The receiver uses this URI to contact the sender. For example:

Contact: Sender <sip:sender@10.31.100.20>t

 

Content-Length

The number of bytes in the message body (in bytes).

Content-Length: 126

 

SIP Header              Description

Content-Type           In addition to SIP headers, SIP messages include a message body that contains information about the content or communication being managed by the SIP session. The Content-Type header specifies what the content of the SIP message is. For example, if you are using SIP with SDP, the content of the SIP message is SDP code.

Content-Type: application/sdp

 

CSeq

The command sequence header contains a sequence integer that is increased for each new SIP request message (but is not incremented in the response message). This header also incudes the request name found in the request message request- line. For example:

CSeq: 1 INVITE

 

Expires                     Gives the relative time after which the message (or content) expires. The actual time and how the header is used depends on the SIP method. For example:

Expires: 5

 

From

Identifies the sender of the message. Responses to a message are sent to the address of the sender. The following example includes the sender’s name (Sender) and the sender’s SIP address (sender@10.31.101.20.):

From: Sender <sip:sender@10.31.101.20>

 

Max-forwards           An integer in the range 0-255 that limits the number of proxies or gateways that can forward the request message to the next downstream server. Also called the number of hops, this value is decreased every time the message is forwarded. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain.

For example: Max-Forwards: 30

 

PAssertedIden– tity

The P-Asserted-Identity header is used among trusted SIP entities to carry the identity of the user sending a SIP message as it was verified by authentication. See RFC

  1. 3325. The header contains a SIP URI and an optional display-name, for example:

P-Asserted-Identity: “Example Person” <sip:10.31.101.50>

 

RAck                         Sent in a PRACK request to support reliability of information or provisional response messages. It contains two numbers and a method tag. For example:

RAck: 776656 1 INVITE

 

SIP Header              Description

 

RecordRoute

Inserted into request messages by a SIP proxy to force future requests to be routed through the proxy. In the following example, the host at IP address 10.31.101.50 is a SIP proxy. The lr parameter indicates the URI of a SIP proxy in Record-Route head- ers.

Record-Route: <sip:10.31.101.50;lr>

 

Route                        Forces routing for a request message through one or more SIP proxies. The following example includes two SIP proxies:

Route: <sip:172.20.120.10;lr>, <sip:10.31.101.50;lr>

 

RSeq

The RSeq header is used in information or provisional response messages to support reliability of informational response messages. The header contains a single numeric value. For example:

RSeq: 33456

 

To                              Identifies the receiver of the message. The address in this field is used to send the message to the receiver. The following example includes the receiver’s name (Receiver) and the receiver’s SIP address (receiver@10.31.101.30.):

To: Receiver <sip:receiver@10.31.101.30>

 

Via

Indicates the SIP version and protocol to be used for the SIP session and the address to which to send the response to the message that contains the Via field. The fol- lowing example Via field indicates to use SIP version 2, UDP for media com- munications, and to send the response to 10.31.101.20 using port 5060.

Via: SIP/2.0/UDP 10.31.101.20:5060