GSR Plugin expected or configurable behavior when receiving an error from Google.

[Sean DiSanti]

Today we are seeing an increase in error responses from Google, based on their API dashboards, so I am trying to measure the impact on our service but searching the logs for specific 5xx responses doesn't yield any results.

How does the plugin handle a 500 or 503 response from the speech to text API, and what options are there to configure that behavior, or the logging of those errors.

[Arsen Chaloyan]

Hi Sean,

If a gRPC request completes with an error, then the following statement will be logged

[WARN] gRPC Status: %s " , m_Status.error_message().c_str()

where the actual status string is returned by the gRPC library (in most of the cases, the remote service endpoint, unless the request fails in the client library itself).

The outstanding RECOGNIZE request would fail in this case, even though in some of the cases, it would make sense to reattempt the gRPC request to make the behavior redundant.

On Thu, Apr 7, 2022 at 10:38 AM Sean DiSanti <sdisanti...@gmail.com> wrote:

Today we are seeing an increase in error responses from Google, based on their API dashboards, so I am trying to measure the impact on our service but searching the logs for specific 5xx responses doesn't yield any results.

How does the plugin handle a 500 or 503 response from the speech to text API, and what options are there to configure that behavior, or the logging of those errors.

--
You received this message because you are subscribed to the Google Groups "UniMRCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unimrcp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/5a112a62-91f8-438f-90b5-0a817d2f294en%40googlegroups.com.

--

Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org

[Sean DiSanti]

Thank you, I haven't actually been seeing recognize errors from FreeSWITCH so I was hoping that there may be an auto retry. We have seen a huge uptick in 500's and 503's in the last week even though we're nowhere near our quotas.

To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/CAC5UscJPadajusdpDoQgU4ojOKQo2eakXQfD0VwU3MRxR%2B1FcQ%40mail.gmail.com.

[Sean DiSanti]

I was able to identify the specific logs related to the 5xx errors and it looks like our FreeSWITCH boxes are not terminating the gather or complaining about recognizer errors for those calls, they just wait until the timeouts expire resulting in 35 seconds of dead air. We are using mod_unimrcp to interact with unimrcpserver, and have definitely seen "ASR ERROR" and "RECOGNIZER ERROR" instances in the past. Are there configuration changes that need to be made so that we can make sure that our FS instances are told about the error so they can move on with the call?

[Arsen Chaloyan]

It is a bit hard to tell what the exact problem was without the UniMRCP server logs. Perhaps based on your description I'd guess that the gRPC endpoint became unavailable, and the requests eventually timed out. You may set the following configuration parameter in umsgsr.xml to limit the wait time for a response acknowledging the gRPC stream creation. This is not the gRPC deadline which applies to the entire gRPC method call.

   <streaming-recognition
      stream-creation-timeout="2000"

To view this discussion on the web visit https://groups.google.com/d/msgid/unimrcp/CAANGHxsfihRtWca-fVmrQzL9rr1C67KXC7-xk1agRsAeMCDrQA%40mail.gmail.com.