> > One thing that I would like to see: more attributes on error responses, > mainly an error code that can be interpreted by the dialplan in order to > react differently, depending of the error type. >
Thanks for the feedback! My preference goes to the "error_details" as it is more flexible, but I > don't know how complex it is to implement. > This shouldn't be too difficult to do, we would just need a way to query the JSON via dialplan. Maybe something similar to channel variables. Definitely something to think about moving forward. On Mon, Mar 29, 2021 at 4:40 PM sdut...@wazo.io <sdut...@wazo.io> wrote: > On 3/22/21 3:14 PM, Ben Ford wrote: > > More information on the protocol used for this and the overall > > project can be found here: > > > > https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=45482453 > > > > After reading the wiki page, if there is anything you feel could be > > improved, we’d love to hear about it. > > Thank you Ben. > > One thing that I would like to see: more attributes on error responses, > mainly an error code that can be interpreted by the dialplan in order to > react differently, depending of the error type. For example, I want to > distinguish when the application received no sound (e.g. because of a > microphone issue) I want the user to know that and try again vs the > application is misconfigured and I just want to stop. > > Using only one "error_msg" attribute for that is not ideal, since the > calling dialplan has to parse the error_msg and react accordingly. > Having a separate error code allows the dialplan to choose the > appropriate behavior easily, while still having the error_msg for > logging/displaying/debugging purposes. > > I see two choices for this improvement: > > - add an "error_code" (or similar) in the error response > > Example: > { > "version": "1.0", > "response": "error", > "error_msg": "Could not connect to Google (server down).", > "error_code": "10001" // or any other string from the application > } > > > - allow external applications to add arbitrary attributes into a > "error_details" attribute > > Example: > { > "version": "1.0", > "response": "error", > "error_msg": "Could not connect to Google (server down).", > "error_details": { > "error_code": "10001", > "error_user_language": "fr_CA" > "error_user_display": "La connexion au serveur Google a échoué" > } > } > > My preference goes to the "error_details" as it is more flexible, but I > don't know how complex it is to implement. > > PS: I am not currently a user of TTS/STT, I don't have a real use-case > needing this. > > -- > Sébastien Duthil > Wazo developer > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev -- Benjamin Ford Software Engineer 256-428-6147 Check us out at www.sangoma.com and www.asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
