The BackToBackCall class is staple of more complex UCMA applications, especially those that perform some kind of third-party call control (brokering or providing services to calls between other users). In a nutshell, the BackToBackCall class allows a UCMA-controlled endpoint to keep a handle to a call that is going on between two other endpoints, rather than between a single remote endpoint and the UCMA application. But there are several features of the BackToBackCall class that you may not be aware of, that can be helpful in certain situations.
Figuring out when media has established on a back to back call
One of the tricky parts of using back to back calls is that the UCMA application isn’t a part of the media stream at all. Media is sent directly between the two other endpoints, even though the SIP messages are proxied through the UCMA application. So a back to back call doesn’t get an instance of AudioVideoFlow, and it can be difficult to tell when the media connection has been established.
Why does this matter? Well, one common use of the BackToBackCall class is to connect other Lync endpoints to an audio conference while retaining full control of the call. If you don’t know when the media connection has established, and you start playing messages, hold music, etc. too early, the first bit of the audio can get clipped off.
To help with this, the BackToBackCall class has an event called RemoteMediaFlowStateChanged, and a corresponding property called RemoteMediaFlowState. All you need to do is create an event handle for RemoteMediaFlowStateChanged, and hold off on playing any audio in your conference until the state has gone to Connected.
Customizing SIP headers
The BackToBackCallSettings class, which you use to set the incoming and outgoing calls for the back to back call, also has properties for an instance of CallEstablishOptions and an instance of CallAcceptOptions. You can use the Headers property on either of these to provide custom SIP headers for either the response to the incoming call leg or the SIP INVITE message for the outgoing call leg.
Setting pass-through headers
As an alternative to providing specific headers to be added to the outgoing INVITE, you can instead specify the names of headers that should be passed through from the incoming call to the outgoing call, using the SetPassThroughHeaderNames method.
When the back to back call creates the outgoing call leg, it creates a completely new SIP INVITE message, and plugs the media information from the incoming INVITE into it. By adding a SIP header name to this list of pass-through headers, you tell UCMA that the header should be copied over from the incoming INVITE to the outgoing INVITE. If there is custom context data of some kind in the incoming INVITE messages, perhaps from an MSPL script, and you need to preserve it in the outgoing leg of the back to back call, this can be invaluable.
If you want to find out which headers are specified as pass-through headers, you can call the GetPassThroughHeaderNames method.
