If I have a call that has routed through SM and down to CM, is it possible for Breeze to intercept without that call having to route back through SM?

Example, call routes from SM -> CM -> agent, agent transfers to a destination on the same CM, can Breeze take any actions on that call? Or does the call have to physically route from CM to SM, and then run an intercept app on that transfer destination?

MichaelNorman wrote:If I have a call that has routed through SM and down to CM, is it possible for Breeze to intercept without that call having to route back through SM?

Example, call routes from SM -> CM -> agent, agent transfers to a destination on the same CM, can Breeze take any actions on that call? Or does the call have to physically route from CM to SM, and then run an intercept app on that transfer destination?

Yes, you can do this.

You would need to setup an "implicit" user rule (Session Manager -> Application Configuration -> Implicit Users), and setup the pattern that would trigger the application there. You will need to tie it to an application sequence that has the Breeze server as the only element, so that the calls get flung to it. Within Breeze, you would need to do the same routing as you normally would. You may need to add implicit user routing within the Breeze Configuration, depending on your application.

Another option you have is to simply route the call directly to the the Breeze server. In this case, you would also need to setup the implicit user routing within the Breeze configuration to tie it to a profile. There are some disadvantages to this (notably, if there is a user that gets built in the system, it will override the routing), but the setup is more simple.

I understand how implicit users would work if the call is being routed through SM, but how will this still work if the call never leaves CM?

MichaelNorman wrote:I understand how implicit users would work if the call is being routed through SM, but how will this still work if the call never leaves CM?

Sorry, read the original question incorrectly. Either way, you need to get the call to be processed by Breeze first, so it gets in sequence, then pass it on to the CM station. You can do this via a forward or a conference. The breeze app will still stay attached to the call as long as the call is active (or the app terminates/ends).

For quite a few of my apps, I will route them through Breeze first, and have Breeze transfer the call (when ends up in CM). I subscribe to the call's events (and then listen to them on the Event Bus), and react when I need to do things. For example, if you have an app that needs to do something after the call center agent is done, you can run the call through Breeze, attach the events, transfer to the call center and wait. When the event bus hears the agent hung up (there will be an event for this), then play an announcement, transfer the call -- do whatever you would have done if you got the call immediately. Only thing to note is that if you are waiting for a hangup, you need to make sure you set the right media-server policy (ONE_PARTY), so that the call isn't dropped before you can do your thing.

There is no way to really react to a call that Breeze has never seen. Breeze will have no control of calls that only live in CM (or live in SM, but never made it to the Breeze server).

Really great info. Thanks I will read up on listening to events. Sounds like that’s exactly what I need.

Based on what I'm reading, if I wanted to be able to block a call from proceeding based on certain criteria, that cannot be done using call eventing. Instead I would need to get the call back to SM in order to intercept it. Is that accurate?

However, some services don’t need to actually perform their logic
before the call is sent to the called party. If such services subscribe for Call Events, the call will be allowed to proceed before the service logic is invoked, thus reducing latency.

MichaelNorman wrote:Based on what I'm reading, if I wanted to be able to block a call from proceeding based on certain criteria, that cannot be done using call eventing. Instead I would need to get the call back to SM in order to intercept it. Is that accurate?

However, some services don’t need to actually perform their logic
before the call is sent to the called party. If such services subscribe for Call Events, the call will be allowed to proceed before the service logic is invoked, thus reducing latency.

That sounds right. You would really only be able to control your "leg" of the call. You can interject another leg (conference, announcements etc) and control that, but I don't think CM would allow you to control it's leg.

That being said, you can control the physical phone that the call ends up on. Probably not useful in your case, but you could watch the event for a call to be picked up by the agent, and then instruct the phone to hang up as soon as the agent picked it up... The deskset control is provided by the ECC framework (connected to an AES)

Hi folks, sorry for being late to the party. As has been observed, there are 2 primary ways that Breeze snap-ins can monitor and control calls: 1) SIP Call Intercept and 2) AES/CTI.

Call Intercept can only be done on the trunk side of CM. Even if there are SIP stations calling each other on the same CM (with the call therefore transiting SM), Breeze cannot intercept and act on those calls. This has to do with several rather complicated reasons. You can still control the call to some degree after it has hit CM, but it is not possible to peform your desired action of intercepting a call being transferred to another individual on the same CM. In fact, it's not even easy to determine that a transfer has occurred via SIP on the trunk side of CM.

