Тфоп

Социал-демократическая партия Германии (СДПГ; нем. Sozialdemokratische Partei Deutschlands, SPD) — одна из двух крупнейших партий Германии, основана 23 мая 1863 Фердинандом Лассалем как Всеобщий германский рабочий союз.

СДП (Служебный Дизель-Поезд) — серия дизель-поездов производства Людиновского тепловозостроительного завода.

СДП — многозначная аббревиатура.

Возможные значения:

Социал-демократическая партия «Адолат» (узб. «Adolat» sotsial-demokratik partiyasi) (СДПУ «Адолат») — политическая партия Узбекистана.

Социал-демократическая партия Украины (объединённая) СДПУ(о) укр.

Соціал-демократична партія України (об’єднана) — украинская политическая партия.

Социал-демократическая партия Австрии (СДПА; нем. Sozialdemokratische Partei Österreichs, SPÖ) — австрийская политическая партия.

Социа́л-демократи́ческая па́ртия Финля́ндии, аббр. СДП (фин. Suomen Sosialidemokraattinen Puolue, SDP) — политическая партия в Финляндии.

Аббревиатура СДПП может означать:

Социал-демократическая партия России:

Социал-демократическая партия Германии

Протокол RTP

При использовании протокола RTP открываются два порта для коммуникации. Один для передачи потока медиаданных (четный номер порта), и один для передачи данных сигнализации (обратная связь для QoS и контроль медиапотока) — RTCP. Значения номеров портов жестко не привязаны, в основном, они сильно зависят от используемого приложения.

  • RTP — Протокол передачи медиаданных в реальном времени (Real-time Transport Protocol)
  • RTCP — Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol)
    • Дополнительно включает в себя информацию о:
    • Потерях пакетов
    • Буферизация «Jitter»
    • Задержки
    • Уровень сигнала
    • Метрика качества сигнала (Call Quality Metrics)
    • Echo Return Loss
    • и т.д.
  • RTCP XR -Расширенный Протокол передачи управляющих данных в реальном времени (Real-time Control Protocol Extended Reports)
    • Все поля, описанные для протокола RTCP, плюс:
    • R Factor — Параметр качества сигнала
    • MOS — Параметр качества сигнала
    • и другие

Пакеты, содержащие передаваемый голос, передаются с использованием RTP/RTCP для протокола SIP, который используется для VOIP вызовов. Протокол RTP может передавать медиаданные, идентифицируемые параметрами, которые зарегистрированы организацией: «Internet assigned numbers authority» — IANA. Они так же используются для полей в протоколе SDP, который используется в SIP и MGCP сообщениях.

Некоторые значения поля payload:

PT название кодека audio/video (A/V) clock rate (Hz) кол-во каналов Документ
0 PCMU A 8000 1 RFC3551
3 GSM A 8000 1 RFC3551
4 G723 A 8000 1 Kumar
5 DVI4 A 8000 1 RFC3551
6 DVI4 A 16000 1 RFC3551
7 LPC A 8000 1 RFC3551
8 PCMA A 8000 1 RFC3551
9 G722 A 8000 1 RFC3551
10 L16 A 44100 2 RFC3551
11 L16 A 44100 1 RFC3551
12 QCELP A 8000 1
13 CN A 8000 1 RFC3389
14 MPA A 90000 RFC3551,RFC2250
15 G728 A 8000 1 RFC3551
16 DVI4 A 11025 1 DiPol
17 DVI4 A 22050 1 DiPol
18 G729 A 8000 1
19 зарезервировано A
20 не назначено A
21 не назначено A
22 не назначено A
23 не назначено A
24 не назначено V
25 CelB V 90000 RFC2029
26 JPEG V 90000 RFC2435
27 не назначено V
28 nv V 90000 RFC3551
29 не назначено V
30 не назначено V
31 H261 V 90000 RFC2032
32 MPV V 90000 RFC2250
33 MP2T AV 90000 RFC2250
34 H263 V 90000 Zhu
35—71 не назначено
72—76 зарезервировано для RTCP во избежание конфликтов RFC3550
77—95 не назначено
77—95 dynamic RFC3551

Протокол RTP и трансляция IP адресов (NAT)

