ACK is not received

[anonymous]

@SviatovN wrote:
555 Это программный телефон который установлен на сервер в качестве теста.


Убедитесь, что звонок с этого телефона на какой нибудь системный номер (например 999) не обрывается через 32 секунды.

@SviatovN wrote:Да Вы правы, моя вина я всё запутал, думал проблема легко решаема

Подозреваю, что она и решается просто. В логе приведённом выше, звонок инициализируется этим телефоном (555). И ACK не пришёл именно от него.
Если PBX и телефон находятся на одном и том же сервере, сервер работает под управлением 2003/XP, да ещё и с двумя сетевыми интерфейсами, то такая ситуация вполне возможна.
Попробуйте либо в конфигурации телефона указать, что сервер находится на 127.0.0.1, либо просто вынести телефон за пределы сервера (запустить на любом другом компютере). Второй вариант предпочтительнее, потому что соответствует реальным условиям эксплуатации PBX.

 

[anonymous]

В общем настроил Прокси через другой компьютер и всё заработало, спасибо за помощь!

 

[anonymous]

Добрый день.
У меня похожая проблема, но есть отличия.
Обрыв соединения у меня происходит только на входящих звонках через 20-30 сек и то не всегда ( на исходящих такого нет, VoIP провайдеры разные на входящие и исходящие звонки)
Схема у меня совсем простая:
сервер на нём 3CX
шлюз linksys (на нём весит аналоговая трубка) в той же сети смотрит на сервер ( все включенно в один коммутатор)
Параметр ALLOWSOURCEASOUTBOUND у меня изначально =1

вот лог при обрыве соединения

13:26:06.859 [CM503008]: Call(2): Call is terminated
13:26:06.843 [CM503021]: Call(2): ACK is not received
13:25:40.000 Currently active calls - 1: [2]
13:25:34.781 [CM503007]: Call(2): Device joined: sip:[email protected]:5063
13:25:34.781 [CM503007]: Call(2): Device joined: sip:[email protected]:5060
13:25:25.187 [CM505001]: Ext.10: Device info: Device Identified: [Man: Linksys;Mod: SPA Series;Rev: General] Capabilities:[reinvite, no-replaces, able-no-sdp, recvonly] UserAgent: [Linksys/SPA2102-5.2.12] PBX contact: [sip:[email protected]:5060]
13:25:25.187 [CM503002]: Call(2): Alerting sip:[email protected]:5063
13:25:25.078 [CM503025]: Call(2): Calling Ext:Ext.10@[Dev:sip:[email protected]:5063]
13:25:25.046 [CM503004]: Call(2): Route 1: Ext:Ext.10@[Dev:sip:[email protected]:5063]
13:25:25.046 [CM503010]: Making route(s) to
13:25:25.046 [CM505003]: Provider:[3tel.com] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [comfytel] PBX contact: [sip:XXXXXXXX@[email protected]:5060]
13:25:25.031 [CM503001]: Call(2): Incoming call from 7495775xxxx@([email protected]) to
13:25:24.875 [CM503012]: Inbound out-of-office hours rule (unnamed) for 10003 forwards to DN:10
13:22:03.328 [CM503008]: Call(1): Call is terminated
13:22:03.312 [CM503021]: Call(1): ACK is not received
13:21:56.000 Currently active calls - 1: [1]
13:21:31.234 [CM503007]: Call(1): Device joined: sip:[email protected]:5063
13:21:31.218 [CM503007]: Call(1): Device joined: sip:[email protected]:5060
13:21:25.812 Currently active calls - 1: [1]
13:21:21.640 [CM504001]: Ext.IVRForward: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=adf3496d5cde7221/IVRForward]
13:21:21.640 [CM504001]: Ext.EndCall: new contact is registered. Contact(s): [sip:[email protected]:40600;rinstance=27e771c40aa3d9a7/EndCall]
13:21:19.359 [CM505001]: Ext.10: Device info: Device Identified: [Man: Linksys;Mod: SPA Series;Rev: General] Capabilities:[reinvite, no-replaces, able-no-sdp, recvonly] UserAgent: [Linksys/SPA2102-5.2.12] PBX contact: [sip:[email protected]:5060]
13:21:19.359 [CM503002]: Call(1): Alerting sip:[email protected]:5063

