Filter
Top Products
SIP
Issue 6 January 2008 139
SIP deployment scenarios
SIP and DNS
In all SIP configurations it is highly recommended to use both Dynamic Name System (DNS)
and Dynamic Host Configuration Protocol (DHCP). The customer must have DNS running in the
enterprise for external lookups. Proper DNS configuration allows for proper server resolution,
including external domains, as well as ease of provisioning within the intranet. The SIP domain
is used for addressing at the SIP level, such as sending an invite to user1@avaya.com. DNS is
used for looking up individual host addresses in a network. This allows a SIP user to move
around the SIP network, registering at different locations in the IP network, and even using
different phones, while maintaining a common public address – e.g. user1@avaya.com.
SES only supports a single SIP domain in a deployment. This domain is usually the top level
domain for that enterprise, e.g. avaya.com. Often people reference the cs.columbia.edu
configuration which at first glance looks like a sub-domain of columbia.edu. From the SES
perspective, configuring a system like cs.columbia.edu and columbia.edu would be two
separate domains and each one would view the other as an external domain. Each system
would be viewed like any other deployment, having it’s own administration, users, etc.
Home-edge single box solution
SES is available as a single box solution in any of the releases. The home/edge system is the
most straightforward configuration and includes configuration of surrounding services for proper
operation. An Access Layer Gateway (ALG) is required for traversing the firewall. SIP capable
ALGs are required to handle the appropriate ports/address translation needed for SIP signaling
and RTP media.
Figure 49:
Typical home/edge configuration on page 140 shows a typical home/edge
configuration which is valid for any release. Additionally a remote-end user using a VPN tunnel
is shown. While SES may support TLS, TCP and UDP as transport protocols, the use of
Transport Layer Security (TLS) is recommended whenever possible. The 2.0 and 2.1 releases
include presence between Softphone clients, but no subscriptions to Communication Manager
extensions and no presence server. The 3.0 release includes the presence server for additional
presence features and policy management.