Bell, если помните, я уже не раз жаловался на проблемы именно с приёмом звонка на мобильный клиент, подключенный к LV через мобильный интернет. Вчера-сегодня решил таки попробовать разобраться, в чём проблема - почему одна и та же BRIA, жужжащая на андроиде и подключённая через 3G к LV, входящие звонки НЕ принимает, а подключённая к sipsorcery либо к sipgate.de, принимает аж на ура. Т.е., тел. начинает звонить макс. через 3-4 секунды после начала набора вызывающим. К чему пришёл методом туда-сюда фтыка и пр. - sipsorcery и sipgate.de реагируют на установки refreshing мобильного клиента - т.е., если клиент хочет перерегистрироваться чаще, чем время перерегистрации клиента, установленное на сервисе по умолчанию, то сервис идёт клиенту навстречу. К примеру, на BRIA время обновления под 3G по умолчанию установлено на 9 секунд. И это позволяет работать на приём, несмотря на NAT любого мобильного провайдера. На LV вход через 3G не работает НИКАК. Видимо, потому, что 1 минута на обновление клиента, жёстко установленная на LV, это очень хорошо для WLAN, но бесконечно много для 3G. Если я правильно понимаю суть уловки мобильных провайдеров, то за эти 60 секунд они минимум трижды успевают сменить айпи клиента, и входящий звонок на него приходит просто в никуда. Кстати, через sipsorcery у меня роскошно заработал на вход встроенный sip-клиент моей Nokia E72. На LV под 3G я им могу пользоваться лишь на выход. Т.е., когда выхожу из дома или офиса, отключаю нокию от её линии на LV, подключаюсь к ней через Nimbuzz (который на вход работает), а нокию подключаю к специально выделенной для неё линии на LV, через которую звоню наружу. Крик больной души, короче. Есть два неудобства при использовании этого "sipsorcery-костыля" - лишнее звено в цепи и отсутствие КПВ при исходящих звонках (звонках только на внутреннии линии LV!). В остальном всё просто идеально. Bell, у меня вежливый вопрос - нельзя ли сделать так, чтобы LV, как sipsorcery, sipgate.de и иже с ними, гибко реагировала на refreshing interval подключаемых клиентов? Просит клиент 9 секунд - на тебе 9 секунд. Хочет клиент 12 - на тебе 12! Или это может "положить" сервер? Спасибо.
Спасибо, что ответили зы Страшно спрашивать, но, всё-таки спрошу - а когда (хоть приблизительно) следует ожидать новую версию? зызы Запишите меня добровольцем
У меня возник вопрос. Тестирую VoIP через GSM/GPRS/EDGE/3G/CDMA/HSDPA/HSUPA/HSPA+/LTE USB модем для применения за городом. Так как не известно, какое там качество покрытия, пробовал на EDGE. Схема подключения Модем -> Роутер -> VoIP шлюз (G.729) -> Сервер Либерал -> Gigaset 610 (711a). А вопрос такой. Звоню с VoIP шлюза на Гигасет. Если что то сказать на стороне шлюза, задержка есть заметная. Если сказать что либо на стороне Гигасет, задержки нет. Даже меньше, если звонить с GSM телефона напрямую. Вопрос, как это можно объяснить? Ведь на EDGE пинг большой, скорость низкая. Но почему входящие пакеты не задерживаются, и задержка не чувствуется, если говорить на в Гигасет и слушать на VoIP шлюзе. А если говорить на стороне VoIP шлюза, то задержка огромная, как по спутнику. Проблема явно в скорости, т.к. если выбрать любой другой режим, тот же WCDMA/UMTS либо LTE, то задержки естественно нет. И ещё вопрос, я так понимаю "болезни" приема входящих вызовов VoIP шлюз тоже будет подвержен, при использовании 3G/2G?
to barmalito: я не задумывался почему, но и правда: там, где LV через 3g не работает, иногда фурычит скайп (Pre³) и всегда - SIPNET с фирменными настройками на NOKIA E72!
У нас теперь будет поддержка TCP, возможно, это тоже сможет помочь, если клиент умеет. Но мы еще сравним работающие решения и наше.
Это нереально двояким образом. Т.к.обновление ip адреса создаёт ненужный широковещательный трафик, что при узком канале смерти подобно для сервисов. И с другой стороны вы бы тогда не смогли пользоваться никакими интерактивными ресурсами. В т.ч. видео, аудио. Скорее это связанно с какими то настройками Nat. типо времени открытия портов.
Это связано с ассимитричностью интернет каналов. Исходящяя скорость всегда (в реальности) меньше входящей. В плане голоса это может проявляется двояко, в зависимости от настроек кодека. Конкретно от длины фрейма. Это что то типо буффера. Чем короче длина фрема (буффера) тем более голос приближен к живому, а при низкой скорости это проявляется в пропадание частей голоса. Чем больше фрейм тем больше задержка на принимающей стороне, но зато нет пропадания голоса (так же как при большом буфере нет зависаний видео\аудео). Единственно, что непонятно почему задержка в одну сторону только. ну это может быть с разными настройками на разных сторонах наверное. Как-то так...
Скорее всего да. Дело в том, что я даже отдалённо не представляю, как работает NAT. Читая умных людей (тм) на форумах, понял, что он виноват. А вот в чём именно - увы...
Вот именно, что не понятно. Потому что пробовал все виды кодеков, которые доступны наVoIP шлюзе. И пробовал разную длину фреймов. Результат одинаковый, и от настроек практически не зависящий.
Достаточно знать, что keep alive параметр в настройках то, должно "теоретически" держать NAT открытым.
Ясно, спасибо. Теперь понял, зачем у sipsorcery этот "keep alive" в настройках линии вообще присутствует. Я всегда там ставил птичку чисто из соображений, что хуже не будет. А тут вот оно что, михалыч... И оно, кстати, держит. Даже не теоретически, а вполне практически. С активным "keep alive" на вход прекрасно работают (нормальные) мобильные клиенты. Просто хорошо работают.
Keep-alive это то, что клиент шлет серверу, а не сервер клиенту. По крайней мере я обратных ситуаций не встречал. Это просто пустой пакет с лоакльного sip-порта на sip-port сервера
Мне сложно судить, остаётся только верить. Но зачем тогда эта опция (которую можно активировать либо не активировать) присутствует в настройках линии на сервере у того же сипсорсери?
Ну чисто теоретически, я допускаю, что такое может быть, но 1. Это очень накладно с точки зрения сервера. Keep-alive пакеты шлются достаточно часто. 1000 клиентов раз в 10 секунд это 100 пакетов в секунду, не считая остальных запросов на регистрацию и обруботку соединений. Даже на ЛВ регистраций существенно больше, чем 1000. 2. Большого смысла с точки зрения прохождения NAT в этом нет. Если такие пакеты шлет клиент - ситуация ровно та же самая, пара IP адрес-Port держатся открытыми какое то время на NATе. Но нагрузка на сервер меньше, а клиенту все равно. Но вообще интересно, хотелось бы посмотреть, что они реально шлют клиенту и с какой частотой. Мой аккаунт на sipsorcery прикрыли, заводить все по новой большого смысла нет. Если есть регистрация с LV на sipsorcery - включите keep-alive для такой линии, а я посмотрю.
Bell, у меня на сипсорери кроме "костыля" для LV уже почти год как ничего нет - все у вас на LV. Я вам сейчас сброшу данные доступа к sipsorcery и экспериментируйте там, сколько душе угодно. Там есть три линии с keep alives, которые работают вместе с LV. Одна из них "рабочая" - через неё включена нокия (через нативный клиент), а остальные чисто экспериментальные - это я андроидные телефоны с разными сип-клиентами проверяю на жизнеспособность. Смотрите приват, короче.