View a markdown version of this page

Processeur d'analyse des appels et destinations de sortie pour le SDK Amazon Chime - Kit SDK Amazon Chime

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Processeur d'analyse des appels et destinations de sortie pour le SDK Amazon Chime

Vous ne pouvez spécifier des éléments uniques qu'une seule fois par configuration du pipeline Media Insights. Tous les processeurs et récepteurs doivent résider sur le même AWS compte, et vous devez les créer dans la même AWS région que le point de terminaison que vous appelez. Par exemple, si vous utilisez le us-east-1 point de terminaison pour Amazon Chime SDK Media Pipelines, vous ne pouvez pas transmettre un flux de données Kinesis depuis la région. us-west-2

Développez chaque section pour obtenir des informations sur chaque destination.

Éviers pris en charge :KinesisDataStreamSink.

Vous ne pouvez pas associer ce processeur à un processeur Amazon Transcribe. Pour plus d'informations sur Amazon Transcribe Call Analytics, consultez la section Analyse des Real-time appels dans le manuel Amazon Transcribe Developer Guide. Si vous activez l'analyse post-appel en l'incluant PostCallAnalyticsSettings dans l'appel d'AmazonTranscribeCallAnalyticsProcessorConfigurationAPI, vous recevez des artefacts à l'emplacement Amazon S3 spécifié lorsque le pipeline Media Insights s'arrête et que le traitement est terminé.

Note

Si vous interrompez le pipeline pendant plus de 35 secondes, puis que vous le reprenez, des artefacts post-appel sont générés dans des fichiers séparés avec des ID de session différents dans le compartiment Amazon S3.

Post-call les artefacts incluent un fichier JSON d'analyse et un fichier d'enregistrement audio WAV ou Opus. L'URL du compartiment Amazon S3 pour les fichiers d'enregistrement expurgés (si vous activez la rédaction du contenu) et non expurgés est envoyée au Kinesis Data Stream une fois pour chaque session d'analyse des appels Amazon Transcribe après l'appel, dans le cadre de la section des métadonnées. onetimeMetadata

L'analyse des appels avec Amazon Transcribe utilise les données audio entrées depuis le Kinesis Video Stream.

  • Encodage multimédia pris en charge : audio Little-Endian 16 bits signé PCM.

  • Fréquences d'échantillonnage des supports prises en charge : entre 8 000 Hz et 48 000 Hz.

StreamConfigurationentrée pour un processus Amazon Transcribe Analytics :

  • Vous devez le spécifier KinesisVideoStreamArn pour chaque flux.

  • (Facultatif) Le KVS FragmentNumber lance une tâche d'analyse des appels avec le segment situé après un fragment spécifié. S'il n'est pas fourni, il utilise le dernier segment du flux vidéo Kinesis.

  • Cela StreamChannelDefinition définit qui parle. L'analyse des appels Amazon Transcribe nécessite un son à deux canaux. Vous devez spécifier quel haut-parleur se trouve sur quel canal lorsque vous appelez l'CreateMediaInsightsPipelineAPI. Par exemple, si votre agent parle en premier, vous réglez sur ChannelId 0 to pour indiquer le premier canal et ParticipantRole AGENT pour indiquer que l'agent parle.

Note

Lorsque vous utilisez un connecteur vocal pour créer un appel à l'MediaInsightsPipelineaide d'un processeur d'analyse des appels Amazon Transcribe, le signal audio du segment du compte Voice Connector est utilisé AGENT et le son du segment PSTN est CUSTOMER destiné au. ParticipantRole

Pour le connecteur vocal SIPREC, nous nous appuyons sur les métadonnées SIPREC. Dans la plupart des cas, l'étiquette de flux dont la valeur lexicographique est la plus faible est considérée comme la. AGENT

L'exemple suivant montre l'entrée Kinesis Video Stream pour un flux audio bicanal.

"StreamChannelDefinition" : { "NumberOfChannels" : 2 "ChannelDefinitions": [ { "ChannelId": 0, "ParticipantRole": "AGENT" }, { "ChannelId": 1, "ParticipantRole": "CUSTOMER" } ] }

En revanche, l'exemple suivant montre deux entrées mono provenant de deux flux vidéo Kinesis différents.

