How to encode audio for Alexa Voice? - audio

I would like to use Amazon's Alexa Voice Service (AVS) but when I use the Recognize Speech Request all I get back is "{message: null}". Authentication works, request seems to be correct because I've received error messages from the API when authentication failed or request was malformed.
I have a wav audio file, 16000 Hz, 1 channel, and use PHP's base64_encode() to encode the wav file's content.
For the audio file the AVS documentation only says Type: Binary Data. Represents the data for the audio.
Here's the request I'm sending:
Headers
POST /v1/avs/speechrecognizer/recognize HTTP/1.1
Host: access-alexa-na.amazon.com
Content-Type: multipart/form-data; boundary=86371ffc080fbb6fc614e8e36d0b8a4d
Authorization: Bearer Atza|IQEBL... (valid token)
Transfer-Encoding: chunked
Cache-Control: no-cache
Body
--86371ffc080fbb6fc614e8e36d0b8a4d
Content-Disposition: form-data; name="request"
Content-Type: application/json; charset=UTF-8
{
"messageHeader": {
"deviceContext": [
{
"name":"playbackState",
"namespace":"AudioPlayer",
"payload": {
"streamId": "xxxxxxxxxxxx",
"offsetInMilliseconds": "xxxxxxxxxxxx",
"playerActivity": "xxxxxxxxxxxx"
}
}
]
},
"messageBody": {
"profile": "alexa-close-talk",
"locale": "en-us",
"format": "audio/L16; rate=16000; channels=1"
}
}
--86371ffc080fbb6fc614e8e36d0b8a4d
Content-Disposition: form-data; name="audio"
Content-Type: audio/L16; rate=16000; channels=1
SUQzAgAAAAAQS1RUMgAAFwBhb...(truncated result of base64_encode(file.wav))
--86371ffc080fbb6fc614e8e36d0b8a4d--
Any idea what's wrong/missing?

The encoding for the audio file should be Linear PCM not base 64. Hope this helps

The POST body should contain the raw audio binary data. You can use a tool like sox to convert the audio to the format AVS is expecting it in which is mono channel, 16k Hz sample rate, signed 16 bit PCM.

Related

Etag support for S/4 EX