При проведении VOIP сеанса связи, образуются два RTP потока, по одному в каждом направлении. Если один из участников, участвующий в этом сеансе, использует IP адрес из приватной сети, тогда поток от абонента, находящегося в публичной сети в сторону NAT сервера, не сможет достичь абонента, находящегося во внутренней сети. Для решения этой проблемы часто используется Symmetric RTP (симметричный RTP). Для дополнительной информации об использовании VOIP в сетях с NAT, смотри: NAT and VOIP.

Статьи

Документы RFC:

  • IETF RFC 3550 RTP: Транспортный протокол для приложений, работающих в реальном времени.
  • IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR)
  • IETF RFC 1890 RTP профиль для звуковых и видео конференций с Минимальным управлением.
  • IETF RFC 2508 Сжатие заголовков IP/UDP/RTP пакетов для низкоскоростных линий связи.
  • IETF RFC 3545 Расширенная компрессия RTP (CRTP) для линий связи с высокими задержками, большими потерями пакетов и частой повторной отправкой данных.

Ссылки по теме:

Оригинал: http://www.voip-info.org/wiki/view/RTP

Протокол RTP. Организация передачи трафика реального времени по сети Интернет. Мультимедиа

[1]

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

Протокол передачи видео- и аудиоинформации в реальном масштабе времени — RTP

Почему нужен RTP

В Интернет возможна потеря пакетов, изменение их порядка в процессе транспортировки, а также вариация времени доставки в достаточно широких пределах.

В приложениях реального времени (аудио- и видеоконференции, живое видео, удаленная диагностика в медицине, компьютерная телефония, игры, мониторинг в реальном времени и др.) отправитель генерирует поток данных с постоянной скоростью, а получатель (или получатели) должен предоставить эти данные приложению с той же самой скоростью.

Протокол транспортного уровня — TCP не подходит для приложений реального времени:

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

Для согласования требований приложений реального времени с возможностями Интернет был разработан транспортный протокол реального времени — RTP (Real-Time Transport Protocol).

Протокол RTP (RFC 1889 — A Transport Protocol for Real-Time Applications” H.

Schulzrinne, S. Casner, R. Frederick, V. Jacobson) обеспечивает в IP-сетях доставку адресатам аудио- и видеопотоков в масштабе реального времени. Согласно стеку рекомендаций H.323, в сетях с негарантированной полосой пропускания с целью минимизации задержек и максимального использования имеющейся полосы пропускания для передачи аудио- и видеопотоков, а также сигнализации RAS применяется протокол User Datagram Protocol (UDP). Этот протокол задействует механизм многоадресной рассылки (IP Multicast) для негарантированной доставки звука и видео определенному числу пользователей. Поверх IP Multicast работает RTP, который создает необходимые условия для нормального воспроизведения полученных потоков на абонентских терминалах.

Принципы построения протокола RTP

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

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

Реализацию функций RTP контролирует транспортный протокол управления передачей в режиме реального времени RTCP — Real-time Transport Control Protocol (RFC 1889). Он также отслеживает качество обслуживания и снабжает соответствующей информацией участников конференции. RTCP использует тот же самый базовый транспортный протокол, что и RTP (обычно UDP), но другой номер порта.

RTP работает поверх UDP и может поддерживать передачу данных в реальном времени между несколькими участниками RTP-сеанса.

RTCP выполняет несколько функций:

  1. Обеспечение и контроль качества услуг и обратная связь в случае перегрузки. Так как RTCP-пакеты являются многоадресными, все участники сеанса могут оценить, насколько хороши работа и прием других участников. Сообщения отправителя позволяют получателям оценить скорость данных и качество передачи. Сообщения получателей содержат информацию о проблемах, с которыми они сталкиваются, включая утерю пакетов и избыточную неравномерность передачи. Обратная связь с получателями важна также для диагностирования ошибок при распространении. Анализируя сообщения всех участников сеанса, администратор сети может определить, касается данная проблема одного участника или носит общий характер. Если приложение-отправитель приходит к выводу, что проблема характерна для системы в целом, например, по причине отказа одного из каналов связи, то оно может увеличить степень сжатия данных за счет снижения качества или вообще отказаться от передачи видео — это позволяет передавать данные по соединению низкой емкости.
  2. Идентификация отправителя. Пакеты RTCP содержат стандартное текстовое описание отправителя. Они предоставляют больше информации об отправителе пакетов данных, чем случайным образом выбранный идентификатор источника синхронизации. Кроме того, они помогают пользователю идентифицировать потоки, относящиеся к различным сеансам.
  3. Оценка размеров сеанса и масштабирование.

    Для обеспечения качества услуг и обратной связи с целью управления загруженностью, а также с целью идентификации отправителя, все участники периодически посылают пакеты RTCP. Частота передачи этих пакетов снижается с ростом числа участников. При небольшом числе участников один пакет RTCP посылается максимум каждые 5 секунд. RFC 1889 описывает алгоритм, согласно которому участники ограничивают частоту RTCP-пакетов в зависимости от общего числа участников. Цель состоит в том, чтобы трафик RTCP не превышал 5% от общего трафика сеанса.

