Alcatel OmniTouch ACS 7.1.4, Site Preparation Manual

Page: 34 / 150

............................................................................................................................................................................................................................................................
To prepare your network Planning Your OmniTouch ACS Stack
6 - 2 8AL90212USAC ed01
November 20, 2008
............................................................................................................................................................................................................................................................
– If your OmniTouch ACSs have 1Gbit secondary (eth1) Ethernet interfaces,
obtaining and enabling your switch ports for 1Gbit will ensure plenty of bandwidth
for all stacked configurations.
– For PSTN OmniTouch ACSs, all calls that require mixing go directly across the
stack backplane. Thus, PSTN stack backplanes require more bandwidth than VoIP
backplanes (
see Appendix B for a discussion of stack backplane bandwidth).
However, PSTN OmniTouch ACS servers have 8 or fewer T1/E1 interfaces (less
than 240 ports maximum).
– For VoIP OmniTouch ACSs, Alcatel-Lucent recommends 1Gb ports, to allow for
future expansion.
Note:
In an OmniTouch ACS stack, PSTN requires more backplane bandwidth
than VoIP because there is also audio being transmitted.
........................................................................................................................................................................................................................
3
Design DNS framework.
– DNS servers that resolve the stack name should be configured to resolve the stack
name to a set of records, one for each application server in the stack. (There are
usually 2 application servers in a stack). This will help browsers to connect
correctly in the event of application server failover. Note that browsers differ in the
speed of detection and switching to alternate addresses; users’ patience may time
out before the browser does, in which case they will manually close and re-open the
browser and then successfully reopen the application
– If you are using VoIP, performance over application server failover will be
improved if name resolution in your network is provided by a “smart DNS” server
or load balancer which can detect application server failure, and preemptively
route application server requests to the other application server. In the absence of
such a capability, SIP requests may be dropped if the device generating the SIP
requests does not detect the failure and switches to the secondary server. Note that
it does no harm to send requests to the secondary server if the primary is up; the
request will be serviced correctly with just a slight increase in signaling latency.
Providing such a DNS framework is standard practice in many server farms.
– If the DNS framework resolves the stack name to different servers in an arbitrary
fashion, this will not impact SIP. SIP requests are indifferent as to which server in a
stack they are routed to; OmniTouch ACS (My Teamwork) will proxy them to the
correct destination. Similarly, HTTP/HTTPs requests will be proxied or redirected
appropriately. However, IM sessions are statefull; if the URL used for instant
messaging resolves to a different server than that on which the session is initiated,
the session will be lost.