PG电子赏金船长试玩版

書名： Building Enterprise Ready Telephony Systems with sipXecs 4.0
作者名： Michael W. Picher
本章字數： 2877字
更新時間： 2021-04-01 14:04:58

Plan the installation

Begin the planning phase of the installation by utilizing the data collected. Fill this data into spreadsheets, which can be used during the installation. The call flow will be designed and then the network configuration will be diagrammed.

Extension planning

Extensions are required for most devices on the system. To avoid re-numbering user extensions, it is important to think about the organization and plan for the future. If a single site is all that is required, a three-digit dial plan can be utilized. If multiple sites are required, at least a four-digit plan will be needed.

The only new concept that will be added here is that of a phantom extension. A phantom extension is a typical user extension that does not have a phone registered to it. Phantom extensions can be utilized for general delivery mailboxes and call routing.

The following table can be utilized for planning extension use:

For an organization with two sites, with one hundred or so users at each, the extensions might be planned out as follows:

In the preceding extension plan, each site uses five hundred extensions. Two hundred extensions are utilized for telephone extensions (one hundred more than needed with yet another one hundred between users and phone system services). Forty extensions are reserved for hunt groups, twenty extensions are reserved for park orbits, ACD queues have twenty reserved, auto attendants have another 20 extensions, and finally, phantom extensions have fifty extensions reserved. Enough buffer has been left on each side of each extension range to allow for unplanned growth.

Users and phones

The sipxconfig service has the ability to import user and phone information to speed up deployment. If you have a small number of users, you may just want to add them one by one. For large numbers, however, importing is the way to go and if the following table is saved as a Comma Separated Values (CSV) file, it can be directly imported. Either way, organize your collected data and utilize a spreadsheet with the following rows to speed up deployment:

