Это тоже полностью не решает проблему =) «Мы» все еще находимся за натом и «узлу с реальным ипом» все еще нужно угадать, где же мы ловим его медиа-трафик.
Реальный выход — использовать протоколы совмещающие сигнализацию и медиа и задающие рабочие порты на транспортном уровне.
Это понятно. Предположим он нашел «ближайший узел», который выдал «звонящему» прямой маршрут до вызываемого. Ок, дальше что? А дальше надо устанавливать SIP-сессию с вызываемым — тут тоже проблем особо не возникает, один порт на вызывающем — один на вызываемом.
А дальше затык. После установления сессии на уровне SDP-протокола конечные устройства оговаривают порты с\на которые будет слаться медиа. Вот тут-то и проблема: как угадать, в какой порт смапится случайно выбранный порт из диапазона?
А НАТ они как будут в автоматическом режиме преодолевать для SIPа? Или пользователю надо будет знать какой типа ната используется в сети и допиливать настройки?
Рад, что SIPS жив =) И доганяет по функционалу Kamailio.
А теперь о непонятностях:
1. Для чего Presence (кстати, рфц3261 его не описывает, это расширение SIP 2.0) включен в ядро? А потом еще и в Routing Engine?
2. Почему поддержка NAT включается в обработку после анализа транзакции? (Хотя тут могу допустить, что сделано для отбрасывания несуществующих транзакций до анализа NAT)
3. Для чего доступ к БД на уровне анализа диалогов и ниже? Я думаю памяти вполне бы хватило. Оверхед sql операций привысит, ИМХО, выигрыши от прочих решений.
4. Как по мне, ядро должно все-таки включать минимальный функционал. Доступ к БД и прочие «тяжелые» рюшки лучше «поднять выше».
Кстати, для «напобаловаться» можно запустить 2+ прожорливых процесса `time md5sum /dev/urandom &` и, изменяя их приоритеты, следить за распределением процессорного времени.
Согласен, с одной стороны, домен.рф ничем не отличается от такого же в зоне .ru (технически набор записей для него тот же =) ). Опять же наличие нескольких алисасов, скажем, для своего сайта не приносит прямого дохода. Да еще и следить надо за его состоянием (штука все ж новая для тех. реализации).
А теперь посмотрим с другой стороны на появление национальной зоны.рф
Я считаю, что для любой компании, так или иначе связанной с ИТ, покупка своего домена в этой зоне, в первую очередь, возможность показать, что она (компания) держит «руку на пульсе» ИТ событий. Это, как ни крути, повысит доверие клиентов.
А ценообразование… Да, в России оно всегда было загадочным процессом =) Давайте относится к нему философски. Ну иногда жаловаться в ФАС.
С точки зрения тарификации по местным тарифам, да.
Мне кажется не стоит привязывать принимающий скайп-клиент к определенному месту. Сегодня это Бобруйск, завтра — Бостон, послезавтра — Нью-Дели. При этом вам как звонили на питерский номер, так и будут звонить.
Для бобруйской АТС это будет межгород до Питера.
Имелось ввиду ситуация, когда абоненты Питера дозваниваются до вас, скажем, во Францию звоня на местный питерский номер. Отсюда и местные тарифы.
Приведенный в примере нат задает соответствие srcHost:srcPort — dstHost:dstPort.
Можно конечно в поставку включать индивидуальный STUN сервер. Но это тоже не решает проблему Port-restricted cone NAT.
Реальный выход — использовать протоколы совмещающие сигнализацию и медиа и задающие рабочие порты на транспортном уровне.
IAX2, как пример решения.
А дальше затык. После установления сессии на уровне SDP-протокола конечные устройства оговаривают порты с\на которые будет слаться медиа. Вот тут-то и проблема: как угадать, в какой порт смапится случайно выбранный порт из диапазона?
Может все-таки «давить»? Или я не уловил шутку юмора?
А теперь о непонятностях:
1. Для чего Presence (кстати, рфц3261 его не описывает, это расширение SIP 2.0) включен в ядро? А потом еще и в Routing Engine?
2. Почему поддержка NAT включается в обработку после анализа транзакции? (Хотя тут могу допустить, что сделано для отбрасывания несуществующих транзакций до анализа NAT)
3. Для чего доступ к БД на уровне анализа диалогов и ниже? Я думаю памяти вполне бы хватило. Оверхед sql операций привысит, ИМХО, выигрыши от прочих решений.
4. Как по мне, ядро должно все-таки включать минимальный функционал. Доступ к БД и прочие «тяжелые» рюшки лучше «поднять выше».
Очень показательный пример.
А теперь посмотрим с другой стороны на появление национальной зоны.рф
Я считаю, что для любой компании, так или иначе связанной с ИТ, покупка своего домена в этой зоне, в первую очередь, возможность показать, что она (компания) держит «руку на пульсе» ИТ событий. Это, как ни крути, повысит доверие клиентов.
А ценообразование… Да, в России оно всегда было загадочным процессом =) Давайте относится к нему философски. Ну иногда жаловаться в ФАС.
Да, про несерьезно я, конечно, имел ввиду бизнес =)
Да, предоставление услуги прямого номера по сипу довольно развито. Но тем более интересен сервис skypeinrus, предоставляющий номер для skype.
Мне кажется не стоит привязывать принимающий скайп-клиент к определенному месту. Сегодня это Бобруйск, завтра — Бостон, послезавтра — Нью-Дели. При этом вам как звонили на питерский номер, так и будут звонить.
К сожалению, сам скайп, на сколько я знаю, пока не предоставляет такую услугу в России.
Я думаю PayPal будет в будущем также доступен российским пользователям.
Имелось ввиду ситуация, когда абоненты Питера дозваниваются до вас, скажем, во Францию звоня на местный питерский номер. Отсюда и местные тарифы.