mensajejs2009

saludo

Bug en CentOS 5.2 y zaptel

Al intentar compilar los módulos de zaptel en CentOS 5.2 se produce un error. La descripción del mismo y su solución pueden verla en este enlace.

CCIP y VoIP conceptos para un diseño

Best Practices for VoIP in the Contact Center; Part 1: Planning a Successful Transition


Written by Lori Bocklund and Brian Hinton

Once you’ve decided to implement VoIP, you’ll need a plan that will help you decide what you want to gain, who can help guide the process, how you will communicate your vision internally, and how to evaluate your options.
Voice over Internet Protocol (VoIP) has reached a new level of maturity in the contact center industry. We can now shift the conversation from “Why should I do VoIP?” to “When and how should I move to VoIP?”
Because VoIP is such a rich, deep and complex topic, defining best practices for planning, implementation and support requires more than one article. Therefore, this article is the first in a series to help those that are on their way to VoIP — or anticipate they soon will be — to prepare for a successful transition that has lasting business value for the company and the center.
Start a VoIP Planning Process
VoIP offers many opportunities for delivering business value. While the multisite is the “killer application” for VoIP, single-site environments can also find business value in this new system, including pseudo-multisite configurations for remote agents in satellite offices or homes, and business continuity and multimedia contact center operations.
What value do you expect to derive from VoIP? Most find reducing costs and adding flexibility and agility to adapt to changing business needs are two of the main drivers. Others include:
· Agent efficiency and a common routing and reporting engine across all sites through virtualization
· Reduced technology costs through centralized intelligence for a distributed network of sites
· IT operations, administration and maintenance efficiency through multisite centralization
· Operating efficiencies considering aggressive growth or acquisitions, or the need for more distributed staff
· Operating efficiencies for multimedia contact handling (e.g., email, text chat, Web collaboration, fax in addition to voice calls), including a common routing and reporting engine for all media
· Enhanced disaster recovery/business continuity strategies
· Peak call-handling flexibility/agility
· Readily tap escalation re­sources across the enterprise
· Facilitate home agents or satellite offices for an expanded, flexible labor pool
When is a good time to transition? There are many events likely to force discussions on platforms, vendors and architectures, and generally will lead to a path to VoIP — whether through gradual transition of a hybrid platform or outright conversion to VoIP. Some of the triggers that prompt the transformation include:
· Out of support technology or other reason for considering upgrade or replacement
· Major growth
· New site, facility or move
· Merger or acquisition
· Leadership change, cultural change, power shift or other organizational event
· Replacing or pursuing adjunct applications such as CTI, QM, WFM
· Reorganization or other operational change that tears down silos by site or group
· Vendor dissatisfaction
Companies find many reasons to move to VoIP. Then the real planning can begin.
Build a Crossfunctional Team
Implementing VoIP in the contact center impacts several areas of the organization. It is essential that a team made up of representatives from contact center operations, IT and Telecom coordinates the VoIP project. Table 1 lists the minimum required team and purpose of each player’s involvement.
The primary project sponsor will likely come from IT or the contact center(s). However, the project has limited possibilities for success without all of these departments involved as stakeholders in the transition. Some projects also include analysts, training representatives, human resources, change management and others, at least for specific meetings dealing with issues pertinent to them.
Table 1. Crossfunctional Team Members and Their Roles