При организации видеоконференции каждый участник должен иметь IP-адрес и две пары UDP-портов: для RTP и RTCP, так как звук и изображение передаются как два независимых потока. RTCP-пакеты посылаются независимо для каждой из этих двух сессий.

На уровне RTP не существует какой-либо взаимосвязи между аудио- и видео сессиями. Только RTCP-пакеты несут в себе одни и те же имена участников.

Определения

Пакет RTP. Информационный пакет, содержащий фиксированный заголовок. Один пакет транспортного нижнего уровня, например UDP, обычно содержит один RTP-пакет.

Поле данных RTP. Информация, пересылаемая в пакете RTP, например, фрагменты звука или сжатые видео данные.

Пакет RTCP. Управляющий пакет, содержащий фиксированный заголовок, сходный с RTP, за которым следуют структурные элементы, зависящие от типа RTCP-пакета. Обычно несколько RTCP-пакетов посылаются как составной RTCP-пакет, вложенный в дейтограмму нижележащего уровня.

Транспортный адрес. Комбинация сетевого адреса и порта, которая идентифицирует конечную точку канала (например, IP-адрес и UDP-порт). Пакеты следуют от транспортного адреса отправителя к транспортному адресу получателя.

Сессия RTP. Период с момента установления группой участников RTP-обмена до его окончания.

Источник синхронизации (SSRC — Synchronization SouRCe). Источник потока RTP-пакетов, определяется 32-битным числовым SSRC-идентификатором, который записывается в заголовок RTP-пакета и не зависит от сетевого адреса. Все пакеты от источника синхронизации содержат временную привязку и нумерацию. Эти данные используются принимающей стороной при воспроизведении. Источниками синхронизации могут служить источники первичного сигнала (микрофоны или видеокамеры), а также RTP-смесители. SSRC-идентификатор представляет собой случайное число, которое является уникальным для данной RTP-сессии. Если формируется несколько потоков в рамках одной RTP-сессии (например, от нескольких видеокамер), то каждый поток должен быть снабжен уникальным SSRC-идентификатором.

Информационный источник (CSRC — Contributing SouRCe). Источник потока RTP-пакетов, который вносит вклад в общий поток, формируемый RTP-смесителем. Смеситель вставляет список SSRC-идентификаторов, которые идентифицируют отдельные источники, в заголовок RTP-пакетов. Этот список называется CSRC-списком. Примером приложения может быть аудио-конференция, где смеситель отмечает всех говорящих, чей голос порождает исходящие пакеты. Это позволяет принимающей стороне идентифицировать говорящего, хотя все пакеты имеют один и тот же SSRC-идентификатор.

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

Кроме оконечных систем RTP поддерживает трансляторы и смесители, которые рассматриваются как промежуточные системы на уровне RTP.

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

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

Монитор. Приложение, которое получает RTCP-пакеты, посланные участниками RTP-сессии, в частности диагностические сообщения, производит оценку состояния связи, копит долгосрочную статистику обмена.

Заголовок RTP-пакета
Заголовок пакета RTP

Первые 12 октетов присутствуют во всех RTP-пакетах. Список CSRC-идентификаторов присутствует только тогда, когда пакет формируется смесителем.

V (2 бита) — поле версии протокола RTP. Текущая версия — вторая.

P (1 бит) — поле заполнения. Если Р=1, пакет содержит один или более дополнительных октетов-заполнителей в конце поля данных (заполнители не являются частью поля данных). Последний октет заполнителя содержит число октетов, которые должны игнорироваться. Заполнитель нужен при использовании некоторых алгоритмов шифрования при фиксированном размере блоков или при укладке нескольких RTP-пакетов в один UDP.

X(1 бит) поле расширения заголовка. Если Х=1, то за основным заголовком следует еще один дополнительный, используемый в экспериментальных расширениях RTP.

