No delivery

[DrVoIP]

I have debugged a number of issues using the deployment guide and seem to get this working right up to the delivery of the recording. No email, SMS options seem to work. The doc is not clear on SES as to verification of users. Do you need to get the users listed and verified first? Even after email verification of user, no email sent. Where are logs for SES attempts and failures? I have made several deployments but seem to fail on the delivery side any guidance is appreciated.

[efh365]

Hi DrVoIP,

Only the sender email needs to be verified. If you deployed your stack before verifying the email, it takes a few hours for the email verification to propagate and emails go through.

You can look for the logs for the notification delivery in CloudWatch under the Lambda function that has 'VoicemailStream' in the title.

A few other areas to check: 1) Do you have live media streaming enabled in your Connect instance? 2) Do you see logs in the Lambda function with 'KvsProcess' in the title? That will show that you are consuming the streams properly to kick off the audio processing 3) Did you deploy in a region where SES and other dependent AWS services are available?

[DrVoIP]

First, very creative solution. Well done. We find not cludwatch log with voicemailstream in title. There are about 12 other voice mail functons in the log, but none that say stream? 1 - media streaming enabled 2 KvsProcess working 3 - SES is in the region Who is the Sender email? That might be the issue. Observation - I modified the queue hold flow so that after we check agent extension and find they are Uavailable, we prompt to press a key if they want to transfer to another member of the team; if not we take the message. We not that the use of TRANSFER TO QUEUE step follows the success path, but always disconnects the caller? Is this a result of previously setting the queue to the agentID as that is the only difference between this any any other hold queue flow?

[DrVoIP]

I also note that when logging into Cognito that I can an alert that says I have selected Cognito to send emails?

[efh365]

Thanks for the responses.

The sender email was entered when you deployed the stack. It is also visible when viewing the global settings in the admin portal. That is the email that should be verified by SES. Were you able to look at the CloudWatch logs I suggested? That will show if a notification was attempted to be sent. If there are no logs there then it is failing at an earlier step.

In regards to your observation, I think I am following your use case. Is the agent available when you transfer the customer?

Yes, I believe you can let Cognito send emails. I have not tested this scenario though.

[DrVoIP]

1 - In a standard deployment, which is sending email SES or Cognito? I was just noting that when I looked at Cognito it had a warning suggesting SES should be used rather an Cognito. I just deployed the stack as provided in the template with no change. 2 - you suggested looking in cloudwatch for a log with VoicemailStreamn the title. As I reported there is not such log or lambda function with stream in the title? There are about 10functions created by CF but none with streamin the title. 3 - I made a simple contact flow after the flow reports the agent is unavailalbe, offering them the option to leave amessage for the agent or to transfer to someone on else using the Tranfer To Queue step. That fails the only way I get it to work is to transfertoa phone number which is not desirable as we then lose all the contact attributes. As it stands we still do not get emails,sms or transcriptions, though all else seems to work. I note no recordings in the s3 bucket created by CF name contains audiorecordingsbucket. Then that might be the root issue?

[michaelgamazon]

I see that you mentioned, "I note no recordings in the s3 bucket created by CF name contains audiorecordingsbucket. Then that might be the root issue?" I agree that that seems like a likely root cause. I have a recording for every voicemail. Perhaps looking at the access log for that bucket could help. This CloudFormation script setups up an access logging bucket with the words voicemailaccesslogbucket and send the access requests for the audio recordings to that bucket with the prefix of audio-recording-bucket-logs. Those logs might tell us if a permissions issue is to blame.

In order to see what puts the object here I enabled object level logging in my audio recording bucket and saw that the putobject call is made by the KVSProcessRecording Lambda function. This is the Java Lambda function Looks like this occurs in the code around here [2]. Can you look in your CloudWatch logs for your KVSProcessRecording Lambda function, look for "Uploading Audio", and let us know if you see any errors around this part of the logs?

[DrVoIP]

cloudwatch for that KVS log looks ok, but I dont see anything that says "uploading audio" I see Start, Processing CTR, Record Data (all the json content looks correct but there is a lot of nul data for example "NextContactId": null, "PreviousContactId": null, "Queue": { "ARN": "arn:aws:connect:us-west-CCCCCCCCCCCC:instance/ff882dc3-b208-446a-a9d5-397367217ff0/queue/agent/cf45f63b-02a4-49f3-aa31-9ee264031bc8", "DequeueTimestamp": "2020-04-16T20:35:24Z", "Duration": 37, "EnqueueTimestamp": "2020-04-16T20:34:47Z", "Name": null }, "Recording": null, "Recordings": null, "SystemEndpoint": { "Address": "+1760CCCCCCC", "Type": "TELEPHONE_NUMBER" }, "TransferCompletedTimestamp": null, "TransferredToEndpoint": null), but i do see this "org.json.JSONException: JSONObject["Recordings"] is not a JSONArray. " before end.

TheCCCC above are edited by me to cut out none public date.

I have done the deployment three times using the provided CF. Two times there is nothing in the recording bucket and one time there is no delivery of recorded message. sender email is verified. All else seems to be working, all lambda functions expect this one potentially do not show any errors.

[DrVoIP]

I aslo note that the dynamodB table ContactVoicemailTable-1 has not items?

[DrVoIP]

The consist error in the KVSPprocessing log is "org.json.JSONException"JSONObject["contactid"] not found

[efh365]

The error in KVSProcessing is ok. This function is triggered by CTRs and Agent Event Streams. If an event goes through that does not have a contactId, then it will trigger this function, hit the line with no contact id, then stop. The logs that do have the contact id are the ones that are related to voicemail.

"org.json.JSONException: JSONObject["Recordings"] is not a JSONArray. " >> This looks like it could be the error. When processing the audio, we pull the Recordings field off of the CTR. That should always be an array. This is on line 35 of the ContactTraceRecord.java file.

Since the example you posted has a lot of null data im wondering if it is an event that we dont care for. Can you paste that same log from an event that you know is an attempted voicemail?

Im sorry you're having so much trouble with this! I have not seen this problem from another customer yet.

[DrVoIP]

I deleted this stack. I have been able to get other deployments working ( I have done four so far) and will just assume that this first one was a learning experience. The problems I think were related to changing the kinesis stream that the CF creates to use the stream that the instance might already have configured. Additionally, I think using a SENDER email that is also the email of an Agent in the instance might also be an issue. The application is clearver and very useful. I have been able to modify it for a "dial by name" application with LEX front end that can resolve name string to extension numb, and as a bail out option in queue holds. I have been setting up Queues Names as Agent users to enable queue based voice mail, a much request functionality. It might be helpful to add FllowID to the database as a option so that if an agent is unable the caller can option for holding in an Agent Personal Queue of transfer to another queue. Anyway, impressive application and I seem to be able to work through initial issues.

[efh365]

I'm glad to hear you have it working now! I like the dial by name adjustment with Lex - great idea. Good point about adding a flow ID to the database. I will add that recommendation to our list to see if it is something we will incorporate into a future version.