Develop a Vision
With the team in place, the next step in VoIP planning is to develop a clear vision that is communicated and understood throughout IT and call center operations leadership. Everyone must see how VoIP will help the center achieve the defined business goals, what it will look like in the organization, why it makes sense, and the path to get there.
It is also important that IT understand how the new system architecture fits in its overall goals and strategic directions, and how it will successfully implement and support the new environment. Because there is more than one way to implement VoIP, you will need to develop a VoIP technology strategy and transition plan as part of the vision. The technology strategy and plan lead to architectural decisions for IT and functional capabilities for the center.
Consider Options, Choices and Design Decisions
One of the primary responsibilities of the team and one of the key components of the technology plan is to decide what VoIP really means in the organization, given the variety of ways to implement it. The choices depend on many factors, including the current infrastructure (in­vestment, configuration, age, support, vendor, network readiness, etc.), the business goals and the triggering events pointing to VoIP. The approach will differ for an enterprise versus a contact center focus, and for evolving the current platform with the existing vendor versus replacing the current system.
A good starting point in considering all the options, choices and design decisions the team must make is to take stock of the factors and influences in the current environment. Then you can proceed through the planning phases shown in Figure 1 on the previous page.
VoIP can primarily be for call management (agent availability and routing decisions), delivering the call to the desktop as TDM or VoIP — as data packets over the network. You will need to address the strategy for phone replacement and many other questions about the desktop: Gradually evolve to IP phones when TDM phones are at end-of-life (an option only when evolving the current vendor’s platform)? Move to IP on a standards-based phone based on Session Initiation Protocol (SIP) or a vendor’s own flavor of IP? Place phone controls on the PC (soft phone)? Put the voice path through the PC? Connect the PC to the phone and use the phone as a switch, or have two jacks and data paths to the desktop? Plug the IP phone in or use PoE (power over Ethernet)?
While these are just some of the design decisions faced when transitioning to VoIP, the following are others you’ll want to consider:
· Scope — enterprise or contact center(s) only
· Vendor — evolve current vendor or choose new vendor
· Overall architecture — hybrid/transition from TDM, full VoIP
· Sourcing — premise-based solution or hosted or managed services
· Other contact center applications — leveraging current or seeking new applications beyond routing and reporting — e.g., CTI, IVR, QM, WFM
· Server architecture — redundancy, locations for applications and media servers, gateways and interface devices
· Network architecture — termination locations and dial plan strategy for toll free and local, MPLS or other network protocol between sites, converged voice and data or separate voice network
· Endpoints — TDM or IP, soft phones and/or hard phones, SIP or proprietary if IP
· Desktop power strategy — PoE or local power, backup
· Desktop connectivity strategy — two jacks/network access, or single jack with PC connected to phone
· Encoding strategy — compression across WAN, or full G.711 throughout network
· Quality of Service strategy — what methods at what layers
· Security strategy — consistent with data networks and applications, or any differences for voice
· Testing and retesting/monitoring strategy — for jitter, latency and packet loss, at a minimum
A key decision is whether to integrate or replace other current applications. Many contact center VoIP vendors have other applications already integrated with their solutions. In fact, ACD, CTI and even IVR can be part of the core solution. Some vendors bundle quality monitoring and call recording, and even workforce management. Current investments, current use and the vendor solutions in play all impact these decisions. Table 2 summarizes considerations for key adjunct applications.
One of the benefits in a multisite environment is the ability to install the primary hardware/software in one or two hubs — reducing cost and facilitating business continuity/disaster recovery. Now more decisions arise: how many hubs, where will they be, and what gets installed at each location? With the data-like architectures of today’s voice systems, these hubs may reside in a data center rather than a call center location.
There are also some interesting blended options available that again depend on the current investment and architecture. Some companies with multiple sites and various, up-to-date PBXs at each site will use IP (not Voice over IP) for agent availability and routing decisions for pseudo-virtualization. Virtualization depends on tie-lines for call movement. Business value comes from agent efficiency through virtualization but not the IT/telephony benefit of VoIP with hubs and centralization. This can be a more complex and expensive environment to maintain and support. See Figure 2.

Figure 1. VoIP Planning


Table 2. Key Considerations for Adjunct Applications


Complete the VoIP Planning Process
With a vision, key decisions regarding options, and a common plan for virtualization in a multisite environment, you are nearly ready to move on to implementation.
Of course, standard best practices in project management apply. Document decisions and issues, and prepare a project plan that defines not only the technology steps but the related organizational, process and operations changes that will accompany the VoIP project. Prepare to involve the staff in the trenches — both in IT/telecom and the call center — if not already engaged.
Our next article in the series will provide best practices for implementation, covering the key steps for network preparation, design, configuration and development, testing, pilot, and rollout. Part 3 will provide the critical elements of supporting and effectively applying the new VoIP environment.

The Virtualization Opportunity
One of the primary drivers for VoIP is the cost savings through virtualization. This can be a result of agent virtualization and server/application virtualization across sites. The potential for agent efficiency through virtualization depends on the contact center’s virtualization readiness, and the degree of virtualization sought. The figure below shows varying degrees of virtualization, with greater change but also potential benefit on the far right end of the spectrum.
Figure 2: Virtualization Continuum

The maximum value from virtualization occurs for multisite or multiple, smaller functional groups that transition to any agent, any time routing schemes. However, this is often difficult to achieve in practice. Is every agent capable of handling every call? Can every agent access the required applications? Is it possible to train every agent to process every call type? Are there any licensing or other regional issues? Can processes be standardized across all sites/functions? In most centers, the answer to these questions is “not completely,” but there is usually some potential for cross-training, skills consolidation and process standardization. Many will start modestly and continue moving in the virtual direction. Define the process changes, application changes, training or technology such as Knowledge Management required to get the benefits of full virtualization. This decision and vision is a key part of planning for virtualization in a VoIP environment.


Best Practices for VoIP in the Contact Center; Part 2: Steps for a Successful Implementation
');
document.write('');
document.write('');
document.write('');
document.write('');
//-->