CC (CSRC count – число CSRC, 4 бита).

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

M (1 бит) поле маркера. Интерпретация маркера определяется профайлом.

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

PT (7 битов) — поле типа полезной нагрузки.

Идентифицирует тип полезной нагрузки и формат данных RTP-пакета, включая сжатие и шифрование данных и определяет интерпретацию поля данных приложением.

Порядковый номер пакета (Sequence Number, 16 битов). Каждый источник начинает нумеровать пакеты с произвольного номера, увеличиваемого затем на единицу с каждым посланным пакетом данных RTP. Это позволяет обнаружить потерю пакетов и определить порядок пакетов с одинаковой отметкой о времени. Несколько последовательных пакетов могут иметь одну и ту же отметку о времени, если логически они порождены в один и тот же момент, как, например, пакеты, принадлежащие к одному и тому же видеокадру.

Временная метка (Timestamp, 32 бита). Поле отметки о времени. Это поле содержит момент времени, в который первый октет данных полезной нагрузки был создан. Единицы, в которых время указывается в этом поле, зависят от типа полезной нагрузки. Значение определяется по локальным часам отправителя. Начальное значение временной метки является случайным. Несколько последовательных RTP-пакетов могут иметь идентичные временные метки, если логически они генерируются одновременно (например, относятся к одному и тому же видеокадру).

SSRC (Synchronization Source Identifier, 32 бита). Поле SSRC идентифицирует источник синхронизации. Этот идентификатор выбирается случайным образом, так чтобы в пределах одной RTP-сессии не было двух равных SSRC-кодов, и не зависит от сетевого адреса. Все приложения должны быть способны выявлять случаи равенства SSRC-кодов. Если отправитель изменяет свой транспортный адрес, он должен также сменить и SSRC-идентификатор.

CSRC-список (Contributing source Identifier, 32 бита). Список полей идентификаторов источников, «подмешанных» в основной поток, например, с помощью смесителя. Количество элементов в списке: от 0 до 15. Число идентификаторов задается полем CC. Примером может служить аудио-конференция, в RTP-пакеты которой собраны речи всех участников, каждый со своим CSRC — они-то и образуют список CSRC. При этом вся конференция имеет общий SSRC.

В протоколе RTP предусмотрен механизм расширений заголовка, который позволяет модифицировать заголовок и использовать приложения с новыми форматами поля данных.

Протокол RTCP, как и всякий управляющий протокол, значительно сложнее и по структуре, и по выполняемым функциям. Хотя основу протокола RTCP составляет RTP, он содержит множество дополнительных полей, с помощью которых он реализует свои функции.

Пример RTP сети с оконечными системами ES, смесителями MUX и трансляторами TRS

Оконечная система генерирует или воспринимает данные, посылаемые в виде RTP-пакетов. Алгоритмы работы отправителя и получателя RTP-пакетов описаны в RFC 1889.

Смеситель принимает потоки RTP-данных от одного или нескольких источников и формирует из них один общий поток. Так как объединяемые потоки не синхронизованы, смеситель производит синхронизацию потоков и формирует свою собственную временную шкалу для исходящего потока. Таким образом, все пакеты данных, переадресованные смесителем, будут помечены SSRC-идентификатором смесителя. Для того чтобы сохранить информацию об источниках исходных данных, смеситель должен внести SSRC-идентификаторы из заголовков входящих RTP-пакетов в список CSRC-идентификаторов формируемого исходящего пакета, а также должен включить свой собственный SSRC-идентификатор в CSRC-список для данного пакета.

Например, запись «M1:13(1,17)» обозначает пакет, отправленный смесителем MUX1, который идентифицируется случайным значением SSRC 13 и двумя CSRC-идентификаторами 1 и 17, скопированными с SSRC-идентификаторов пакетов оконечных систем ES1 и ES2

Транслятор переадресует RTP-пакеты, не изменяя их SSRC-идентификаторы. Некоторые типы трансляторов передают данные без изменений, другие кодируют данные и соответственно изменяют коды типа данных и временные метки.

В RTP-сессии могут быть задействованы несколько смесителей и трансляторов. Если два смесителя включены последовательно, как MUX2 и MUX3, то пакеты, полученные смесителем, могут быть уже объединены и включать CSRC-список со многими идентификаторами. Смеситель (MUX3) должен формировать CSRC-список для исходящих пакетов, используя CSRC-идентификаторы уже смешанных входных пакетов (выход MUX2) и SSRC-идентификаторы несмешанных входных пакетов, поступивших от ES9 (E:36). Это отмечено на рисунке для выходных пакетов смесителя MUX3 как M3:99(9,11,36).

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

