Swallowing meaningful errors from rest API

[synthmusic]

... else {
	callback(new errors.RequestError('Unexpected response from OpenTok'));
}

is used many times in archiving.js, which will obfuscate what may be an actual usable error message from the openTok rest api. I'm thinking to submit an update, but of course checking first if this goes against some strategy in place on purpose. Perhaps a new error type in errors.js? Problem being the objects only take messages and not the error code, so might need to "stringify" the code in the message

[CatGuardian]

I was just having a similar thought.

If you are going to to do this then please add a 'statusCode' parameter to the error objects. And then assign the HTTP status response code to all of the errors in this system.

https://tokbox.com/developer/rest/#stop_archive

The problem I'm running into is that I want to know that a 409 is thrown during stopArchiving instead of having to rely on a string from the opentok API.