Watson API gibt 408 Statuscode zurück

Question

Wir haben ein seltsames Watson-API-Verhalten festgestellt.

Wir verwenden Watsons Sprache-zu-Text, um Audiodateien zu transkribieren und haben kürzlich auf eine neuere Version von Python SDK aktualisiert. Für eine bestimmte Datei (49 min, 45 MB wave file) reagiert die Watson-API nun weiterhin mit status code 408 und der Nachricht Session timed out.

Es passiert meistens auf unserem Staging-Server und funktioniert meistens in unserer lokalen Umgebung (wir konnten es nur einmal für mehrere Versuche reproduzieren). Unsere Logik geht davon aus, dass eine neue Sitzung vor jeder Anfrage erstellt wird.

Wir haben die API-Dokumentation überprüft, konnten jedoch keine Lösung finden. Wir verwenden python 3.5 zusammen mit watson-developer-cloud==0.26.0.

Haben Sie eine Idee, wie Sie dieses Problem lösen können?

Edit: Code, der für die Anfrage

speech_to_text = SpeechToTextV1(
     username=WATSON_USER, 
     password=WATSON_PASSWORD 
) 

with open(path, 'rb') as audio_file: 
    return speech_to_text.recognize(
     audio_file, 
     content_type=kwargs.get('content_type'), 
     timestamps=kwargs.get('timestamps'), 
     inactivity_timeout=kwargs.get('inactivity_timeout'), 
     word_alternatives_threshold=kwargs.get('word_alternatives_threshold'), 
     word_confidence=kwargs.get('word_confidence'), 
     model=kwargs.get('model'), 
     profanity_filter=kwargs.get('profanity_filter'), 
     smart_formatting=kwargs.get('smart_formatting'), 
     speaker_labels=kwargs.get('speaker_labels'), 
    ) 

Parameter verantwortlich ist, die wir zu senden

content_type = "wav" 
timestamps = True 
inactivity_timeout = -1 
word_alternatives = 0.99 
word_confidence = True 
profanity_filter = False 
smart_formatting = True 
speaker_labels = True 
model = en-US_NarrowbandModel 

Answer 1

ich das gleiche Problem vor ein paar Tagen haben, und was für mich gelöst zu pflegen Sitzung aktiv, indem Audiodaten mit Stille gesendet werden, bevor das 30-Sekunden-Sitzungs-Timeout auftritt.

Ein Sitzungs-Timeout (HTTP-Statuscode 408) tritt auf, wenn ein Client eine Sitzung startet, aber der Dienst kein Audio für 30 seconds empfängt. Es tritt auch auf, wenn eine Sitzung aktiv ist, aber für 30 Sekunden keine Anforderung vom Client empfangen wird. Die letztere Bedingung tritt nur auf, wenn der Dienst 30 Sekunden lang keine Daten vom Client empfängt und der letzte Datenblock noch nicht empfangen wurde. Wenn der Client alle Daten gesendet hat, kann der Dienst mehr als 30 Sekunden benötigen, um eine Antwort zu generieren. In diesem Fall wird die Anforderung nicht überschritten.

Sowohl für WebSocket-Verbindungen als auch für HTTP-Sitzungen können Sie eine Sitzung aktiv halten, indem Sie Audiodaten senden, einschließlich nur Stille, bevor das 30-Sekunden-Sitzungszeitlimit auftritt. (Sie müssen auch den inactivity_timeout-Parameter wie im nächsten Abschnitt beschrieben auf -1 einstellen.) Für die Dauer aller Daten, die Sie an den Dienst senden, wird eine Gebühr erhoben, einschließlich der Stille, die Sie zum Verlängern einer Sitzung senden.

Im Idealfall würden Sie eine Sitzung einrichten, kurz bevor Sie Audio für die Transkription erhalten und es erhalten, indem Sie Audio mit einer Rate senden, die nahezu in Echtzeit ist. Ihre Anwendung sollte auch ordnungsgemäß von geschlossenen Verbindungen wiederherstellen.

Sie können innerhalb official Documentation über diesen Fehler sehen.

Answer 2

Hallo @mateuszb von Ihrer Beschreibung Ich verstehe, dass Sie dieses Problem mit Unterbrechungen haben. Vor ein paar Wochen wurde der Watson STT-Dienst aktualisiert und jetzt, um eine Verbindung nicht zu Timeout (und ich spreche über die session timeout) müssen Sie Audio "in etwa Echtzeit" Rate Feed. In 30 Sekunden müssen Sie also mindestens 15 Sekunden Audio senden. Können Sie Ihre Protokolle und Ihren Code überprüfen, um sicherzustellen, dass Sie diese Anforderung erfüllen? Es ist möglich, dass diese fehlgeschlagenen Sitzungen sind, weil der STT-Dienst hungert.