Written by Lori Bocklund and Brian Hinton
With your VoIP implementation plan in place, the relationship you’ve built with your IT department and vendor will really come into play. Take advantage of this teamwork to get the most value out of your project.
Voice over Internet Protocol (VoIP) has reached a new level of maturity in the contact center industry. We can now shift the conversation from “Why should I do VoIP?” to “When and how should I move to VoIP?”
Because VoIP is such a rich, deep, and complex topic, defining best practices for planning, implementation and support requires more than one article. Our first article addressed how to plan for VoIP and the important decisions to make regarding virtualization, technical design, functional capabilities and other factors. This article, the second in the series, focuses on implementation. We hope it will help those who are on their way to implementing VoIP — or anticipate that they soon will be — take all the right steps to be successful.
Click here to read Part 1: Planning a Successful Transition.
Build a Detailed Project Plan
Building a project plan marks the transition from planning to implementation. Oftentimes you can leverage the vendor’s project plan as a starting point or for input in building your master, internal detailed project plan. Be aware, however, that the vendor’s plan is generally very limited in scope, and you will probably need to document your detailed plan before the vendor’s is available.
The project plan links all the key players. Table 3 in Part 1 of this article series detailed the cross-functional team members and their roles. Each team member has critical functions to perform to ensure a successful migration. While IT probably knows it needs to prepare the network, and telecom probably knows it needs to prepare the facility for installation, and operations knows it needs to prepare the staff for process change, the detailed project plan is the only way to reveal dependencies among the various tasks so these many efforts come together at the right times.

First and Foremost — Properly Prepare the Network
There are many things that lead to a successful implementation but there is one item that is THE primary enabler of success — the data network has to be properly prepared to carry voice! Often, IT feels its data network is ready for VoIP or it can be with minimal changes. This position must be backed up by detailed assessment and testing. In reality, IT may need to make key changes and upgrades to make the network “VoIP ready.”
A comparison of traditional voice and data network characteristics (see Table 1 below) reveals why moving voice onto a data network should not be trivialized. A network built for the behavior of data packets is not adequate for carrying voice as data packets.
The differences in voice and data characteristics drive the following requirements for VoIP:
· We need quality controls that prioritize voice (quality of service, or QoS).
· We need to monitor and manage performance (latency, jitter and packet loss) to acceptable levels.
· We need to use different protocols (RTP/UDP vs. TCP) that emphasize speed over accuracy.
· We need highly reliable, scalable, secure networks.
· We need standards for voice that are adopted by all (with session initiation protocol, or SIP, being the “winning” standard in today’s market).
The addition of voice places new demands on the IT team even though many of the same principles for effective network and systems operation apply in creating secure communications and a scalable, reliable network. Voice traffic sizing must consider whether the voice is compressed or not. This decision generally applies across the WAN but not the LAN (most LANs today have adequate bandwidth so don’t require compression). Users accustomed to a “five nines” reliable voice environment expect their voice communications to continue to be available at all hours, in all circumstances. As we emphasize below, assessments, testing, and ongoing monitoring are keys to success.
Most likely, you will be putting voice on a converged (data and voice) network. Regardless, with VoIP you will be putting voice onto a network designed for data. Since voice and data communications have completely different characteristics, IT must monitor and manage the network differently to assure control of the voice packets for optimum delivery. Most companies apply QoS strategies to ensure tolerable delay in packet arrival (latency), variability (too late, too early or out of sequence) in packet arrival (jitter), and packet loss. For better network management and control, many change their network service between sites (across the WAN). Multi-protocol Label Switching (MPLS) is typically used as it enables voice packet prioritization.
Some companies take a more conservative approach and use a separate voice network to avoid either voice or data traffic suffering under load. This approach can solve network capacity projection concerns. It can also simplify the testing required. However, it comes at a greater network and resource cost.
A best practice is to have a thorough network assessment by your chosen vendor or a third party that specializes in network assessments. This assessment will identify changes required to your network for capacity and functionality, and may lead to switch and/or router upgrades or replacements. Your vendor needs to validate network readiness once you make the required upgrades. The data network must be load and quality tested prior to cutover as well as part of the ongoing network management.
Bottom line: For VoIP implementation success, the IT/networking staff has to guarantee that the network is secure, scalable and reliable to a degree to which it has not been accustomed for data communications.
Table 1: Traditional Voice and Data Network Characteristics