User name: This is extension the user will use. Extensions typically start at 200 and go up from there.
Voice-mail PIN: This is the password for the user to go into his or her voicemail. It also is the password for entry into the user portal.
SIP password: The SIP password is the password the phone will use to register. It should be complex and must consist of at least eight letters (upper and lower case) and numbers.
First name: This is the user's first name.
Last name: This is the user's last name.
User alias: The user alias is something other than a number that can be used to dial the user. Consider adding their email alias here (if the user's email address is <tuser@company.com>, his or her alias would be tuser). This will allow the user to be dialed across the Internet from a softphone.
Email Address: The user's email address can be used to forward his or her voicemail.
User group: Define groups of users to better manage settings for multiple users. This field can be left blank if you are not sure about what groups you might use. User groups define permissions for users such as Superadmin Access, Change PIN from IVR, Configure Personal Auto Attendant, 900 Dialing, International Dialing, Local Dialing, Long Distance Dialing, Toll Free Dialing, Voicemail, Record System Prompts, and Internal Voicemail Server, or Microsoft Exchange UM Voicemail Server.
Phone serial number: This will be the Ethernet MAC address of the physical phone that the user will have. If the user has a softphone, this will be left blank.
Phone model: This will be the model of the managed IP phone that the user will have. If this phone will not be managed (that is, a softphone or not in the list of supported managed phones), this field should be left blank. If you know the web interface has support for the phone model you need, try to extrapolate the phone model from this list (for example, polycom9000). These are some of the phones that are managed as of this writing: polycom300, polycom430, polycom500, polycom550, polycom650, polycom600, polycom4000, cisco7960, cisco7940, cisco18x, cisco7905, cisco7912, gsPhoneBt, gsPhoneGxp, gsPhoneGxv3000, gsHt286, gsHt386, gsHt486, gsHt488, gsHt496, snom300, snom320, and snom360.
Phone group: Just as with users, phones can be grouped and managed more easily. Consider groups of phones by department or by type of phone (for example, Poly330 or FrontOffice).
Phone description: A description of the phone may be added. It may be convenient to put the name of the user assigned to the phone here.

Populate the table with information gathered during the information gathering phase. The only field that allows spaces in the data is the "Phone description" field. If you haven't ordered or received phones, fill in this information just before deployment.

Define permissions for user groups

A table with the following rows will help with defining the groups of user privileges:

Group Name: Name of the group.
Superadmin Access: User can log into administration interface.
Change PIN from IVR: User can change PIN value from the voicemail system. PIN is used to log into voicemail system and web interface. PIN does not affect the password that phones use to authenticate with registration server.
Configure Personal Auto Attendant: User can configure personal auto attendant.
900 Dialing: User can dial 900 numbers.
Attendant Directory: List user in auto attendant.
International Dialing: User can dial international numbers.
Local Dialing: User can dial local numbers.
Long Distance Dialing: User can dial long distance numbers.
Mobile Dialing: User can dial mobile numbers.
Toll Free: User can dial toll free numbers.
Voice Mail: User has a voicemail inbox.
Record System Prompts: User can record system prompts.
Internal Voicemail Server: User has permissions for Internal Voicemail Server.
Microsoft Exchange UM Voicemail Server: User has permissions for Microsoft Exchange UM Voicemail Server.

Groups and users can only have either Internal Voicemail Server or Microsoft Exchange UM Voicemail Server selected.

Call flow

Plan out how calls flow through the organization. Utilize any call flow information gathered previously and modify the call flow if it does not meet the current needs of the organization. Of interest here is developing how the system should work for the organization without worrying about the specifics of how to make the system work.

In the planning phase, the call flow needs to be detailed out to simplify the programming of the phone system. For example, if the call flow defines that inbound calls to telephone number 555-555-5555 during the day ring 'Reception', then 'Reception' needs to be defined. Is it a hunt group of three users, or an ACD group that handles inbound calls, or just a single user at the front desk phone? What happens if that call does not get answered? Does the call go to an auto attendant, or does it go to voice mail? Planning out this call flow is important to how the organization is viewed by its callers.

If the call flows identified in the information gathering phase are complete and function properly for the organization, the job is simpler. Review the following sections and develop the detail behind each of the call destinations by utilizing the previously gathered information as a base.

If a phone system doesn't presently exist for the organization, the call flow needs to be clearly defined. Build flowcharts detailing work-day call flows and after hours/weekend call flows. All call flows should have some sort of destination. These destinations will be one of these four things: an auto attendant, a hunt group, an ACD queue, or an individual user/mailbox.

The two most important call flows to identify are the inbound calls during the day and the inbound calls after hours. All other call flows should build from these.

Auto attendants

If the organization utilized auto attendants previously, much of the information from the information gathering phase can be utilized. Typically, for a good auto attendant design, do not go more than two auto attendants deep. Callers become annoyed if they have to go down through too many layers.

For each auto attendant envisioned, the following table should be completed:

The columns of the table can be explained as follows:

DTMF Timeout: The time to wait between each dial pad key before interpreting the user's request (cannot be greater than Overall DTMF Timeout).
Overall DTMF Timeout: The total time to wait before interpreting a user's request.
Maximum DTMF Digits: The maximum number of dial pad keys to accept before interpreting the user's request.
Replay Count: The number of times the auto attendant will repeat the prompt after the initial announcement due to no input being received from the user before giving up and transferring the call or disconnecting.
Invalid Response Count: The number of times the user can input an invalid response before transferring the call or disconnecting.
Transfer on Failures: If enabled, the auto attendant will transfer the call to a designated extension if no valid response is received. If disabled, the call will be disconnected.
Transfer Extension: The extension to be used when transfer on failure is enabled.
Prompt to play when transferring call on failure: The message that a user will hear when being transferred on failure.

Hunt groups

Hunt groups in sipXecs are defined with the following information: name, extension (pilot number), description of the purpose, whether to allow forwarding to extensions users may have their phone forwarded to, sequencing of the hung group entries, their timeout values, and what to do on failure to reach any user (a fallback extension or go to the voicemail box of the last user in the list). The following table will assist with planning hunt groups:

In the preceding example, the engineering hunt group has a pilot number of 2301. When a call is made to 2301, the extensions 2010 and 2012 ring for 30 seconds. After 30 seconds, the extension 2014 rings for 30 seconds. If the call is not answered, the user is directed to voicemail for the extension 2014.

Notice that no circular or linear hunt group is defined as we may have when data was collected. sipXecs does not support the concept of circular hunt groups. Additionally, extensions cannot be utilized in the above hunt group list more than once. If some sort of circular ringing is required, consider utilizing an ACD queue instead.

ACD queues

If ACD Queues are required in the new system, their detail needs to be thought out beforehand. The following table will help capture all of the information required for each ACD Queue:

The columns of the table can be explained as follows:

Overflow type: Calls will either overflow to a hunt group or another ACD queue.
Overflow destination: The destination will be a hunt group pilot number or the name of the overflow ACD queue.
Overflow entry: If no hunt group or overflow queue is defined, the call can be transferred to this extension or SIP URI.
Call routing scheme: The ACD call routing scheme that will be employed on this queue. The options are Ring All, Circular, Linear, and Longest Idle Agent.
Maximum ring delay: This is the maximum time in seconds that the queue will allow an agent station to ring before a ring-no-answer condition is declared and the call is re-routed to a different agent.
Maximum queue length: This is the maximum number of calls that are allowed to wait in this queue. If a call arrives at this queue and the resulting call count exceeds this number, then an overflow condition for this queue will be triggered. A value of "-1" disables this limit check.
Maximum wait time: The maximum time in seconds that a call can reside in a queue. When a waiting call exceeds this time limit, an overflow condition for this queue will be triggered. A value of zero disables timeouts.
FIFO overflow: If "Yes", then an overflow condition occurs and a First-In, First-Out (FIFO) scheme will be employed in order to determine which call will be moved to the configured overflow queue. If not set, then a Last-In, First-Out (LIFO) scheme will be employed.
Answer mode: If set to "Immediate", the call will be answered immediately upon arriving at this queue and the configured welcome-audio file will be played to the caller. Once the audio has completed, the queue will then attempt to route the call. If set to "Deferred", the queue will first attempt to route the call and if it is unable to immediately route the call, it will then be answered. If set to "Never", the call will not be answered while on this queue; but will be answered when actually connecting to an agent.
Barge in: If set, the welcome audio will be terminated early should an agent become available while it is being played.
Welcome audio: The welcome audio is a WAV file that is played to callers. If no file is specified, there will be silence.
Queue audio: The queue audio is a WAV file that is played repeatedly to the caller until the queue either routes the call to an agent or to another queue.
Audio interval: This is the interval in seconds before repeating the play of the specified queue audio. If the queue audio is actually longer than this time, it will be terminated and restarted from the beginning.
Call termination audio: This is the WAV file message that is played to the caller when it has been determined that the call must be terminated. Once the audio has completed, the call will be dropped. If no audio is specified, then a busy tone will be played prior to terminating the call. The duration of the busy tone is specified by the termination-tone-duration attribute.
Termination tone duration: This is the duration in seconds that the termination tone (busy tone) is to be played if no call-termination audio is specified and the call is to be dropped by the queue. A value of zero indicates that no tone is to be played prior to dropping the call.
Agent wrap-up time: The period of time in seconds that has to pass before the ACD transfers a new call to an agent after a previous call has been completed. If set to 0, it will be disabled.
Agent non-responsive time: The period of time in seconds that has to pass before the ACD transfers a new call to an agent after a previous call was not answered.
Maximum bounce count: The number of rejected or non-answered calls an agent may have before being "bounced" (automatically signed out of the ACD queue). If set to 0, it will be disabled.

Network planning

Plan out the network changes required. Start with making some decisions about virtual networks and IP addressing. VLANs are strongly encouraged, though not required, for all of the reasons stated in the Equipment selection section of this chapter.

Physical network

Plan the physical network connectivity by starting with a network diagram. The following network diagram details the physical network's critical components and IP addressing information:

Virtual network

The virtual network diagram should look decidedly different from the physical network diagram. In planning the virtual network, pay particular attention to how routing between the data VLANs and phone VLANs will be handled. Not all firewalls are not able to route internal traffic. If this is the case with the firewall in use at the organization, the default gateway may need to be relocated to the Layer 3 switch (assuming that it can route between VLANs). This routing should be tested as the new network is deployed.

The following network diagram details the virtual network's critical components and IP addressing information:

Site preparations

Once the network diagram is complete, consider where all of the equipment is to be physically located as well as how it is connected. Identify any new network connections required to complete the new network configuration. Identify any services that need to be extended from the demarc to where the gateways will be located.

Verify that ample power supply is in each network closet and that adequately sized UPS equipment has been identified for each closet. Ensure that proper ventilation and/or cooling systems are in place in each closet.

Document additional network information

Some additional information should now be added to the site IP addressing table. One seemingly simple decision that needs to be made is what the SIP domain will be. This decision can have some wide-ranging implications.

One of the goals of a SIP system is to simplify communications. One way to help simplifying communications is by utilizing the same email and SIP phone addresses. For instance, if I want to email Bob Jones at XYZ Company, it would be very convenient if his email address and phone number were both <bjones@xyzcompany.com>.

In order to support this functionality, the external DNS hosting provider needs to support SRV records. Also, the network administrator for the internal network will need to maintain an internal copy of the external domain on the internal DNS server. The internal copy of the external DNS host names should reference internal IP addresses of local network resources instead of any external references that might be pointed at the organization's firewall.

官术网_书友最值得收藏!

Building Enterprise Ready Telephony Systems with sipXecs 4.0