Amer Networks E5Web GUI - Manual (Page 411)

Important: Third Party Equipment Compliance
cOS Core is based on the SIP implementation described in RFC 3261. However, correct
SIP message processing and media establishment cannot be guaranteed unless local
and remote clients as well as proxies are configured to follow RFC 3261.
Unfortunately, some third party SIP equipment may use techniques that lie outside RFC
3261 and it may not be possible to configure the equipment to disable these. For this
reason, such equipment may not be able to operate successfully with the cOS Core SIP
ALG.
For example, analog to digital converters that do not work with the SIP ALG may come
pre-configured by service providers with restricted configuration possibilities.
NAT traversal techniques like STUN also lie outside of RFC 3261 and need to be disabled.
cOS Core Supports Three Scenarios
Before continuing to describe SIP in more depth, it is important to understand that cOS Core
supports SIP usage in three distinct scenarios:
• Protecting Local Clients
In this scenario, the proxy is located somewhere on the public Internet.
• Protecting Proxy and Local Clients
Here, the proxy is located on the same network as the clients. However, this case can be
divided into two scenarios:
i. The clients and proxy are on an internal, trusted network.
ii. The clients and proxy are on the DMZ network.
Traffic Shaping with SIP
Any traffic connections that trigger a cOS Core IP rule with an associated service object that uses
the SIP ALG cannot also be subject to traffic shaping.
SIP Components
The following components are the logical building blocks for SIP communication:
User Agents These are the end points or clients that are involved in the client-to-client
communication. These would typically be the workstation or device used in
an IP telephony conversation. The term client will be used throughout this
section to describe a user agent.
Proxy Servers These act as routers in the SIP protocol, performing both as client and
server when receiving client requests. They forward requests to a client's
current location as well as authenticating and authorizing access to
services. They also implement provider call-routing policies.
The proxy is often located on the external, unprotected side of the Clavister
Security Gateway but can have other locations. All of these scenarios are
Chapter 6: Security Mechanisms
411