From: "Sergey Muravyev" Received: from mail.moscow.stalker.com ([89.175.185.228] verified) by mail.bestvoip.ru (CommuniGate Pro SMTP 6.2c3) with ESMTPS id 2870333 for CGatePro@ru.stalker.com; Mon, 22 May 2017 12:10:54 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=stalker.com; s=test1; bh=Kj7hdqb6rlt30DNtRTCM9CxFBtN6mIQWjltqN6JlpcQ=; h=Content-Transfer-Encoding:Content-Language:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:To:Subject:From; b=js3GREIU8ODZEtxeRG u3E07js0wdZsSbFoMWbimpfNRBnl7hkDjMGTQe/Fpq1RQNukNmmu9eOCYHPUXKfNACWSQllFzfc9U m7dYfuB50FrE5J+evQVExVIKt2VwiFe1ALdzwsyHoKlvloQPW/yLTvqtbK7HNBLiFfI3xH27E4Yk= Received: from [10.1.1.180] (account sergeym@mail.moscow.stalker.com [10.1.1.180] verified) by mail.moscow.stalker.com (CommuniGate Pro SMTP 6.2c4d) with ESMTPSA id 52134261 for CGatePro@ru.stalker.com; Mon, 22 May 2017 12:10:54 +0300 Subject: =?UTF-8?B?UmU6IFtDR1BdIGF1dG8tYXR0ZW5kYW50INC00LvRjyDQvdC10YHQvtCy?= =?UTF-8?B?0YHQtdC8INC70L7QutCw0LvRjNC90YvRhSDQvdC+0LzQtdGA0L7Qsg==?= To: CommuniGate Pro Russian Discussions References: Message-ID: <1a28253e-ea0e-2187-6039-d82e5d22ba11@communigate.com> Date: Mon, 22 May 2017 12:10:53 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Здравствуйте, On 21.05.2017 13:33, Miloserdov Dmitry wrote: > On Sun, 21 May 2017 11:48:03 +0300 > "Dmitry Akindinov" wrote: >> Здравствуйте. >> >> On 2017-05-21 10:53, Miloserdov Dmitry wrote: >>> On Sat, 20 May 2017 07:58:33 +0300 >>> "Dmitry Akindinov" wrote: >>>>>> Какая-то из сторон не поддерживает session timers и не хочет >>>>>> отвечать на OPTIONS в диалоге. Попробуйте в WebAdmin -> Settings >>>>>> -> Real-Time -> Nodes изменить таймер сессий по умолчанию на >>>>>> радикально большое значение (скажем, два часа.) Если поможет, то >>>>>> это оно. >>>>> >>>>> Попробую. >>>>> Но дело в том что перед разрывом соединения нет вообще никаких sip >>>>> запросов ни в какую сторону. >>>> >>>> В логе, кусочек которого вы показали, речь шла именно о неудаче >>>> обновить таймер сессии с помощью OPTIONS. Стоит поднять уровень лога >>>> SIP Transport - будет хорошо видно запросы и ответы. >>>> >>>>> По сети перед разрывом ходят обычные RTP пакеты и CGP просто >>>>> перестает их принимать и отвечает icmp-port-unreachable. >>>>> Ниже запись sip трафика для проблемного звонка. Разрыв произошел >>>>> между 14 и 15 пакетами на 151 секунде >>>> >>>> А зачем и кому там столько BYE? Уже с 7-го пакета. Это не похоже на >>>> нормальный диалог. А ACK (предположительно - начало диалога) был >>>> 6-м. То есть, CGPro практически сразу после установления диалога >>>> начал его разрывать, а шлюз не отвечал. 15-м пакетом был BYE уже от >>>> шлюза, на который CGPro ответил, что этого диалога нет давно. >>>> В логах CGPro можно увидеть гораздо больше, если сделать их чуть >>>> подробнее. >>> >>> Зачем не знаю. Первый не 7ой а третий, остальные точная копия. >>> То есть попытки разорвать соединения начались еще до того как >>> автосекретарь успел принять звонок. >>> Похоже это проблема из-за контакт центра. >> Надо бы подробные логи звонка. Стесняетесь сюда - тогда на >> support@communigate.com. Там отвечают. >> >>> Контакт центр настроен, а IVR в нем нет - хотелось обойтись стандартным. >> IVR в Контакт-центре есть, он там шораздо человечнее по интерфейсу, >> чем базовый. > Имел в виду "Контакт центр настроен, а IVR в нем не настроен" > В базовом задаются первые цифры и длина добавочного номера, а в CC > просто предлагают > просто "разрешить звонки на добавочные номера". Я сходу не нашел на > какие номера можно будет звонить, так как часть номеров у меня не > локальные для CGP В текущей версии Контакт-центра в наборе добавочного номера можно набрать любой номер от 3 до 5 цифр и на него будет сделан вызов. Планируется добавить настройки для задания первых цифр и длины добавочного номера в будущих версиях Контакт-центра. При настроенном контакт-центре в домене использовать стандартный IVR из приложения "Автосекретарь" возможно, но не рекомендуется, поскольку нецелесообразно усложняется сценарий звонка в этом случае. С контакт-центром рекомендуется использовать и IVR из контакт-центра (более гибкий, с бОльшим количеством настроек, чем стандартный IVR). В Вашем сценарии возник неправильный порядок применения сигнальных правил. Покажите, пожалуйста, какие условия, действия, а также Priority и Stage установлены для правил: "PBX Center starter" аккаунта pbx@my.domain и "ccIn_domain"? У Вас получается, что сначала применяется правило PBX Center starter, а потом сразу ccIn_domain с перенаправлением на #ccincoming. Попробуйте, пожалуйста, для правила ccIn_domain установить Stage - пустой (immediately), а приоритет - Highest, как описано в инструкции по установке Контакт-центра. Если после этого проблема останется, то пришлите, пожалуйста, новый лог неудачного звонка. > > >>> Или так делать нельзя, не поддерживаемая конфигурация? >>> Отключение правила переадресующего входящие на ccincoming#pbx убрало >>> все эти преждевременные BYE. Про проблемы с разрывом через 2 минуты >>> пока не знаю протестирую в понедельник. >> >> Вот всё-таки хорошо было бы увидеть подробные логи в оригинальной >> конфигурации. > > Ниже кусок лога в начале того звонка. От INVITE до OK между ними было > два BYE. > > [] > 19:01:12.741 4 DIALOG-001792 callee set: pbx@my.domain > 19:01:12.741 4 SIGNAL-126490 applying Account rules > 19:01:12.741 5 SIGNAL-126490 processing 2 rules. stage=-1 > 19:01:12.741 4 SIGNALRULE-126490 rule(PBX Center starter) conditions met > 19:01:12.741 4 SIGNALRULE-126490 rule(PBX Center starter): -> > sip:pbx#pbx@my.domain > 19:01:12.741 2 SIGNALRULE-126490 rule(PBX Center starter): redirected > 19:01:12.741 5 SIGNAL-126490 1 of 2 rules processed > 19:01:12.741 4 SIGNAL-126490 AOR added: sip:pbx#pbx@my.domain > 19:01:12.741 2 SIGNAL-126490 redirected by Rules > 19:01:12.741 5 SIGNAL-126490 timeout immediate set > 19:01:12.741 2 SIGNAL-126490 INVITE sip:pbx#pbx@my.domain > 19:01:12.741 2 PBXLEG-016008 'pbx' created for ACCOUNT(pbx@my.domain) > 19:01:12.741 2 SIGNAL-126490 SIPS-101880: {1/2} sent to NODE-016008: > INVITE sip:pbx#pbx@my.domain > 19:01:12.741 5 SIGNAL(1) 126490: enqueued (0 secs) > 19:01:12.741 5 SIGNAL(1) 126490: timeout > 19:01:12.741 4 SIGNAL-126490 stage timeout (0 sec) > 19:01:12.741 5 SIGNAL-126490 processing 1 rules. stage=0 > 19:01:12.741 4 SIGNALRULE-126490 rule(ccIn_domain) conditions met > 19:01:12.741 2 PBXLEG-016008 started <- DIALOG-001792: > 2043@GWhost(sip:2043@GWhost:5060;user=phone)(noUPDATE)(noREFER) > 19:01:12.741 2 PBXLEG-016008 session refresh=300(active) > 19:01:12.741 2 PBXLEG-016008 pbx.sppr(Main) started > 19:01:12.741 4 SIGNALRULE-126490 rule(ccIn_domain): -> > sip:ccincoming%23pbx@my.domain > 19:01:12.742 2 PBXLEG-016008 ProgramLog: "calledUser = 4444" > 19:01:12.742 2 SIGNALRULE-126490 rule(ccIn_domain): redirected > 19:01:12.742 5 SIGNAL-126490 1 of 1 rules processed > 19:01:12.742 4 SIGNAL-126490 cancelling all > 19:01:12.742 4 SIGNAL-126490 {1/2} NODE-016008 cancelled > 19:01:12.742 4 SIGNAL-126490 AOR added: sip:ccincoming%23pbx@my.domain > 19:01:12.742 5 SIGNAL-126490 timeout set for 900s > 19:01:12.742 2 SIGNAL-126490 INVITE sip:ccincoming%23pbx@my.domain > 19:01:12.742 2 PBXLEG-016010 'ccincoming' created for > ACCOUNT(pbx@my.domain) [] -- Best regards, Sergey Muravyev