|
|
Здравствуйте,
On 21.05.2017 13:33, Miloserdov Dmitry wrote:
On Sun, 21 May 2017 11:48:03 +0300
"Dmitry Akindinov" <CGatePro@ru.stalker.com> wrote:
Здравствуйте.
On 2017-05-21 10:53, Miloserdov Dmitry wrote:
On Sat, 20 May 2017 07:58:33 +0300
"Dmitry Akindinov" <CGatePro@ru.stalker.com> 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
|
|