Принцип работы VoIP (Voice over Internet Protocol)

Рис. 6 Сеть VoIP без тандемного кодирования

    Одно  из преимуществ сети IP заметно на [рис. 6]: для установки соединения между двумя РВХ необязательно арендовать канал связи у телефонной компании. Если два пункта соединены сетью данных, то передача данных VoIP между ними вполне возможна.

    Система номеров центрального РВХ доступна каждому из маршрутизаторов VoIP. Это позволяет каждому устройству VoIP принимать решения о маршрутизации вызовов и избежать необходимости в объединяющих линиях. Такое изменение особенно полезно тем, что позволяет избавиться от бесполезных циклов компрессии-декомпрессии.

2.2 Транспортные протоколы

    Характеристики  протокола Интернета (Internet Protocol — IP) определяют два основных транспортных механизма — протокол пользовательских дейтаграмм (User Datagram Protocol — UDP) и протокол управления передачей (Transmission Control Protocol — TCP). Как правило, когда необходимо надежное соединение, имеет смысл использовать протокол TCP, а если необходима простота, но необязательна надежность — протокол UDP.

    В связи с "чувствительным" ко времени  характером голосового трафика для  передачи голоса логично было выбрать протокол UDP/IP. Однако передача "пакет за пакетом", характерная для протокола UDP, обеспечивает недостаточно подробную информацию, чем необходимо. Для передачи в реальном масштабе времени, а также для передачи трафика, чувствительного к задержке, Инженерная группа по решению конкретных задач Интернета (Internet Engineering Task Force — IETF) выбрала протокол RTP. Данные VoIP передаются поверх протокола RTP, который, в свою  очередь, передается поверх протокола UDP. Следовательно, пакет VoIP передается с заголовком пакета RTP/UDP/IP.

2.2.1 Протокол RTP

    Протокол RTP (Real-Time Transport Protocol — протокол передани данных в реальном масштабе времени) — это стандарт для передачи чувствительного  к задержке трафика через пакетные сети. Как упоминалось раньше, данные протокола RTP передаются поверх протокола UDP и IP. Протокол RTP предоставляет принимающей станции информацию, отсутствующую в не требующих установления соединения потоках UDP/IP. В [табл. 2] показаны два важнейших бита информации - порядковый номер (sequence number) и временная метка (timestamp). Протокол RTP использует информацию о последовательности пакетов, чтобы определить, по порядку ли они прибывают, а информация о временных метках нужна для определения времени "путешествия" пакета от отправителя до получателя (т.е. дребезга).

Табл. 2 Заголовок транспортного протокола реального времени 

    При необходимости, протокол RTP можно использовать как для передачи мультимедийных данных, так и для интерактивных служб вроде телефонии Интернета. Протокол RTP, впоследствии названный протоколом контроля RTP (RTP Control Protocol — RTCP), имеет две составляющие — часть данных (data part) и часть контроля (control part).

    Часть данных протокола RTP — это тонкий протокол, который обеспечивает поддержку для приложений реального времени, таких как непрерывная передающая среда (например, аудио и видео), включая восстановление синхронизации (timing reconstruction), обнаружение потерь и идентификацию содержимого (content identification).

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

    В документе RFC 36II определенно еще  одно новое предложение: протокол контроля RTP с дополнительными отчетами (RTP Control Protocol Extended Reports — RTCP XR), который предоставляет богатый набор данных для управления VoIP. Данные для этих дополнительных отчетов могут быть предоставлены такой технологией, как VQmon, встроенной в телефоны VoIP или шлюзы. Во время вызова эти данные должны периодически отсылаться, чтобы обеспечить в реальном времени обратную связь по качеству речи. Созданные отчеты представляют собой очень полезный набор метрических данных VoIP, включая информацию о потере сетевых пакетов, о задержке пакетов RTP и т.д.

    Для трафика реального времени протокол RTP — весьма важное и полезное приобретение, но существуют и некоторые недостатки. Заголовки IP/RTP/UDP составляют 20, 8 и 12 байт соответственно. В целом получается уже 40-байтовый заголовок, который вдвое больше, чем полезная нагрузка при использовании G.729 с двумя голосовыми выборками (20 мс). Столь большой заголовок можно сжать до 2-4 байт, используя сжатие заголовка RTP (RTP Header Compression — CRTP).

2.2.2 Надежный пользовательский протокол передачи данных

    Надежный  пользовательский протокол передани данных (Reliable User Data Protocol— RUDP) придает дополнительную надежность протоколу UDP без установления соединения. Протокол RUDP обеспечивает надежность, не нуждаясь в ориентированном на соединение протоколе, вроде TCP. Метод, на котором основан протокол RUDP, заключается в рассылке множества копий пакета, а принимающая станция имеет возможность отказаться от ненужных или избыточных пакетов. Такой механизм существенно повышает вероятность того, что один из пакетов отправителя все-таки дойдет до получателя.

    Этот  механизм известен также как предварительное  исправление ошибок (Forward Error Correction— FEC). Существует несколько реализаций FEC, отличающихся использованием полосы пропускания (удвоение или утроение объема используемой полосы пропускания).

