Вы правы, говоря, что Lync разветвляет вызовы. Если у пользователя несколько конечных точек, Lync разветвит вызов каждой конечной точке, а в ответ каждая конечная точка вернет ответ на звонок.
Вы можете создать скрипт MSPL для получения 180 ответов. Поскольку MSPL не имеет состояния, для него потребуется вспомогательное приложение (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 или нет.
Обратите внимание, что я не проверял это, это просто схема того, как я попытаюсь справиться с ситуацией.
person
Willem
schedule
02.12.2014