KVS-1: "StreamChannelDefinition" : { "NumberOfChannels" : 1 "ChannelDefinitions": [ { "ChannelId": 0, "ParticipantRole": "AGENT" } ] } KVS-2: "StreamChannelDefinition" : { "NumberOfChannels" : 1 "ChannelDefinitions": [ { "ChannelId": 1, "ParticipantRole": "CUSTOMER" } ] }

Chaque enregistrement Amazon Transcribe contient un UtteranceEvent ou unCategoryEvent, mais pas les deux. CategoryEventsavoir un detail-type deTranscribeCallAnalyticsCategoryEvent.

L'exemple suivant montre le format de sortie de métadonnées à usage unique pour Amazon Transcribe.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "CallAnalyticsMetadata", "mediaInsightsPipelineId": "string", "metadata": "string" // JSON encoded string of the metadata object } // metadata object { "voiceConnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string", "oneTimeMetadata": "string" // JSON encoded string of oneTimeMetadata object } // onetimeMetadata object { "inviteHeaders": "string", // JSON encoded string of SIP Invite headers key-value pair "siprecMetadata": "string", // siprec metadata in XML "siprecMetadataJson": "string", // siprec metadata in JSON (converted from above XML) // If PostcallSettings are enabled for Amazon Transcribe Call Analytics "s3RecordingUrl": "string", "s3RecordingUrlRedacted": "string" } // inviteHeaders object { "string": "string" }

L'exemple suivant montre le format de sortie Amazon Transcribe Call Analytics.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "TranscribeCallAnalytics", "mediaInsightsPipelineId": "string", "metadata": { "voiceConnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string" }, "UtteranceEvent": { "UtteranceId": "string", "ParticipantRole": "string", "IsPartial": boolean, "BeginOffsetMillis": number, "EndOffsetMillis": number, "Transcript": "string", "Sentiment": "string", "Items": [{ "Content": "string", "Confidence": number, "VocabularyFilterMatch": boolean, "Stable": boolean, "ItemType": "string", "BeginOffsetMillis": number, "EndOffsetMillis": number, }, ] "Entities": [{ "Content": "string", "Confidence": number, "Category": "string", // Only PII is supported currently "Type": "string", "BeginOffset": number, "EndOffset": number, }, ], "IssuesDetected": [{ "CharacterOffsets": { "Begin": number, "End": number } }] }, "CategoryEvent": { "MatchedCategories": ["string"], "MatchedDetails": { "string": { "TimestampRanges": [{ "BeginOffsetMillis": number, "EndOffsetMillis": number }] } } } }

Si la configuration d'analyse des appels est associée à un connecteur vocal Amazon Chime SDK, la charge utile de mise à jour du connecteur vocal suivante sera envoyée lors d'une mise à jour en continu du connecteur vocal.

L'exemple suivant montre un format de métadonnées de mise à jour pour les processeurs Amazon Transcribe et Transcribe Call Analytics.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "CallAnalyticsMetadata", "callevent-type": "Update", "metadata": "string" // JSON encoded string of the metadata object } // metadata object { "voiceConnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string", "oneTimeMetadata": "string" // JSON encoded string of oneTimeMetadata object } // onetimeMetadata object { "sipHeaders": "string", // JSON encoded string of SIP Invite headers key-value pair "siprecMetadata": "string", // siprec metadata in XML "siprecMetadataJson": "string" // siprec metadata in JSON (converted from above XML) } // sipHeaders object { "string": "string" }

L'exemple suivant montre un format de métadonnées de mise à jour pour Call Analytics Amazon S3 Recording.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "Recording", "callevent-type": "Update", "metadata": "string" // JSON encoded string of the metadata object } // metadata object { "voiceConnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string", "oneTimeMetadata": "string" // JSON encoded in string of oneTimeMetadata object } // onetimeMetadata object { "sipHeaders": "string", // JSON encoded string of SIP Invite headers key-value pair "siprecMetadata": "string", // siprec metadata in XML "siprecMetadataJson": "string" // siprec metadata in JSON (converted from above XML) } // sipHeaders object { "string": "string" }

Les exemples suivants montrent les métadonnées permettant d'enregistrer un appel SIP entre deux personnes, Alice et Bob. Les deux participants envoient et reçoivent des fichiers audio et vidéo. Par souci de simplicité, l'exemple ne contient que des extraits de SIP et SDP, et SRC enregistre les flux de chaque participant sur SRS sans mixage.

INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 To: <sip:recorder@example.com> Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=00000000000000000000000000000000 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: <sip:2000@src.example.com>;+sip.src Content-Type: multipart/mixed;boundary=boundary Content-Length: [length] Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... Content-Type: application/rs-metadata Content-Disposition: recording-session <?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>complete</datamode> <group group_id="7+OTCyoxTmqmqyA/1weDAg=="> <associate-time>2010-12-16T23:41:07Z</associate-time> <!-- Standardized extension --> <call-center xmlns='urn:ietf:params:xml:ns:callcenter'> <supervisor>sip:alice@atlanta.com</supervisor> </call-center> <mydata xmlns='http://example.com/my'> <structure>structure!</structure> <whatever>structure</whatever> </mydata> </group> <session session_id="hVpd7YQgRW2nD22h7q60JQ=="> <sipSessionID>ab30317f1a784dc48ff824d0d3715d86; remote=47755a9de7794ba387653f2099600ef2</sipSessionID> <group-ref>7+OTCyoxTmqmqyA/1weDAg== </group-ref> <!-- Standardized extension --> <mydata xmlns='http://example.com/my'> <structure>FOO!</structure> <whatever>bar</whatever> </mydata> </session> <participant participant_id="srfBElmCRp2QB23b7Mpk0w=="> <nameID aor="sip:alice@atlanta.com"> <naSRCme xml:lang="it">Alice</name> </nameID> <!-- Standardized extension --> <mydata xmlns='http://example.com/my'> <structure>FOO!</structure> <whatever>bar</whatever> </mydata> </participant> <participant participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <nameID aor="sip:bob@biloxy.com"> <name xml:lang="it">Bob</name> </nameID> <!-- Standardized extension --> <mydata xmlns='http://example.com/my'> <structure>FOO!</structure> <whatever>bar</whatever> </mydata> </participant> <stream stream_id="UAAMm5GRQKSCMVvLyl4rFw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>96</label> </stream> <stream stream_id="i1Pz3to5hGk8fuXl+PbwCw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>97</label> </stream> <stream stream_id="8zc6e0lYTlWIINA6GR+3ag==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>98</label> </stream> <stream stream_id="EiXGlc+4TruqqoDaNE76ag==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <label>99</label> </stream> <sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ=="> <associate-time>2010-12-16T23:41:07Z</associate-time> </sessionrecordingassoc> <participantsessionassoc participant_id="srfBElmCRp2QB23b7Mpk0w==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <associate-time>2010-12-16T23:41:07Z</associate-time> </participantsessionassoc> <participantsessionassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw==" session_id="hVpd7YQgRW2nD22h7q60JQ=="> <associate-time>2010-12-16T23:41:07Z</associate-time> </participantsessionassoc> <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv> </participantstreamassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> </participantstreamassoc> </recording>

L'exemple suivant montre les métadonnées mises à jour lorsqu'un participant à un appel met l'autre en attente. Dans ce cas, reçoit participant_id srfBElmCRp2QB23b7Mpk0w== uniquement des flux multimédia et n'en envoie aucun. L'élément send XML est donc omis. En revanche, participant_id zSfPoSvdSDCmU3A3TRDxAw== envoie du contenu multimédia à l'autre participant, mais ne reçoit pas de contenu multimédia de celui-ci, de sorte que l'élément recv XML est omis.

INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 To: <sip:recorder@example.com> Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: <sip:2000@src.example.com>;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... Content-Type: application/rs-metadata Content-Disposition: recording-session <?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w=="> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv> </participantstreamassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send> </participantstreamassoc> </recording>

L'exemple suivant montre la mise à jour des métadonnées lorsque l'appel reprend. La charge utile contient désormais les éléments recv XML send et.

INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 To: <sip:recorder@example.com> Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: ab30317f1a784dc48ff824d0d3715d86 ;remote=f81d4fae7dec11d0a76500a0c91e6bf6 CSeq: 101 INVITE Max-Forwards: 70 Require: siprec Accept: application/sdp, application/rs-metadata, application/rs-metadata-request Contact: <sip:2000@src.example.com>;+sip.src Content-Type: multipart/mixed;boundary=foobar Content-Length: [length] Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ... m=video 49174 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:97 a=sendonly ... m=audio 51372 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:98 a=sendonly ... m=video 49176 RTP/AVPF 96 a=rtpmap:96 H.264/90000 a=label:99 a=sendonly .... Content-Type: application/rs-metadata Content-Disposition: recording-session <?xml version="1.0" encoding="UTF-8"?> <recording xmlns='urn:ietf:params:xml:ns:recording:1'> <datamode>partial</datamode> <participantstreamassoc participant_id="srfBElmCRp2QB23b7Mpk0w=="> <send>i1Pz3to5hGk8fuXl+PbwCw==</send> <send>UAAMm5GRQKSCMVvLyl4rFw==</send> <recv>8zc6e0lYTlWIINA6GR+3ag==</recv> <recv>EiXGlc+4TruqqoDaNE76ag==</recv> </participantstreamassoc> <participantstreamassoc participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> <send>8zc6e0lYTlWIINA6GR+3ag==</send> <send>EiXGlc+4TruqqoDaNE76ag==</send> <recv>i1Pz3to5hGk8fuXl+PbwCw==</recv> <recv>UAAMm5GRQKSCMVvLyl4rFw==</recv> </participantstreamassoc> </recording>

Éviers pris en charge :KinesisDataStreamSink.

Vous ne pouvez pas associer ce processeur à l'analyse des appels Amazon Transcribe. Pour plus d'informations sur l'entrée et la sortie d'Amazon Transcribe, consultez la section Transcrire le streaming audio dans le manuel Amazon Transcribe Developer Guide.

La session d'analyse des appels avec Amazon Transcribe prend des données audio en entrée depuis Kinesis Video Stream.

  • Supporté MediaEncoding : audio Little-Endian 16 bits signé PCM.

  • Fréquences MediaSampleRate d'échantillonnage prises en charge : entre 8 000 Hz et 48 000 Hz.

StreamConfigurationentrée pour les processeurs Amazon Transcribe :

  • Vous devez le spécifier KinesisVideoStreamArn pour chaque flux.

  • (Facultatif) KVS FragmentNumber - Démarre une tâche d'analyse des appels avec le segment situé après un fragment spécifique. S'il n'est pas fourni, il utilisera le dernier segment disponible sur le flux vidéo Kinesis.

  • StreamChannelDefinitionAmazon Transcribe prend actuellement en charge le son avec deux canaux. Vous devez le spécifier NumberOfChannels au moment de l'exécutionStreamChannelDefinition. De plus, vous devez transmettre la ChannelId valeur si vous envoyez du son mono sur deux canaux distincts. Dans votre transcription, les canaux se voient attribuer les étiquettes ch_0 et ch_1. L'exemple suivant montre l'entrée KVS pour un flux de canal audio mono.

"StreamChannelDefinition" : {" NumberOfChannels" : 1 }

L'exemple suivant montre l'entrée KVS pour deux entrées audio mono dans deux flux différents.

KVS-1: "StreamChannelDefinition" : { "NumberOfChannels" : 1 "ChannelDefinitions": [ { "ChannelId": 0 } ] } KVS-2: "StreamChannelDefinition" : { "NumberOfChannels" : 1 "ChannelDefinitions": [ { "ChannelId": 1 } ] }
Note

Pour le connecteur vocal créé à l'MediaInsightsPipelineaide d'un processeur Amazon Transcribe, le tronçon audio du compte Voice Connector est attribué à channel-0 et le tronçon audio du RTPC à. channel-1

Pour le connecteur vocal SIPREC, nous nous appuyons sur les métadonnées SIPREC. Dans la plupart des cas, l'étiquette de flux dont la valeur lexicographique est la plus faible est attribuée à. channel-0

Pour les processeurs d'analyse des appels Amazon Transcribe et Amazon Transcribe, si vous transmettez deux flux vidéo Kinesis et que chaque flux contient un canal audio mono, nous entrelacons les deux canaux en un seul flux audio avant de traiter les données d'analyse des appels Transcribe ou Transcribe.

L'exemple suivant montre un format de sortie de métadonnées à usage unique pour Amazon Transcribe.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "CallAnalyticsMetadata", "mediaInsightsPipelineId": "string", "metadata": "string" // JSON encoded string of the metadata object } // metadata object { "voiceConnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string", "oneTimeMetadata": "string" // JSON encoded string of oneTimeMetadata object } // onetimeMetadata object { "inviteHeaders": "string", // JSON encoded string of SIP Invite headers key-value pair "siprecMetadata": "string", // siprec metadata in XML "siprecMetadataJson": "string" // siprec metadata in JSON (converted from above XML) } // inviteHeaders object { "string": "string" }