Dive in — Design, Develop/Configure and Integrate
Each design step, without exception, requires cross-functional involvement and a commitment of the appropriate time and resources. Onsite design sessions with active participation from IT, Telecom, Operations (including call center and other business users) and vendors will contribute to a successful implementation. (Make sure consultative design sessions are included in the vendor statement of work, or SOW.) Also, trainers need to be involved in the design meetings so they can develop and deliver training prior to cutover. The following list details some of the topics to discuss in these meetings:
· Routing for virtualization
· Call-flow design
· IVR usage
· Role of CTI
· Desktop applications — call/phone control/unified desktop/screen pop
· Multimedia contact routing
One of your main responsibilities is to manually document call flows, work flows, switch configuration and IVR set up into flow charts and spreadsheets so the vendor’s design engineers can “translate” the design into the new solution. This is a demanding process and is the source of business value at cutover when changes are made to the existing configuration. The tradeoff is ease of design and translation if you keep everything the same versus achieving business value sooner when you approach the design as a “green field” opportunity for improvement.
Before the vendor can install the solution onsite, you must prepare the facilities. Many vendors offer a site survey as part of the design process. The vendor will detail necessary upgrades to racks, power, heating/cooling, ventilation, space and additional cable requirements. Work closely with your vendor to ensure that the implementation is not delayed due to unprepared facilities.
The vendor will then use the design session outcomes to configure your solution within their system. Include knowledge transfer and onsite time in your vendor SOW if you intend to manage your own system going forward.
The complexity of the integration process depends on the solution you have chosen. If you are implementing a suite solution with all components pre-integrated, the primary issue will be the overall integration with your legacy data sources and any additional adjunct applications. If your solution is a mix of components, the vendor may be providing the components and the integration. Otherwise, if the solution includes separate vendors, IT and the telecom staff (and potentially third-party integrators) will have a major integration effort to implement the total solution.

When You’re Nearly Ready to Launch — Test, Train, Pilot and Rollout
Once the project team has designed the solution and the vendor has installed and configured the system, the next step is to test the system. It is crucial as part of the planning and design to determine where and how a testing and a training environment will be set up. Both environments need to be “live” early enough to allow for ade­quate testing and training. The vendor will begin with system operability and will test that the solution “works” as designed, that all the components “talk” to each other, and that any integration for which they were responsible was successful.
Once the vendor has determined the solution is ready for user testing, you will test all call flows in detail including all IVR applications (self-service). Develop a test script that includes every call path for every call flow option and conduct all appropriate test types and scenarios. IT and telecom staff will need to test the network capacity and resiliency of the entire configuration. Vendor involvement in this testing varies but at the very least they should be standing by to solve problems discovered in testing and stand behind their design.
Representatives from training identify changes during the design session for supervisor, agent and administrative staff that will require training prior to cutover. Changes for the front-line staff may be significant — more than getting familiar with a new phone. There will most likely be a completely new desktop interface and functionality. The vendor will often be responsible for administrative training and train-the-trainer for supervisors and agents. Sometimes the vendor will deliver training materials and hold the initial training sessions for the frontline staff. Define the training approach in the vendor SOW.
It is difficult to schedule enough time during implementation for testing and training, so be careful these crucial steps do not get lost in the rush to meet milestones. Additionally, the training cannot be so early that the frontline staff forgets prior to going live.
If organizational structure, systems and time allow, cutover can be more successful in a phased approach where any problems can be identified prior to a complete rollout. It is ideal to start with a small pilot group that tests the solution in production, with real customers. Once the pilot is successful, it is time for rollout generally by site, group, or function (rather than the “big bang” approach). Mitigate risks by cutting over during off-peak or closed hours.
Complete the VoIP Implementation Process
With the system in production across groups and sites, the company should start to reap the business value from its new VoIP technology. However, as with any new technology and operational change, it may take a few months for things to settle in and for the teams to work out all the kinks. Then, support be­comes critical to optimize technology application to business needs.
VoIP is a different world that creates new issues and opportunities for IT, Telecom, and support functions in the contact center. We will address this issue in our final article in the series: best practices for supporting and effectively applying the new VoIP environment.

Key Steps in the VoIP Implementation Process



Achieve Business Value Out of the Gate
Achieving business value isn’t easy, especially right from the start. Sometimes it is tempting to implement “as is” to minimize the overall impact of change, with the goal to really apply the new system capabilities later. This approach is dangerous, as it is even harder to change after implementation, and companies often lose resources and momentum after cutover (and, therefore, never achieve the changes and optimal business value). Pursuing operational change after implementing new technology that replicates the old approach will require an ongoing commitment or a whole new project and team. Using a formal change management process can mitigate the impact of the overall change. Our recommended best practice is to embrace the change and maximize business value during initial implementation.

Asterisk Detailed Variable List

Asterisk standard channel variables

There are a number of variables that are defined or read by Asterisk. Here is a list of them. More information is available in each application's help text. All these variables are in UPPER CASE only. Variables marked with a * are builtin functions and can't be set, only read in the dialplan. Writes to such variables are silently ignored.
${ACCOUNTCODE} * Account code (if specified) (Deprecated; use ${CDR(accountcode)})