Etag is supported in SDK: https://sap.github.io/cloud-sdk/docs/java/features/odata/use-typed-odata-v4-client-in-sap-cloud-sdk-for-java/#handling-of-etags
So experimenting it by using BusinessPartner entity in S/4 EX.
But seems there's no If-Match header:
How come the header doesn't show up - any prerequisite with etag?
(entering on behalf of the implementation partner team)
I checked the VersionIdentifier of the response and it was not set to a value.
I also checked the response's JSON __metadeta and header, but there were no values that appeared to correspond to the ETag value.
[Code]
BusinessPartner bp1 = new DefaultBusinessPartnerService().getBusinessPartnerByKey(bpId).execute(dest);
log.debug("get 1: {}", bp1);
log.debug("get 1 VersionIdentifier: {}", bp1.getVersionIdentifier());
bp1.setOrganizationBPName1("SCP Update 1st:" + System.currentTimeMillis());
ODataUpdateResult result1 = new DefaultBusinessPartnerService().updateBusinessPartner(bp1).execute(dest);
log.debug("Update1 Http Status: {}", result1.getHttpStatusCode());
bp1.setOrganizationBPName1("SCP Update 2nd:" + System.currentTimeMillis());
bp1.setVersionIdentifier("dummy");
ODataUpdateResult result2 = new DefaultBusinessPartnerService().updateBusinessPartner(bp1).execute(dest);
log.debug("Update2 Http Status: {}", result2.getHttpStatusCode());
[Log]
get 1: BusinessPartner(super=VdmObject(customFields={}, changedOriginal...
get 1 VersionIdentifier: None
Update1 Http Status: 204
Update2 Http Status: 204
[GET Response JSON(__metadata) / Response Header]
(It has masked the IP address.)
"__metadata": {
"id": "https://xxx.xxx.xxx.xxx:xxxxxx/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1000001')",
"uri": "https://xxx.xxx.xxx.xxx:xxxxxx/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1000001')",
"type": "API_BUSINESS_PARTNER.A_BusinessPartnerType"
},
HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
content-length: 3152
dataserviceversion: 2.0
sap-metadata-last-modified: Thu, 14 May 2020 23:58:07 GMT
cache-control: no-store, no-cache
sap-processing-info: ODataBEP=,crp=,RAL=,st=,MedCacheHub=SHM,codeployed=X,softstate=
sap-server: true
sap-perf-fesrec: 243070.000000
I tried setting the VersionIdentifier to a meaningless value in my test code (2nd update).
The update process seems to be successful, although the request header now has "If-Match" added to it.
(I was expecting the update to fail because the values never match, so I was hoping the update would fail.)
[2nd Update(setVersionIdenfifier)]
(It has masked some of the values.)
PATCH http://xxx.xxx.xxx.xxx:xxxxxx/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner(BusinessPartner='1000001') HTTP/1.1
x-csrf-token: xxx
Content-Type: application/json
Accept: application/json
If-Match: dummy
Authorization: Basic xxx
SAP-Connectivity-SCC-Location_ID: xxx
Proxy-Authorization: Bearer xxx
sap-language: en
sap-client: xxx
Content-Length: 55
If ETags are not part of OData service responses, then you should approach the IT/administrators who maintain the S/4 backend. The SAP Cloud SDK is only consuming the OData service. Unfortunately it can't leverage ETag support if it's disabled.

How to use Microsoft.Graph with client authorization and not get a 401

We have
created Azure Active Directory
created a new Application
registered the new Application in Azure AD
given ALL the permissions to the API
granted admin permissions
Now we login with this app credentials
We get authorization:
GET /1111111-aaaa-4fd3-bf32-9bfc460f67b1/oauth2/v2.0/authorize HTTP/1.1
Host: login.microsoftonline.com
cache-control: no-cache
Postman-Token: 111111-aaaa-4696-9828-9110670706c5
We get the token:
POST /11111111-aaaa-4fd3-bf32-9bfc460f67b1/oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded
cache-control: no-cache
Postman-Token: 11111111-aaaa-47e4-b2fb-6b94cd02312a
client_id=11111111-aaaa-482e-ab17-86e4c2c6240c
scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
client_secret=aaaaaaaaaaaDJk6jBJ%2FuBRJM6AFxyFIDMKn867hmvU%3D
grant_type=client_credentials
The token analyzed with jwt.io:
{
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/1111111-ccc6-4fd3-bf32-9bfc460f67b1/",
"iat": 1541603660,
"nbf": 1541603660,
"exp": 1541607560,
"aio": "42RgYFB+/Gyh8uF3yl+uKU7km//kFwA=",
"app_displayname": "ToDoListService",
"appid": "1111111-4e99-482e-ab17-86e4c2c6240c",
"appidacr": "1",
"idp": "https://sts.windows.net/1111111-ccc6-4fd3-bf32-9bfc460f67b1/",
"oid": "1111111-98fb-4a47-af7f-d3800dde2f7b",
"roles": [
"Chat.UpdatePolicyViolation.All",
"Calls.JoinGroupCall.All",
"EduRoster.Read.All",
"OnlineMeetings.Read.All",
"Mail.ReadWrite",
"OnlineMeetings.ReadWrite.All",
"Device.ReadWrite.All",
"User.ReadWrite.All",
"Domain.ReadWrite.All",
"Application.ReadWrite.OwnedBy",
"SecurityEvents.Read.All",
"Calendars.Read",
"EduAssignments.ReadWrite.All",
"People.Read.All",
"Application.ReadWrite.All",
"Calls.InitiateGroupCall.All",
"Group.Read.All",
"Directory.ReadWrite.All",
"EduAssignments.ReadWriteBasic.All",
"MailboxSettings.Read",
"EduAdministration.Read.All",
"Calls.JoinGroupCallAsGuest.All",
"Sites.Read.All",
"Sites.ReadWrite.All",
"Contacts.ReadWrite",
"Group.ReadWrite.All",
"Sites.Manage.All",
"SecurityEvents.ReadWrite.All",
"Notes.Read.All",
"User.Invite.All",
"EduRoster.ReadWrite.All",
"Files.ReadWrite.All",
"Directory.Read.All",
"User.Read.All",
"EduAssignments.ReadBasic.All",
"EduRoster.ReadBasic.All",
"Files.Read.All",
"Mail.Read",
"Chat.Read.All",
"ChannelMessage.Read.All",
"EduAssignments.Read.All",
"Calendars.ReadWrite",
"identityriskyuser.read.all",
"EduAdministration.ReadWrite.All",
"Mail.Send",
"ChannelMessage.UpdatePolicyViolation.All",
"MailboxSettings.ReadWrite",
"Contacts.Read",
"IdentityRiskEvent.Read.All",
"AuditLog.Read.All",
"Member.Read.Hidden",
"Calls.AccessMedia.All",
"Sites.FullControl.All",
"Reports.Read.All",
"Calls.Initiate.All",
"Notes.ReadWrite.All"
],
"sub": "1111111-98fb-4a47-af7f-d3800dde2f7b",
"tid": "1111111-ccc6-4fd3-bf32-9bfc460f67b1",
"uti": "hxPwbjRRm0y6SI8hxuckAA",
"ver": "1.0",
"xms_tcdt": 1541414851
}
You can see that we get all the necesary permissions.
And this petition works:
https://graph.microsoft.com/v1.0/Users/
or
https://graph.microsoft.com/beta/Users/
but not this one:
https://graph.microsoft.com/beta/Users/<user-id>/Calendars
nor this one:
https://graph.microsoft.com/beta/users/<user-id>/sendMail
they both return 401:
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "019ddc83-6528-4f19-95cc-8b99ea53a046",
"date": "2018-11-07T16:03:55"
}
}
}
I think that we had got all the necessary permission, configuration... etc... so why isn't it working? :'(
[UPDATE]
detailed call to get calendars
GET /v1.0/Users/<user-id>/Calendars HTTP/1.1
cache-control: no-cache
Postman-Token: xxxxxxxxxxxxxxxxxxxxxxx
Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
User-Agent: PostmanRuntime/7.3.0
Accept: */*
Host: graph.microsoft.com
accept-encoding: gzip, deflate
Connection: close
Response
HTTP/1.1 401 Unauthorized
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json
request-id: 11111111-aaaa-aaaa-a115-e09bb6f09917
client-request-id: 11111111-aaaa-aaaa-a115-e09bb6f09917
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Europe","Slice":"SliceC","Ring":"3","ScaleUnit":"001","Host":"AGSFE_IN_34","ADSiteName":"NEU"}}
Duration: 377.0084
Strict-Transport-Security: max-age=31536000
Date: Thu, 08 Nov 2018 09:16:03 GMT
Connection: close
c6
{
"error": {
"code": "UnknownError",
"message": "",
"innerError": {
"request-id": "2bb9a7c1-f8a3-4c1f-a115-e09bb6f09917",
"date": "2018-11-08T09:16:04"
}
}
}
0
let me start by first of all noticing that you have posted a client secret on a public forum :) And one that has luxurious permission on your tenant. I hope you have changed the client secret by now.
But to get back to your question - I will have to ask a bit more in detail to get a better understanding of what your actual results were:
According to your JWT printout you are getting a V1 token but using the client credential flow (the field "ver" is set to 1.0). The Microsoft Documentation here Get access without a user explicitly states that you should use a V2 Token to access Microsoft Graph in this scenario. So the first question is: Did you create your Azure App using the V2 Portal: https://apps.dev.microsoft.com/ ? If not then this may be the issue.
A more common issue when manually testing - Have you made sure that the token had not expired from the time you got it from the /token endpoint up to the time you tested your API call?
If none of the above - please post your request to the https://graph.microsoft.com/beta/Users//Calendars endpoint in detail, the devil may be in the details

INVALID_REQUEST_PARAMETER - filename not found in Content-Disposition header of multipart form

I am attempting to add a document by multipart form to an existing draft envelope via the Docusign REST API endpoint: /envelopes/[envelopeId]/documents/[documentId]
The error message I get is:
The request contained at least one invalid parameter. A filename was not
found in the Content-Disposition header ('filename="filename.ext"
As you can see, there is a filename parameter in the Content-Disposition value. I've tried multiple different edits and adjustments of the Content-Disposition header, but each has failed. Here is what appears to be the correct format that throws the error.
Headers:
Authorization "Bearer [token]"
Accept "application/json"
Content-Type "multipart/form-data; boundary=AAAAAA"
--AAAAAA
Content-Disposition: form-data
Content-Type: application/json
{"fileExtension":"pdf","name":"test file name.pdf","documentId":1,"order":1}
--AAAAAA
Content-Disposition: file; filename="test file name.pdf"; documentId=1
Content-Type: application/pdf
[binary output]
--AAAAAA--
Anyone from Docusign or in general able to see what's wrong or give me a hand? Thanks.
multipart/form-data will not work for the updateEnvelopeDocument api
Instead specify the Content-Type and content-disposition in the Headers. Request body should only contain the file stream.
put /envelopes/[envelopeId]/documents/[documentId]
[Headers]
Content-Type: application/pdf
content-disposition: file; filename="test file name.pdf"; fileExtension=pdf; documentId=1
[Body]
[binary output]
The other option is to use the updateListEnvelopeDocuments api which supports multipart/form-data. You can also choose to update multiple documents in a single api call using this api.
PUT /v2/accounts/{accountId}/envelopes/{envelopeId}/documents
Headers:
Authorization "Bearer [token]"
Accept "application/json"
Content-Type "multipart/form-data; boundary=AAAAAA"
--AAAAAA
Content-Type: application/json
Content-Disposition: form-data
{
"documents": [
{
"documentId": 1,
"fileExtension": "pdf",
"name": "test file name.pdf"
}
]
}
--AAAAAA
Content-Type: application/pdf
Content-Disposition: file; filename="test file name.pdf"; fileExtension=pdf; documentId=1
Content-Transfer-Encoding: stream
[Binary output]
--AAAAAA--

Create AD user and add to group at the same time?

I know how to create an AD B2C user, as well as add them to a group via the graph API. I'm doing this in my Azure Function. What I'm wondering is, is it possible to create the user and add them to the group at the same time? If not, then I suppose I'll have to handle the potential case of a user being created but failing to be added to a group. How likely is this sort of scenario? I'm trying to make sure I cover all my bases for all failure conditions, so any input would be appreciated. Thanks.
It seems like you want to use Batch Processing for these kinds of requests.
Here is the sample request they post in the article:
The following example shows a batch request that contains five items:
A change set that creates a user, testuser#contoso.onmicrosoft.com (POST). This operation includes the Prefer: response-no-content header to suppress the newly created user being returned.
A change set that updates the Department and Job Title properties of the new user (PATCH), and sets its manager navigation property (PUT).
A query for the manager of the new user (GET).
A change set that deletes the new user (DELETE).
A query for the user (GET). This operation will fail because the user was deleted in the previous step.
POST https://graph.windows.net/contoso.onmicrosoft.com/$batch?api-version=1.5 HTTP/1.1
Authorization: Bearer ey … jQA
Content-Type: multipart/mixed; boundary=batch_36522ad7-fc75-4b56-8c71-56071383e77b
Host: graph.windows.net
Content-Length: 2961
--batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: multipart/mixed; boundary=changeset_77162fcd-b8da-41ac-a9f8-9357efbbd620
Content-Length: 631
--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd620
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /contoso.onmicrosoft.com/users?api-version=1.5 HTTP/1.1
Content-Type: application/json
Accept: application/json
Content-Length: 256
Prefer: return-no-content
Host: graph.windows.net
{
"accountEnabled": true,
"displayName": "Test User",
"mailNickname": "testuser",
"passwordProfile": { "password" : "Test1234", "forceChangePasswordNextLogin": false },
"userPrincipalName": "testuser#contoso.onmicrosoft.com"
}
--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd620----batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: multipart/mixed; boundary=changeset_4b2cbfb7-011d-4edb-8bbf-e044f9830aaf
Content-Length: 909
--changeset_4b2cbfb7-011d-4edb-8bbf-e044f9830aaf
Content-Type: application/http
Content-Transfer-Encoding: binary
PATCH /contoso.onmicrosoft.com/users/testuser#contoso.onmicrosoft.com?api-version=1.5 HTTP/1.1
Content-Type: application/json
Accept: application/json
Content-Length: 72
Host: graph.windows.net
{
"department": "Engineering",
"jobTitle": "Test Engineer"
}
--changeset_4b2cbfb7-011d-4edb-8bbf-e044f9830aaf
Content-Type: application/http
Content-Transfer-Encoding: binary
PUT /contoso.onmicrosoft.com/users/testuser#contoso.onmicrosoft.com/$links/manager?api-version=1.5 HTTP/1.1
Content-Type: application/json
Accept: application/json
Content-Length: 112
Host: graph.windows.net
{
"url":"https://graph.windows.net/contoso.onmicrosoft.com/users/a71e4d1c-ce99-40dc-8d4b-390eac63e039"
}
--changeset_4b2cbfb7-011d-4edb-8bbf-e044f9830aaf----batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: application/http
Content-Transfer-Encoding:binary
GET /contoso.onmicrosoft.com/users/testuser#contoso.onmicrosoft.com/$links/manager?api-version=1.5 HTTP/1.1
Accept: application/json
Host: graph.windows.net
--batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: multipart/mixed; boundary=changeset_9a0b5878-0f4a-4f57-91c5-9792cdd5ef20
Content-Length: 331
--changeset_9a0b5878-0f4a-4f57-91c5-9792cdd5ef20
Content-Type: application/http
Content-Transfer-Encoding: binary
DELETE /contoso.onmicrosoft.com/users/testuser#contoso.onmicrosoft.com?api-version=1.5 HTTP/1.1
Accept: application/json
Host: graph.windows.net
--changeset_9a0b5878-0f4a-4f57-91c5-9792cdd5ef20----batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: application/http
Content-Transfer-Encoding:binary
GET /contoso.onmicrosoft.com/users/testuser#contoso.onmicrosoft.com?api-version=1.5 HTTP/1.1
Accept: application/json
Host: graph.windows.net
--batch_36522ad7-fc75-4b56-8c71-56071383e77b--

TXT post to DocuSign always gives INVALID_MULTI_PART_REQUEST Boundary terminator not found error

I'm new to this and probably doing something very stupid, but if I carry on like this, I'll be bald!
As a test, I am just trying to send a TXT document for signing to DocuSign via a HTTP Post. I have followed the examples they give (I believe) but what ever I try, I get the same error.
Error:
"INVALID_MULTI_PART_REQUEST",
"message": "An error was found while parsing the multipart request. Boundary terminator '--AAAAA--' was not found in the request.
Ultimately I want to send base64 encoded PDFs but if I cannot even get TXTs to work...
I am using an XML scripting language specific to our in-house application to make the HTTP request, and the process has a diagnostic mode which can dump the request elements out to file to help sort issues: These TXT files are next and I have removed any sensitive data:
REQUESTHEADERS.TXT:
Content-Type: multipart/form-data; boundary=AAAAA
Content-Length: 565
X-DocuSign-Authentication: <DocuSignCredentials> <Username>myemail#myemail.com</Username><Password>mypassword</Password> <IntegratorKey>mykey</IntegratorKey></DocuSignCredentials>
Host: demo.docusign.net
Accept: application/json; charset=UTF-8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
REQUESTDATA.TXT
Content-Type: application/json; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: form-data
{
"status":"created",
"emailSubject":"Test",
"emailBlurb":"This is a test",
"documents":[
{
"name":"test1.txt",
"documentId":"1",
"order":"1"
}
],
"recipients":{
"signers":[
{
"email":"myemail#myemail.com",
"name":"Fred Blogs",
"recipientId":"1"
}
]
}
}
--AAAAA
Content-Type: text/plain; charset=UTF-8
Content-Disposition: file; filename="test1.txt";documentid=1
Please sign this test document
--AAAAA--
Please, if any one can tell me what is wrong I would be very grateful indeed!
It's the formatting of the call, please take note on where I have line breaks and where I do not.
Request
--AAAAA
Content-Type: application/json; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: form-data
{
"status":"created",
"emailSubject":"Test",
"emailBlurb":"This is a test",
"documents":[
{
"name":"test1.txt",
"documentId":"1",
"order":"1"
}
],
"recipients":{
"signers":[
{
"email":"myemail#myemail.com",
"name":"Fred Blogs",
"recipientId":"1"
}
]
}
}
--AAAAA
Content-Type: text/plain; charset=UTF-8
Content-Disposition: file; filename="test1.txt";documentid=1
Please sign this test document
--AAAAA--
Response
{
"envelopeId": "{envelopeId}",
"uri": "/envelopes/{envelopeId}",
"statusDateTime": "2015-02-27T18:53:39.5700000Z",
"status": "created"
}

Resources