B2B Call and Lync Response Group

B2B call is one of the most useful UCMA features. B2B allows a middle tier application to remain in the signaling path while allowing media streams to be traversed directly between the peers.

However, B2B call might cause some headache for developers when it is in Established state and consultative/supervised transfer appears on the scene. When this happens, UCMA application receives a SIP INVITE request with Replaces header. The Replaces header refers to the B2B call leg being transferred.

general_consultative_transfer.png

If UCMA application rejects this INVITE request then it actually rejects the transfer request and causes headache for the one who initiated the consultative transfer. If it accepts the INVITE request then UCMA stack immediately tears down the B2B call leg (thus the entire B2B call).

Outcome:

  • UCMA application loses the B2B call
  • Peer A and Transfree are not connected
  • UCMA application has a “dangling” call to the Transferee
general_consultative_transfer_outcome.png

Lync Response Groups

The same happens if Lync Response Group is involved. The following description assumes that “Enable agent anonymity” option is disabled on the Response Group. Please also note that the term “Response Group agent”  refers to the Lync client or the IP phone the agent uses.

consultative_transfer_rg.png

So the following happens if Lync Response Group is involved:

  1. Caller dials the UCMA application which sets up a B2B call to a Lync Response Group
  2. Audio between Caller and Response Group is established when Response Group picks up the C2 B2B call leg. Caller can listen to TTS/wma messages played by the Response Group. Meanwhile Response Group tries to look up a Response Group agent which is in Available status. If no one is available then Response Group plays music on hold to Caller.
  3. Response Group launches a call to a Response Group agent as soon as one is available
  4. When the call between the agent and the Response Group is established, Response Group initiates a consultative transfer by sending a REFER request to the agent. This REFER request includes a Refer-To header with the endpoint URI of the UCMA application and SIP dialog reference (call id, from tag, to tag) to the call between the UCMA application and the Response Group (C2 call leg of the B2B call).
  5. Response Group agent extracts these information from the REFER message and sends an INVITE request to the UCMA application with Replaces header. This Replaces header also includes dialog reference (call id, from tag, to tag) to the C2 B2B call leg.

The following happens as soon as the UCMA application accepts the INVITE request:

  • the C2 call leg of the B2B call terminates (since the call is replaced) -> the entire B2B call terminates (one of its call legs is terminated)
  • the call between the UCMA application and the agent establishes
  • the call between the Response Group and the agent terminates (Response Group terminates that call when agent reports that call between the agent and the UCMA application is established)
consultative_transfer_rg_outcome.png

Outcome:

  • UCMA application loses the B2B call
  • Caller and Response Group agent are not connected
  • UCMA application has a “dangling” call to the Response Group agent

The question: what UCMA application should/can do to guarantee that caller and Response Group agent is connected to each other as the outcome of the consultative transfer and no "dangling" call remains.

Solution

This solution is for environments where Caller initiates calls from Lync client and uses some desktop application which can use Lync client SDK.

In this case, the UCMA application can use some out of band mechanism to instruct Caller’s desktop application to dial UCMA application from Lync client again. When the UCMA application receives the call, it sets up a B2B call between Caller and the Response Group agent. It does that in a tricky way: when it sets up the B2B call leg to the Response Group agent (C2) it sets the Replaces header to replace the already established call between the UCMA application and the Response Group agent.

BackToBackCallSettings b2bSettings1 = new
BackToBackCallSettings(callFromCaller2UCMAApp);

BackToBackCallSettings b2bSettings2 =
new BackToBackCallSettings(
new AudioVideoCall(new Conversation(ucmaAppEndPoint)),
callFromRGAgent2UCMAApp.RemoteEndpoint.Uri);

b2bSettings2.CallEstablishOptions = new CallEstablishOptions();
b2bSettings2.CallEstablishOptions.Headers.Add(
new SignalingHeader("Replaces",
callFromRGAgent2UCMAApp.CallId + ";to-tag=" +
callFromRGAgent2UCMAApp.RemoteTag + ";from-tag=" +
callFromRGAgent2UCMAApp.LocalTag));

BackToBackCall b2bFromCaller2RGAgent = new
BackToBackCall(b2bSettings1, b2bSettings2);

b2bFromCaller2RGAgent.BeginEstablish(OnB2BEndEstablish, null);

It can also impersonate Caller. By using the Replaces header and impersonating Caller, the same Lync conversation window will remain opened on the Response Group agent's desktop and the agent will see Caller as the peer the call is coming from. So the entire consultative transfer is quite seamless from the Response Group agent’s perspective.

solution.png

After Response Group agent accepts the INVITE request belonging to the C2 call leg, Caller and Response Group agent becomes connected and C3 terminates.

solution_outcome.png

That is the desired outcome of the consultative transfer ...