In our company, we use Lync/Skype for Business. In the database, is there a way to know whether a call is missed?
For example, a customer called the support number, but for certain reason, the call is not pickup, is there a way to find this call info by query Lync/Sfb database?
Or, Lync/SfB will not log info in this case?
Thanks
It depends on the "Call" did you refer here to a PSTN call? If thats a simple VOIP call then a so called peer2peer call might happen here which didn´t involved the Skype for Business (=SfB) / Lync server as this is done between both SfB clients without the server.
I think a good step might be to check whats currently possible with the build in Monitoring Reports in Skype for Business Server (see here as starting point).
Related
I need to implement the following logic - I send a message to the user, and if he doesn't reply, I send it again after 12 hours.
I wonder what is the best way to do this? I was thinking about using Akka.NET - after a certain amount of time the actor would check if the user replied to my message and if not, would send it again.
Is there maybe an easier way? If not, there are some questions for Akka.NET
Do you know any good sources where I can see how this library should be used in ASP.NET Core? The documentation is not clear enough for me.
Where to keep the actors and the logic associated with them? In a separate project? Where can I create an actorSystem?
I'm new to this topic, thank you in advance for all the answers.
I theory you could just use standard actor system schedule a message order to resend an email after 12h, but this has natural problems with a fact, that if your process will crash, all of its in-memory state will be lost.
In practice you could use one of two existing plugins, which give you durable schedules:
Akka.Persistence.Reminders which works on top of Akka.Persistence, so you can use it on top of any akka.net persistence plugin.
Another way is to use Akka.Quartz.Actor which offers dedicated actors on top of Quartz.NET and makes use of Quartz's persistence capabilities.
This is a theoretical question.
imagine an aspnet website. by clicking a button site sends mail.now:
I can send mail async with code
I can send mail using QueueBackgroundWorkItem
I can call a ONEWAY webservice located in same website
I can call a ONEWAY webservice located in ANOTHER website (or another subdomain)
none of above solutions wait for mail operation to be completed.so they are fine.
my question is why I should use service solution instead of other solutions. is there an advantage ?
4th solution adds additional tcpip traffic to use service its not efficient right ?
if so, using service under same web site (3rd solution) also generates additional traffic. is that correct ?
I need to understand why people using services under same website ? Is there any reason besides make something available to ajax calls ?
any information would be great. I really need to get opinions.
best
The most appropriate architecture will depend on several factors:
the volume of emails that needs to be sent
the need to reuse the email sending capability beyond the use case described
the simplicity of implementation, deployment, and maintenance of the code
Separating out the sending of emails in a service either in the same or another web application will make it available to other applications and from client side code. It also adds some complexity to the code calling the service as it will need to deal with the case when the service is not available and handle errors that may occur when placing the call.
Using a separate web application for the service is useful if the volume of emails sent is really large as it allows to offload the work to one or servers if needed. Given the use case given (user clicks on a button), this seems rather unlikely, unless the web site will have really large traffic. Creating a separate web application adds significant development, deployment and maintenance work, initially and over time.
Unless the volume of emails to be sent is really large (millions per day) or there is a need to reuse the email capability in other systems, creating the email sending function within the same web application (first two options listed in the question) is almost certainly the best way to go. It will result in the least amount of initial work, is easy to deploy, and (perhaps most importantly) will be the easiest to maintain.
An important concern to pay significant attention to when implementing an email sending function is the issue of robustness. Robustness can be achieved with any of the possible architectures and is somewhat of an different concern as the one emphasized by the question. However, it is important to consider the proper course of action needed if (1) the receiving SMTP refuses the take the message (e.g., mailbox full; non-existent account; rejection as spam) and (2) an NDR is generated after the message is sent (e.g., rejection as spam). Depending on the kind of email sent, it may be OK to ignore these errors or some corrective action may be needed (e.g., retry sending, alert the user at the origination of the emails, ...)
I`m trying to build a script that will capture the credit card info like card number,cvc and expiration date using asterisk 11.x and asterisk-java library for AMI/AGI integration.
Right now I am able to build a script that will acquire that info if it is called via dialplan but i have a different scenario:
1. A call enters a queue.
2. An agent from the specific queue answer the call
3. The caller wants to input the card details
4. After the caller has entered the card details is redirected back to agent to continue the call.
My specific problem is related to step 3 as I do not know how to route the caller to my AGI and then back to the same agent. (eventually the agents has to be still involved in (some) call to guarantee that when the caller returns from agi it is still available)
Any idea how can I achieve that ? I know that this is a common practice so I think that there has to be a way.
When the call is delivered to the agent, use a macro to set a custom channel variable with the agent ID or extension in it.
Then, when your credit-card authentication function is done, read the variable and use an AGI command to transfer the call back to the agent.
Further Reading
http://www.voip-info.org/wiki/view/Asterisk+variables
http://www.voip-info.org/wiki/view/Asterisk+manager+Example:+Transfer
Note if this solution solves your problem, please 'accept' it to make it easier for others with the same issue to find it. thanks!
There are no any common practice for business process like you have. That depend of you and your client only.
You can use features conf or transfer. Can transfer to special extension or to conference room.
No way say what suite you better.
For sure you need understand how asterisk work before write any AGI/AMI or dialplan application. I can recommend ORelly's "Asterisk the future of telephony" book as start point.
I would like to know if there is a web api for asterisk. I would also like to know if the average wait time to talk to a customer service agent is exposed through the api.
I have looked around online, but could not get an firm answer.
Any pointers are appreciated.
AFAIK, no, there is no such thing in Asterisk.
What does exist is the ability of parsing the queue_log file. You can get the moment the call started, the moment the call was answered by an agent, and subtract them - this will give you the wait time. Also, the first extra data value of the CONNECT event contains the time waited.
(If you are not in the mood for parsing a text file, you can register the queue logs in the database and use SQL to generate reports based on the logs. This is in fact my preferred approach.)
If you want to provide this information to other apps, you can write your own application which reads queue_log file/table and provides a webservice which returns wait times. In the case you decide to do it, we can try some more robust answers.
I'm writing an application where the user will create an appointment, and instantly get an email confirming their appointment. I'd also like to send an email the day of their appointment, to remind them to actually show up.
I'm in ASP.NET (2.0) on MS SQL . The immediate email is no problem, but I'm not sure about the best way to address the reminder email. Basically, I can think of three approaches:
Set up a SQL job that runs every night, kicking off SQL emails to people that have appointments that day.
Somehow send the email with a "do not deliver before" flag, although this seems like something I might be inventing.
Write another application that runs at a certain time every night.
Am I missing something obvious? How can I accomplish this?
Choice #1 would be the best option, create a table of emails to send, and update the table as you send each email. It's also best not to delete the entry but mark it as sent, you never know when you'll have a problem oneday and want to resend out emails, I've seen this happen many times in similar setups.
One caution - tightly coupling the transmission of the initial email in the web application can result in a brittle architecture (e.g. SMTP server not available) - and lost messages.
You can introduce an abstraction layer via an MSMQ for both the initial and the reminder email - and have a service sweeping the queue on a scheduled basis. The initial message can be flagged with an attribute that means "SEND NOW" - the reminder message can be flagged as "SCHEDULED" - and the sweeper simply needs to send any messages that it finds that are of the "SEND NOW" or that are "SCHEDULED" and have a toBeSentDate >= the current date. Once the message is successfully sent - the unit of work can be concluded by deleting the message from the queue.
This approach ensures messages are not lost - and enables the distribution of load to off-peak hours by adjusting the service polling interval.
As Rob Williams points out - my suggestion of MSMQ is a bit of overkill for this specific question...but it is a viable approach to keep in mind when you start looking at problems of scale - and you want (or need) to minimize/reduce database read/write activity (esepcially during peak processing periods).
Hat tip to Rob.
For every larger project I usually also create a service which performs regular or periodical tasks.
The service updates its status and time of last execution somewhere in the database, so that the information is available for applications.
For example, the application posts commands to a command queue, and the service processes them at the schedule time.
I find this solution easier to handle than SQL Server Tasks or Jobs, since it's only a single service that you need to install, rather than ensuring all required Jobs are set up correctly.
Also, as the service is written in C#, I have a more powerful programming language (plus libraries) at hand than T-SQL.
If it's really pure T-SQL stuff that needs to be handled, there will be a Execute_Daily stored procedure that the service is going to call on date change.
Create a separate batch service, as others have suggested, but use it to send ALL of the emails.
The web app should record the need to send notifications in a database table, both for the immediate notice and for the reminder notice, with both records annotated with the desired send date/time.
Using MSMQ is overkill--you already have a database and a simple application. As the complexity grows, MSMQ or something similar might help with that complexity and scalability.
The service should periodically (every few minutes to a few hours) scan the database table for notifications (emails) to send in the near future, send them, and mark them as sent if successful. You could eventually leverage this to also send text messages (SMS) or instant messages (IMs), etc.
While you are at it, you should consider using the Command design pattern, and implement this service as a reusable Command executor. I have done this recently with a web application that needs to keep real estate listing (MLS) data synchronized with a third-party provider.
Your option 2 certainly seems like something you are inventing. I know that my mail system won't hold messages for future delivery if you were to send me something like that.
I don't think you're missing anything obvious. You will need something that runs the day of the appointment to send emails. Whether that might be better as a SQL job or as a separate application would be up to your application architecture.
I would recommend the first option, using either an SQL or other application to run automatically every day to send the e-mails. It's simple, and it works.
Microsoft Office has a delivery delay feature, but I think that is an Outlook thing rather than an Exchange/Mail Server thing, so you're going to have to go with option 1 or 3. Or option 4 would be to write a service. That way you won't have to worry about scheduled tasks to get the option 3 application to run.
If you are planning on having this app hosted at a cheap hosting service (like GoDaddy), then what I'd recommend is to spin off a worker thread in Global.asax at Application_Start and having it sleep, wake-up, send emails, sleep...
Because you won't be able to run something on the SQL Server machine, and you won't be able to install your own service.
I do this, and it works fine.