Не проходят звонки на телефоны с кодом 495

[hedgehog]

А у меня наоборот не прошел входящий вызов с 495 на мой сип-номер. Мой номер был свободен и подключен к серверу, но вызывающей стороне было сказано, что вызов не может быть принят. Мне сразу позвонили на сотовый и я перезвонил на номер, с которого мне звонили со своего сип, звонок прошел нормально, что подтверждает, что мой сип-номер был подключен к серверу. Не понятно почему входящий звонок не прошел.

[alg]

Вчера как раз в районе 11 вечера были некоторые проблемы с платформой, что могло выражаться в нестабильной работе SIP.

[alex8888]

Вчера как раз в районе 11 вечера были некоторые проблемы с платформой, что могло выражаться в нестабильной работе SIP.

Могли ли вчерашние проблемы с платформой вызвать необходимость сново включить STUN?

[alg]

Вчера как раз в районе 11 вечера были некоторые проблемы с платформой, что могло выражаться в нестабильной работе SIP.

Могли ли вчерашние проблемы с платформой вызвать необходимость сново включить STUN?

Нет.

[alex8888]

Значит STUN нужен? Немного непонятная ситуация - я в пятницу общался с вашей ТП, и мне четко сказали что STUN надо отключать... Вот и гадаю надо или нет?

[alg]

Значит STUN нужен? Немного непонятная ситуация - я в пятницу общался с вашей ТП, и мне четко сказали что STUN надо отключать... Вот и гадаю надо или нет?

Смотрите... STUN может потребоваться в случае, если телефон не имеет внешнего IP-адреса и находится за NAT'ом, а платформа не может обойти этот NAT. Основные признаки такой ситуации - телефон по каким-то причинам не может зарегистрироваться, звонок "отваливается" через 30 секунд или не ходит звук, хотя вроде бы все варианты настроек перепробовали.

В большинстве случаев указание STUN-сервера при работе с comtube не требуется (т.е., включение STUN - скорее исключение, чем правило). И если ранее все работало, а сейчас вдруг перестало - вероятно, что-то с настройками на вашей стороне, или у провайдера. У нас настройки не менялись.

[alex8888]

Вот по-моему именно в попытке обхода NAT и кроется проблема...
Я использую FireWall DFL-210, он умеет работать с SIP алгоритмом и производитель рекомендует для корректной работы отключать механизмы преодоления NAT как на сервере так и на SIP клеенте.
Столкнулся с тем, что переодически (пока не смог определить закономерность) при выключенном STUN продолжительность передачи RTP трафика 130 сек, это, как я понимаю, время жизни сесси UDP. Интересно то, что в момент соединения с абонентом, поднимается две параллельных сесси (видимо up/down), так вот время одной из сессий как и положено уменьшается и доходя до 0 не возобнавляется (абонента не слышно), а время второй сессии не меняется(??).

[sd]

Отключите в вашем FireWall DFL-210 функцию по работе с SIP. По идее все должно заработать.

[hedgehog]

Вчера как раз в районе 11 вечера были некоторые проблемы с платформой, что могло выражаться в нестабильной работе SIP.

Если это был ответ мне, то описываемая мной ситуация была не в 11 вечера. Мне звонили 18 Октября 2009, 11:34, а я перезвонил 18 Октября 2009, 11:35.
Сейчас вот сам попробовал позвонить на свой номер, тоже самое. Робот говорит, что "к сожалению я не могу сейчас подойти к телефону, оставьте Ваше сообщение или отправьте факс после звукового сигнала"

[alg]

hedgehog, сейчас Ваш номер не значится в списке зарегистрированных на сервере. Вероятно, имеет смысл перезагрузить sip-адаптер или X-lite.