2.3 Проектирование системы номеров

    Наибольшие  затруднения при проектировании сети корпоративной телефонии (Enterprise Telephony — ЕТ) вызывает система номеров (dial plan). Причиной является комплекс проблем интеграции несоразмерных сетей. Большинство таких несоразмерных сетей было разработано без учета возможности интеграции.

    Хорошим примером соединения несоразмерных  сетей является объединение двух компаний. При таком развитии событий, следует соединить сети передачи данных компаний (IP-адресация, бухгалтерские приложения и инвентарная база данных). Вероятность того, что обе компании использовали одинаковые методологии при реализации своих сетей данных, очень мала, поэтому, скорее всего, возникнут определенные проблемы.

    Такие же проблемы могут возникнуть и в  телефонных сетях. При объединении  двух компаний их телефонные системы (голосовая  почта, бухгалтерия, дополнительные возможности  и системы набора номеров) могут оказаться несовместимыми.

    Подобные  проблемы могут возникнуть у компании при приобретении корпоративной  системы набора номеров. Рассмотрим компанию X. Последние три года для  компании X обернулись стремительным ростом, и теперь она управляет 30 офисами во всем мире со штаб-квартирой в Рубцовске. В настоящее время компания X звонит на все 29 отдаленных офиса через сеть PSTN. Теперь она хочет упростить систему набора для всех отдаленных офисов, чтобы улучшить и упорядочить коммуникации между служащими.

    Ныне  штаб-квартира компании X владеет большой системой РВХ, а в отдаленных офисах системы РВХ поменьше. Для этой компании возможны следующие варианты:

• Приобрести арендованные каналы между штаб-квартирой и всеми отдаленными офисами.
• Приобрести у телефонной компании виртуальную закрытую сеть (Virtual Private Network — VPN) и звонить используя код доступа куда угодно.
• Воспользоваться существующей инфраструктурой данных и передавать голос, используя сеть данных.

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

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

• Перспективы развития.
• Цена арендованных каналов или VPN.
• Цена дополнительного оборудования для голосовых пакетов.
• Совпадение номеров (когда один телефонный номер принадлежит нескольким абонентам).
• Последовательности вызова (схема вызова каждого абонента).
• Бизнес-время (время дня, в которое ожидается наибольшее количество вызовов).

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

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

    Таким образом, у компании X будет трехзначный код офиса и четыре цифры для абонентской линии. Такое решение было принято потому, что в компании вряд ли будет больше 999 филиалов.

2.3.1 Порядок вызова у конечной коммутационной станции и IP-телефонии

    Чтобы упростить объяснение последовательности вызова через TDM или конечную коммутационную станцию и сеть IP, рассмотрим в примеры звонка соседу по сети PSTN и Интернету. На [рис. 7] приведен пример последовательности вызова через современную сеть PSTN.

Рис. 7 Звонок соседу через современную PSTN

     В этом примере Боб звонит своей  соседке Джудит. Они оба абоненты локальной конечной коммутационной станции, а следовательно, сеть SS7 им не нужна. Ниже приведена последовательность действий.

1. Боб снимает телефонную трубку.
2. Локальная конечная коммутационная станция посылает Бобу сигнал ответа АТС (гудок).
3. Боб набирает семизначный номер телефона Джудит.
4. Конечная коммутационная станция получает и анализирует семизначный номер, чтобы выявить получателя телефонного вызова. О том, что кто-то звонит из дома Боба, конечная коммутационная станция узнает через определенный порт, который был выделен Бобу.
5. Коммутатор анализирует вызываемый семизначный номер, чтобы определить, является ли номер локальным (т.е. может ли его обслужить коммутатор).
6. Коммутатор выясняет абонентскую линию Джудит.
7. Затем конечная коммутационная станция уведомляет канал Джудит звонком на ее телефон.
8. Бобу на голосовой канал возвращается длинный гудок, который посылает конечная коммутационная станция. Боб слышит гудок, и знает, что телефон Джудит звонит. (Звонок телефона Джудит и гудки, которые слышит Боб, никак не синхронизированы.)
9. Джудит поднимает телефонную трубку.
10. Конечная коммутационная станция устанавливает голосовой канал между Бобом и Джудит. Это дуплексный канал DS-0 (Digital Service, Level 0 — цифровой сервис, уровень 0) на 64 Кбит/с через центральную коммутационную станцию, вполне допускающий передачу голоса.

    Если  телефон Джудит обслуживает не та же конечная коммутационная станция, то станция Боба попытается по своим  таблицам маршрутизации определить, как соединить этот вызов. Чтобы при вызове Джудит полностью определить номер согласно спецификации Е.164, она может добавить префиксные цифры.