Assume the following scenario:
You have a trusted middle tier UCMA application
The application hosts an application endpoint and the endpoint is registered to a Lync FE pool
There is an audio/video conference created by the application endpoint
There is a PSTN call connected to the trusted application endpoint. The call is already in Established state
You want the UCMA application to deliver the remote PSTN party to the conference
There are 2 scenarios to do that. This blog post describes both of them and lists the pros and cons.
The following figure shows the initial state emphasizing the signaling path, the associated SIP dialogs and the media path. Although it is not correct, please note that I might use the terms “SIP dialog” and “call” interchangeably in the discussion below.
Scenario A: using C3P dial-in
The first scenario uses Conference Control Channel Protocol (C3P) dial-in strategy and back-to-back (B2B) call. The steps are the followings:
1) The UCMA application initiates a so called “self-transfer”. The main purpose of this self-transfer is to have call in Establishing state instead of the current call which is already Established. When the application initiates the self-transfer, the UCMA layer sends a SIP REFER request to the Mediation Server in the background. The Refer-To header plays a very important role. Among others, it indicates which SIP dialogs will be replaced.
2) Assuming that the “Refer support” property of the Lync Server trunk is set to “Enable sending refer to the gateway”, this REFER request is propagated to the IP gateway. Upon receiving the REFER request, the IP gateway initiates a new SIP dialog and sends a SIP INVITE to the Mediation Server. The Replaces header in the INVITE is derived from the Refer-To header received in REFER request previously.
When the Mediation Server receives the SIP INVITE from the IP gateway, it sends a SIP INVITE to the UCMA application through the Front-End (see the difference in the Replaces header).
3) When the UCMA application receives the SIP INVITE then it has a new call in Establishing state and it can now setup a B2B call to the conference. First it joins the remote party to the conference then dials into the conference. Joining to the conference means sending a SIP INFO to the focus. This SIP INFO message conveys a C3P request (request: addUser; type: dial-in) in the message body. Dialing to the conference means a SIP INVITE sent in the background in order to establish the B2B audio call to the MCU.
4) When the B2B call changes to Established state then the original SIP dialogs
- between the IP gateway and the Mediation Server (dialog A) and
- between the Mediation Server and the UCMA application (dialog B)
are terminated automatically since they are replaced.
5) What's left is a B2B call to the conference and the media stream between the IP gateway and the MCU through the Mediation Server.
So PSTN caller is delivered to the conference successfully while the call control is retained by the UCMA application via B2B.
Scenario B: using C3P dial-out
The initial state is the same as before.
But the subsequent steps are quite different:
1) The UCMA application transfers the original call (dialog B) to the conference. This results in sending a SIP INFO to the Front-End in the background. The INFO message conveys a C3P request as before but in this case it is a dial-out request instead of a dial-in request. Upon receiving this C3P request, the Front-End automatically adds the remote party to the focus and the MCU automatically dials out the remote party. As before, the Replaces header in the SIP INVITE indicates which dialog to replace.
When the Mediation Server receives the SIP INVITE, it sends a SIP INVITE to the IP gateway. This INVITE does not contains Replaces header.
2) When the new call between the Mediation Server and the IP gateway changes to Established state then the call between the MCU and the Mediation Server also changes to Established state. When latter happens then the original call between UCMA application and the Mediation Server (dialog B) terminates since it is replaced. This has the consequence that the associated call between the Mediation Server and the IP gateway (dialog A) also terminates.
3) What's left is a call between the IP gateway and the MCU through the Mediation Server.
So PSTN caller is delivered to the conference successfully while the call control is lost by the UCMA application.
Pros and cons
Before looking at the pros and cons, let us stop for a moment and see the 2 scenarios from the IP gateway perspective: in the 1st scenario (dial-in) the gateway received a SIP REFER request while it received a SIP INVITE in the 2nd scenario (dial-out). This is one of the key differences between the 2 scenarios. The 1st scenario involves a transfer request (REFER) from the gateway perspective while the 2nd scenario does not. It just requires setting up a simple call instead (INVITE). So 2nd scenario will work even if the gateway has any problems with performing transfer requests. The unlucky ones who has already worked with buggy firmware on different Lync qualified gateways and pulled out all of their hairs when gateways do not perform simple transfer requests (e.g. AudioCodes Mediant 1000, “SIP/2.0 500 Server Internal Error”) know what I am talking about … Anyway, the 2nd scenario is a good fallback scenario for anyone who develops UCMA applications, want to deliver PSTN callers to conference and do not want to completely rely on gateway’s REFER support.
So let us see the pros and cons:
- Scenario A: using C3P dial-in
- Call control is retained by the UCMA application
- It involves a call transfer from the PSTN caller’s perspective
- PSTN caller might hear ringback tone to for a short period of time
- It takes longer than the other scenario
- You rely on the gateway’s REFER support
- Scenario B: using C3P dial-out
- It is much faster than the other scenario
- No call transfer is involved
- PSTN caller never hears ringback tone
- Good fallback strategy if you face buggy gateways and REFER does not work
- UCMA application loses call control