Вы правы, говоря, что звонки Lync forks. Если у пользователя несколько конечных точек, Lync разветвит вызов на каждую конечную точку и в свою очередь, каждая конечная точка вернет ответ.
Вы можете создать скрипт MSPL, чтобы уловить 180 ответов. Поскольку MSPL не имеет статуса, для него потребуется приложение поддержки (a ServerApplication), которое проверяет, отправлен ли ответ 180 на текущий вызов и блокирует последующие ответы о звонках. Исходя из предположения, что для всех запросов заголовок CallID будет идентичным, вы можете затем решить, какие ответы отправить, а какие нет.
Простой MSPL будет что-то вроде:
<lc:applicationManifest
lc:appUri="http://www.contoso.com/DefaultRoutingScript"
xmlns:lc="http://schemas.microsoft.com/lcs/2006/05">
<lc:responseFilter reasonCodes="1XX" />
<lc:proxyByDefault action="true" />
<lc:splScript><![CDATA[
if (sipResponse && sipResponse.StatusCode == 180)
{
Dispatch("OnResponse");
}
]]></lc:splScript>
</lc:applicationManifest>
Затем в серверном приложении вы справляетесь OnResponse событие, я думаю, что-то вроде этого:
public void OnResponse(object sender, ResponseReceivedEventArgs e)
{
if (e.Response.StatusCode == 180)
{
var callIdHeader = e.Response.AllHeaders.FindFirst(Header.StandardHeaderType.CallID);
if (callIdHeader != null)
{
var callId = callIdHeader.Value;
if (ShouldSendRingingResponse(callId))
{
e.ClientTransaction.ServerTransaction.SendResponse(e.Response);
}
}
}
}
public bool ShouldSendRingingResponse(string callId) { .... }
Затем вы можете создать некоторую логику функцию ShouldSendRingingResponse, чтобы увидеть, отправлять ли ответ 180 или нет.
Обратите внимание, что я не тестировал это, это всего лишь базовый план того, как я попытаюсь справиться с ситуацией.