соответсвенно внутренний номер 10 это и есть linksys
на сервере у меня 1 физический интерфейс, но есть еще один виртуальный (хамачи), соответсвенно шлюз и 3CX между собой работают по адресам локальной сети.

Да еще
сервер из инета не виден, белого IP у меня нет.

 

[anonymous]

ALLOWSOURCEASOUTBOUND параметр предназначен для решения проблем внешних клиентских подключений. Поэтому забудьте о нём. В Вашем случае он ни на что не влияет.
ACK может не приниматься только от инициатора звонка, так что не удивительно, что проблемы нет при исходящих звонках НА провайдера.

Вы по-моему, проблему ищете не там, где она возникает. Шлюз и локальная сеть тут ни при чём.

В логе, PBX не получает ACK при входящем звонке от провайдера(?) sip.web3tel.com.
Какую версию PBX используете?

А эта строчка вообще странная...
PBX contact: [sip:XXXXXXXX@[email protected]:5060]

Установите отладочный уровень логирования, и перезапустите сервис 3CXPhoneSystem.
Лог предоставьте из консоли управления полный, включая сообщение:
[CM500002] Info on incoming INVITE:
Вместе со всем контентом принятого запроса

Логи обрамляйте тегом "Code" (см. инструментарий окна редактирования)

Спасибо

 

[anonymous]

c XXX это я с секуюрностью видимо переборщил на самом деле там нормальный sip логин и IP адрес
Версия у меня v10.0.19117.1690 надо обновится?
Как включить отладочное логирование, подскажите.
Вообще проблема плавающая, если это провайдер то какие настройки надо покрутить?
Т.е. получается так,звонок от провайдера приходит, идет разговор 30 секунд и дальше обрыв. Проблема возникает не всегда.
Как я уже писал сервер находится за НАТОМ и соответсвенно белого IP у меня нет, может ли это влиять? Как я прочитал конфигурация за НАТОМ работоспособна, но не желательна.

 

[anonymous]

@kad wrote:c XXX это я с секуюрностью видимо переборщил на самом деле там нормальный sip логин и IP адрес
Вот как раз интересно, какой, там адрес. (хотя бы два первых его сегмента)

@kad wrote:
Как включить отладочное логирование, подскажите.

Настройки->Дополнительно и не забудьте подтвердить изменения и потом перезапустить сервис "3CX PhoneSystem"

@kad wrote:
Вообще проблема плавающая, если это провайдер то какие настройки надо покрутить?
Т.е. получается так,звонок от провайдера приходит, идет разговор 30 секунд и дальше обрыв. Проблема возникает не всегда.

Это плохо. Значит проблема где-то в NAT или нестабильном соединении.
Тут ситуация такая.
1. ACK не туда высылается провайдером
2. кто-то блокирует его по пути к PBX
3. провайдер иногда забывает его высылать.

1. и 3. маловероятны, поскольку у провайдеров сЕти и оборудование должны за всем этим следить и справляться с "исключительными" ситуациями. Кроме того, оба варианта могут быть легко расследованы провайдером, поскольку это всё на его стороне.

вариант 2. более вероятен, поскольку может объясняться плохим соединением, ограничением трафика, которое может просто игнорировать UDP пакеты. Также, если NAT "шарится" множеством сетей, то могут быть проблемы с непредсказуемым изменением оторбражения портов. Опять же, всё это лишь теория.

Проблема, которую расследовали в этой ветке изначально, была связана с маршрутизацией запросов в локальной сети (посмотрите на сложность подключения). В простых сетях это работает всегда без проблем.

@kad wrote:
Как я уже писал сервер находится за НАТОМ и соответсвенно белого IP у меня нет, может ли это влиять? Как я прочитал конфигурация за НАТОМ работоспособна, но не желательна.
Большинство инсталляций работают за NAT'ом. Если Вы не планируете подключать внешние телефоны, то Вам должно быть всё равно. Проблемы Вашего NAT должны решаться провайдером, хотя есть ситуации, когда это является невыполнимой задачей.

 

[anonymous]