Более подробное описание протоколов RTP и RTCP можно найти в RFC-1889

Мы предлагаем соединение станций Panasonic KX-TD816/1232/500 по приведенной ниже схеме.

Абонент 1ххх основной АТС для соединения с удаленной АТС снимает трубку, набирает код доступа к удаленной АТС (например 6), и внутренний № 2ххх удаленной АТС. Абонент 2ххх удаленной АТС для соединения с основной АТС снимает трубку, набирает код доступа к основной АТС (например тоже 6), и внутренний № 1ххх удаленной АТС.

При такой схеме возможно переключение вызова, поступившего в основную АТС на удаленную АТС и наоборот, а также использование с удаленной АТС внешних линий основной АТС.

Для реализации подобной схемы потребуются свободные внутренние аналоговые порты на основной АТС и свободные внешние аналоговые порты на удаленной АТС. Количество этих портов определяет число возможных одновременных соединений между двумя АТС. В зависимости от количества этих соединительных линий, выбирается емкость системы цифровой передачи. Она может быть одно-, двух-, четырех-, и восьмиканальной. Для организации передачи цифрового сигнала между станционной и абонентской частью системы уплотнения нужна выделенная линия (медная пара), имеющая сопротивление шлейфа не более 1200 Ом. Кроме этого потребуется плата прямого доступа DISA для удаленной АТС.

Соединение любых АТС, через Интернет/Интранет по технологии VoIP

Технология передачи речевой информации по сетям передачи данных, использующих протокол IP, называется IP-телефонией.

В настоящий момент в мире существует несколько вариантов реализации сетей IP-телефонии, основанных на трех основных протоколах:
 

  • Рекомендации Международного союза электросвязи (ITU-T) H.323
  • Предложения рабочей группы MMUSIC комитета IETF (Internet Engineering Task Force) по использовании протокола SIP (Session Initiation Protocol).

  • Сетевая архитектура, разработанная рабочей группой MEGACO комитета IETF и МСЭ (протокол Megaco/H.248).

Рекомендации H.323

Наибольшее распространение получил протокол обмена, предложенный Международным союзом электросвязи (ITU) в Рекомендации Н.323. Сети на базе семейства протоколов Н.323 ориентированы на интеграцию с телефонными сетями и представляют собой конвергентное решение по передаче голосового трафика телефонных сетей по сетям IP. В рекомендации H.323 предусмотрено использование протокола Q.931, широко применяемого в сетях ISDN, для процедуры установления соединений в сетях IP-телефонии. Для организации голосовых каналов используется протокол H.245, а передача трафика осуществляется с помощью протоколов RTP/RTCP/UDP. Протокол RAS, входящий в семейство протоколов Н.323, обеспечивает операторам связи высокий уровень контроля за использованием сетевых ресурсов, поддержку аутентификации пользователей и начисления платы за предоставленные услуги.

Преимущества:
 

  • Стандарт МСЭ H.323 обеспечивает гарантию совместимости оборудования.
  • H.323 — гарантия качества предоставляемых услуг, передачи речевой информации с высоким качеством и допустимой (управляемой — в случае применения в сетях Интранет) задержкой, благодаря использованию скоростных каналов ПД, механизмов QoS, развитости технологии компрессии речи на базе DSP.
  • Разнообразные варианты конфигурации и схемы включения благодарят гибкому и модульному ПО.

Шлюз IP-телефонии
 

Реализует передачу речевого (мультимедийного) графика, поступающего из сети с коммутацией каналов, по сетям с маршрутизацией пакетов IP посредством протокола Н.323. Основным функциональным назначением шлюза является преобразование речевой информации, поступающей со стороны ТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP; кодирование и упаковка речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование. Кроме того, шлюз конвертирует сигнальные сообщения систем сигнализации DSS1 и ОКС7 в сигнальные сообщения Н.323 (Q.931) и осуществляет обратное преобразование.

Samsung SMG-3200 — шлюз IP-телефонии для корпоративных сетей
 