${BLINDTRANSFER} The name of the channel on the other side of a blind transfer
${BRIDGEPEER} Bridged peer
${CALLERANI} * Caller ANI (PRI channels) (Deprecated; use ${CALLERID(ani)})
${CALLERID} * Caller ID (Deprecated; use ${CALLERID(all)})
${CALLERIDNAME} * Caller ID Name only (Deprecated; use ${CALLERID(name)}) ${CALLERIDNUM} * Caller ID Number only (Deprecated; use ${CALLERID(num)})
${CALLINGANI2} * Caller ANI2 (PRI channels)
${CALLINGPRES} * Caller ID presentation for incoming calls (PRI channels)
${CALLINGTNS} * Transit Network Selector (PRI channels)
${CALLINGTON} * Caller Type of Number (PRI channels)
${CHANNEL} * Current channel name
${CONTEXT} * Current context
${DATETIME} * Current date time in the format: DDMMYYYY-HH:MM:SS (Deprecated; use ${STRFTIME(${EPOCH},,%d%mNaVH:NaVS)})

${DB_RESULT} Result value of DB_EXISTS() dial plan function
${DNID} * Dialed Number Identifier (Deprecated; use ${CALLERID(dnid)})
${EPOCH} * Current unix style epoch
${EXTEN} * Current extension
${ENV(VAR)} Environmental variable VAR
${GOTO_ON_BLINDXFR} Transfer to the specified context/extension/priority after a blind transfer (use ^ characters in place of to separate context/extension/priority when setting this variable from the dialplan)
${HANGUPCAUSE} * Asterisk cause of hangup (inbound/outbound)
${HINT} * Channel hints for this extension
${HINTNAME} * Suggested Caller*ID name for this extension
${INVALID_EXTEN} The invalid called extension (used in the "i" extension)
${LANGUAGE} * Current language (Deprecated; use ${LANGUAGE()})
${LEN(VAR)} * String length of VAR (integer)
${PRIORITY} * Current priority in the dialplan
${PRIREDIRECTREASON} Reason for redirect on PRI, if a call was directed
${RDNIS} * Redirected Dial Number ID Service (Deprecated; use ${CALLERID(rdnis)}) ${TIMESTAMP} * Current date time in the format: YYYYMMDD-HHMMSS (Deprecated; use ${STRFTIME(${EPOCH},,%Y%mNaVH%M%S)})
${TRANSFER_CONTEXT} Context for transferred calls
${FORWARD_CONTEXT} Context for forwarded calls
${UNIQUEID} * Current call unique identifier
${SYSTEMNAME} * value of the systemname option of asterisk.conf Application return values
In Asterisk 1.2, many applications return the result in a variable instead of, as in Asterisk 1.0, changing the dial plan priority (+101). For the various status values, see each application's help text. ${AGISTATUS} * agi()
${AQMSTATUS} * addqueuemember()
${AVAILSTATUS} * chanisavail()
${CHECKGROUPSTATUS} * checkgroup()
${CHECKMD5STATUS} * checkmd5()
${CPLAYBACKSTATUS} * controlplayback()
${DIALSTATUS} * dial() - see also ${HANGUPCAUSE}
${DBGETSTATUS} * dbget()
${ENUMSTATUS} * enumlookup()
${HASVMSTATUS} * hasnewvoicemail()
${LOOKUPBLSTATUS} * lookupblacklist()
${OSPAUTHSTATUS} * ospauth()
${OSPLOOKUPSTATUS} * osplookup()
${OSPNEXTSTATUS} * ospnext()
${OSPFINISHSTATUS} * ospfinish()
${PARKEDAT} * parkandannounce()
${PLAYBACKSTATUS} * playback()
${PQMSTATUS} * pausequeuemember()
${PRIVACYMGRSTATUS} * privacymanager()
${QUEUESTATUS} * queue()
${RQMSTATUS} * removequeuemember()
${SENDIMAGESTATUS} * sendimage()
${SENDTEXTSTATUS} * sendtext()
${SENDURLSTATUS} * sendurl()
${SYSTEMSTATUS} * system()
${TRANSFERSTATUS} * transfer()
${TXTCIDNAMESTATUS} * txtcidname()
${UPQMSTATUS} * unpausequeuemember()
${VMSTATUS} * voicmail()
${VMBOXEXISTSSTATUS} * vmboxexists()
${WAITSTATUS} * waitforsilence() Various application variables
${CURL} * Resulting page content for curl()
${ENUM} * Result of application EnumLookup
${EXITCONTEXT} Context to exit to in IVR menu (app background()) or in the RetryDial() application ${MONITOR} * Set to "TRUE" if the channel is/has been monitored (app monitor()) ${MONITOR_EXEC} Application to execute after monitoring a call
${MONITOR_EXEC_ARGS} Arguments to application
${MONITOR_FILENAME} File for monitoring (recording) calls in queue
${QUEUE_PRIO} Queue priority
${QUEUE_MAX_PENALTY} Maximum member penalty allowed to answer caller
${QUEUESTATUS} Status of the call, one of: (TIMEOUT FULL JOINEMPTY LEAVEEMPTY JOINUNAVAIL LEAVEUNAVAIL)
${RECORDED_FILE} * Recorded file in record()
${TALK_DETECTED} * Result from talkdetect()
${TOUCH_MONITOR} The filename base to use with Touch Monitor (auto record) ${TOUCH_MONITOR_FORMAT} The audio format to use with Touch Monitor (auto record) ${TOUCH_MONITOR_OUTPUT} * Recorded file from Touch Monitor (auto record)
${TXTCIDNAME} * Result of application TXTCIDName
${VPB_GETDTMF} chan_vpb The MeetMe Conference Bridge uses the following variables:
${MEETME_RECORDINGFILE} Name of file for recording a conference with the "r" option ${MEETME_RECORDINGFORMAT} Format of file to be recorded
${MEETME_EXIT_CONTEXT} Context for exit out of meetme meeting ${MEETME_AGI_BACKGROUND} AGI script for Meetme (zap only)
${MEETMESECS} * Number of seconds a user participated in a MeetMe conference The VoiceMail() application uses the following variables:
${VM_CATEGORY} Sets voicemail category
${VM_NAME} * Full name in voicemail
${VM_DUR} * Voicemail duration
${VM_MSGNUM} * Number of voicemail message in mailbox
${VM_CALLERID} * Voicemail Caller ID (Person leaving vm)
${VM_CIDNAME} * Voicemail Caller ID Name
${VM_CIDNUM} * Voicemail Caller ID Number
${VM_DATE} * Voicemail Date
${VM_MESSAGEFILE} * Path to message left by caller The VMAuthenticate() application uses the following variables:
${AUTH_MAILBOX} * Authenticated mailbox
${AUTH_CONTEXT} * Authenticated mailbox context DUNDiLookup() uses the following variables
${DUNDTECH} * The Technology of the result from a call to DUNDiLookup()
${DUNDDEST} * The Destination of the result from a call to DUNDiLookup() The Zaptel channel sets the following variables:
${ANI2} * The ANI2 Code provided by the network on the incoming call. (ie, Code 29 identifies call as a Prison/Inmate Call) See also: NANPA ANI II Digits Assignments
${CALLTYPE} * Type of call (Speech, Digital, etc)
${CALLEDTON} * Type of number for incoming PRI extension i.e. 0=unknown, 1=international, 2=domestic, 3=net_specific, 4=subscriber, 6=abbreviated, 7=reserved
${CALLINGSUBADDR} * Called PRI Subaddress
${FAXEXTEN} * The extension called before being redirected to "fax"
${PRIREDIRECTREASON} * Reason for redirect, if a call was directed
${SMDI_VM_TYPE} * When an call is received with an SMDI message, the 'type' of message 'b' or 'u' The SIP channel uses the following variables:
${SIPCALLID} * SIP Call-ID: header verbatim (for logging or CDR matching)
${SIPDOMAIN} * SIP destination domain of an inbound call (if appropriate)
${SIPUSERAGENT} * SIP user agent
${SIPURI} * SIP uri
${SIP_CODEC} Set the SIP codec for a call
${SIP_URI_OPTIONS} * additional options to add to the URI for an outgoing call
${RTPAUDIOQOS} RTCP QoS report for the audio of this call
${RTPVIDEOQOS} RTCP QoS report for the video of this call The Agent channel uses the following variables:
${AGENTMAXLOGINTRIES} Set the maximum number of failed logins
${AGENTUPDATECDR} Whether to update the CDR record with Agent channel data ${AGENTGOODBYE} Sound file to use for "Good Bye" when agent logs out
${AGENTACKCALL} Whether the agent should acknowledge the incoming call ${AGENTAUTOLOGOFF} Auto logging off for an agent
${AGENTWRAPUPTIME} Setting the time for wrapup between incoming calls
${AGENTNUMBER} * Agent number (username) set at login
${AGENTSTATUS} * Status of login ( fail on off )
${AGENTEXTEN} * Extension for logged in agent The Dial() application uses the following variables:
${DIALEDPEERNAME} * Dialed peer name
${DIALEDPEERNUMBER} * Dialed peer number
${DIALEDTIME} * Time for the call (seconds)
${ANSWEREDTIME} * Time from dial to answer (seconds)
${DIALSTATUS} * Status of the call, one of: (CHANUNAVAIL CONGESTION BUSY NOANSWER ANSWER CANCEL DONTCALL TORTURE)
${DYNAMIC_FEATURES} * The list of features (from the applicationmap section of features.conf) to activate during the call, with feature names separated by '#' characters ${LIMIT_PLAYAUDIO_CALLER} Soundfile for call limits
${LIMIT_PLAYAUDIO_CALLEE} Soundfile for call limits
${LIMIT_WARNING_FILE} Soundfile for call limits
${LIMIT_TIMEOUT_FILE} Soundfile for call limits
${LIMIT_CONNECT_FILE} Soundfile for call limits
${OUTBOUND_GROUP} Default groups for peer channels (as in SetGroup)
See "show application dial" for more information The chanisavail() application sets the following variables:
${AVAILCHAN} * the name of the available channel if one was found
${AVAILORIGCHAN} * the canonical channel name that was used to create the channel ${AVAILSTATUS} * Status of requested channel When using macros in the dialplan, these variables are available
${MACRO_EXTEN} * The calling extensions
${MACRO_CONTEXT} * The calling context
${MACRO_PRIORITY} * The calling priority
${MACRO_OFFSET} Offset to add to priority at return from macro The ChanSpy() application uses the following variables:
${SPYGROUP} * A ':' (colon) separated list of group names. (To be set on spied on channel and matched against the g(grp) option) If you compile with OSP support, these variables are used:
${OSPINHANDLE} OSP handle of in_bound call
${OSPINTIMELIMIT} Duration limit for in_bound call
${OSPOUTHANDLE} OSP handle of out_bound call
${OSPTECH} OSP technology
${OSPDEST} OSP destination
${OSPCALLING} OSP calling number
${OSPOUTTOKEN} OSP token to use for out_bound call
${OSPOUTTIMELIMIT} Duration limit for out_bound call
${OSPRESULTS} Number of remained destinations CDR Variables

