Assuming I have a breeze server A defined as:

ServerA
SIP IP: 10.0.0.21
Mgmt IP 10.0.0.22

I have a service deployed to Server A. I place a call through Server A, confirmed via callListener/callIntercepted log files that it is connected to this server. I obtain the UCID and perform the following:

logger.fine("IsHostedOnLocalNode = " + CallProperties.isHostedOnLocalNode(call));
logger.fine("GetNodeThatHostsCall = " + CallProperties.getNodeThatHostsCall(call));

I see this output:
2018-05-11 07:48:45,119 [WebContainer : 3] TestService FINE - TestService-1.1.1.23.0 - IsHostedOnLocalNode = false
2018-05-11 07:48:45,120 [WebContainer : 3] TestService FINE - TestService-1.1.1.23.0 - GetNodeThatHostsCall = 10.0.0.21

How is it possible that isHostedOnLocalNode is false, when it is giving me THIS server's IP?

It *seems* to only occur if I have a call pinned up and I redeploy a service. Not sure if actually related, but if I release the call and call again, it seems to go away until the next redeploy.

Yes, I could see this confusing the system. I'll run it by the developer, but I think that this falls in that borderline area between a bug or "working as designed". It does poke a bit of a hole in the seamless upgrade story.

Michael,

Can you tell me more about the call scenario? In particular, is the call sequenced into a Breeze more than once?

For instance, could it be that this call is sequenced into a Breeze both on origination (when someone makes an outbound call) and termination (when a user is going to receive a call)?

You mention that the logic retrieves the "Call" based on a UCID. It is preferred, when possible, to use the exact call ID when retrieving a call. In your use case, do you have access to the call ID when looking up the call?

Thanks,
Thor

Hi, sure be happy to.

It is only sequenced once, currently configured for "Called Service Invocation" since when/if we launch this, it will be sequenced on several inbound VDNs. Right now just have 1 vdn/dial string we are testing with.

So our set up is that on the agent desktop we have a CTI client that has access to all of the information (UCID, UUI, etc) from the call via AES for call control. I envision this web service being called by the agent via a link either in the CTI application or on another application running from the agent desktop.

The way this is designed currently is that we have a call listener in the service which at this point is not doing anything but providing me logging to know when the call hits this server, and prints out the UCID for the call. It also has a web service component which would be called by the desktop application descrubed above. I currently don't see a way to retrieve the Call ID from applications that are running on the agent desktop and have no visibility into the breeze infastructure.

What problem would this solve if we were to somehow obtain CallID? I'm sure the call is actually hitting this same server in the scenario below, so unless you're telling me the code for "IsHostedOnLocalNode" is more accurate when providing CallID instead of UCID, I don't see why it matters?

Hi Michael,

The reason looking up a call using a "UCID" as opposed to a "CallID" is that the same "UCID" backing a call can span multiple Breezes, whereas a "CallID" is unique to a particular snap-in instance on a particular Breeze. Therefore, in case there are multiple Breezes involved for the same snap-in, the platform has to pick a particular snap-in instance on a specific Breeze. It may not always be the exact call the application expects.

This should not be your case based on your description (multiple Breezes, or multiple invocations of the same snap-in for the same call).

The only way that I can think of that you would see this behavior is if you have a service which is not sequenced for a call, but rather listens for events when a call arrives. However, based on your original post you write, "I place a call through Server A, confirmed via callListener/callIntercepted log files that it is connected to this server. " This means that the call is sequenced. Given that you only have one call, the system should return the local one.

Btw, what version of Breeze do you have?

At this point, I am going to have to look at a trace. From the CLI:
1) ce dlogon
2) ce dlogw > /tmp/thor_call
3) perform single call test
4) ctrl-c (for ce dlogw)
5) Attach the results (thor_call) in an e-mail to thorsten@avaya.com
6) ce dlogoff

Thanks,
Thor

Ok. It definitely is sequenced. I will say that eventually we would allow calls to route across any of the breeze servers, and hopefully the load balancer would direct the call to the appropriate server the call is currently on via session affinity. We have another thread open on that.

We are using version 3.2 where I am currently developing and testing this service. Our company has anywhere from 3.2 to 3.4 depending on the division.

I will say this seems more like a bug than anything in that in order to produce this issue, I have to do the below:

-open a call through the server by dialing the sequenced VDN
-leave the call connected through this procedure as if I was talking to an agent
-redeploy my service
-then hitting the web service url gives the error message indicated.

I've sent log files. Thanks.

Hi Michael,

The step "-redeploy my service" will destroy the call, and any active calls on the node associated with service. A light call representation will persist in a data-grid, but it - too - will be removed as a part of an audit.

The logic asking "Does this call reside on my local node" will always return false while the light call representation still resides in the data grid. However, once the audit has removed that representation, the API will throw an exception stating that there is no such call in the system.

I took a look at the log files to verify that the above is indeed what's going on in the system. However, I don't seem to have the complete log, because I don't see the "INVITE", nor do I see when the service is un-deployed. Can you take a new sets of logs, starting before the call is made, through the re-deploy of the snap-in, the REST request, then stop the trace?

I am not completely clear on your use case. Is the goal to upgrade a service? If so, the recommended way is to deploy service/v1, then deploy service/v2. The service profile can be configured to route all new calls to the latest version (or if you want a particular version). This way service/v1 can shed traffic, as service/v2 picks up new traffic.

Thanks,
Thor

I see what you are saying Thorsten. If we were in production we would deploy as v2 and not redeploy the same version. Since we are just testing it was overkill to do that. Let’s call this one solved for now, knowing that we will just have to place a new call when we redeploy the same version.

Thanks Michael.

Thor