I have a Back-to-Back call from caller to our ucma server to client/operator. When doing a transfer on the leg from caller to ucma, there are a few different results which can happen; the transfer target answers, doesn't answer or ignores the call (ignore/busy button).
I want to differentiate between the later two; busy and no answer. In the ucma application I only get a FailureRequestException with text "The transfer operation failed. For more information, refer to the message data in the exception." I cannot figure out anywhere in the exception or otherwise how to know the difference between busy and no answer. Both generates the same exception with no obvious parameter saying whichever it is.
Is there any way I can know the reason the transfer failed in this scenario?
I'm not sure if this will help, but if you can get the final non-provisional status code for the invite, a "ignore" end will be a 603. A no answer will be a "480" - altho a 480 (Temporarily Unavailable) can be returned for lots of other reasons.
Also the situation can be confused if the user has more than one endpoint (e.g. Desktop Lync Client and Mobile Lync Client). So you end up with forked requests / responses with only one overall response back to you. Then you may not always be able to tell exactly why the call was terminated.
I actually find it funny you are saying you get a FailureRequestException. I would be expecting a FailureResponseException. With a FailureResponseException exception you can pull out the status code.
From the UCMA 4.0 exception model msdn page:
FailureResponseException
Thrown when a 4xx, 5xx, or 6xx response was received for a request. This exception contains the ResponseData property, which contains the complete response including response code, reason text, headers, and message body. In some rare cases, this may also be thrown when an error other than a 4xx, 5xx, or 6xx response occurred. In such cases the ResponseData property is null.