Scheduling Conference Fails with Reason maxConferencesExceeded

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.

Management Network Leads to 5 Seconds Delay in PSTN Dialout

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

Application Recovery in Paired Front End Pool Environment

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-CsManagementServerFailoverInvoke-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.

“504 Server time-out” While Creating Audio Conferences on a Lync Enterprise Edition Front End Pool

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.

Delivering PSTN Caller to Conference

Assume the following scenario:

  1. You have a trusted middle tier UCMA application
  2. The application hosts an application endpoint and the endpoint is registered to a Lync FE pool 
  3. There is an audio/video conference created by the application endpoint
  4. There is a PSTN call connected to the trusted application endpoint. The call is already in Established state
  5. 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.


High Availability Scenarios for UCMA Applications

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.

Poor Conferencing Performance Using Lync Server Standard Edition

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.

Resource Requirement for UCMA Based Call Recording

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.

Transferring SBA/SBS Registered Users Results in “403 Forbidden”

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”.

UCMA Application Endpoints: Choosing Containers to Publish Presence Data

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)

UCMA Application vs. Lync Policies and Dial Plan

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.

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.

On Voice Response Scalability

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

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.

AudioVideoMcuSession.EndTransfer() raises FailureResponseException “400 Bad request”

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 toA 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.

Conferencing Delay

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.

B2B is useful as it is. It allows applications to remain in the signalling path. Thus you can use B2B to monitor call progress, report different call stages or perform call control. But one might ask why should I use conferencing? Do I need it? What are the pros and cons of using that? Obviously, pros mean the additional opportunities conferencing adds to B2B and cons primarily mean the delay required by conferencing.