Благодаря современному и элегантному техническому дизайну платформа Odoo уникальна. Это позволяет нам и разработчикам нашего сообщества предоставлять первоклассное удобство использования, масштабируемое для всех приложений .

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

Наконец, с регулярными ежегодными выпусками Odoo развивается намного быстрее, чем любое другое решение.

7 миллионов пользователей
развивают свой бизнес с помощью Odoo

Кредитная карта не требуется — Мгновенный доступ

Начните сейчас — это бесплатно

Как RTP (транспортный протокол реального времени) работает в VOIP?

Протокол передачи в реальном времени с аббревиатурой RTP был стандартизирован в 1996 году. Он позволяет передавать аудио- и видеоданные в режиме реального времени. RTP имеет сквозные транспортные возможности для приложений реального времени в многоадресных или одноадресных сетевых службах. Таким образом, он широко используется для интерактивных аудио- и видеоконференций.

На практике RTP опирается на множество протоколов. Архитектура TCP/IP использует протокол UDP. Это неотъемлемая часть приложения, в отличие от других транспортных протоколов, таких как TCP. Использование протокола UDP для инкапсуляции пакетов RTP включает определенные ограничения, особенно на уровне исправления ошибок. В результате любой потерянный или поврежденный пакет просто игнорируется и отбрасывается. Протокол RTP отдает предпочтение конкатенации и комбинированию звука и изображения, а не целостности передаваемых данных.

Роль RTP заключается в обеспечении единого способа передачи данных с учетом ограничений в реальном времени. С этой целью RTP вводит маркеры времени и порядковые номера в различные мультимедийные потоки (аудио, видео и т. д.), контролирует прибытие пакетов к месту назначения и идентифицирует тип транспортируемой информации. Однако этот протокол не может резервировать ресурсы в сети, обеспечивать надежность в сети или гарантировать время доставки.

Например, в мультимедийном сеансе каждый носитель передается в отдельных сеансах RTP. Это позволяет серверу адаптировать поток к пропускной способности получателей. Впоследствии, благодаря идентификатору источника и отметке времени выборки, можно обеспечить синхронизацию. RTP можно использовать отдельно, но его можно связать с протоколом управления в реальном времени (RTCP).

В то время как различные методы предлагают гарантии распределения ресурсов в сети, они вряд ли обеспечивают применение временных гарантий маршрутизации информации, таких как джиттер, который плохо контролируется. Именно для решения этой проблемы был предложен стандарт протокола передачи в реальном времени, которым является RTP. Транспортный протокол в реальном времени (RTP) и его надстройка для протокола управления транспортом в реальном времени (RTCP). Соответственно, они позволяют транспортировать и контролировать потоки данных, обладающие свойствами реального времени.

Говоря кратко, RTP основан на следующих принципах:

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

• Предоставление мультимедийных приложений с транспортным протоколом, адаптированным к их структуре

• Предоставление мультимедийных приложений, измененных в соответствии с сетевым поведением, для оценки свойств сети (коэффициент ошибок, задержка, дрожание и т. д.).

Несмотря на надежность TCP, которая имеет преимущество в управлении надежной передачей (повторная отправка IP-пакетов в случае ошибки), она, к сожалению, несовместима с потоком в реальном времени. В результате UDP используется как более простой протокол, т. е. без исправления ошибок и упорядочивания пакетов по прибытии. Для этого мы будем использовать два дополнительных протокола: RTP и RTCP. Эти два протокола используют разные коммуникационные порты для ссылки на приложения, работающие на обоих взаимодействующих компьютерах (локальном и удаленном). Четный порт будет использоваться RTP, а нечетный — RTCP.

Модель OSI

RTP можно описать как надстройку UDP, добавляющую к каждому передаваемому пакету ценную информацию о порядковом номере (который восстанавливает порядок полученных пакетов) плюс метку времени пакета для базы данных восстановить. Времени. Таким образом, получатель информации знает дату отправки пакета и может измерить время нахождения в сети для сокращения времени передачи путем сравнения времени передачи нескольких пакетов одного и того же обмена.

RTP управляется на уровне приложения. Его целью является предоставление сквозных транспортных функций для приложений реального времени через многоадресные или одноадресные сетевые услуги (аудиоконференции, интерактивное видео/видеовещание, аудио/симуляция). Основная роль RTP заключается в реализации порядковых номеров IP-пакетов для восстановления голосовой или видеоинформации, даже если базовая сеть меняет порядок пакетов. С технической точки зрения, RTP позволяет:

– Восстановить временную базу аудио, видео и потоков данных в реальном времени в целом.
— Быстро обнаруживать потерю пакетов и сообщать об этом источнику за время, совместимое с сервисом.

Как и любой другой телекоммуникационный протокол, RTP имеет определенные ограничения:

– RTP не действует на уровне маршрутизаторов.
— не контролирует QoS.
— Не резервирует ресурсы (на этом уровне вмешивается RSVP). RSVP — это сигнальный протокол, который позволяет приложению резервировать ресурсы в Интернете.
— RTP не гарантирует доставку пакетов.
— RTP не обеспечивает автоматическую повторную передачу отсутствующих пакетов.

Протокол RTCP встроен в RTP. Его основная роль состоит в том, чтобы сообщать (у источника) о поведении сети (предоставлять информацию о качестве сети) путем распространения статистических результатов, сделанных участниками сеанса RTP. Технически это называется обратной связью.

Источник может использовать эту информацию, которая передается в режиме реального времени, чтобы адаптировать тип кодирования к уровню доступных ресурсов. Также обеспечивает передачу информации, идентификацию участников сеанса RTP. Таким образом, каждый может знать, сколько участников входит в состав конференции. Наконец, он регулирует скорость передачи. Эта информация будет использоваться для улучшения скорости вывода и ее адаптации для размещения всех желающих присоединиться к мероприятию.

Конфиденциальность медиапотоков достигается за счет шифрования. Поскольку сжатие данных, используемое с форматами полезной нагрузки, описанными в этом профиле, применяется сквозно, шифрование может быть выполнено после сжатия, чтобы не было конфликта между двумя операциями. Потенциальная угроза отказа в обслуживании существует для кодировок данных, использующих методы сжатия с вычислительной нагрузкой, отличной от нагрузки принимающей стороны. В экстремальных условиях атакующий потенциал может внедрить в поток сложные патогенные дейтаграммы, подлежащие декодированию, что вызовет перегрузку получателя.