Call transfer from responsegroup fails in Lync 2013.
Had a recent issue with responsegroups in Lync2013,
What I tried to do was basically a "next next" operation.
I was going to set up an overflow to an external phonenumber for a queue in Lync.
This is "next next" right?
But it was not.
I set the queue and group up like this:
I also added the neccecary policies and dialplan with powershell.
I then had a cup of coffe and waited for Lync to replicate.
But when i called the responsegroup there was the standard waiting music before the call terminated.
When calling the responsegroup internally i could see in my Lync client that the call was being forwarded to the overflow number but then the message "cannot locate user" was displayed.
This was rather odd becuase a had another responsegroup set up the excact same way with the same policies and this worked.
After tracing a bit i tried changing the workflow of my working responsegroup so that it pointed to the queue that was failing.
Another wait for the Lync to replicate and the tried calling the responsegroup number again.
And magically this worked.
Conclusion:
The queue and group configuration is OK but the workflow does not work.
I then checked the failing endpoint/workflow with get-csapplicationendpoint.... | select object *.
It showed that the dialplan and voicepolicy was exactly the same as the working workflow endpoint.
Everything looks to be in order but its still not working.
Setting my common sense aside I then deleted the failing workflow.
I kept the queue and group as it was.
I created the excact same workflow again and pointed it to the queue I used before.
Assigned the same voice policy and dialplan as before with the same powershell commands.
Waited for replication and the when calling again the overflow works as intended.
I have no good explanation for this.
To me it appears like the voice policy is displayed correct but is in fact not applied to the endpoint.
If you don't assign a voice policy to the enpoint it will produce the same error.
Cure: Delete the failing endpoint/workflow and create it again.
What I tried to do was basically a "next next" operation.
I was going to set up an overflow to an external phonenumber for a queue in Lync.
This is "next next" right?
But it was not.
I set the queue and group up like this:
I also added the neccecary policies and dialplan with powershell.
I then had a cup of coffe and waited for Lync to replicate.
But when i called the responsegroup there was the standard waiting music before the call terminated.
When calling the responsegroup internally i could see in my Lync client that the call was being forwarded to the overflow number but then the message "cannot locate user" was displayed.
This was rather odd becuase a had another responsegroup set up the excact same way with the same policies and this worked.
After tracing a bit i tried changing the workflow of my working responsegroup so that it pointed to the queue that was failing.
Another wait for the Lync to replicate and the tried calling the responsegroup number again.
And magically this worked.
Conclusion:
The queue and group configuration is OK but the workflow does not work.
I then checked the failing endpoint/workflow with get-csapplicationendpoint.... | select object *.
It showed that the dialplan and voicepolicy was exactly the same as the working workflow endpoint.
Everything looks to be in order but its still not working.
Setting my common sense aside I then deleted the failing workflow.
I kept the queue and group as it was.
I created the excact same workflow again and pointed it to the queue I used before.
Assigned the same voice policy and dialplan as before with the same powershell commands.
Waited for replication and the when calling again the overflow works as intended.
I have no good explanation for this.
To me it appears like the voice policy is displayed correct but is in fact not applied to the endpoint.
If you don't assign a voice policy to the enpoint it will produce the same error.
Cure: Delete the failing endpoint/workflow and create it again.
Comments
Post a Comment