Перейти к содержанию
    

gena_dj

Участник
  • Постов

    23
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные gena_dj


  1. А откуда в воздухе энергетические зоны?

    Думаю, что модель электронного газа применить можно. Но магнитными эффектами пренебречь скорее всего.

  2. Доброе время суток!

     

    Интересует информация: кто использовал вызовы с категорией "передача данных" для каких сотовых операторов в каком регионе РФ?

    Какие возникали сложности?

    Как осуществлялась тарификация таких вызовов?

     

    Спасибо!

  3. Работа с портом(ReadFile, WriteFile) должна осуществляться только в том потоке, который открыл этот порт (CreateFile).

    Это еще почему?

    Можно открыть в одном потоке, а читать в другом.

     

    Единственное, что нельзя делать - одновременно пытаться работать в двух разных потоках.

  4. Доброго времени суток!

     

    Интересует subj.

     

    Как я понял, основа этого ЦАП - дельта-сигма модулятор, который генерирует 1-битный шум с переменной плотностью распределения и со спектральной плотностью такой, что большая часть энергия сосредоточена в ВЧ-области. Поэтому возможно эффективно отфильтровывать этот шум НЧ-фильтром.

     

    Если я в чем-то ошибаюсь - поправьте пожалуйста.

     

    Если я все понимаю правильно - подскажите пожалуйста, какой принцип действия дельта-сигма модулятора.

     

    Спасибо!

  5. 1. Передавать RTP с голосом не нужно, вместо него можно передавать любые UDP-пакеты

    2. Когда я тестировал с МТС, я контролировал, что трафик ходит напрямую с NAT-NAT, а не через релеи

    3. STUN есть практически у любого провайдера VoIP, в интернете полно публичных сервисов. Чтобы задействовать STUN достаточно зарегистрироваться у публичного провайдера. Небольшой список здесь.

    4. Все порты открывать не нужно, достаточно открыть по одному порту с каждой стороны.

    5. Если не хочется городить огород с выделенными серверами - можно задействовать любой публичный SIP-сервер для установки тоннеля.

     

     

    Проблемы передачи VoIP в поднятой теме как бы вопрос второстепенный.

    Я бы обратил внимание на вот этот драфт.

    http://tools.ietf.org/html/draft-ietf-behave-turn-06

     

    Т.е. в VoIP телефонии все схвачено. Если они не могут сделать прямой канал, то сразу же задействуют релейных агентов, т.е. внешние серверы через которые пропускается трафик.

    Но публичных релейных агентов никто не даст.

    TURN как стандарт еще не закончен.

    Да и STUN публичных не так уж и много и находятся далеко.

    Сам проткол STUN предусматривает авторизацию, т.е. если STUN, то не значит халявный.

     

    Да и тунелем метод со STUN назвать нельзя.

    Сервер за NAT-ом желающий открыть все свои порты должен по идее для каждого порта из 65536 провести сеанс со STUN сервером. Понятно, что это не реально.

  6. Это довольно странно, только с одним оператором удалось проверить. Я подробно тестировал эту ситуацию на МТС, работало стабильно.

     

    Кстати, работа skype здест не авляется критерием. Напишите подробнее, как тестировали. Лучше пробовать с правильным sip-оператором и с sip-телефоном, поддерживающим stun. (например, x-lite (eyeBeam, Bria))

  7. Вот именно, что получится. Иначе бы и STUN-а не было (почитайте кстати rfc3489, это очень интересно) В случае, если кто-то из-под NAT-а выпустил пакет наружу, NAT держит этот тоннель. Наружний порт становится проброшен на внутренний локальный порт. Исключение - symmetric NAT.

     

    Ниже - цитата из rfc

    Binding requests are used to determine the bindings allocated by NATs. The client sends a Binding Request to the server, over UDP. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client

    ....

    The STUN client is typically embedded in an application which needs to obtain a public IP address and port that can be used to receive data. For example, it might need to obtain an IP address and port to receive Real Time Transport Protocol (RTP) [12] traffic.

  8. WMP100

    Спасибо,

    то что нужно.

     

    GR64 умеет через PCM. все вейвкомы умеют.

     

    в аттаче аудио апноут для GR64. там местами есть полезная информация по использованию PCM интерфейса.

    Спасибо,

    тоже кране полезная информация.

  9. Не понял, в предыдущем посте сказано что нужен внешний сервер. Где решение для связи напрямую?

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

  10. Если не секрет: какой кодек для голоса планируется использоваться и какой алгоритм шифрования?

     

    Я бы взял SPEEX и CryptMT (потоковый) с предварительным обменом закрытых ключей по RSA

     

    Но есть 3 "НО":

    1. Не показывайте Ваш продукт никому

    а) разработка без лицензии запрещена (разрешена при длине ключа менее 40 бит для систем с закрытым ключем и менее 128 бит - с открытым + некоторых других)

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

    2. Некоторые операторы открывают возможность Data Call за отдельную плату, некоторые не предоставляют вообще (по предварительной информации - Tele2 в России не предоставляет услугу)

    3. Тарификация таких вызовов, как правило, с первой секунды.

  11. Можно сравнительно легко решить проблему используя VPN сервер.

    Тут либо покупаете услугу VPN у кого-нибудь в инете (50$ в год),

    либо покупаете и ставите дома роутер с VPN и прикручиваете его к Dinamic DNS если нет статического адреса.

    После чего все мобильные дивайсы могут быть и серверами и клиентами и все видны друг другу по любым портам.

    VPN - не слишком ли круто для микроконтроллеров? Да и вообще, это лишнее (пропускать трафик через третье место - лишние проблемы, в то время, когда можно пропускать напрямую) Читайте мой предыдущий пост.

  12. Я думаю, что тоннель между двумя пользователями, сидящими за NAT-ами (в общем случае разными), установить можно. В VoIP для этого применяется STUN. Как я себе это представляю - объясню.

     

    1. Пользователь 1 (П1) отсылает UDP-пакет STUN - серверу. При этом сервер "видит" host:port реального интерфейса на NAT-сервере

    2. П1 узнает от сервера host:port

    3. П1 регистрируется на sip-сервере со своим реальными host:port

    4. Шаги 1 - 3 выполняет Пользоваетль 2 (П2)

    5. П1 и П2 регистрируются на SIP-сервере с учетом своих реальных host:port

    6. Далее SIP - сессиия проходит с учетом реальных host:port пользователей.

     

    Как я вижу организацию тоннеля между двумя пользователями за NAT-ами.

    1. Инициатор отсылает UDP-пакет выделенному серверу в реальной сети. При этом сервер "видит" host:port реального интерфейса на NAT-сервере

    2. П2 получает от выделенного сервера host:port инициатора

    3. П2 отсылает на host:port инициатора UDP-пакет.

    4. Инициатор отвечает на этот пакет по адресу отправителя.

    Это все, установили тоннель :)

     

    Если нужны услуги по организации выделенного сервера в интернете для таких дел - могу помочь.

     

    Но так или иначе, можно использовать публичные SIP и STUN сервера.

  13. Да, похоже это то, что нужно.

    Только описание этого интерфейса так и не нашел. Есть у кого-нибудь Digital Audio section of Integrator's Manual? Следует ли ожидать, что интерфейс будет такой же, как у нокии 12? (NOKIA 12 GSM MODULE HARDWARE INTEGRATION MANUAL)

×
×
  • Создать...