FeaturesThe following list identifies a few of the key features afforded by the SNAPsolution.
SNAPsolution ComponentsThe power behind every application of a NetSapiens SNAPsolution is created by the ideal customer specific mixture of SNAPiq, SNAPsoftware, and SNAPped In tools and services. Figure 1-1 shows how the SNAPsolution components fit together to deliver unparalleled capabilities. The following sections summarize the key components of the SNAPsolution. SNAPsolution Components
SNAPappsSNAPapps are NetSapiens offered or customer created applications that can be deployed using SNAPsolution. Examples of the applications available with the SNAPsolution include:
SNAPiqSNAPiq is a deployment expertise offering that addresses customer-specific requirements. No matter what level of VoIP experience you bring to the table, NetSapiens will provide the necessary skills to bring your application to market quickly and efficiently.
SNAPsoftwareSNAPsoftware is a suite of highly available and distributable software components that allow for maximum scalability and include all of the necessary software functionality required for a complete service provider solution. SNAPviewsSNAPviews are Web-based portals that simplify utility, configuration, and management. Each user level within the platform, from end-user to NOC Engineer, has a distinct brand-able web portal to address their particular use cases.To access the individual portals, use the following URLs:
BrandingPlease follow this link to BrandinSNAPossSNAPoss provides the business operations functionality such as fault management, configuration, accounting, performance management, and security management.
SNAPswitchSNAPswitch provides the core application delivery capabilities required for a full-featured deployment.
SNAPped InSNAPped In is NetSapiens Partner Program, which constantly qualifies additional value-added tools and services that are needed to meet custom deployment requirements.
Sample ApplicationsThe following figures show examples of possible applications with the SNAPsolution.Example of a Hosted PBX/IP
Centrex Application
Example of a Prepaid Calling
Application
Example of a Call Center
Application
SNAPsoftware ArchitectureNetSapiens SNAPsoftware runs on optimized versions of industry-proven Linux-based Web Services infrastructure, and can run on one or multiple industry standard servers. The SNAPsolution software components are designed and built from the ground up by NetSapiens, which gives us the ultimate flexibility with your deployment.Important Concepts and TermsUsers vs. DevicesThe distinction between users and devices is important. Devices are physical entities or connections, such as phones, that register to the system. Users are profiles that have associated sets of features, such as voice mail, call forwarding, and simultaneous ring. It is possible for a user profile to have more than one device associated with it.Matching and TranslationMatch rules are a core concept of the SiPbx. As a call setup (INVITE) traverses the system from one messaging module to another, the path that each “leg” takes is based on matching of either the SIP To-URI or the SIP From-URI. In most cases, the matching is performed on the To-URI, but there is one exception, as listed below.Once the appropriate match rule is found based on the tightest possible match, the messaging is prepared, based on the particular rule, to move into the next messaging module. In essence, these rules translate the To-URI and/or the From-URI, which affect the way the message is input to the next module. Using this methodology, the system administrator has complete control over the call treatment. The table below shows which URI is being matched as a call flows through the system.
Call Control ModulesConnection ModulesThe connection is both the first and the last module hit for inbound and outbound calls, respectively. When an inbound call enters the SNAPswitch, the first test ascertains whether there is a connection rule that matches on the From-URI in the INVITE message. If there is, the associated connection rule is loaded and used to pass the message on to the Dial Translation module, which is configured for that connection. For an outbound call, the INVITE message is formed from the Call Routing Module (see below) and passed to the Connection Module. In this case, there will be an attempted match on the To-URI. If one is found, the INVITE is routed out. Dial TranslationDial Translations are applied on any incoming SIP INVITE and any USER profile-based call. This includes transfers, forwards, and simultaneous ring as well as initial inbound and on-net calls. Dial Translations are assigned to inbound connections and to system users. Within the Dial Translation rules, it is possible to translate the user and host parts of the To-URI (destination) as well as the user and host parts of the From-URI (source). It is also possible to translate the Source Name from within the administrator login.The Dial Translation rules are also where the application module is selected. Application ModuleDial Translation also allows the appropriate application to be configured. The Application Modules include such functionality as Auto-Attendant, Voice Mail, and inbound and outbound calls. The table below lists the most commonly used applications and corresponding functionality.
Dial Policy ModuleAfter the call setup messaging exits the Dial Translation Module, it enters the Dial Policy Module. Like dial translations, dial policies are configured based on the system user and connection rules. They are also similar in that they apply to the system user for an outbound call (including transfer, forward, etc.) and to the connection for an inbound call. Through the dial policy, the system administrator can permit or deny calls based on the To-URI.Call Routing ModuleFrom the Dial Policy Module, the call enters the Call Routing Module. From the Call Routing Module, the INVITE is formulated based on the To-URI. It is also possible to provide two alternate routes. If the initial INVITE is rejected, the second is tried, and so on. |