• SonicOS and SonicOSX 7 VoIP
• VoIP
  • VoIP Security
    • Security Appliance Requirements for VoIP
  • VoIP Protocols
    • H.323
    • SIP
  • SonicWall’s VoIP Capabilities
    • VoIP Security
    • VoIP Network
    • VoIP Network Interoperability
    • Supported Interfaces
    • Supported VoIP Protocols
      • H.323
      • SIP
      • SonicWall VoIP Vendor Interoperability
      • CODECs
      • VoIP Protocols on which SonicOS/X Does Not Perform Deep Packet Inspection
    • BWM and QoS
      • Quality of Service
    • How SonicOS/X Handles VoIP Calls
      • Incoming Calls
      • Local Calls
• Settings
  • Configuring VoIP Settings
    • General Settings
    • SIP Settings
      • Enabling SIP
    • H.323 Settings
      • Configuring Bandwidth on the WAN Interface
      • Configuring VoIP Access Rules
  • Configuring VoIP Logging
• Call Status
• SonicWall Support
  • About This Document

Security Appliance Requirements for VoIP

VoIP is more complicated than standard TCP/UDP-based applications. Because of the complexities of VoIP signaling and protocols, as well as inconsistencies that are introduced when a Security Appliance modifies source address and source port information with Network Address Translation (NAT), it is difficult for VoIP to effectively traverse a standard Security Appliance. Here are a few of the reasons why.

• VoIP operates using two separate protocols - A signaling protocol (between the client and VoIP Server) and a media protocol (between the clients). Port/IP address pairs used by the media protocols (RTP/RTCP) for each session are negotiated dynamically by the signaling protocols. Firewalls need to dynamically track and maintain this information, securely opening selected ports for the sessions and closing them at the appropriate time.
• Multiple media ports are dynamically negotiated through the signaling session - negotiations of the media ports are contained in the payload of the signaling protocols (IP address and port information). Firewalls need to perform deep packet inspection on each packet to acquire the information and dynamically maintain the sessions, thus demanding extra Security Appliance processing.
• Source and destination IP addresses are embedded within the VoIP signaling packets - A Security Appliance supporting NAT translates IP addresses and ports at the IP header level for packets. Fully symmetric NAT Security Appliances adjust their NAT bindings frequently, and may arbitrarily close the pinholes that allow inbound packets to pass into the network they protect, eliminating the service provider's ability to send inbound calls to the customer. To effectively support VoIP it is necessary for a NAT Security Appliance to perform deep packet inspection and transformation of embedded IP addresses and port information as the packets traverse the Security Appliance.
• Firewalls need to process the signaling protocol suites consisting of different message formats used by different VoIP systems - Just because two vendors use the same protocol suite does not necessarily mean they interoperate.

To overcome many of the hurdles introduced by the complexities of VoIP and NAT, vendors are offering Session Border Controllers (SBCs). An SBC sits on the Internet side of a Security Appliance and attempts to control the border of a VoIP network by terminating and re-originating all VoIP media and signaling traffic. In essence, SBCs act as a proxy for VoIP traffic for non-VoIP enabled Security Appliances. SonicWall Security Appliances are VoIP enabled Security Appliances that eliminate the need for an SBC on your network.

VoIP is supported on all SonicWall appliances that can run SonicOS/X, as long as the VoIP application is RFC-compliant.