Issue: Your middle tier UCMA application uses trusted application endpoint to schedule conferences on demand. When a conference is not needed anymore, your application invokes ApplicationEndpoint.ConferenceSession.BeginTerminateConference() to terminate the conference. Your application works fine for a while. Then it suddenly starts getting ConferenceFailureException with reason code maxConferencesExceeded each time a new conference is tried to be scheduled.
Assumption: Your Lync Server infrastructure is virtualized and you have 2 network interface cards both in the Front-End Server(s) and Mediation Server(s). One network adapter belongs to the production (voice) network and the other one belongs to the virtual machine management network.
You have a middle-tier UCMA application in this environment which schedules an audio/video conference and dials out a PSTN number from the conference using AudioVideoMcuSession.BeginDialOut(telUri, callbackFunction, …).
Symptom: Your UCMA application faces 5 seconds delay
Lync Server 2013 supports paired Front End Server Pool environment for disaster recovery purposes. Such environment includes 2 Lync Front End pools and a pairing relationship between them. The pools are generally Lync Server Enterprise Edition pools and they are generally installed in different geographic locations. If one of the Front-End pools goes down or becomes unavailable then Lync Server administrators can turn to the Lync Server Management Shell and manually initiate a failover procedure (Invoke-CsManagementServerFailover, Invoke-CsPoolFailover). After this is done, all user services are available for Lync users again but now the services are provided by the other Front End pool.
That is great. But what about UCMA applications? In short: when performing the above described disaster recovery procedure application endpoints are left on their original Front End pool. They are not moved to the other one. You need to perform further manual configuration in order to recover the services provided by your UCMA application. This blog post talks about the manual configuration required and describes what can be done on the application side to minimize the downtime.
This blog post describes what happens in the background when a middle-tier UCMA application schedules audio conferences in a Lync Server 2013 Enterprise Edition Pool environment. It also describes what the Lync Server Pool does in the background in order to provide a highly available solution for conferencing and what UCMA application needs to do when a specific symptom (“SIP/2.0 504 Server time-out”) occurs.
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.
This blog post describes 4 high availability scenarios for middle tier UCMA application developers in a Microsoft Lync Server environment. Description starts from the most basic scenario which actually does not guarantee any high availability to the most advanced one which supports multiple datacenters. Each scenario is built upon the previous one.
The average conferencing delay and the maximum conference request rate are the 2 most important measures you need to know in order to make an informed decision about whether audio conferencing is a suitable building block for your application or not. The first measure is quite important because it represents the delay each caller typically experiences. The latter one is also important because it determines whether you can satisfy your application level quality/performance requirements. This blog post analyzes these 2 measures in Lync Server 2013 Standard Edition environment.
Lync Server 2013 does not have call recording functionality. Although, users having Lync 2013 client can record calls but it is a purely client side functionality and because of this it has very limited relevance in business environment. Lync users can record their own calls but there is no centrally manageable, rule based, built-in server side call recording functionality which can be used for quality assurance or legal purposes.
This post describes how Lync 2013 qualified solutions record calls in Lync Server 2013 environment and investigates the resource requirement of the UCMA based call recording.
As the first step of Lync - Skype integration Microsoft released presence, IM and audio interoperability both for Lync Server 2013 and Office 365 users in May 2013. Other modalities such as video, desktop sharing and functionality like conferencing are not supported but I suppose we might see them in the near future.
Let us see what this means from UCMA perspective ...
Symptom: a Lync user who is registered in a Lync Survivable Branch Appliance (SBA) or Survivable Branch Server (SBS) dials an UCMA application endpoint which is behind a standalone Lync Front-End Server or a Front-End Server pool. The call is established successfully but subsequent transfer request initiated by the UCMA application fails with error code “403 Forbidden”.
This blog post describes what happens if transport level connectivity issues occur between a UCMA application which hosts at least one application endpoint and the associated Lync Front-End (FE) Server. It also describes know how to gracefully recover from such network outages.
UCMA application endpoints can publish presence information and can be notified when new subscribers are interested in their presence. They can add subscribers to their presence container(s) as members and allow them to receive subsequent presence information published to those containers.
Developers need to decide which containers application endpoints can publish presence data to. There are several options available
- use only the default container
- use all of the predefined ones
- create custom container(s)
Besides installing and provisioning UCMA application, Lync Server administrator needs to assign appropriate policies and dial plan to UCMA application endpoints in order to let the application work as expected. Depending on the functionality, application endpoints might need permissions to use basic telephone functionalities (e.g. call forward, call transfer), dial out PSTN numbers and organize conferences. If an application endpoint is created without specifying associated dial plan and policies then Lync Server assigns the default dial plan and default policies to the endpoints. If these are too restrictive then CE might not work as expected.
If Microsoft.Speech.Synthesis.SpeechSynthesizer.SelectVoice(String name) raises ArgumentException with Message property “Cannot set voice. No matching voice is installed or the voice was disabled.” then make sure that the version number of Microsoft.Speech.dll matches the version of language packs you have installed.
This post is about the firewall rules required on a Windows application server to host a UCMA based middle-tier application. The post describes how incoming media packets cross the firewall running on the UCMA application server.
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.
Microsoft UCMA Core API and Microsoft Speech API provide easy to use programming interfaces to play audio messages to callers. Associated development kits are widely used to implement Microsoft Lync tied or standalone ACD and IVR applications where playing prerecorded audio and dynamically constructed TTS messages are basic functionality.
These programming interfaces are well documented; a lot of technical articles and examples are on the Web. However, you can hardly find materials talking about scalability e.g. listing memory and CPU requirements to provide voice services for a given number of callers at the same time while using these programming interfaces. There are no documents stating how such applications can scale by adding more memory and CPU resources to the computers applications are running on. Providing answers to such questions is essential in current virtualized application world and hosted environments.
Answering machine detection (AMD) is a mechanism used by dialers to guess whether an outbound call is human answered or connected to voicemail. Having an effective AMD mechanism is really important for outbound dialers since a significant portion of the calls might be connected to voicemail. Disconnecting these calls instead of routing them to agents can save a lot of time.
If your UCMA application tries to transfer an already established PSTN call to conference by invoking AudioVideoMcuSession.EndTransfer() and it receives FailureResponseException with the magical Message property set to “A 400 (Bad request) response was received from the network and the operation failed …” then most probably you are facing the same issue I have spent weeks before.
Probably the 2 most useful
features UCMA offers are conferencing and back-to-back (B2B) call. Their
popularity mainly comes from the wide range of services which can be
developed using them.