SMG-3200 — IP шлюз, реализующий протокол H.323 v2 и v3 технологии голос поверх IP (VoIP), обеспечивает передачу речевой информации в реальном масштабе времени по сетям IP, т.е. маршрутизирует потоки информации между сетями с коммутацией каналов (ТФОП, ведомственная сеть) и сетью с пакетной коммутацией (Ethernet).

Шлюз SMG-3200 может использоваться в среде LAN предприятия или оператора как самостоятельно, так и во взаимодействии с ПО управления (Gatekeper, Call manager).

Кроме обеспечения интеграции офисной или учрежденческой АТС с локальной сетью передачи данных и возможности перенаправления речевого и факсимильного трафика в сеть Интранет или Интернет, на базе системы могут быть реализованы онлайновые приложения по обработке вызовов и операторские центры по работе с клиентами (Call Center, CRM), а также услуги e commerce с возможностью получения голосовых консультаций в режиме on line. Оборудование может быть установлено в сетях компаний, заинтересованных в организации голосовых "горячих линий", служб технической поддержки, диалоговых справочных служб и т.д.

Шлюз Samsung SMG-3200 — простое и эффективное решение по организации телефонной связи на ведомственной сети передачи данных

SMG-3200 позволяет пользователям устанавливать телефонные соединения и передавать факсы по внутренней сети (Интранет), т. е. по внутриведомственной сети с протоколом IP и по аналогичным сетям операторов. SMG-3200 ориентирован на компании с расположенными в разных частях страны или за рубежом офисами, заинтересованные в недорогих и эффективных решениях, позволяющих снизить расходы на телефонные переговоры за счет более эффективного использования собственной сети ПД или Интернет, при этом не отказываясь от привычных и удобных телефонных функций учрежденческих АТС.

SMG-3200 — хорошо масштабируемая система (от 8 до 32 одновременных голосовых каналов), оснащенная картами разнообразных сетевых интерфейсов. SMG-3200 может подключается к учрежденческим АТС по линии Е1 (ISDN PRI) с сигнализацией DSS1, а к локальной сети — через интерфейс 10/100Base-T Ethernet. Для всех соединений шлюз SMG-3200 выполняет сжатие данных, эхоподавление и передачу многочастотных сигналов (DTMF), например, для донабора номера (вызов внутренних абонентов, получение справок и т.д), распознавания и передачи телефаксов, других функций.

Проведенные испытания на сетях ряда Московских операторов подтверждают совместимость шлюза SMG-3200 с оборудованием Cisco (1750, 26хх, 36хх, AS5300), Dialogic, VocalTec (шлюзы).

Варианты применений шлюза IP-телефонии Samsung SMG-3200

Объединение удаленных офисов через Internet/Intranet
 

  • SMG-3200 — решение для организации телефонной связи в ведомственной сети передачи данных.
  • На базе шлюза IP-телефонии SMG-3200 возможна организация междугородной (дальней) телефонной связи между офисами компаний по ведомственной сети IP или Интернет.

На рисунках показаны варианты применения шлюза SMG-3200.

1. Вариант подключения АТС потоком Е1 (ISDN PRI)

2. Вариант подключения АТС по аналоговым линиям (FXO/FXS)

3. Вариант подключения офисов с разнотипным оборудованием (в том числе небольших офисов, не имеющих АТС)

Шлюз IP-телефонии SMG-3200 позволяет осуществить эволюционное (поэтапное) движение к мультисервисным сетям следующего поколения и обеспечить следующие преимущества:
 

  • Сохранение инвестиций, за счет использования и расширения существующей инфраструктуры (локальная сеть ПД и телефонная сеть). Благодаря, применению шлюзов VoIP эти инфраструктуры могут объединяться, реализуя новые виды сервиса.
  • Эффективное использование имеющихся сетей с протоколом IP.
  • Значительное снижение эксплуатационных расходов (сокращение полосы пропускания) и достижение при этом сопоставимого с традиционными сетями качества передачи речи.
  • Постепенную конвергенцию различных транспортных технологий передачи мультимедийной информации путем шлюзования мультисервисных сетей доступа и сетей местной телефонной связи с магистральными сетями пакетной передачи данных.
  • Потенциальное сокращение расходов, благодаря использованию единой инфраструктуры для служб передачи речи, видео и данных.
  • Снижение тарифов и расходов на междугородную и международную связь.
  • Для обеспечения привычного доступа к современным коммуникационным сетям и через сети с протоколом IP в случае перегрузки или отказа сети IP новые соединения автоматически переводятся шлюзом SMG-3200 в сеть ТФОП.
  • Простоту установки аппаратуры и программного обеспечения (Plug&Play).
  • Совместимость с учрежденческими и офисными АТС других производителей.