Another variant of this is the Call Events provided by the Call Event and Control Snap-in. This doesn't allow you to intercept calls before they are delivered to their destination. It does allow you to perform some call control without having to install ECC. It is still limited to seeing what happens on that trunk SIP signaling.

Use of AES via ECC adds some benefits such as being able to see and control station to station calls in the same CM, but it doens't enable your snap-in to actually intercept a call before it is delivered to its destination. ECC events are avaialble either via REST or via the Eventing Framework (RestCall event family). Control operations are only available via REST.

I know this was a lot of information in a small amount of space. Let me know if you have further questions.

Thanks Joel. Just to confirm, the only way for me to block a call being transferred would be to have the call go up to SM/Breeze, intercept it, and based on criteria either call.allow or call.suspend, play message, etc?

That's correct, but this has a number of ramifications in CM. It creates multiple calls where there used to only be one. Trunk utliziation is increased. Certain group features will not work as well. Reporting is messed up as well if this is a contact center scenario. It's generally not advised to go this route, which unfortunately may make it impossible to implement your use case.

JoelEzell wrote:That's correct, but this has a number of ramifications in CM. It creates multiple calls where there used to only be one. Trunk utliziation is increased. Certain group features will not work as well. Reporting is messed up as well if this is a contact center scenario. It's generally not advised to go this route, which unfortunately may make it impossible to implement your use case.

what happens to the intercepted call if avaya breeze were to go offline during the call that is being intercepted

The behavior if Breeze goes down is as follows:

* Media will continue to flow, but no further control operations (hold, unhold, transfer, conference) will be able to happen on the call
* If control operations are attempted before Communication Manager puts the call in "media preservation mode" (usually sometime between 0-10 minutes), the call will drop.
* If control operations are attempted after CM puts the call in media preservation mode, the operation will fail but media will continue to flow.

JoelEzell wrote:The behavior if Breeze goes down is as follows:

* Media will continue to flow, but no further control operations (hold, unhold, transfer, conference) will be able to happen on the call
* If control operations are attempted before Communication Manager puts the call in "media preservation mode" (usually sometime between 0-10 minutes), the call will drop.
* If control operations are attempted after CM puts the call in media preservation mode, the operation will fail but media will continue to flow.

Joel
Can you please clarify on this scenario of an intercept snap-in. Once the call is intercepted to get sip messages and handle some logic based on the sip message, The call hasn't been allowed yet until a call.allow() is executed. If Breeze were to fail during that moment and go offline, is call allowed automatically even when breeze goes offline?
I am trying to evaluate the risk for a call dropping due to breeze specially for critical calls.

Also, what about the case if the phone is registered to Session Manager?

thanks

There are timeouts at several levels that protect against failures for calls in progress (the above information was regarding behavior during stable established calls).

The Breeze Application Router has a timeout where it will allow a call to proceed if a snap-in hasn't responded in X seconds. Session Manager also has a timeout if it sends a call to Breeze and there's no response within Y seconds. I don't remember what X and Y are, but I'll ask somebody to respond with that information.

If it's Breeze that has timed out and there is a cluster of Breeze servers, Session Manager will remove that Breeze server from the pool until it responds affirmatively to an OPTIONS message.

Regarding phones registered to Session Manager, everything here applies to SIP stations registered to SM. The big factor is whether Communication Manager is in the sequence vector for the user (and in nearly all cases, it will be).

Sorry, I need to correct / clarify a few of the statements from my previous reply. First, I've been told that there isn't in fact a Breeze Application Router timer(X) that protects against failed snap-ins. If the thread returns without a snap-in having invoked allow(), divertTo, or terminate(), then the Application Router will by default allow the call to continue. If the thread never returns, then the call will not proceed.

Regarding the SM timer (Y), this timer will help in the case of an INVITE having been sent to a Breeze that is already offline. It will NOT help in the case of any INVITEs that are being processed by Breeze at the time of a failure. Breeze sends a 100 TRYING message back to SM as soon as it receives an INVITE, and this cancels the timer that SM sets to reroute INVITEs in the case of a failure. Calls that Breeze and its snap-ins have started to process but not yet completed at the time of a failure will not succeed. In fact, this window of vulnerability extends until the call has been answered (200 OK) and ACK’ed by the caller.