L'exemple suivant montre le format de sortie Amazon Transcribe.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "Transcribe", "mediaInsightsPipelineId": "string", "metadata": { "voiceconnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string" } "TranscriptEvent": { "Transcript": { "Results": [{ "Alternatives": [{ "Entities": [{ "Category": "string", "Confidence": number, "Content": "string", "EndTime": number, "StartTime": number, "Type": "string" }], "Items": [{ "Confidence": number, "Content": "string", "EndTime": number, "Speaker": "string", "Stable": boolean, "StartTime": number, "Type": "string", "VocabularyFilterMatch": boolean }], "Transcript": "string" }], "ChannelId": "string", "EndTime": number, "IsPartial": boolean, "LanguageCode": "string", "LanguageIdentification": [{ "LanguageCode": "string", "Score": number }], "ResultId": "string", "StartTime": number }] } } }

Cuves prises en charge : KinesisDataStreamSink SqsQueueSinkSnsTopicSink,, etLambdaFunctionSink.

Vous pouvez associer ce processeur au processeur d'analyse des appels Amazon Transcribe, au processeur Amazon Transcribe ou à l'enregistrement des appels. Vous devez utiliser les StartVoiceToneAnalysisTask API StartSpeakerSearchTask or pour appeler un processeur d'analyse vocale. Pour plus d'informations sur l'utilisation de l'analyse vocale, consultez la section Utilisation de l'analyse vocale du SDK Amazon Chime.

Les enregistrements Kinesis Data Stream (KDS) générés par l'analyse des appels incluent l'ID du pipeline multimédia, le type de détail, les métadonnées et les sections spécifiques au processeur. Pour plus d'informations sur la consommation de données provenant d'un flux de données Kinesis, reportez-vous à la section Lire des données depuis Amazon Kinesis Data Streams, dans le guide du développeur Amazon Kinesis Streams. Pour créer une configuration avec ce récepteur, vous devez disposer d'une kinesis:DescribeStream autorisation sur le flux spécifié.

Metadonnées

La metadata section des enregistrements KDS générés contient toutes les paires clé-valeur spécifiées CallAnalyticsRuntimeMetadata lors de l'CreateMediaInsightsPipelineappel d'API. Si une session d'analyse des appels a été initiée par un connecteur vocal, la section des métadonnées est automatiquement remplie avec les paramètres suivants :

  • transactionId

  • fromNumber

  • toNumber

  • callId

  • voiceConnectorId

  • direction

Outre les paramètres indiqués ci-dessus, la section des métadonnées pour les sessions d'analyse des appels initiées par Voice Connector sera remplie avec un oneTimeMetadata champ contenant :

  • inviteHeaders

  • siprecMetadata

Ce document n'est publié sur Kinesis Data Streams qu'une seule fois au début de la session et possède une valeur detail-type deCallAnalyticsMetadata.

Vous pouvez transmettre des identifiants uniques dans le cadre MediaInsightsRuntimeMetadata de chaque appel d'CreateMediaInsightsPipelineAPI afin d'identifier de manière unique la source de chaque enregistrement transmis à votre flux de données Kinesis.

L'enregistrement d'analyse des appels lit le son d'un flux KVS, l'enregistre sous forme de fichier audio et télécharge le fichier vers le compartiment Amazon S3 spécifié. Après l'enregistrement, l'analyse des appels envoie également les métadonnées de l'appel ainsi que l'emplacement du fichier à KDS. Si vous activez un entrepôt de données, les métadonnées de l'appel (y compris les métadonnées SIPREC si SIPREC a été utilisé) sont transmises à l'entrepôt de données dans un ensemble de tables Parquet que vous pouvez interroger.

Comme tout autre processeur d'analyse des appels, vous devez d'abord créer une configuration pour le pipeline. Vous pouvez utiliser la console Amazon Chime SDK ou l'interface de ligne de commande pour créer la configuration. Vous utilisez ensuite l'interface de ligne de commande pour créer le pipeline. Pour plus d'informations sur l'utilisation de la console pour créer des configurations d'enregistrement, reportez-vous àCréation de configurations d'analyse des appels pour le SDK Amazon Chime, plus haut dans cette section. Pour plus d'informations sur l'utilisation des flux de travail d'enregistrement, reportez-vous àComprendre les flux de travail pour l'enregistrement des appels pour le SDK Amazon Chime, plus haut dans cette section.