If the channel has a cdr, that cdr record has it's own set of variables which can be accessed just like channel variables. The following builtin variables are available and, unless specified, read-only. ${CDR(clid)} Caller ID
${CDR(src)} Source
${CDR(dst)} Destination
${CDR(dcontext)} Destination context
${CDR(channel)} Channel name
${CDR(dstchannel)} Destination channel
${CDR(lastapp)} Last app executed
${CDR(lastdata)} Last app's arguments
${CDR(start)} Time the call started.
${CDR(answer)} Time the call was answered.
${CDR(end)} Time the call ended.
${CDR(duration)} Duration of the call.
${CDR(billsec)} Duration of the call once it was answered.
${CDR(disposition)} ANSWERED, NO ANSWER, BUSY
${CDR(amaflags)} DOCUMENTATION, BILL, IGNORE etc
${CDR(accountcode)} The channel's account code (read-write).
${CDR(uniqueid)} The channel's unique id.
${CDR(userfield)} The channels uses specified field (read-write).
In addition, you can set your own extra variables with a traditional Set(CDR(var)=val) to anything you want. NOTE Some CDR values (eg: duration & billsec) can't be accessed until the call has terminated. As of 91617, those values will be calculated on-demand if requested. Until that makes it into a stable release, you can set endbeforehexten=yes in cdr.conf, and then use the "hangup" context to wrap up your call. Certain functional variables may be accessed with ${foo()}. A list of these functional variables may be found by typing "show functions" at the Asterisk CLI.