@SY wrotekad wrote:c XXX это я с секуюрностью видимо переборщил на самом деле там нормальный sip логин и IP адрес
Вот как раз интересно, какой, там адрес. (хотя бы два первых его сегмента)


PBX contact: [sip:[email protected]:5060]

Включил расширенное логирование, теперь буду наблюдать.
Тут конечно могут быть проблемы как на стороне провайдера интернет, так и на стороне провойдара VoIP надеюсь логи покажут...
Спасибо.

 

[igor.snezhko]

Из практики скажу - месяц бились с похожей проблемой.

Простейшая схема, 3CX за роутером D-link DIR-615. Заведено два SIP провайдера.

Один провайдер работает без проблем. А второй - то работает, то нет, то работает с обрывами.

Перепробовали все, с клиентом состоялся разговор о возврате денег...

Потом я поговорил с умными людьми в D-link, которые сказали, что в дешевых роутерах (не только Dlink), из-за малого объема памяти и слабого процессора, НЕ РЕАЛИЗОВАН конический NAT. Вместо этого в них используют корявый SIP ALG.

После этого, я уже сам додумался поискать альтернативную прошивку и нашел Open WRT прошивку для этой модели.

После прошивки, все идеально заработало и работает по сей день.

Вот такое дело... От роутера D-link фактически осталась одна надпить на корпусе...

 

[anonymous]

@igor.snezhko wrote:Из практики скажу - месяц бились с похожей проблемой.

Простейшая схема, 3CX за роутером D-link DIR-615. Заведено два SIP провайдера.

Один провайдер работает без проблем. А второй - то работает, то нет, то работает с обрывами.

Перепробовали все, с клиентом состоялся разговор о возврате денег...

Потом я поговорил с умными людьми в D-link, которые сказали, что в дешевых роутерах (не только Dlink), из-за малого объема памяти и слабого процессора, НЕ РЕАЛИЗОВАН конический NAT. Вместо этого в них используют корявый SIP ALG.

После этого, я уже сам додумался поискать альтернативную прошивку и нашел Open WRT прошивку для этой модели.

После прошивки, все идеально заработало и работает по сей день.

Вот такое дело... От роутера D-link фактически осталась одна надпить на корпусе...

В моем случае роутер тоже из дешевых (ASUS-работает на альтернативной прошивке от Олега).
Т.е. получается что в теории такую проблему можно было бы решить имея белый IP отказавшись от "кривого" NATa?

 

[igor.snezhko]

Не уверен, т.к. тогда и все телефоны внутри сети нужно было бы на белые IP сажать. 3CX не любит двух сетевых карт...
Нужет именно правильный роутер, и нормальный провайдер. Или, хотя бы, нормальный провайдер.
Как я сказал, OpenWRT дала очень хорошие результаты.

 

[anonymous]

вот сегодня снова повторилась проблема с обрывов соединения при входещем звонке. Обрыв просиходит примерно через 30-37 секунд разговора.
Вот расширенные логи, к сожалению я в них не увидел чего то объясняющего проблему

