ou might not deploy SIP trunk without a firewall. But the big problem with SIP is that it uses a wide range of ports to transmit media. If you keep all these ports open into your firewall, your network is open for vulnerability. We see firewalls that can open pinholes intelligently. You can check with your SBC vendor, too. Closing and opening media pinholes on a session-by-session basis. By default, all pinholes should be closed. Pinholes should not be opened until explic- itly configured or signaled via session initiation. Pinholes for a session should be closed immediately after the appropriate session ter- mination signaling. Threat Protection Any IP network is always subject to certain levels of threats. You cannot stop it; instead, you need to take protection measures to safeguard your network. One interesting thing to know is that most of the attacks come from inside the network. Put the following questions in your RFP and see how the SBC handles those attacks: Does the product support DoS protection? Does the product support DDoS protection? Does the product enable trusted/authenticated users access while under DoS attack? Does the product support blocking L3/4 attacks (for example, TCP, SYN, ICMP, fragments, IP spoofing, and SO on)? Does the product support blocking L5 attacks (for example, SIP signaling floods, malformed messages, Rogue RTP Detection, and SO on)? Does the product support blocking spoofing, masquerading, and toll fraud? Does the product support blocking and verify anomalous behavior? Does the product support virus protection? Does the product support Spam over Internet Telephony (SPIT) attacks? Does the product support auto and manual threat signature updates? Does the product implement real-time caller verification to protect against script- based attacks? Policy You will always put some policy into the network, but your SBC might not implement those. We see some good policy servers that keep all policies in the central location and execute them locally in the SBC. Even if you are not de