DUNDi Enterprise Configuration SIP

This is all you should need to setup DUNDi between two boxes with SIP.
You can add more boxes to your network in a similar way.

(Based on configurations in the configs directory of the Asterisk source code and documents published by Brian K. West aka bkw_)
DUNDi Enterprise Configuration IAX

Note: This configuration is currently non-functional, as chan_sip does not support "dbsecret" at this time. You can create a configuration where the passwords are actually included in the DUNDi mappings or in the peer definitions. A patch to support dbsecret in chan_sip is forthcoming (for CVS HEAD only).

Things to keep in mind:

• Unless you have specifically listed a host in your sip.conf the call will come in on the context defined in the [general] section by context. You may want to include the [dundi-priv-local] in this context.

On both boxes in your extensions.conf:

; Private DUNDi network
[dundi-priv-canonical]
; Direct numbers

[dundi-priv-customers]
; If you are an ITSP or Reseller, list your customers here.

[dundi-priv-via-pstn]
; If you are freely delivering calls to the PSTN, list them here

[dundi-priv-local]
include => dundi-priv-canonical
include => dundi-priv-customers
include => dundi-priv-via-pstn

[dundi-priv-switch]
; Just a wrapper for the switch
switch => DUNDi/priv

[dundi-priv-lookup]
include => dundi-priv-local
include => dundi-priv-switch

[macro-dundi-priv]
exten => s,1,Goto(${ARG1},1)
include => dundi-priv-lookup

---

sip.conf on both boxes:

[priv]
type=user
dbsecret=dundi/secret
context=dundi-priv-local

---

dundi.conf on both boxes under mappings:
In many cases you will need to replace ${IPADDR} with your local IP address