11:06:01.859 Currently active calls [none]
11:05:29.859 Currently active calls [none]
11:05:02.218 [CM503008]: Call(51): Call is terminated
11:05:02.203 [CM503021]: Call(51): ACK is not received
11:04:57.859 Currently active calls - 1: [51]
11:04:30.218 [CM503007]: Call(51): Device joined: sip:[email protected]:5063
11:04:30.203 [CM503007]: Call(51): Device joined: sip:[email protected]:5060
11:04:30.203 [MS210003] C:51.1:Answer provided. Connection(transcoding mode[unsecure]):87.255.xxx.xxx:9014(9015)
11:04:30.187 [MS210001] C:51.2:Answer received. RTP connection[unsecure]: 192.168.2.236:16412(16413)
11:04:30.187 Remote SDP is set for legC:51.2
11:04:25.859 Currently active calls - 1: [51]
11:04:22.187 [CM505001]: Ext.10: Device info: Device Identified: [Man: Linksys;Mod: SPA Series;Rev: General] Capabilities:[reinvite, no-replaces, able-no-sdp, recvonly] UserAgent: [Linksys/SPA2102-5.2.12] PBX contact: [sip:[email protected]:5060]
11:04:22.187 [CM503002]: Call(51): Alerting sip:[email protected]:5063
11:04:22.093 [CM503025]: Call(51): Calling Ext:Ext.10@[Dev:sip:[email protected]:5063]
11:04:22.078 [MS210002] C:51.2:Offer provided. Connection(transcoding mode): 192.168.2.131:7122(7123)
11:04:22.046 [CM503004]: Call(51): Route 1: Ext:Ext.10@[Dev:sip:[email protected]:5063]
11:04:22.031 [CM503010]: Making route(s) to
11:04:22.031 [MS210000] C:51.1:Offer received. RTP connection: 204.138.165.128:38256(38257)
11:04:22.031 Remote SDP is set for legC:51.1
11:04:22.031 [CM505003]: Provider:[3tel.com] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [comfytel] PBX contact: [sip:[email protected]:45027]
11:04:22.031 [CM503001]: Call(51): Incoming call from 7495775xxxxx@([email protected]) to
11:04:21.875 [CM503012]: Inbound out-of-office hours rule (unnamed) for 10003 forwards to DN:10
11:04:21.875 Looking for inbound target: called=xxxxxxxxx; caller=7495775xxxxx
11:04:21.859 [CM500002]: Info on incoming INVITE:
INVITE sip:[email protected]:45027;rinstance=0460f52333574c67 SIP/2.0
Via: SIP/2.0/UDP 204.138.165.129;branch=z9hG4bKa686.2848ade7.0
Via: SIP/2.0/UDP 204.138.165.128:5060;branch=z9hG4bK42169ad1;rport=5060
Max-Forwards: 16
Record-Route:
Contact:
To:
From: "7495775xxxx";tag=as1a9b678a
Call-ID: [email protected]
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Date: Thu, 06 Oct 2011 07:04:14 GMT
Supported: replaces
User-Agent: comfytel
Content-Length: 0
P-hint: usrloc applied

 

[igor.snezhko]

Такая проблема бывает, если 3CX отправляет запрос на установку соединения, но не получает ответ через тот же интерфейс.
Причины:
1. Две сетевые карты.
2. Кривая работа NAT в роутере.
3. Кривая работа SIP ALG в роутере.

 

[anonymous]

@igor.snezhko wrote:Не уверен, т.к. тогда и все телефоны внутри сети нужно было бы на белые IP сажать. 3CX не любит двух сетевых карт...
Нужет именно правильный роутер, и нормальный провайдер. Или, хотя бы, нормальный провайдер.
Как я сказал, OpenWRT дала очень хорошие результаты.
В данном случае я имел ввиду повесить "белый" IP на моём роутере, таким образом уменьшев количество "натов".
Сейчас ситуация такова, провайдер натит со своего белого, общего IP на мой роутер смотрящий своим WANом в локальную сеть провайдера и в свою очередь мой роутер натит пакеты изв мою локальную сеть, где и живет PBX.
Навесив белый IP на мой роутер уберётся одно звено.
Как вы считаете, коллега?

ЗЫ
За мысль про прошивку спасибо, в этом направлении тоже буду смотреть.

 

[anonymous]

@igor.snezhko wrote:Такая проблема бывает, если 3CX отправляет запрос на установку соединения, но не получает ответ через тот же интерфейс.
Причины:
1. Две сетевые карты.
2. Кривая работа NAT в роутере.
3. Кривая работа SIP ALG в роутере.

Тут самый главный момент на мой взгляд, что проблема плавающая, а не постоянная. И сама собой рассасывается.
Я пока склонен думать на п 2 и на кривую работу провайдера VoIP.

 

[anonymous]

Если уменьшите количество NAT между PBX и провайдером (прямое подключение маршрутизатора локальной сети к "белому" адресу), то проблема либо исчезнет, либо выяснятся дополнительные нюансы окружения.

 

[anonymous]

@SY wrote:Если уменьшите количество NAT между PBX и провайдером (прямое подключение маршрутизатора локальной сети к "белому" адресу), то проблема либо исчезнет, либо выяснятся дополнительные нюансы окружения.
Я правильно понимаю, что расширенные логи ясности не внесли в проблему?
И еще вопрос.
У кого проблема с ошибкой ACK is not received, независимо от конетекста ( обрыв на внутр. телефонах или при соединении с провайдером) время обрыва 30-40 секунд. Это срабатывает таймаут?
Тут уже по моему вопрос поднимался, можно ли подкрутить что то в этом направлении?

 

