2
votes

we've encountered a strange watson API behaviour.

We're using Watson's speech-to-text to transcribe audio files and recently have upgraded to newer version of python sdk. Now, for one particular file (49 min, 45 MB wave file), Watson API keeps responding with status code 408 and message Session timed out.

It happens mostly on our staging server and works fine most of the times in our local environment (we were able to reproduce it only once for multiple attempts). Our logic assumes that new session is created before each request.

We've checked API documentation, but couldn't find any solution. We're using python 3.5 along with watson-developer-cloud==0.26.0.

Do you have any idea how to solve that problem?

Edit: Code that's responsible for the request

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'),
    )

Parameters that we're sending

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
2
@TheDarkKnight thanks for that remark, I've updated the post with the code that we're using - mateuszb

2 Answers

3
votes

I have the same problem a few days ago, and what solved for me is to maintain session active by sending any audio data, with silence, before the 30s session timeout occurs.

A session timeout (HTTP status code 408) occurs when a client starts a session but the service receives no audio for 30 seconds. It also occurs when a session is active but no request is received from the client for 30 seconds. The latter condition occurs only if the service receives no data from the client for 30 seconds and it has not yet received the last chunk of data. If the client has sent all data, the service can take more than 30 seconds to generate a response; in this case, the request does not time out.

For both WebSocket connections and HTTP sessions, you can keep a session active by sending any audio data, including just silence, before the 30-second session timeout occurs. (You must also set the inactivity_timeout parameter to -1, as described in the next bullet.) You are charged for the duration of any data that you send to the service, including the silence that you send to extend a session.

Ideally, you would establish a session just before you obtain audio for transcription and maintain it by sending audio at a rate that is close to real time. Your application should also recover gracefully from closed connections.

You can see within official Documentation about this error.

2
votes

Hi @mateuszb from your description I understand that you are having this issue intermittently. Few weeks ago the Watson STT service was updated and now in order for a connection not to timeout (and I'm talking about the session timeout) you need to feed audio "at approximately real time" rate. So in 30 seconds, you need to send at least 15 seconds of audio. Can you please check your logs and your code to make sure you are meeting this requirement? It is possible that those failed sessions are because the STT service is starving.