I want to write an easy as short as possible java program using JTAPI, that connects to the CUCM and gets a notification when a call is done by the user.
In other words, i want to make a journal live journal for the user showing who making the calling (always the user) who is being called, and the duration.
JTrace application (with source code) is part of Cisco JTAPI installation. Using this application you can observe all the call activity of the user. You need to enable/configure the user for CTI Application on CUCM admin and use those credentials to start JTrace.
Related
I am currently using Twilio Studio to build a customer service process that allows clients to make calls to a Twilio number, which redirects to representatives.
How can I allow clients to send a voice message (voicemail) if the call is not picked up or if the call is not within working hours. Thanks!
Twilio developer evangelist here.
With the Connect Call To widget you can connect further widgets after either the call ending or the caller hanging up. In your case, you need to decide whether the call ended successfully or because the call wasn't picked up. You can do this by adding a Split Based On widget after the Connected Call Ended transition and testing on the DialCallStatus.
DialCallStatus can be any of completed, answered, busy, no-answer, failed, or canceled. In your case you are looking for "no-answer". You can use the Split widget to direct the flow onto the Record Voicemail widget when that happens.
As for calls not within working hours, that is a bit more complicated. To get the current time and compare to working hours will require you to run some code. You can do this with a Twilio Function, for example. There is an example application in the Twilio Code Exchange that implements this functionality but you would need to adjust it to use within your Studio Flow.
I have trouble with one of my devices (Tracker dongle) communicating with Cumulocity. I used the Device Registration interface to register its IMEI. Then I accepted it in the same interface when it first connected. But now the tracker-agent I deployed is continually logging:
c.t.d.DeviceBootstrapProcessor : Start bootstrapping:
(DEVICE_IMEI)
And I got nothing arriving on Cumulocity. So I'm guessing it's stuck trying to retreive the device credentials? (Cf. DeviceBootstrapProcessor.tryAccessDeviceCredentials). I have another device of the same type which worcks just fine in the same configuration and I can't tell what's the difference between the two. Is there a step I'm missing to correctly register a device?
The tracker-agent has an additional registration for itself. It is once per tenant and automatically triggers after registering the first tracker device.
What you need to do is register the agent (via device registration) with the following ID:
tracker-agent-{tenant}
(replace {tenant} with the tenant you want do register the agent). This needs do be done once per tenant to allow the tracker agent to create devices and data.
In our application we have a back-to-back-connection between an operator (client) and a caller, via an ucma-application we built. Now we want to transfer the caller to another operator or number.
This transfer is attended, so we want to keep the call in the client at least until the transfer is completed.
The client application tells the ucma-application to do the transfer. As such, the server makes a transfer on the leg from ucma -> caller. In this scenario, the leg from ucma to the client application remains intact, but we want to receive information about this transfer so that we can show the transfer status in the client application. If the transfer fails, it should also be clear to the operator (it should also be on hold during the time of the transfer, and continue to be on hold even after transfer failed).
Which is the correct way to do this in UCMA?
It's hard to give you advice as there are multiple ways to do what you want depending on what you need to achieve.
I think the main problem is that you are doing the transfer in the middle, you can't tell the Lync Client to go on "hold". Because of this, you can only put the call on hold from the point of view of UMCA application. This means that if you will have to provide your own UI to unhold the call if it fails, maybe from your own Client Application GUI.
What you could do is write a Lync Client SDK controlled Lync Client application. If you have a Lync Client SDK controlled Lync Client, you could remote control the Lync Client to do the transfer, that way you get the standard Lync Client failed transfer UI. If you do this, what is the point of the UCMA application?
If you have to do it from the UCMA point of view, you could:
Provide the UI in your only Client Application (I would think no nice) including controlling the hold status on a failure
Lync Client SDK controlled Lync Client to put the call on Hold that way it's the standard Lync Client way to unhold on failure, then the only need to worry about the display of a failed transfer. Maybe display something in your client application, maybe a send a in call IM from the UCMA application?
See if the Lync Client support BoardWork Extensions (specifically the Remote Control Hold Event Package). If it does then you can remotely put the call on hold, most likely though that it doesn't :(
I'm building an application, it's easy and what I want to do is the following. I want a brainless client and all the work should be done on the server. So I want a way to change windows forms in my server application and not on the client itself.
So when I have an application like blackjack the user presses hit then the hit function on the server get called, he will calculate everything, send the result back to the client and then the client updates it buttons and GUI (like displaying cards, and so on).
Now how do you do this in WCF? I know how to call remote function but I can't get the windows forms part to work (can I add this in the contract, and how?)
Thanks!
Your client should handle all of its own UI. Your service shouldn't have anything to do with the UI.
Instead of having the service handle the UI, just have it send messages back to the client and let the client figure out which UI elements to show or not based on the messages.
So, when the server calculates some result, like BLACKJACK!, it'll send a message indicating that back to the client which will then show the proper UI elements.
Make sense?
Disclaimer: This is a follow-on question from my other question about NServiceBus which was answered very thoroughly.
My current question is this: If a website is built to be 'dumb' like the article referred to, above, suggests then how does the following scenario work?
A user registers on a website by filling out a form with relevant details. When the user clicks the 'submit' button on the form the web application takes the form data and creates a message which it sends to the application tier using NServiceBus and Bus.Send(). The application tier goes about the business of creating the new user and publishing the event that the user has been created (Bus.Publish()) so that other processes can do their thing (email the new user, add the user to a search index, etc, etc).
Now, since the web application in this scenario relies entirely on the application tier for the creation of the new user instance, how does it get to know about the user's id? If I didn't use NServiceBus in this scenario but, rather, let the website issue an in-process call to a DAL I'd use NHibernate's GuidComb() strategy to create the identifier for the new user before persisting the new row in the database. If the message handler application which receives the command to create a new user (in the current scenario) uses the same strategy, how is the userId communicated back to the web application?
Do I have to apply a different strategy for managing identifiers in a scenario such as this?
You're free to come up with an ID to use as a correlation identifier by putting it in your message in the web application, allowing it to be carried around whatevery processes are initiated by the message.
That way, you can correlate the request with other events around your system, if only they remember to supply the correlation ID.
But it sounds like you want your user ID to be fed back to you in the same web request - that cannot easily be done with an asynchronous backend, which is what messaging gives you.
Wouldn't it be acceptable to send an email to the user when the user has been created, containing a (secret) link to some kind of gateway, that resumes the user's session?
Wouldn't the UI be able to listen to the bus for the "user created" event? And then you could correlate either by having the event include some kind of event ID linking back to the "user creation requested" event or against some other well known data in the event (like the user name). Though you probably also have to listen to multiple events, such as "user creation failure" event.
This is not unlike normal AJAX processing in a web browser. Technically, you don't block on the out of band call back to the web server. You invoke the call and you asynchronously wait for a callback.