[anonymous]

@kad wroteSY wrote:Если уменьшите количество NAT между PBX и провайдером (прямое подключение маршрутизатора локальной сети к "белому" адресу), то проблема либо исчезнет, либо выяснятся дополнительные нюансы окружения.
Я правильно понимаю, что расширенные логи ясности не внесли в проблему?

Прояснили лишь несколько аспектов, но причины, по которой ACK от провайдера не "долетел" к PBX, они не объясняют.
Его нет в конечной точке и всё тут.
В логах видно, что PBX стоит за каким-то натом и сконфигурирован использовать STUN сервер для "вычисления" своего местаположения в "глобальной" сети. В случае "многокаскадного" NAT это, в общем случае, нормально не может работать, поскольку NAT'ы рано или поздно всё равно что-то поменяют. Особенно тот, который транслирует много "соединений" (внешний)

Есть ещё один нюанс...
SIP порт 5060 транслируется в 45027 на внешнем NAT, а вот порты RTP 9014 и 9015 (которые тоже вычислялись STUN сервером) не поменялись, при прохождении всех NAT'ов.

Если есть желание поэкспериментировать, то попробуйте поменяйте SIP порт в конфигурации PBX на какой-нибудь в диапазоне 10000-20000. Для этого придётся переконфигурировать все телефоны и перезапустить PBX, так что не делайте этого на "живой" системе.

В заключение, хочу повторить:
ACK не "долетел" до хоста PBX по независимым от PBX и локальной сети причинам. С уверенностью можно сказать, что он вообще не появлялся в локальной сети. По этой причине, логи PBX дать ответ не могут.

Работает всё так (o) не обязательные части:
1. ->INVITE - запрос на установление соединения и указание приёмника звука на стороне провайдера
2. (o)<-100 Trying
3. (o)<-180 Ringing
4. <-200 OK - подтверждение соединения и указание приёмника звука на стороне PBX (повторяется до прихода ACK)
5. ->ACK - подтверждение приёма 200 OK (высылается на каждый принятый 200 OK)

Поскольку звук есть, то провайдер 100% принял 200 OK (иначе звука от провайдера не было бы)
Вопросы те же:
1. Высылался ли ACK провайдером (сомневаюсь что нет, но узнать их логов PBX это невозможно)
2. Высылался ли ACK по правильному адресу? Если количество проблемных звонков малО, то высылается он по правильному адресу.
3. А пропустил ли этот ACK приёмник (внешний NAT)? Тут ничего неизвестно.

Итого:
Прямое соединение маршрутизатора локальной сети к "белому" IP (NAT под полным контролем и только один) даст ответы на все вопросы сразу.

Немного многословно, но я пытался прояснить как можно больше аспектов проблемы.

Спасибо за внимание

 

[anonymous]

@SY wrote:
Прояснили лишь несколько аспектов...
---не надо цитировать полностью, тем более, такие длинные сообщения ---


Спасибо за Ваш развернутый ответ.
Я уже тоже решил идти путём белого IP адреса.
В этой связи короткий вопрос. Когда на моём роутере появится белый IP, надо ли на PBX отключать использование STUN сервера?

 

[anonymous]

@kad wrote:
...
Я уже тоже решил идти путём белого IP адреса.
В этой связи короткий вопрос. Когда на моём роутере появится белый IP, надо ли на PBX отключать использование STUN сервера?

Если у Вас статический "глобальный" адрес и к нему подключен маршрутизатор, который обслуживает доступ из локальной сети (NAT/Firewall), то можно выключить использование STUN и прописать адрес, который будет использоваться PBX.
При этом, на NAT/Firewall чётко привязать внешние порты к внутреннему IP хоста PBX.
Смотрите:
Настройки->Сеть в консоли управления.
Это должно быть указано и в документации АТС.

 

[anonymous]

Ясно.
и соответственно я делаю PAT порта 5060 TCPUDP и диапозона 9000-9049 из инета на мой локальный PBX