Pour utiliser l'interface de ligne de commande pour créer une configuration

Exécutez la commande suivante :

aws chime-sdk-media-pipeline create-media-insights-pipeline-configuration --cli-input-json file://configuration.json

L'exemple suivant montre un fichier JSON de configuration dont seul l'enregistrement est activé :

{ "MediaInsightsPipelineConfigurationName": configuration_name, "ResourceAccessRoleArn": role_arn, "Elements": [ { "KinesisDataStreamSinkConfiguration": { "InsightsTarget": KDS_arn //Where recording live metadata will be delivered. }, "Type": "KinesisDataStreamSink" }, { "S3RecordingSinkConfiguration": { "Destination": "arn:aws:s3:::kvs-recording-testing", "RecordingFileFormat": file_format // Specify "Opus" or "WAV" as the recording file format. }, "Type": "S3RecordingSink" } ] }

Rappelez-vous ce qui suit :

  • Pour activer l'enregistrement des appels via Kinesis Video Streams, le son doit être en little-endian 16 bits signé PCM. La fréquence d'échantillonnage doit être de 8 kHz.

  • Les créateurs doivent définir une période de conservation des données suffisamment longue pour le flux vidéo Kinesis afin de garantir que les fragments sont conservés et utilisables par l'analyse des appels.

  • Si vous activez l'enregistrement des appels, seul ou en combinaison avec d'autres processeurs, vous devez fournir deux ARN Kinesis Video Stream pour l'enregistrement. L'enregistrement des appels ne prend pas en charge une seule entrée audio stéréo.

L'exemple suivant montre le format de sortie des métadonnées pour l'analyse des appels et l'enregistrement Amazon S3.

{ "time": "string", // ISO8601 format "service-type": "CallAnalytics", "detail-type": "Recording", "mediaInsightsPipelineId": "string", "s3MediaObjectConsoleUrl": "string", "recordingDurationSeconds": "number", "metadata": "string" // JSON encoded string of the metadata object } // metadata object { "voiceConnectorId": "string", "callId": "string", "transactionId": "string", "fromNumber": "string", "toNumber": "string", "direction": "string", "startTime": "string", // ISO8601 format "endTime": "string", // ISO8601 format "oneTimeMetadata": "string" // JSON encoded in string of oneTimeMetadata object } // onetimeMetadata object { "sipHeaders": "string", // JSON encoded string of SIP Invite headers key-value pair "siprecMetadata": "string", // siprec metadata in XML "siprecMetadataJson": "string" // siprec metadata in JSON (converted from above XML) } // sipHeaders object { "string": "string" }

Pour activer l'amélioration de la voix, incluez un VoiceEnhancementSinkConfiguration élément dans un appel d'CreateMediaInsightsPipelineConfigurationAPI.

Cet exemple montre un élément typique.

{ "Type":"VoiceEnhancementSink", "VoiceEnhancementSinkConfiguration": { "Disabled": Boolean (string) // FALSE ==> Voice Enhancement will be performed }

Pour mettre à jour une configuration, ajoutez l'VoiceEnhancementSinkConfigurationélément à un appel d'UpdateMediaInsightsPipelineConfigurationAPI. Lorsque vous le faites, l'GetMediaInsightsPipelineConfigurationAPI inclut l'VoiceEnhancementSinkConfigurationélément dans les résultats.

Cet exemple de demande montre comment activer l'amélioration vocale et l'enregistrement Amazon S3.

POST /media-insights-pipeline-configurations HTTP/1.1 Content-type: application/json { "MediaInsightsPipelineConfigurationName":"media_insights_configuration_name", "ResourceAccessRoleArn":"arn:aws:iam::account_id:role/resource_access_role", "Elements":[ { "Type":"S3RecordingSink", "S3RecordingSinkConfiguration":{ "Destination":"arn:aws:s3:::input_bucket_path", "RecordingFileFormat":"Wav" } }, { "Type":"VoiceEnhancementSink", "VoiceEnhancementSinkConfiguration": { "disabled":"false" } } ], "ClientRequestToken":"client_request_token" }
Note

L'VoiceEnhancementSinkélément nécessite toujours un S3RecordingSink élément dans une configuration d'analyse des appels.