Форумы COMTUBE

замечательно проходят исходящие, в том числе и на 700000. Слышимость двусторонняя.

при входящих звонках нет слышимости в обе стороны.

Входящие и исходящие - с SIP на SIP? Попробуйте в настройках телефона (а лучше - обоих телефонов) оставить один кодек, предпочтительно - G.711.

до сегодняшнего дня пробовал несколько раз, нерегулярно

проблема скорее всего не в кодеке. Звонки нуружу нормально проходят. При звонке из внешнего мира похоже просто не устанавливается соединение (телефон не выдает CONNECTED, а продолжает писать RINGING )

на роутере пробросил SIP на телефон - результат нулевой.

после многочисленных безуспешных попыток, заканчивавшихся RINGING..., ситуация еще ухудшилась - на все попытки позвонить на сип-номер (через шлюз и по сипу) сип-атс включает сообщение "оставьте сообщение...", даже до отображения попытки звонка дело не доходит.

А если на телефоне попробовать включить STUN? STUN-сервер - или comtube.ru, или stun.xten.com. Файрволл какой-либо есть? Если есть, то можно, в качестве эксперимента, на время его отключить.

У меня также входящие звонки не проходят.
При ответе в трубке тишина, а звонящий продолжает слышать длинные гудки.

В техподдрежку обращался, звонил. Проблему признали, но так и не починили

м.б. уважаемые администраторы comtub`a ответят, что надо для пользования их сервисом с устройства за NAT`ом:
1.надо ли пробрасывать SIP и/или RTP (какие порты?) на устройство.
2.какого время регистрации на сервере (почему-то слишком часто срабаывает голосовая почта)
3.каков алгоритм поступления вызова (идет ли он от серверов Комтуба или непосредственно от абонента)

leonid0326 писал(а):м.б. уважаемые администраторы comtub`a ответят, что надо для пользования их сервисом с устройства за NAT`ом:
1.надо ли пробрасывать SIP и/или RTP (какие порты?) на устройство.
2.какого время регистрации на сервере (почему-то слишком часто срабаывает голосовая почта)
3.каков алгоритм поступления вызова (идет ли он от серверов Комтуба или непосредственно от абонента)

Ничего особенного за NAT'ом делать не нужно. Главное - чтобы файрволл не блокировал порты.
1. Пробрасывать не надо, NAT сам прокинет. Если же есть файрволл - да, нужно настраивать проброс конкретных портов. Телефон отправляет запрос на наш порт 5060, обратный трафик должен быть разрешен. RTP на нашей стороне - 20000-30000, на клиентской стороне могут быть другие значения.
2. Время слишком большим ставить нежелательно, обычно 600 или 1800 секунд - нормально. Также, если телефон за NAT, можно включить Keep-Alive.
3. Звонок на SIP - с сервера comtube.

Предупреждаю: все, что не имеет отношения к названию темы (то бишь, оффтопик), будет удаляться.

Что касается слишком большого тайм-аута для повторной регистрации - лучше ставить поменьше, чем 1 час. Повлиять на успешную перерегистрацию телефона в сети мы не можем - нельзя заставить телефон перерегистрироваться, инициировав соответствующий запрос со стороны сервера. Телефон сам должен понимать, что время пришло и отправить сообщение REGISTER. Кроме того, поскольку SIP основан на не совсем надежном протоколе передачи данных UDP, то доставка пакетов не гарантируется (а вот как телефон отреагирует на то, что REGISTER ушел, а ответа не было - сказать трудно). Теоретически, можно попытаться установить TCP-транспорт в настройках телефона (вместо UDP), но это не всеми поддерживается.

могу однозначно сказать, что в моем случае необходим проброс порта 5060 с внешнего адреса файерволла на внутренний адрес телефона.

leonid0326 писал(а):2. Время слишком большим ставить нежелательно, обычно 600 или 1800 секунд - нормально. Также, если телефон за NAT, можно включить Keep-Alive

т.е. надо делать время перерегистрации меньше, чем время жизни записи в NATе?

alg: видимо, да (но без крайностей типа 60 секунд и менее). Советую прекратить здесь обсуждать регистрацию - это не по теме, лучше заведите отдельный топик. Нарушителям будут выдаваться предупреждения.

есть ли зависимость от типа НАТа: симметричный, полный конус, частичный конус..?

кстати нашел ссылку, м.б. кому поможет http://aoz.com.ua/2009/02/06/sipovernat/

На разных типах NAT'а мы не проверяли ввиду отсутствия всех типов NAT'а под рукой. Однако проблемы возникают достаточно редко. Лучше, конечно, чтобы вообще проблем не было, но так мало у кого получается. Хотя мы стараемся исправляться, если вдруг что