Для реализации этих преимуществ, шлюз SMG-3200 обеспечивает:
 

  • Набор интерфейсов с ТФОП и протоколов сигнализации с планируемым расширением перечня поддерживаемых протоколов.
  • Высокую степень готовности.
  • Высокую масштабируемость (от 8 до 32 голосовых каналов в одном устройстве) и возможность установки нескольких шлюзов в одну стойку.
  • Возможность дистанционного обновления программного обеспечения с учетом появления новых версий протоколов H.323 и протокола SIP.

Материал взят с сайта:


Главная > Технологии > АТС

VoIP кодеки. Сравнение кодеков IP телефонии

2012. Skype переходит на новый кодек Opus. Trueconf тоже


Skype в ближайшее время перейдет на использование нового аудиокодека Opus, ориентированного для работы в беспроводных сетях. Главное техническое достоинство Opus заключается в найденном балансе между компрессией аудиосигнала и его качеством, что актуально в условиях передачи в сетях мобильных операторов. Кодек использует гибкий алгоритм адаптации в случае изменения пропускной способности канала — например, при переходе с 3G-сигнала на Wi-Fi соединение — и, в дальнейшем, может обеспечить разговор в CD-качестве.

Также применены специальные алгоритмы для борьбы с потерей пакетов при ограниченных возможностях беспроводной сети. Кодек является бесплатным и может быть свободно лицензирован сторонними разработчиками для использования в VoIP-приложениях. Согласна со Skype и отечественная компания Trueconf, которая разрабатывает системы видесвязи. Она провела исследования и по результатам реализовала поддержку Opus в своих продуктах. На картинке — график сравнения качества Opus с другими кодеками.

2010. Mango-Office получил поддержку кодека G.729


В сервисе виртуальной АТС Mango-Office реализована поддержка речевого кодека G.729, применяемого в SIP-телефонии и позволяющего абоненту получать качественные услуги связи  при наличии даже узкополосного доступа к Интернету. По сравнению с G.711, кодек G.729 требует значительно меньшей полосы пропускания, а значит, позволяет использовать имеющийся у компании Интернет-канал  с большей эффективностью. Кроме того, G.729 позволяет получать высокое  качество связи для удаленных и мобильных сотрудников, работающих через беспроводные сети доступа (Wi-Fi, WiMax и т.д.) с использованием SIP телефонов, софтфонов, ноутбуков или КПК.

2009. Telephone — новый SIP-клиент под Mac


Telephone — это новая VoIP-программа для Mac, которая имеет простой и умный  интерфейс (в отличии от большинства софтфонов, которые имитируют настоящие кнопочные телефоны на экране). При вводе имени или номера телефона осуществляется поиск по общесистемной адресной книге (которая, кстати, может синхронизироваться штатными средствами между несколькими компьютерами и Айфоном). Виден результат поиска. Поддерживаемые кодеки: семейство G.711 (PCMA, PCMU), Speex/8000 (narrowband), Speex/16000 (wideband), Speex/32000 (ultra-wideband), iLBC, GSM, L16. Работает отправка DTMF, в наличии русский и английский интерфейсы. Требования к системе: Mac OS X 10.5 Leopard на платформе Intel.

2006.

VoIP-кодеки GIPS внедряются на мобильные устройства

Движок GIPS VoiceEngine производства Global IP Sound теперь будет использоваться не только в программе Skype для ПК, но и в мобильных телефонах, адаптерах для аналоговых телефонов и других устройствах, работающих по VoIP-протоколу. Об этом было подписано соответствующее соглашение между Global IP Sound Inc. и компанией Skype. Технология GIPS VoiceEngine используется в программе Skype начиная с лета 2003 г. Она включает в себя кодеки и другие компоненты, которые эффективно устраняют эхо, дрожание и прочие искажения, возникающие при передаче звука через интернет. Расширение лицензии свидетельствует о том, что компания Skype намерена выводить свой бизнес за пределы персональных компьютеров. Сервис VoIP-телефонии становится все более доступен для пользователей мобильных телефонов, которые подключаются в интернет через хот-споты WiFi или через специальные VoIP-гейты.

Добавить комментарий

Закрыть меню