TABLE OF CONTENTS 1 Avaya Breeze Call Intercept Snap-ins...1 2 The Cardinal Rules for Call Intercept Snap-in Invocation...1 3 Supported scenarios for Call Intercept Snap-ins...2 3.1 Both H.323 and SIP endpoints are supported...2 3.2 Only inbound and outbound calls are supported...2 4 High level description of configuration for Call Intercept Snap-ins...2 4.1 Configuring Session Manager to invoke Avaya Breeze Snap-ins...3 4.2 Configuring Avaya Breeze Platform to invoke a Call Intercept Snap-in...4 5 Detailed description of Inbound and Outbound call flows for H.323 Endpoints...4 6 Avaya Breeze Call Intercept Snap-ins with SIPEndpoints...6 7 Avaya Breeze Call Intercept Snap-ins with Communication Manager ISDN trunks...9 8 Not supported: endpoint to endpoint calls...11 9 SIP endpoint to endpoint calls...12 9.1 SIP endpoint to endpoint calls within the same Communication Manager...13 9.2 Unsupported: Explicitly sequencing Avaya Breeze Platform...15 10 What does the future hold?... 16 11 Recap: the Cardinal Rules. for Call Intercept Snap-in Invocation... 16 AVAYA BREEZE CALL INTERCEPT SNAP-INS The Avaya Breeze Platform is an application platform that allows new capabilities to be added to the Avaya Aura Platform. It is a single integrated environment that extends across multiple devices and channels, enabling developers to build and deploy communications applications in days without needing detailed communication development skills. Call Intercept Snap-ins are among the most commonly requested application capabilities. This white paper will outline how these Snap-ins can be invoked to support high value customer solutions. A note about terminology: this document uses the words Snap-in and Service interchangeably. They should be considered to be synonymous. 1 Avaya Breeze Call Intercept Snap-ins One unique aspect of Avaya Breeze Platform and the Avaya Aura architecture is the ability to implement Call Intercept Snap-ins. In the context of Avaya Aura Session Manager, these capabilities were previously known as Sequenced Applications. Call Intercept Snap-ins allow additional applications to be invoked on behalf of the calling or called party any time those parties make or receive a call. These call treatments are in addition to any functionality provided by Avaya Aura Communication Manager, the primary call feature server. Unlike traditional Computer Telephony Integration (CTI) applications, Call Intercept Snap-ins can be invoked during call establishment and prior to the called endpoint receiving the call. This opens up a whole world of call treatment opportunities that simply cannot be supported with traditional CTI. Examples include Call Block/Do Not Call applications, Identity Changing applications, and applications with access to a media stream (audio, video) for the purposes of playing announcements. This document will outline the Cardinal Rules of Avaya Breeze Call Intercept Snapin Invocation. It will also provide detailed descriptions of call flows to help better explain the rationale behind those rules and the workings of the Avaya Aura Platform when these rules are followed. It will also illustrate unsupported flows, give some rationale for why those flows are not supported, and provide a brief view of the future call flow plans from Avaya. 2 The Cardinal Rules for Call Intercept Snap-in Invocation For any Call Intercept Snap-in, the following cardinal rules will apply. Following these rules is required for an application to work in the same fashion for both SIP and H.323 endpoints. avaya.com 1
1. Only inbound and outbound calls between the enterprise and the PSTN are supported. a. If the environment uses ISDN trunks to Communication Manager, special provisioning will be required to force all trunk calls out to Session Manager so that Avaya Breeze applications can be invoked. 2. Always use Implicit Sequencing for Avaya Breeze applications, even for SIP endpoints. The concept of Implicit Sequencing is detailed below. 3. If there are multiple instances of Communication Manager in the environment, you may need additional logic in your Snap-in to prevent the application from being invoked on an inter-enterprise (endpoint to endpoint) call. 3 Supported scenarios for Call Intercept Snap-ins 3.1 Both H.323 and SIP endpoints are supported Call Intercept Snap-ins can operate equally well on Avaya H.323 endpoints or SIP endpoints. At the initial introduction of Session Manager, sequenced applications were originally targeted exclusively to SIP endpoints. The capabilities of Implicit Sequencing extended support for sequenced applications to H.323 endpoints and the Avaya Breeze Platform leverages this functionality. 3.2 Only inbound and outbound calls are supported Call Intercept applications are only supported on calls between the Public Switched Telephone Network (PSTN) and the enterprise. This document will refer to those calls as Inbound and Outbound calls. Inter-enterprise (endpoint to endpoint) calls (even on SIP endpoints) are NOT currently supported. 4 High level description of configuration for Call Intercept Snap-ins Before reviewing the details of Inbound and Outbound call flows, this section will discuss how to configure Session Manager Implicit Sequence Vectors and Avaya Breeze Service Profiles so that Avaya Breeze Snap-ins can be invoked. Two distinct configurations are required: 1. Session Manager must be configured to invoke Avaya Breeze Snap-ins. 2. Avaya Breeze Platform must be provisioned to invoke the Call Intercept Snap-in. A high level description for how to administer these configurations is noted below. Detailed instructions can be found in the Administering Avaya Breeze Platform and Deploying Avaya Breeze Platform documents. These documents can be downloaded from the Avaya DevConnect website (http://devconnect.avaya.com) and from http://support.avaya.com. avaya.com 2
IMPLICIT VERSUS EXPLICIT APPLICATION SEQUENCING. In early releases of Session Manager, Application Sequences could only be provisioned against users of SIP endpoints as administered in Avaya Aura System Manager. The term Implicit User was later introduced to enable administration of Sequenced Applications for users of H.323 and other endpoints without the requirement that these users be explicitly identified as such in System Manager. Although the term Explicit is not used in System Manager, it is used in this document as a differentiating term to refer to the initial use of application sequences provisioned against System Manager Users. To begin, it is important to understand that Call Intercept Snap-ins fall into three broad categories: Calling Party Services, Called Party Services and Services which include both Calling and Called Party Services. Calling Party Services are applied on the behalf of the caller. These are referred to as Origination applications in Session Manager provisioning. Examples of Calling Party Services are: - Do Not Call and other types of call restriction applications - Identity changing applications. Called Party Services are applied on the behalf of the person receiving the call. These are referred to as Termination applications in Session Manager provisioning. Examples of Called Party Services are: - Call Block - Enhanced Caller ID (change caller ID based on contact list) Examples of Snap-ins that might include both Calling Party and Called Party services are: - Call Logging - Call Recording (Future) 4.1 Configuring Session Manager to invoke Avaya Breeze Snap-ins In order for Session Manager to invoke Avaya Breeze Snap-ins when calls are being originated / received, the following administration on System Manager is required: Administer one or more Avaya Breeze instances as a SIP Entity Create an Application that represents Avaya Breeze Platform. - Note that from the perspective of Session Manager, the Avaya Breeze Platform is the Application rather than a snap-in deployed within Avaya Breeze Platform. Create an application sequence that includes the Avaya Breeze application Create one or more Implicit User Rules that match the numbers of the Avaya Breeze users. Note that the users must also be provisioned explicitly as Users in System Manager. - These rules are specified with patterns that can match large number ranges with a single entry. - The pattern can have an Origination Application Sequence and / or a Termination Application Sequence associated with them. Associate Avaya Breeze Application Sequence with the Implicit User Rule avaya.com 3
- For Calling Party applications, set the Origination Application Sequence to be an Application Sequence that includes Avaya Breeze application. - For Called Party applications, set the Termination Application Sequence to be an Application Sequence that includes Avaya Breeze application. 4.2 Configuring Avaya Breeze Platform to invoke a Call Intercept Snap-in In order for the Avaya Breeze Platform to invoke a Call Intercept snap-in, the following actions must be performed on System Manager: Deploy the service - The service developer will need to declare in a Properties File whether that service is a Calling Party service or Called Party service or both. Create a Service Profile and add the service to that profile Provision all users of Avaya Breeze services as Users in System Manager - All users of SIP endpoints will already exist as users in System Manager - Users of H.323 endpoints may or may not already exist as users. If they do not appear as users, they must be added to System Manager. Associate the Service Profile with each user of Avaya Breeze services - If different groups of users have different services, or have different configuration for the same service, create multiple Service Profiles and associate the users with the different Service Profiles as desired. 5 Detailed description of Inbound and Outbound call flows for H.323 Endpoints. The following two figures illustrate these supported scenarios with H.323 endpoints and either Session Border Controllers (SBCs) or SIP trunk gateways acting as the interface to the PSTN. Figure 1. Outbound Call from H.323 endpoint to PSTN avaya.com 4
In this example, Alice initiates a call to somebody outside of the enterprise. 1. Alice s H.323 endpoint signals directly to Communication Manager that she would like to a make a call to a particular phone number. 2. Communication Manager applies any features that it would normally apply when Alice originates a call. This could include features such as Class of Restrictions that restricts the numbers that Alice is allowed to call. 3. Communication Manager consults its routing table and determines that it should route this call out to Session Manager for further handling. 4. Session Manager checks to see if the calling party number matches any Implicit User Rule that has been provisioned. It finds a match and invokes the Origination Application Sequence that was defined for that pattern. The Avaya Breeze Platform is in this sequence and so it receives the call. 5. The Avaya Breeze application determines which Service Profile has been assigned to Alice and finds that it should invoke the Caller ID Changing Snap-in. 6. The Caller ID Changing Snap-in changes the Caller ID from Alice to Company Name. 7. The Avaya Breeze application sends the call back to Session Manager. 8. Session Manager checks to see if the called party number matches any Implicit User Rule that has been provisioned. It doesn t find a match so proceeds to routing. 9. Session Manager consults its routing tables and determines that it must send the call to an SBC or SIP Trunk Gateway 10. The SBC / SIP Trunk Gateway sends the call to the PSTN. Figure 2. Inbound call from PSTN to H.323 endpoint avaya.com 5
Similarly, here is an example of the call path when somebody outside of the enterprise calls Alice. 1. The SBC / SIP Trunk Gateway sends the call to the Session Manager. 2. Session Manager checks to see if the calling party number matches any Implicit User Rule that has been provisioned. It doesn t find a match. 3. Session Manager checks to see if the called party number matches any Implicit User Rule that has been provisioned. It finds a match and invokes the Termination Application Sequence that was defined for that pattern. Avaya Breeze Platform is in this sequence and so it receives the call. 4. Avaya Breeze application determines which Service Profile has been assigned to Alice and finds that it should invoke the Call Block Service. 5. The Call Block Snap-in checks to see if the caller is allowed to call Alice. It finds that the caller is not on the block list so allows the call to proceed. 6. Avaya Breeze application sends the call back to Session Manager 7. Session Manager consults its routing tables and determines that it must send the call to Communication Manager 8. Communication Manager applies any features that it would normally apply when Alice receives a call. This could include features such as call forwarding or voice mail. 9. Communication Manager alerts Alice s phone. 6 Avaya Breeze Call Intercept Snap-ins with SIP Endpoints Call flows on SIP endpoints work somewhat differently than the H.323 example provided above. As mentioned previously, Implicit Sequencing did not originally work with SIP endpoints. Only the Explicit application sequence would be invoked for a SIP endpoint, even if there were an Implicit Rule that matched that user s address. That Session Manager limitation has now been changed so that both Explicit and Implicit sequencing can optionally be applied to SIP endpoints. This change requires a patch for Session Manager 6.2 Feature Pack 3 that will be included in an upcoming release. With this modification, administration of Avaya Breeze Call Intercept Snap-ins is exactly the same for SIP endpoints as it is for H.323 endpoints. In both cases an Implicit User Rule can be provisioned with a pattern that matches the endpoint address and associates an Avaya Breeze application sequence with that Implicit User Rule. The only difference with SIP endpoints is that there will also be an avaya.com 6
Explicit Application Sequence associated with the user. That rule will minimally contain Communication Manager in the sequence. Other sequenced applications such as those created using Avaya ACE Foundation Toolkit may also be included in this explicit application sequence. Such applications will continue to operate as they did prior to the introduction of the Avaya Breeze application. Inbound and outbound call flows with SIP endpoints will operate as follows: Figure 3. Outbound call from SIP endpoint to PSTN Here is the sequence when Carol, a SIP endpoint user, initiates a call to someone outside of the enterprise. 1. Carol s SIP phone initiates a SIP call with Session Manager 2. Session Manager checks the originating address to see if it matches a SIP user. It finds Carol s provisioned information. 3. Session Manager invokes any applications in the origination Application Sequence that is associated with Carol. This includes Communication Manager. This part is called Explicit Sequencing because it is being applied against a user that was explicitly provisioned in Session Manager. Session Manager invokes Communication Manager as a sequenced application. 4. Communication Manager applies any features that it would normally apply when Carol originates a call. This could include features such as Class of Restrictions that restricts the numbers that Carol is allowed to call. 5. Communication Manager sends the call back to Session Manager for further handling. 6. Now that it has completed Explicit Sequencing for Carol, Session Manager checks to see if the calling party number matches any Implicit User Rule that has been provisioned. It finds a match and invokes the Origination Application Sequence that was defined for that pattern. The Avaya Breeze Platform is in this sequence and so it receives the call. avaya.com 7
7. The Avaya Breeze application determines which Service Profile has been assigned to Carol and finds that it should invoke the Caller ID Changing Snap-in. 8. The Caller ID Changing Snap-in changes the Caller ID from Carol to Company Name. 9. The Avaya Breeze application sends the call back to Session Manager 10. Session Manager checks to see if the called party number matches any Implicit User Rule that has been provisioned. It doesn t find a match so proceeds to routing. 11. Session Manager consults its routing tables and determines that it must send the call to a SBC or SIP Trunk Gateway 12. The SBC / SIP Trunk Gateway sends the call to the PSTN. Figure 4. Inbound call from PSTN to SIP endpoint Similarly the following sequence describes the call flow when someone outside of the enterprise calls Carol on her SIP phone. 1. The SBC / SIP Trunk Gateway sends the call to the Session Manager. 2. Session Manager checks to see if the calling party number matches any Implicit User Rule that has been provisioned. It doesn t find a match. 3. Session Manager checks to see if the called party number matches any Implicit User Rule that has been provisioned. It finds a match and invokes the Termination Application Sequence that was defined for that pattern. The Avaya Breeze Platform is in this sequence and so the Avaya Breeze Platform receives the call. 4. The Avaya Breeze application determines which Service Profile has been assigned to Carol and finds that it should invoke the Call Block Snap-in. avaya.com 8
5. The Caller Block Snap-in checks to see if the caller is allowed to call Carol. It finds that the caller is not on the block list so allows the call to proceed. 6. Avaya Breeze application sends the call back to Session Manager 7. Now that it has completed Implicit Sequencing, Session Manager checks the called address to see if it matches a SIP user. It finds Carol s provisioned information. 8. Session Manager invokes any applications in the termination Application Sequence that is associated with Carol. This includes Communication Manager. This part is called Explicit Sequencing because it is being applied against a user that was explicitly provisioned in Session Manager. Session Manager invokes Communication Manager as a sequenced application. 9. Communication Manager applies any features that it would normally apply when Carol receives a call. This could include features such as call forwarding or voice mail. 10. Communication Manager sends the call back to Session Manager for further handling. 11. Session Manager sends the call to Carol s registered endpoint which then alerts. 7 Avaya Breeze Call Intercept Snap-ins with Communication Manager ISDN trunks All of the examples above illustrate a case in which an SBC or SIP Trunk Gateway is used. In many deployments the interface to the PSTN will be ISDN trunks that connect directly to Communication Manager. Under these circumstances call paths will not by default send calls between H.323 endpoints and ISDN trunks through Session Manager. Instead, the Avaya Aura Platform will route the call directly between the endpoint and the trunk. While calls between SIP endpoints and ISDN trunks do traverse through Session Manager, this happens during the explicit sequencing phase and implicit applications would not be invoked. To resolve this issue, it is possible to configure Communication Manager Automatic Route Selection (ARS) and Incoming Call Handling Treatment (ICHT) so that all calls to / from any trunk will be routed through Session Manager. Please see the Administering Avaya Breeze Platform document for details on how this configuration should be completed. Below is an example for an outbound call from Alice on H.323: avaya.com 9
Figure 5. Outbound call from H.323 endpoint to ISDN trunk 1. Alice s H.323 phone signals directly to Communication Manager that she would like to a make a call to a particular phone number. 2. Communication Manager applies any features that it would normally apply when Alice originates a call. This could include features such as Class of Restrictions that restricts the numbers that Alice is allowed to call. 3. Communication Manager consults the special routing provisioning that was created to force outgoing calls to Session Manager. It sends the call to Session Manager for further processing. 4. Session Manager checks to see if the calling party number matches any Implicit User Rule that has been provisioned. It finds a match and invokes the Origination Application Sequence that was defined for that pattern. The Avaya Breeze Platform is in this sequence and so it receives the call. 5. The Avaya Breeze application determines which Service Profile has been assigned to Alice and finds that it should invoke the Caller ID Changing Snap-in. 6. The Caller ID Changing Snap-in changes the Caller ID from Alice to Company Name. 7. The Avaya Breeze application sends the call back to Session Manager. 8. Session Manager checks to see if the called party number matches any Implicit User Rule that has been provisioned. It doesn t find a match so proceeds to routing. avaya.com 10
9. Session Manager consults its routing tables and determines that it must send the call to Communication Manager, acting as a trunk gateway. This entails techniques such as adding extra steering digits to the called number so that Communication Manager will avoid the special routing provisioning that sent the call to Session Manager and will instead send it directly out the ISDN trunk. 10. Communication Manager consults its routing tables and sends the call out of an ISDN trunk to the PSTN. Incoming calls are handled in a similar fashion, but please note that there are some differences in the details as described in the document Deploying Avaya Breeze Platform. 8 Not supported: endpoint to endpoint calls. Call Intercept applications are currently not supported for calls within an enterprise between two Avaya Aura endpoints. The following diagram illustrates why this is the case. When Alice calls Bob (both using H.323 endpoints), Communication Manger applies both its origination features (on Alice s behalf) and termination features (on Bob s behalf) without sending the call to Session Manager at all. Forcing such calls through Session Manager as is done with calls to and from the PSTN would impact other Communication Manager features including AES and ACE CTI applications. Figure 6. H.323 endpoint to H.323 endpoint call on the same Communication Manager There is a special case for calls between endpoints that are served by two different instances of Communication Manager. These kinds of calls will traverse Session Manager and implicit sequencing will be applied. For some services, this may not matter but there are cases where services will require special logic. Take the following example: avaya.com 11
Figure 7. H.323 endpoint to H.323 endpoint call on different Communication Manager Instances In this example, the Whitelist sample application from the Avaya Breeze SDK is shown as a called party application. This application allows the employees of a company to specify a list of individual numbers that would be passed to their extension directly. A call from any number not on the employees list would be redirected to a Contact Center. What if that company wanted to grant an exemption to everybody within the company? If the service was written under the assumption that only calls to / from the PSTN would be processed by the application, then calls between two employees served by different instances of Communication Manager would also be diverted. To resolve this issue a developer would need to add extra logic for intra-enterprise calls. The Whitelist application would need to include the logic to determine if the caller is an enterprise employee in addition to checking to see if the caller is on the whitelist. If all enterprise users are provisioned in System Manager, this is a relatively easy check. The Avaya Breeze Enterprise Data API can be used to do a lookup of a user based on their handle or phone number. If not all users are in System Manager, it may be necessary to provision number ranges or patterns for the service that match all enterprise phone numbers. 9 SIP endpoint to endpoint calls As illustrated below, the flow for a SIP endpoint to SIP endpoint call across Communication Manager instances results in exactly the same flow for the Avaya Breeze Platform. The flow is only different between the each endpoint and Session Manager / Communication Manager. avaya.com 12
Figure 8. SIP endpoint to SIP endpoint call on different Communication Manager Instances Note one very important feature in the diagram above. Recall that in the endpoint to trunk calls, Explicit Origination sequencing occurred first, followed by Implicit Origination sequencing. The opposite was true for calls from a trunk to an endpoint, where Implicit Termination sequencing occurred first followed by Explicit Termination sequencing. Session Manager will follow that same set of rules for calls between two SIP endpoints. The implicit sequencing phases are sandwiched between the Explicit sequencing phases. Again, the important thing to remember with respect to Avaya Breeze services, however, is that things work exactly the same with SIP endpoints as they do with H.323 endpoints. 9.1 SIP endpoint to endpoint calls within the same Communication Manager Application developers should also understand how Communication Manager as an Evolution Server processes calls between two SIP endpoints. The diagram below illustrates the flow. avaya.com 13
Figure 9. SIP endpoint to SIP endpoint call on the same Communication Manager When Communication Manager is running in Evolution Server mode, it is not capable of separating its origination and termination processing into two half calls. Instead, if a given Communication Manager instance is responsible for both the calling and called party, it always performs processing for both of those parties at the same time. However, Communication Manager must be in the Application Sequence for both parties in cases where the caller is not an endpoint on the same Communication Manager. This means that in cases where Communication Manager is applying features for both parties in a call, there needs to be a way to signal that termination features have already applied when a call has already been termination sequenced by Session Manager. It does this by applying a shortcut parameter to one of the route headers. When Communication Manager is termination sequenced and it sees this shortcut parameter, it simply bounces the call back to Session Manager. There is particular relevance of this call path for the Avaya Breeze Platform. The sandwich model mentioned above also applies to these endpoint to endpoint calls as well. The implicit Application Sequences are invoked by Session Manager in between the Communication Manager invocations. See the diagram below for an illustration. avaya.com 14
Figure 10. SIP endpoint to SIP endpoint call on the same Communication Manager with Avaya Breeze Platform Under these circumstances the developer would like to avoid having Avaya Breeze services invoked from this position. For instance, imagine a Calling or Called party service that redirected a call under the assumption that Communication Manager had not yet started its voice mail (coverage) timer. If the voice mail timer expired before the redirect-to party answered the call, then that party would not get a chance to answer. Fortunately, the Avaya Breeze Platform has been designed to do the same thing as Communication Manager when it sees the shortcut parameter. It will do nothing, and will simply bounce the call back to Session Manager without invoking any services. Again, although the call flow is quite different, the operation of Avaya Breeze Call Intercept Snap-ins is exactly the same for SIP endpoints as it is for H.323 endpoints. 9.2 Unsupported: Explicitly sequencing Avaya Breeze Platform Explicit sequencing of SIP endpoints for Avaya Breeze services is not supported, but developers may ask why the Avaya Breeze Platform cannot be placed in the user (explicit) sequence vector so that it can be invoked for endpoint to endpoint calls. The illustration below shows this case. avaya.com 15
Figure 11. An unsupported call flow using Explicit Sequencing to invoke Avaya Breeze Platform There are two reasons why this is not currently supported: Most importantly, this would create a different level of support for SIP and H.323 endpoints. Developers would have to be very cognizant of the Avaya Breeze Platform being invoked differently for different endpoint types. If the Avaya Breeze Platform was in both the Implicit Application Sequence for H.323 support and the user Application Sequence for SIP endpoint to endpoint calls, the Avaya Breeze application would likely be invoked twice. 10 What does the future hold? Clearly, endpoint to endpoint calls within an enterprise are important. Avaya is in the process of evaluating a potential enhancement to Communication Manager such that all calls to / from endpoints are optionally forced out to Session Manager for application sequencing. This enhancement is not currently planned for a Communication Manager release. 11 Recap: the Cardinal Rules for Call Intercept Snapin Invocation To conclude, please remember the Cardinal Rules that were mentioned at the beginning of this paper. These rules were developed so that an application works in the same fashion for both SIP and H.323 endpoints. avaya.com 16
1. Only inbound and outbound calls between the enterprise and the PSTN are supported. a. If the environment uses ISDN trunks to Communication Manager, special provisioning will be required to force all trunk calls out to Session Manager so that Avaya Breeze applications can be invoked. 2. Always use Implicit Sequencing for the Avaya Breeze Platform, even for SIP endpoints. The concept of Implicit Sequencing is detailed below. 3. If there are multiple instances of Communication Manager in the environment, you may need additional logic in your service to prevent the application from being invoked on an inter-enterprise (endpoint to endpoint) call. By following these rules, developers will be well on the way to authoring robust, compelling Call Intercept applications! About Avaya Avaya is a leading, global provider of customer and team engagement solutions and services available in a variety of flexible on-premise and cloud deployment options. Avaya s fabricbased networking solutions help simplify and accelerate the deployment of business critical applications and services. For more information, please visit www.avaya.com. avaya.com 17 2016 Avaya Inc. All Rights Reserved. Avaya and the Avaya logo are trademarks of Avaya Inc. and are registered in the United States and other countries. All other trademarks identified by, TM, or SM are registered marks, trademarks, and service marks, respectively, of Avaya Inc. Other trademarks are the property of their respective owners. 04/16 UC7368 Provide feedback for this document