priv => dundi-priv-canonical,0,SIP,${IPADDR}/${NUMBER},nopartial
priv => dundi-priv-customers,100,SIP,${IPADDR}/${NUMBER},nopartial
priv => dundi-priv-via-pstn,400,SIP,${IPADDR}/${NUMBER},nopartial

---

now on each box cd /var/lib/asterisk/keys

astgenkey -n BOXNAMEHERE

Press enter do not put a password on the keys unless you want to init
keys every time you start asterisk.

Now put exchange public keys between the boxes.



Box A dundi.conf:

[DE:AD:BE:EF:DE:AD]   <-- EID/MAC from BOX B model = symmetric host = boxb.domain.com inkey = BOXB   <- BOX B's public key outkey = BOXA  <- BOX A's private key include = priv permit = priv qualify = yes order = primary 

Box B dundi.conf:

[BE:EF:DE:AD:BE:EF]  <-- EID/MAC from BOX A model = symmetric host = boxa.domain.com inkey = BOXA   <- BOX A's public key outkey = BOXB  <- BOX B's private key include = priv permit = priv qualify = yes order = primary 

Now you can do this in the context which your devices dialout:

exten => _91NXXNXXXXXX,1,Macro(dundi-priv,${EXTEN:1})
exten => _91NXXNXXXXXX,2,Dial(Zap/g1/${EXTEN:1}) ; This is fall through example to a PSTN such a as PRI

And find numbers in your enterprise DUNDi network.

These same things apply to the e164 DUNDi network too.

http://www.voip-info.org/wiki/view/DUNDi+Enterprise+Configuration+SIP

DUNDi Enterprise Configuration SIP with no passwords

http://www.voip-info.org/wiki/view/DUNDi+Enterprise+Configuration+SIP+with+no+passwords

DUNDi Enterprise Configuration IAX

http://www.voip-info.org/wiki/view/DUNDi+Enterprise+Configuration+IAX

Callback for Asterisk

Callback script made to do callback if called channel is busy,

How it works

• If called channel or phone is busy, it will ask to press 5 for callback or any other key to leave voicemail,
• Upon pressing 5, it will create a callfile in /var/spool/asterisk/outgoing with a special channel to be called
• Channel provided in callfile will periodically check if the extension set to callback is busy or available. as soon as it finds the channel available it will try to establish the call.

Php Agi script

#!/usr/bin/php -q
1;

$err=fopen("php://stderr","w");
$in = fopen("php://stdin","r");
while (!feof($in)) {
$temp = str_replace("\n","",fgets($in,4096));
$s = split(":",$temp);
$agi[str_replace("agi_","",$s0)] = trim($s1);
if (($temp == "") || ($temp == "\n")) {
break;
}
}
$cf = fopen("/var/spool/asterisk/outgoing/cb" . $agi"callerid" . $to,"w+");
fputs($cf,"Channel: LOCAL/cb".$agi"callerid".$to."\n");
fputs($cf,"Context: default\n");
fputs($cf,"Extension: ".$to."\n");
fputs($cf,"CallerID: CB ".$agi"callerid"."<".$agi"callerid"."> \n");
fputs($cf,"MaxRetries: 100\n");
fputs($cf,"RetryTime: 30\n");
fclose($cf);
fclose($in);
fclose($err);
?>

Extensions.conf

• in extensions.conf add something like this

exten => s-BUSY,1,ChanIsAvail(SIP/${MACRO_EXTEN}|s)
exten => s-BUSY,2,GotoIf($"${AVAILSTATUS}"<="1"?s-NOANSWER,1)
exten => s-BUSY,3,Read(digit|callback|1)
exten => s-BUSY,4,Gotoif($ "${digit}" = "5"?callback,1:5)
exten => s-BUSY,5,Voicemail(${MACRO_EXTEN},b)
exten => s-BUSY,6,Hangup

exten => callback,1,AGI(callback|${MACRO_EXTEN})
exten => callback,2,Hangup

;in cbXXXXXX first three digits are FROM exten and last ones are TO exten
;this exten is used by CALL FILE, logic for this is to make sure extension we are calling is IDLE or NOT_INUSE state.

exten => _cbXXXXXX,1,Set(FROM=${EXTEN:2:3})
exten => _cbXXXXXX,2,Set(TO=${EXTEN:5:3})
exten => _cbXXXXXX,3,ChanIsAvail(SIP/${TO}|s)
exten => _cbXXXXXX,4,GotoIf($"${AVAILSTATUS}" <= "1"?5:7)
exten => _cbXXXXXX,5,Set(CALLERID(all)="CB ${TO} <${TO}>")
exten => _cbXXXXXX,6,Dial(SIP/${FROM}|10)
exten => _cbXXXXXX,7,Hangup

• Copy Callback script in agi-bin directory.
• Copy callback.gsm in /var/lib/asterisk/sounds/ -