Публикация посвященная IP-телефонии, для читателя обладающего минимальными техническим знаниями. Материал содержит краткую историю возникновения IP-телефонии, описание основных протоколов и технологии VoIP включающее описание и принцип работы сигнального протокола SIP, протокола описания медиасессии SDP и протокол реального времени RTP, технологию адресной трансляции NAT, в конце статьи рассматривается распространенное терминальное оборудование.

Автор: Артем Володин

1.Введение
2.Протоколы VoIP, плюсы, минусы, области применения. Сравнение с протоколами сетей традиционной телефонной связи
3.Инфраструктура сетей связи, использующих телефонию, Voice VLAN и QoS.
4.Session Initiation Protocol(SIP)
5.Session Description Protocol (SDP)
6.RTP: Real-time Transport Protocol
7.NAT: Network Address Translation
8.Обзор наиболее часто используемого оборудования
9.Приложение 1
10.Приложение 2
11.Приложение 3

Введение
В общем понимании, IP-телефония — это передача голосовой информации по сетям с коммутацией пакетов. С развитием технологий передачи данных, качества каналов связи и увеличением скорости, а равно и с удешевлением каналов связи в целом, появилась возможность передавать голосовую информацию дешевле, чем по ТФоП (телефонным сетям общего пользования). Первые упоминания о возможности передачи голоса по сетям пакетной передачи данных появились в труде американца Данни Кохэна — Network Voice Protocol, где он размышлял о передаче голоса через американскую военную сеть Arpanet в 1973 году. Однако, первые рабочие версии протоколов для осуществления аудиовызовов по сетям передачи данных появились только в начале 1990-х годов, но, так как в то время качество каналов передачи данных еще оставляло желать лучшего, качество самой голосовой связи было соответствующим. Ведущие производители телекоммуникационного оборудования Nortell, Cisco, Avaya, все же, увидели потенциал новой технологии и начали активно инвестировать в развитие Voice-over-IP.

Первые массовые внедрения услуг на базе IP-телефонии — это всем известный карточный доступ для звонков на междугородние и международные направления. С того времени появилось мнение, что IP-телефония — это дешево и «как-то работает». Стоимость вызовов была действительно намного ниже традиционных каналов телефонной связи, что и привлекло огромное количество потребителей услуги и, одновременно, показало реальный спрос на услуги связи, что, в конечном счете, привело к быстрому росту популярности IP-телефонии, вкупе с мощным ростом скоростей в сети Интернет и, в целом, многократное улучшение качества каналов связи — IP-телефония на данный момент сильно опережает по темпам роста своего «старшего брата».

Протоколы VoIP, плюсы, минусы, области применения. Сравнение с протоколами сетей традиционной телефонной связи.
Протоколов, позволяющих сделать (или принять) привычный для пользователя телефонный вызов довольно много, мы рассмотрим один из них подробно, и кратко о нескольких.В общем и целом, протоколом IP-телефонии, как правило, называют протокол сигнализации, то есть — протокол обмена информацией о звонке, без медиаданных. Первым рабочим протоколом VoIP был H.323, первые спецификации которого были приняты ITU-T (International Telecommunication Union – Telecommunication sector, Международный союз телекоммуникаций) в 1990-м году. Несмотря на то, что H.323 — это целый стек протоколов, нередко, можно встретить упоминание термина H.323, как частного случая сигнализации VoIP. В состав комплекса оборудования, работающего с протоколом H.323 входит терминальное устройство — шлюз, IP-телефон или даже программный телефон на компьютере, и привратник (gatekeeper) — сервер или, правильнее, центр обработки и распределения вызовов. Привратником может выступать как просто транзитная АТС для маршрутизации вызовов, например, из ТфоП в VoIP, так и сервер балансировки нагрузки между терминальными устройствами. Несмотря на то, что протокол довольно устарел, он до сих пользуется довольно большим спросом, особенно у известных производителей сетевого оборудования, Avaya, к примеру, до сих пор предпочитает H.323, хотя в последних версиях станций IP-Office заметно изменение приоритетов в пользу SIP. Любой коммерческий продукт, связанный с IP-телефонией, будь то учрежденческая АТС от производителей традиционных АТС — Panasonic, Samsung, NEC, или VoIP АТС Avaya или Cisco, если у такой АТС есть поддержка VoIP, то в 99% случаев протокол H.323 будет поддерживаться. В некоторых случаях производитель оборудования разрабатывает свой протокол для VoIP, и оставляет его закрытым (проприетарным ПО). Самый распространенный такой протокол — SCCP (Skinny Client Control Protocol) от компании Cisco. Изначально, протокол был разработан компанией Selsius Systems, но в 1998-м году компания Cisco поглотила Selsius Systems, и сделала этот протокол основным протоколом взаимодействия терминальных устройств собственного производства (IP-телефоны и ATA) с собственной УАТС Cisco Unified Communications Manager, в прошлом Cisco Call Manager, IP-телефоны в офисе Компании работают по SCCP. Так же свой закрытый протокол имеет, к примеру, всем известный Skype. Реверс-инжиниринг протокола программистами-энтузиастами показал, что сигнализация крайне похожа на SIP, но особенностью протокола стало создание целой сети из узлов и центров маршрутизации (supernodes) по технологиям peer-to-peer, которая в последствии получила развитие в протоколе Bittorrent. Центрами маршрутизации являются сервера компании Microsoft, когда как узлами (nodes) могут выступать (и выступают) компьютеры пользователей. Протоколом определяется оптимальный «маршрут» через центры маршрутизации от инициатора к получателю, и на всех узлах резервируется полоса пропускания для вызова. До покупки Skype компанией Microsoft узлами supernodes выступали компьютеры пользователей с внешними адресами (не за NAT). В общем, если вы случайно увидите сетевую активность процесса Skype, но вы в этот момент никому не звоните — будьте уверены, через ваш компьютер смаршрутизирован чей-то вызов. Однако, такой случай сейчас маловероятен, и практически все вызовы транслируются через supernodes.
Компания Digium, первоначальный разработчик программного комплекса Asterisk, вместе с IP-АТС разработала свой протокол VoIP — IAX (Inter-Asterisk Exchange), и сделала его открытым. Для протокола даже написаны рекомендации RFC5456, однако, большого распространения, на мой взгляд, протокол пока не получил. Особенность протокола в том, что есть возможность инкапсуляции нескольких медиа-сессий в один поток данных, подробнее в разделе Real-time Transport Protocol.
Говоря о протоколах VoIP и в попытке сравнить их с протоколами традиционной телефонии можно сказать, что, в плане установления вызова между двумя абонентами, каких-либо принципиальных технологический различий нет. Вся разница только в инфраструктуре и возможной емкости одновременных вызовов. За счет того, что сети передачи данных сейчас на уровне абонента вплотную подошли к уровню 1Гбит/сек в домохозяйство (квартиру), а подключения на скорости 100Мбит/сек присутствуют уже несколько лет, и качество этих каналов высокое, а отказоустойчивость приближается к уровню «пять девяток» 99.999% времени в рабочем состоянии, то основное преимущество IP-телефонии заключается сейчас в дешевой инфраструктуре. Если для сетей традиционной телефонии необходимо прокладывать отдельные провода, строить отдельную кабельную инфраструктуру, использовать специфичное оборудование SDH, PDH и прочих устройств технологий разделения времени Time-Division Multiplexing (TDM), VoIP работает по тем же сетям, вместе с Интернет и IP-телевидением. И, наконец, протокол, о котором мы будем говорить максимально подробно, и который получил наиболее широкое распространение на данный момент — это SIP, Session Initiation Protocol, или протокол инициации сессий. Протокол был разработан двумя инженерами в 1996 году и впервые стандартизован в рекомендациях RFC2543 в 1999. На данный момент повсеместно используется переработанная и дополненная версия рекомендаций RFC3261, опубликованная в 2002-м. В сети IP-телефонии нашей компании для абонентов используется только SIP. Так как для нас это основной протокол, с которым ведется работа, ниже рассмотрим его детальнее. Сравнивая информационное содержание протоколов сигнализации, можно сказать, что, например, H.323 с точки зрения анализа вызова практически идентичен самой распространенной сигнализации канала Е1 — DSS-1 (Digital Subscriber Signaling 1), так как именно сигнальные сообщения реализованы на одном стандарте — Q.931, крайне похож на Q.931 и проприетарный SCCP. Содержание таких сигнальных сообщений — флаги в определенной последовательности и области данных для номеров абонентов. Напротив, протокол SIP был разработан с оглядкой на HTTP, и имеет текстовую составляющую, и очень удобный в плане чтения и анализа. Протокол SIP получил развитие в еще двух протоколах SIP-T и PJSIP. SIP-T это вариация протокола SIP с инкапсулированными в сообщения данными протокола SS7 (Signaling system 7, ОКС-7 общеканальная сигнализация 7), который является основным протоколом сигнализации в магистральных межоператорских соединениях. Вариация PJSIP, как указывается на сайте разработчика – это полнофункциональная реализация SIP и имплементация улучшений по работе с мультимедиа интерфейсами приложениями и NAT. Лицензирование как open source.

 Инфраструктура сетей связи, использующих телефонию, Voice VLAN и QoS.
Современные сети передачи данных обслуживают трафик абсолютно разного характера — от простого просмотра веб-страниц по http, до передачи ТВ сигнала по IP Multicast. В некоторых, довольно частых, случаях, может оказаться, что какой-то сегмент сети полностью загружен, то будет наблюдаться деградация качества сервисов, использующих данный канал — веб страницы будут загружаться намного медленнее из-за ожидания CRC по TCP, а в IPTV будет «рассыпаться» картинка на «артефакты». С телефонией будут похожие признаки (подробнее в разделе RTP). Чтобы этого избежать, в VoIP рекомендуется использовать механизмы ToS/QoS. При возникновении «бутылочного горлышка», когда физическая среда не успевает обработать все tcp/ip пакеты, создается очередь с общим правилом FIFO (First in — first out), при переполнении буфера этой очереди коммутатор или маршрутизатор просто сбросит пакет (drop), и он будет утерян. Для выделения приоритета определенным сервисам используется алгоритм ToS (Type of Service), где пакет несет в себе метку и том, какому из сервисов он принадлежит, и, если какой-либо из сервисов на маршрутизаторе/коммутаторе имеет приоритет, то такой пакет сортируется в начало очереди, или в соответствие со приоритетом — VoIP в самое начало, http посередине, torrent/ftp — в конец.

Схема 1. Сетевой дизайн офисной ЛВС

Говоря о «канонической» сети передачи данных, по принципам которой, в том числе, построена офисная телефонная сеть, то, в основном, используют отдельный VLAN для VoIP, чтобы не замешивать L3 (Layer 3 OSI, уровень маршрутизации) адресацию с компьютерами в сети и для безопасности телефонных соединений. И L2 (Layer 2 OSI, уровень коммутации) метки QoS, прописанные как на коммутаторах доступа, так и на IP-телефонах, показывая, что трафик от/к телефонному терминалу должен быть приоритезирован перед всем остальным трафиком ЛВС. В общем смысле, телефонная сеть должна быть как можно более изолирована от передачи всех остальных данных и должна быть максимально приоритезирована, для наибольшей вероятности доставки пакетов между терминалами.

Session Initiation Protocol(SIP)
Основной идеей, при разработке протокола, была задача, чтобы протокол мог использоваться в широком смысле слова «для установления сеанса связи» между двумя пользователями в сети. Причем истинная цель данного сеанса не обязательно телефонный звонок, это может быть, как передача мгновенного сообщения, так и передача видеосигнала или даже простой трансфер файла. Дополнительно, были задачи упрощения анализа и диагностики проблем, связанных с использованием протокола. Если для H.323 был в основу взят телефонный Q.931 (DSS-1), то сигнальные сообщения SIP были частично скопированы из HTTP. В итоге получился способ связать двух абонентов какого-либо сервиса с очевидными преимуществами

• Сообщения о начале, установлении, изменении и завершении сеанса являются простыми текстовыми сообщениями, которые легко читаются
• Идентификаторы абонентов могут быть произвольным набором символов формата URI (uniform resource identificator) — в общем виде, как e-mail
• Методы аутентификации абонента по паролю аналогичны http (двухфакторная аутентификация с nonce), и аналогичные методы SSL/TLS при необходимости шифрования трафика
• Открытость протокола, возможность использования на оборудовании любого производителя без лицензионных отчислений

Благодаря этим качествам SIP получил, на данный момент, самое широкое распространение в телефонной отрасли. Рассмотрим базовые сценарии установки сеанса связи между абонентами (далее UAC — user agent client) с участием серверов обработки запросов (UAS — user agent server) из рекомендаций RFC3261.

Схема 2. Установка сессии связи SIP (RFC3261)

Абонент Alice (абонент А) пытается установить связь с абонентом Bob (абонент Б).

• F1 — абонент А посылает сообщение SIP INVITE своему серверу обработки с параметрами From (от кого) вида ‘From: «Alice» <sip:alice@user.domain>’ и To (кому) вида ‘To: «Bob» <sip:bob@anotheruser.domain>’; сервер абонента А, получив данный запрос, определит из поля To местонахождение абонента Б. В сообщении так же обязательно должен присутствовать параметр Contact <sip:alice@ip.address.user.terminal:port>, описывающий IP-адрес и порт, который готов к взаимодействию. Согласно RFC ответные SIP сообщения всегда должны высылаться на ip:port из параметра Contact.
• F2 — после определения вызов будет передан на Bob’s UAS тем же сообщением SIP INVITE, а абоненту А –>
• F3 — будет возвращено сообщение SIP 100 Trying. Наличие сообщения Trying, как правило, означает, что UAS/UAC имеют информацию о том, как обработать вызов, иначе, вместо сообщения Trying сразу передается код отбоя неуспешного вызова.
• F4 — UAS абонента Б опознал, что вызов пришел к его абоненту, отправляет SIP INVITE непосредственно на терминальное устройство — IP-телефон, программный телефон, аналоговый шлюз и т. д.
• F5 — отправив запрос на терминал абонента Б, UAS абонента Б возвращает Trying на UAS абонента А, т. к. рекомендациями предусмотрен таймаут ожидания Trying после чего-либо вызов будет перенаправлен через другие UAS, либо будет завершен с соответствующим кодом отбоя
• F6 — терминальное устройство сообщает UAS абонента Б о том, что оно приняло вызов, и извещает пользователя о входящем сеансе связи (звенит телефон). Сообщение 180 Ringing, как правило, используется при полноценном звонке SIP на SIP, когда все устройства, участвующие в вызове, используют SIP, чаще встречается сообщение 183 Session Progress, означающее начало передачи медиа данных до поднятия трубки (обычные гудки, мелодии «замени гудок», автоинформаторы «абонент временно недоступен» и т. д.), подробнее в SDP
• F7 и F8 — Сообщение 180 Ringing доставляется до UAS абонента А, и, в конечном итоге доставляется абоненту А, звонящий теперь понимает, что сеанс связи между терминалами установлен успешно, и надо ждать ответа абонента Б и начала передачи пользовательских данных.
• F9 (затем F10, F11) — абонент Б принял сеанс связи (поднял трубку), и начал передачу пользовательской информации — медиа, файлов, текстовых сообщений, смс и т. д. Сообщение SIP 200 OK доставляется от терминала к UAS абонента Б, затем UAS абонента А, затем самому абоненту А. В данном примере используется метод «спрямления» сетевого трафика, когда сообщение SIP 200 OK содержит указание о том, что медиа (данные) и все последующие SIP сообщения надо слать напрямую абоненту Б. Однако, на деле это почти никогда не выполняется и весь обмен трафиком проксируется через все UAS на пути сеанса связи.
• F12 — Абонент А выслал абоненту Б (напрямую) подтверждение, что установка сеанса связи успешна.

Media session — прямой обмен пользовательскими данными, текст, аудио, видео, прочая произвольная пользовательская информация.

• F13 — абонент Б посылает сообщение SIP BYE с информацией о том, что сеанс связи окончен и завершает передачу пользовательских данных.
• F14 — абонент А высылает обратно сообщение с подтверждением. И завершает передачу пользовательских данных.

Пример полного обмена SIP в Приложении 1.
Соединение UAS абонента А и UAS абонента Б из данного примера — VoIP-транк. Когда две встречные АТС «опознают» друг друга по IP-адресам и/или по URI абонентов. Как правило, такие подключения типа «транк» (англ. Trunk — магистраль) обеспечивают транзитные телефонные каналы между операторскими большими АТС или между операторской и клиентской АТС. Этот пример описывает сеанс связи SIP в самом общем виде. Для точно такой работы терминальных устройств необходимо их присутствие в маршрутизируемой области адресного пространства, т. е. без NAT. В реальных условиях, конечно, такое практически невозможно. Рассмотрим метод регистрации абонента UAC на сервере регистрации UAS. Сервер регистрации может быть, как отдельной сущностью, так и в составе комплекса серверного ПО для обработки запросов SIP. Для упрощения будем считать, что это все один сервер.

Схема 3. Регистрация абонента методом http-digest

Здесь показан обмен данными между UAC и UAS в части регистрации абонента на сервере с двухфакторной авторизацией. Первым сообщением UAS запрашивает регистрацию на UAS, отправляя внутри первого сообщения REGISTER только свой идентификатор для регистрации (как правило, это корректный URI). Сервер, получив такой запрос, определяет абонента и формирует ответ 401 Unauthorized, который содержит точные данные о методе регистрации, такие как, например, realm, в котором должен регистрироваться абонент, а так же обязательный параметр nonce, который участвует в процессе шифрования пароля. Метод называется Digest access authentication, работает аналогично HTTP-авторизации. Метод подробно описан в RFC2069, мы же подробно его рассматривать не будем. Достаточно считать, что серверный ответ 401 Unauthorized — инструкции клиенту по корректной регистрации на сервере, и ключ шифрования пароля nonce. UAC, получив от сервера инструкции формирует новый запрос REGISTER, и, если пара данных логин — hash пароля верная, то сервер дает ответ 200 ОК и запоминает, что зарегистрированный абонент находится на IP-адресе и порту TCP/UDP, откуда пришел запрос.
Пример полного обмена SIP Register в Приложении 2.
Входящие сессии связи для этого абонента будут отправляться на адрес и порт регистрации. Данный метод нужен для случаев, когда абонент мобилен, и не имеет статического положения (ip-адреса) в сети, а так же, для прохождения NAT-роутеров, в которых после регистрации остается открытой NAT-сессия, через которую IP пакет с выходящей сессией связи будет доставлен до абонента за NAT.

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

Схема 3. Исходящая сессия связи с авторизацией http-digest

После запроса от UAC на установление сессии связи (SIP INVITE), сервер возвращает 407 Proxy Authorization Required, с инструкциями по авторизации, аналогичными 401 Unauthorized ответа на запрос на регистрацию. В данном случае, в отличие от метода регистрации, UAC должен ответить ACK (acknowledge), и отправить новый запрос SIP INVITE, с вложенными в него Digest — realm и хэш пароля. Если сервером данные авторизации приняты, он продолжает устанавливать вызов сообщением 100 Trying. Данный метод необходим для авторизации абонента в момент установки сессии связи. Например, исходящая сессия связи может быть установлена с другой пары IP-адрес/порт, отличной от адреса и порта регистрации абонента. До сих пор мы рассматривали примеры с успешными регистрациями или сессиями связи. Рекомендациями RFC протокола SIP предусмотрены классы сообщений, указывающих на неуспешную попытку установления сессии связи или регистрации абонента. Во многом они, опять же, похожи на ответы HTTP при сбоях или недоступности сервиса. Подробно эти сообщения стоит рассматривать при диагностике какой-либо конкретной проблемы, мы же только рассмотрим классы всех сообщений (SIP REQUEST), и самые основные сообщения в этих классах. Сообщения INVITE (начало сессии), REGISTER (запрос на регистрацию), ACK (подтверждение о получении сообщения), CANCEL и BYE являются методами (METHOD), и не имеют классификации по номерам.

Класс сообщений 100 — в данном классе присутствуют информационные сообщения о начале обработки запроса, самые распространенные — 180 Ringing и 183 Session progress, как ответы на INVITE.
Класс сообщений 200 — ответы, завершающие запрос, самый распространенный 200 ОК, подтверждающий успешное установление сессии связи. Другое важное сообщение 202 Accepted, является ответом на метод REFER, указывающий на необходимость вести диалог с третьей стороной (переадресация сессии связи).
Класс сообщений 300 — сообщения о переадресации, самый распространенный 302 Moved temporarily, указывающее на необходимость переадресовать вызов другому абоненту. В практике, кроме сообщения 302, автору никогда не встречалось других диалогов в данном классе.
Класс сообщений 400 — невозможность обработать запрос. Здесь чаще всего встречаются три сообщения, это 401 Unauthorized — запрос абоненту прислать Digest на регистрацию, 403 Forbidden — установление сессии связи запрещено. И всем известное по протоколу http сообщение 404 Not found — означающее, что вызываемый абонент на сети не существует (номер/uri абонента Б не найден). Так же встречаются сообщения:
407 Proxy Authentication Required — запрос абоненту прислать Digest на исходящую сессию связи
408 Request Timeout — когда абонент Б был извещен о вызове, но до установки сессии связи абонент А отменил сессию сообщением CANCEL
480 Temporarily Unavailable — как правило, такое сообщение выдается если у абонента в момент вызова не было регистрации, и такое же сообщение, как правило, отдают сотовые операторы после проигрывания а/и «Абонент вне зоны действия сети».
486 Busy Here – завершение сессии связи причиной занятости вызываемого абонента.
Класс сообщений 500 — ошибки сервера, отказ в обслуживании. Здесь подавляющее большинство сообщений 500 Server Internal Error и 503 Service unavailable. При разнообразных отказах в обслуживании, таких как, например, таймаут ожидания сообщения при инициации вызова и т. д.
Класс сообщений 600 — общие, глобальные ошибки. Те состояния, которые не описаны определенно в RFC попадают в этот класс сообщений, здесь использует практически только одно сообщение 603 Decline, означающее отказ user-agent’а обслуживать сеанс связи по неназванной, как правило умышленно, причине.
Некоторые примеры не успешных вызовов в Приложении 3.

Session Description Protocol (SDP)
Протокол описания медиаданных сессии, как правило сессий связи SIP. Описан в RFC4566 от июля 2006 года. Информация SDP может быть «прикреплена» к любому из методов (INVITE, REFER, OPTIONS, и ответов на них) протокола SIP, которое устанавливает, продолжает или изменяет сессию (INVITE, 200 OK, 183 Session progress, 180 Ringing и т.д.). SDP выглядит, как и SIP, простым текстом, частично словами на английском языке и функционально в нем содержатся атрибуты сессии связи.

• IP адрес владельца сессии и назначение сессии
• Информация об ip-адресе терминации медиа, т. к. может быть отлична от места обработки сообщений SIP
• Информация о поддерживаемых терминальным устройством кодеках аудио и видео медиаданных, отсортированых в порядке приоритета использования.
• Информация о направлении передачи медиаданых — прием и отправка, только отправка, только прием или «неактивная сессия», когда информация о медиавозможностях есть, однако, в данный момент передавать медиа не надо (сессия на паузе, удержании без музыки и т. д. — экономия полосы пропускания каналов ПД).
• Информация о возможных методах обработки цифр донабора DTMF
• Прочая информация об атрибутах пользовательских данных

Session Description Protocol Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.10.10
Session Name (s): SIP Call
Connection Information (c): IN IP4 10.10.10.10
Media Description, name and address (m): audio 24840 RTP/AVP 8 101
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): sendrecv

Схема 4. Блок SDP сообщения INVITE

Понимание содержания данных в SDP позволяет провести точную диагностику проблем, когда сессия успешно устанавливается, а медиа при этом не передается или передается в одну из сторон (односторонняя слышимость). Параметры медиа для сессии связи всегда описаны в SDP. В широком смысле SIP обеспечивает возможность установить сессию связи на каналах передачи данных (интернет), а SDP информирует встречный user-agent о своих возможностях передачи пользовательских данных. При отсутствии, например, согласования медиа (у user-agent’ов разные кодеки), это будет обработано на уровне SIP специальным сообщением 415 No compatible codecs. SDP необходим для изменения состояния сессии, например, постановки вызова на удержание — при срабатывании такого события user-agent формирует SIP INVITE (новый INVITE в рамках установленной сессии называется RE-INVITE) с новым SDP, в котором параметр направления передачи будет равен sendonly (Media Attribute (a): sendonly)— только отправка мелодии на удержании. UAS, получив такое событие должен начать в установленном канале проигрывать встречному UAC музыку на удержании или перенаправить встречного user-agent на взаимодействие медиа вообще с другим сервером (Cisco MTP, media termination point), а инициатору Hold — прекратить передачу медиа. SDP в сообщениях SIP класса 100 (информационные) определяют, так называемый, early media — мелодия предответного состояния, она же «замени гудок» и пр. Когда UAS при получении информации о том, что у абонента Б «звенит» телефон, заменяет КПВ ожидания ответа (КПВ — контроль посылки вызова, гудки) на произвольную мелодию.Например, на IP-АТС Asterisk технически можно заменять звуковой файл КПВ на произвольную мелодию.

RTP: Real-time Transport Protocol
После успешной установки сессии связи, причем, с точки зрения RTP — неважно, по какому протоколу сигнализации, начинается передача пользовательских данных, в общем случае, как мы обсуждали выше — это может быть информация любого рода, аудиоданные (телефонный звонок, голосовые конференции), видеоданные (видеозвонок, видеоконференции), передача файлов. В общем, любая информация, которую необходимо передать между двумя пользователями. Например, Google Talk использует для установления сеанса XMPP, а для передачи пользовательских данных RTP. Данный протокол описан в RFC1886 в 1996 году, затем переработан в 2003 в RFC3550. Рекомендациями RFC описано, что протокол стоит применять для передачи данных реального времени — он-лайн игр, голосовых и видео вызовов, мгновенных сообщений и т.д. После установки сеанса связи, сервером и клиентом в SDP оговаривается пара портов UDP, по одному на каждое терминальное устройство, для приема/передачи медиаданных. Эти порты являются идентификатором медиаданных сессии, то есть в момент активной сессии пара портов может использоваться только одним сеансом связи. Отсюда можно сделать вывод, что при современной вычислительной мощности ЭВМ количество одновременно обрабатываемых сессий ограничено диапазоном UDP портов. Так как RTP это только транспортный протокол, и его цель передача пакетизированной (разбитой на равные «пакеты») медиаинфорциации между участниками сессии, то эту медиаинформацию еще сначала нужно оцифровать (если это голос/видео) и пакетизировать, т. е. подготовить пользовательские данные к передаче по RTP. Эту задачу выполняют DAC (Digital-to-analog converter, аналогово-цифровые преобразователи), которые преобразуют человеческую речь в цифровой формат, затем терминальное устройство пакетизирует медиаданные. Оцифровка речи может проводиться одним из т. н. кодеков — алгоритмов преобразования аналогового сигнала в цифровой. Для кодирования аудио, в настоящий момент, имеется великое множество алгоритмов, это, например, всеми известный MP3 (MPEG Layer 3), перекодирующий уже оцифрованное аудио со значительным сжатием. В случае телефонных вызовов используются узкоспециализированные алгоритмы сжатия человеческой речи, в основном это формат G711, разработанный еще в 1973 году, представляющий собой метод оцифровки и компрессии голоса до 64кбит/сек, что делает его пригодным для использования в сетях с канальной коммутацией — цифровой канал Е1 и т. д., где используется только он. Это так же увеличило рациональность использования G711 и в сетях IP-телефонии, из-за снижения вычислительного ресурса для перекодирования. Лицензирование кодека G711 не осуществляется, так как истекло время патента на алгоритм кодирования, и данный кодек попал в общий доступ. G711 повсеместно распространен в сетях IP-телефонии, как наилучший кодек с точки зрения количества поддерживаемых устройств, качества и занимаемой полосы пропускания. Согласитесь, 64кбит/сек в настоящее время легкодоступны даже в мобильных сетях передачи данных, не говоря уже о наземных каналах связи. Терминальное устройство, преобразовав речь в цифровые данные, буферизирует определенный объем данных, относительно небольшой, затем пакетизирует информацию. Пакетизация, в данном случае — процесс разбивки аудиопотока на равные части, описанные в SDP параметром packet size и присвоением каждому пакету временной метки timestamp, причем «размер пакета» определяется не в количестве информации, а во времени, между пакетами. Как правило этот параметр равен 20мс, то есть RTP отправляет (и получает) 50 пакетов закодированной аудиоиформации в секунду.

Схема 5. Визуализация пакетизированной информации

Этого вполне достаточно, чтобы пользователь не замечал, что голос разбит на части, и речь слышалась «плавно». Получение и декодирование происходит по похожему методу. Полученные RTP пакеты «накапливаются» в jitter-буфере, сортируются по временной метке timestamp, так как пакеты, из-за возможных нагрузок на сеть ПД могут поступить в разное время, после чего декодируются и воспроизводятся в «трубке» у абонента. Если, по какой-то причине, RTP пакетов недостаточно, то отсутствующие/потерянные пакеты будут заменены тишиной. Так же существуют кодеки со значительным сжатием, например, G729, который активно использовался, когда емкость каналов связи была значительно меньше нынешней. Кодек занимает всего 8кбит/сек (сжатие в 8 раз относительно G711). Однако, кодек предоставляет более низкое качество, невозможность передать факс (как инкапсулировать трудносжимаемые 14400 бит/сек в 8000бит/сек без искажения информации?), и требует значительно бОльшие вычислительные ресурсы на оцифровку в реальном времени относительно G711, для современных серверных вычислительных систем практически некритично, а вот для маломощных терминальных устройств (АТА, IP-телефоны) до сих пор остается актуальной проблемой.
Так же, в сетях IP-телефонии, с увеличением абонентов, получает развитие кодек G722, который громко называется HD Voice. Кодек использует больший диапазон частот, чем человеческая речь, и кодирует аудио в диапазоне частот 80 — 14 000Гц, вместо 300-3400Гц в обычном режиме G711, что позволяет значительно улучшить качество передаваемого аудиопотока.

Схема 6. Частотный диапазон кодеков G711 и G722

Кодек использует сжатие, поэтому утилизация полосы пропускания кодеком меньше, чем G711. Внедрение G722 в настоящее время активно ведется и операторами сотовой связи. Немного заглядывая в будущее можно предположить, что с еще большим увеличением емкости каналов связи, а также усовершенствованием технологий создания микрофонов и динамиков, будет целесообразным передавать в RTP даже FLAC (Free Lossless Audio Codec), обеспечивающий максимальное на сегодняшний момент качество оцифрованного звука на полосе пропускания 1-2Мбит/сек. Говоря о полосе пропускания, следует понимать, что 64кбит/сек это полезная информация, к ней еще необходимо прибавлять служебную информацию о заголовках пакетов TCP/IP. В общем случае, занимаемая полоса одного вызова, примерно, 84кбит/сек в одну сторону. 50 RTP пакетов в секунду по 214 байт каждый. Как можно понять из теоретического описания, основная проблема при передаче RTP – это потери пакетов или большая разница по времени попадания пакета в jitter-буфер, т.е. времени фактического поступления IP пакета на сетевой интерфейс user-agent’а. Обе эти проблемы будут занижать качество слышимой речи, грубо говоря, из слов будут выпадать буквы или слоги. При значительных потерях или при значительных различиях в round-trip-time возможны более длительные прерывания до 1-2 секунд.

NAT: Network Address Translation
NAT — технология, в наиболее распространенном варианте, позволяющая заменить адрес источника (локальный) на единственный доступный для группы пользователей маршрутизируемый (внешний) адрес. В настоящее время используется повсеместно. Схема работы «обычного» NAT довольно проста — пользователь в локальной сети запрашивает информацию с ресурса в сети Интернет. IP пакет, достигая роутера, преобразуется таким образом, как будто это сам NAT-роутер выполняет запрос. Роутер, в свою очередь, фиксирует отправленный запрос, и все ответы будет транслировать на адрес локального абонента, в этом случае преобразуя адрес назначения.

Схема 7. ЛВС подключенная к Интернет через NAT

Для абонентского устройства NAT-роутер будет «прозрачным» устройством маршрутизации при использовании протоколов, которые передают только пользовательские данные, такие как HTTP, FTP, XMPP и так далее. SIP, в свою очередь, передает внутри сообщений большое количество информации о местонахождении, адреса терминации RTP, идентификационных и авторизационных данных. Рассмотрим наш пример установки сеанса связи. При инициации, и, если терминал абонента находится за NAT, внутри сообщения SIP INVITE будет передан локальный IP-адрес терминала. Согласно рекомендациям RFC, взаимодействие терминалов на сетевом уровне должно быть описано в идентификационных полях (Contact). Встречный терминал вынужден будет отвечать на этот локальный адрес, и разумеется, сеанс связи не сможет быть установлен.
Вторая проблема при использовании NAT — это наличие таймаута неактивности NAT сессии. Если инициатор сессии связи абонент, находящийся за NAT, эта проблема не так актуальна, если сессия уже была закрыта, то NAT-роутер создаст еще одну, но что делать с входящей связью, когда необходимо установить связь к абоненту за NAT? В таком случае, сервер будет посылать вызов на последний известный (статический или динамический) адрес, но не получит ответа, так как у NAT-роутера сработает правило Drop.
Третья проблема — отсутствие статического IP-адреса как в ЛВС за NAT, так и внешнего адреса у NAT-роутера. Как определить, куда именно в данный момент времени необходимо отправить входящий вызов такому абоненту? В этом случае, SIP сервер или NAT-роутер не будут знать об истинном местонахождении абонента.
Четвертая проблема — вероятная блокировка поступающего RTP трафика. RTP для передачи использует отличную от SIP пару портов, диапазон которых может не пропускаться роутером из-за настроек безопасности (правило Drop на любой неопознанный входящий пакет), либо отсутствием открытой NAT сессии для порта входящего RTP трафика.
Общими симптомами первых трех проблем будет невозможность установить сеанс связи ввиду отсутствия сетевой коннективности между сервером и терминалом абонента. Четвертая проблема будет связана с отсутствием медиаданных (в одну или обе стороны) в установленной сессии.
Решением первой проблемы является игнорирование требования RFC о поле Contact, и отсылка ответных сообщений на явно указанный адрес и порт, в надежде, что NAT-роутер доставит пакет до терминала абонента. В этом случае необходимо точно знать, есть ли между сервером и клиентом NAT-роутеры. И NAT-роутер должен быть настроен соответствующим образом, с пробросом порта на локальный адрес. Это достигается путем специальной донастройки UAS в части обработки поля Contact.
Вторая и третья проблемы частично решаются регистрацией абонента на сервере регистраций, и указанием серверу игнорировать требование RFC о поле Contact, посылая все сообщения на адрес и порт регистрации, в надежде, что NAT сессия еще не закрыта по таймауту, и NAT-роутер доставит пакет до локального абонента. В этом случае, терминальному устройству абонента рекомендуется как можно чаще, в общем случае, с меньшим временем таймаута NAT-сессии, перерегистрироваться на сервере поддерживая или обновляя NAT-сессию. Как правило, это 60-120 секунд.
Для прохождения NAT, иногда, в самих роутерах есть опция SIP ALG (application layer gateway), которая детектирует пакет SIP, разбирает его до 7 уровня OSI, переопределяет все адреса внутри SIP сообщения на адрес внешнего интерфейса и отсылает на SIP-сервер. В теории эта опция должна позволить избавиться от проблемы NAT принципе, но на деле это не работает, т. к. реализация обработки SIP сообщений в ALG далека от требований RFC, и успешного взаимодействия не происходит. Решением четвертой проблемы, чаще всего, является включенная опция UPnP, позволяющая динамически открывать необходимые NAT-сессии и/или «пробрасывать» порты так же, как это делается для Skype или Bittorrent. В данный момент поддерживается всеми терминалами SIP, однако, в большей части зависит от роутеров. Наиболее надежным средством в случае с NAT является установка так называемой «транзитной АТС» (back to back User Agent) — с двумя сетевыми интерфейсами, один «внутренний», другой «внешний», которая занималась бы не трансляцией, а проксированием сессий связи. Но такое решение дорого, и требует от клиентов наличия высококвалифицированных специалистов. Из-за повсеместного распространения NAT, операторы IP-телефонии, при предоставлении услуг по протоколу SIP вынуждены по-умолчанию предлагать клиенту вариант подключения с регистрацией на сервере оператора с включенными дополнительными методами «удержания» NAT-сессии, например, с помощью квалификационного сообщения OPTIONS от сервера к клиенту, на которое встречный терминал должен послать какой-либо ответ, чаще это 200 ОК, процесс можно называть keepalive. Это «дополнительное» взаимодействие обеспечивает наилучшую стабильность при прохождении NAT-роутеров. Большинство проблем NAT связано с выключенным UPnP или избыточностью в настройке проброса портов. Любые современные роутеры поддерживают UPnP, который включен по умолчанию. Любое подключение SIP, если точная топология сети клиента неизвестна, подразумевает нахождение абонента за NAT и выставляется соответствующая настройка обработки пакетов SIP. Случаются сбои в работе роутеров, иногда помогает их перезагрузка. Особое внимание хотелось бы уделить усложненным топологиям сетей, где абонент использует NAT-роутер, но подключен к оператору Интернет без предоставления внешнего адреса, например, Йота. В случае таких подключений количество вероятных проблем с телефонией многократно возрастает и практически не поддается диагностике, т.к. используется «двойной» NAT, и на каком участке сети возникает отказ определить практически невозможно.

Обзор наиболее часто используемого оборудования

Изображение. Аналоговые VoIP-адаптеры FXS

Три самых распространенных устройства – Linksys SPA2102, Cisco SPA122 и Cisco ATA186. Двух портовые аналоговые шлюзы IP-телефонии. Являются, по сути, преобразователями (конвертерами) аналоговых линий в VoIP. Применяются везде, где нужно включить 1-2 аналоговые линии по технологии VoIP. Плюсы – большая мобильность и малые размеры. Минусы – достаточно высокая цена за 1 порт FXS (стоимость устройства плюс 1 Ethernet порт на коммутаторе), нецелесообразно устанавливать данные устройства там, где нужно много аналоговых линий. Шлюзы SPA имеют дополнительный Ethernet порт для первоначальной настройки и удобства управления устройством. Может выступать и как роутер, но не рекомендуется ввиду его малой вычислительной мощности.

Изображение. Аналоговый VoIP-адаптер Cisco(Linksys) SPA8000

Cisco(Linksys) SPA8000. С функциональной точки зрения абсолютно тоже самое, что и Linksys SPA2102, только имеет 8 аналоговых портов FXS. Имеет возможность подключения телефонных аппаратов как напрямую по RJ-12, так и на кросс интерфейсом Amphenol. Имеет дополнительный Ethernet порт AUX (закрыт заглушкой). Используется для управления работающим устройством, если, по каким-либо причинам, не удается получить доступ через сеть ПД.

Изображение. VoIP-шлюз Eltex TAU-8.IP

Eltex TAU-8.IP распространенный шлюз на данный момент. Как и у Cisco SPA8000 имеет 8 аналоговых портов FXS, но только под разъемы RJ-12. Имеет наилучшее соотношение цена / количество портов FXS. К сети ПД подключается одним Ethernet портом, дополнительных портов управления не имеет. На задней панели есть USB порт для подключения 3G/4G модемов.

Изображение. VoIP-шлюз Eltex TAU-8.IP

Eltex TAU-72.IP; шлюзы FXS с высокой плотностью портов. Используются модели на 16, 24, 32, 36 и 72 (как на картинке) FXS порта, число после аббревиатуры TAU означает количество FXS. Имеет несколько портов Ethernet/SFP, поддерживает коммутацию и стандарт 802.1Q (VLAN). Порты FXS расшиваются только на кросс интерфейсами Amphenol. При использовании на «выносах» подключается одним Ethernet портом к сети ПД в любой из доступных Ethernet портов на самом устройстве. То есть порт на коммутаторе определенный, а порт на TAU-XX любой. Перечисленное выше оборудование используется, в основном, для подключения услуг «Абонентская линия» по технологии VoIP. Ниже рассмотрим менее распространенное оборудование VoIP, такое как IP-АТС и IP-телефоны, стационарные и DECT.

IP-телефоны Yealink SIP-T20(P) и Cisco SPA502G (слева направо). Одни из самых распространенных стационарных IP-телефонов. Почти все аппараты такого типа имеют два порта Ethernet для подключения к сети ПД на рабочем месте с одной розетки RJ-45. При использовании IP-телефонов в офисной телефонной сети не требует монтаж отдельной СКС для телефонии (однопарной медной линии) к каждому рабочему месту, IP-телефоны подключаются с розетки и пропускают через себя сеть ПД дальше к компьютеру на рабочем месте. Так же почти все IP-телефоны поддерживают PoE, при использовании PoE коммутаторов с резервированием питания при отключении электричества телефонная связь будет работать.

Изображение. VoIP-DECT: Yealink W52H, Siemens Gigaset C610IP

Самые распространенные IP-телефоны стандарта беспроводной телефонной связи DECT: Yealink W52H, Siemens Gigaset C610IP. Базовые станции подключаются одним портом к сети ПД и не имеют второго порта, т.е. должны быть установлены отдельно от рабочих мест. Зона покрытия DECT должна рассчитываться из технических спецификаций каждого из устройств, но, как правило, составляет «стандартные» 50м внутри зданий и 300м при прямой видимости. Не поддерживают функцию Handover. На каждую из базовых станций можно подключить больше 1 телефонной трубки стандарта DECT, 5 трубок на базу Yealink и 4 трубки на базу Siemens, причем, к базе Siemens можно подключать любую трубку DECT. Данные устройства дают все преимущества радиотелефона вкупе с IP-телефонией.

Изображение. IP-АТС Yeastar MyPBX SOHO и MyPBX Standard(снизу)

IP-АТС Yeastar MyPBX SOHO и MyPBX Standard, коробочные IP-АТС для малых и средних организаций. Версия SOHO имеет один сетевой интерфейс и физически устанавливается в ЛВС организации, но имеет поддержку интерфейсов VLAN и может быть физически включена в коммутатор оператора связи, но, в таком случае придется занимать дополнительно один порт для подключения ЛВС абонента к АТС. Версия Standard имеет два Ethernet интерфейса и подключается к сети оператора и ЛВС абонента разными Ethernet каналами.

В начало

Приложение 1

192.168.85.77 -> 1.1.1.1
INVITE sip:060@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-cb9fd832
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 101 INVITE
Max-Forwards: 70
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
Expires: 240
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 401
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 77341649 77341649 IN IP4 192.168.85.78
s=-
c=IN IP4 192.168.85.78
t=0 0
m=audio 16412 RTP/AVP 0 2 4 8 18 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

1.1.1.1 -> 192.168.85.77
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-cb9fd832
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 101 INVITE
Contact: <sip:060@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Content-Length: 0

1.1.1.1 -> 192.168.85.77
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-cb9fd832
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=1187576231-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 101 INVITE
Contact: <sip:060@1.1.1.1:9955>
Proxy-Authenticate: Digest realm="SIP-REGISTRAR", nonce="7557CA76"
Server: TS-v4.5.1-16bW
Reason: SIP;cause=407;text="Proxy Authentication Required"
Content-Length: 0

192.168.85.77 -> 1.1.1.1
ACK sip:060@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-cb9fd832
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=1187576231-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 101 ACK
Max-Forwards: 70
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0

192.168.85.77 -> 1.1.1.1
INVITE sip:060@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-854da4d6
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 102 INVITE
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="7557CA76",uri="sip:060@ucexpert.ru",algorithm=MD5,response="8b7e58f92e25b7565a172eae786534b3"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
Expires: 240
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 401
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 77341649 77341649 IN IP4 192.168.85.78
s=-
c=IN IP4 192.168.85.78
t=0 0
m=audio 16412 RTP/AVP 0 2 4 8 18 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

1.1.1.1 -> 192.168.85.77
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-854da4d6
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:060@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Content-Length: 0

1.1.1.1 -> 192.168.85.77
SIP/2.0 183 Progress
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-854da4d6
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=3737388456-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:060@1.1.1.1:9955>
Content-Type: application/sdp
Server: TS-v4.5.1-16bW
Content-Length:   312

v=0
o=- 1428053682 1428053682 IN IP4 1.1.1.1
s=-
c=IN IP4 1.1.1.1
t=0 0
m=audio 23762 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=silenceSupp:off - - - -

[Здесь начинается RTP, early media]
269	3.461177000	1.1.1.1	192.168.85.78	RTP	214	PT=ITU-T G.711 PCMU, SSRC=0x13F76B0E, Seq=57471, Time=18955725
270	3.471776000	192.168.85.78	1.1.1.1	RTP	214	PT=ITU-T G.711 PCMU, SSRC=0xB6AC8DE6, Seq=12845, Time=295360502
[--------------------]

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-854da4d6
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=3737388456-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:060@1.1.1.1:9955>
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, REFER, REGISTER, SUBSCRIBE, UPDATE
Server: TS-v4.5.1-16bW
X-mera-expires: 86460
Content-Length:   312

v=0
o=- 1428053682 1428053682 IN IP4 1.1.1.1
s=-
c=IN IP4 1.1.1.1
t=0 0
m=audio 23762 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=silenceSupp:off - - - -

192.168.85.77 -> 1.1.1.1
ACK sip:060@1.1.1.1:9955 SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-a0107bb
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=3737388456-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 102 ACK
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="7557CA76",uri="sip:060@ucexpert.ru",algorithm=MD5,response="8b7e58f92e25b7565a172eae786534b3"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0

[Здесь начинается RTP, разговор]
522	5.235435000	1.1.1.1	192.168.85.78	RTP	214	PT=ITU-T G.711 PCMU, SSRC=0x13F76B0E, Seq=57471, Time=18975885
523	5.235448000	192.168.85.78	1.1.1.1	RTP	214	PT=ITU-T G.711 PCMU, SSRC=0xB6AC8DE6, Seq=12845, Time=295380662
[--------------------]


192.168.85.77 -> 1.1.1.1
BYE sip:060@1.1.1.1:9955 SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-944b996c
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=3737388456-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 103 BYE
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="7557CA76",uri="sip:060@1.1.1.1:9955",algorithm=MD5,response="bcab538ab583a22a75a230b2f2324e50"
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0

1.1.1.1 -> 192.168.85.77
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-944b996c
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=cfa1a6362fadf592o0
To: <sip:060@ucexpert.ru>;tag=3737388456-3826377945-67116434-156294691
Call-ID: cc071e06-159a6002@192.168.85.78
CSeq: 103 BYE
Contact: <sip:060@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Content-Length: 0
 

Приложение 2

192.168.85.77 -> 1.1.1.1
REGISTER sip:ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-999b9395
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=94e4b8a493153778o0
To: "78123375050$home" <sip:78123375050$home@ucexpert.ru>
Call-ID: 578c5bd0-bbd80ab8@192.168.85.78
CSeq: 59633 REGISTER
Max-Forwards: 70
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>;expires=125
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces

1.1.1.1 -> 192.168.85.77
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-999b9395
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=94e4b8a493153778o0
To: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=97976c66d9e811e4922a000423de5009
Call-ID: 578c5bd0-bbd80ab8@192.168.85.78
CSeq: 59633 REGISTER
WWW-Authenticate: Digest realm="SIP-REGISTRAR", nonce="1B879485"
Server: TS-v4.5.1-16bW
Content-Length: 0

192.168.85.77 -> 1.1.1.1
REGISTER sip:ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-ee1b8fc6
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=94e4b8a493153778o0
To: "78123375050$home" <sip:78123375050$home@ucexpert.ru>
Call-ID: 578c5bd0-bbd80ab8@192.168.85.78
CSeq: 59634 REGISTER
Max-Forwards: 70
Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="1B879485",uri="sip:ucexpert.ru",algorithm=MD5,response="c84171b2accd691394d52e36c898dfd5"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>;expires=125
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces

1.1.1.1 -> 192.168.85.77
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-ee1b8fc6
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=94e4b8a493153778o0
To: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=979d973ad9e811e4922a000423de5009
Call-ID: 578c5bd0-bbd80ab8@192.168.85.78
CSeq: 59634 REGISTER
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>;expires=125
Expires: 125
Server: TS-v4.5.1-16bW
Content-Length: 0

Приложение 3
Исходящий сеанс связи, завершенный сообщением «Занято» вызываемой стороной (кому звонили):

192.168.85.77 -> 1.1.1.1
INVITE sip:89500090900@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4644379
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=700b0ab5b7382b1bo0
To: <sip:89500090900@ucexpert.ru>
Call-ID: 342e2e3d-f2601d33@192.168.85.78
CSeq: 102 INVITE
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="2B83ECA4",uri="sip:89500090900@ucexpert.ru",algorithm=MD5,response="ff194cb2738db4202267e1df476c2d62"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
Expires: 240
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 393
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 3021 3021 IN IP4 192.168.85.78
s=-
c=IN IP4 192.168.85.78
t=0 0
m=audio 16420 RTP/AVP 0 2 4 8 18 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

1.1.1.1 -> 192.168.85.77
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4644379
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=700b0ab5b7382b1bo0
To: <sip:89500090900@ucexpert.ru>
Call-ID: 342e2e3d-f2601d33@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:89500090900@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Content-Length: 0

1.1.1.1 -> 192.168.85.77
SIP/2.0 183 Progress
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4644379
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=700b0ab5b7382b1bo0
To: <sip:89500090900@ucexpert.ru>;tag=2124713377-3826378969-67119762-156294691
Call-ID: 342e2e3d-f2601d33@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:89500090900@1.1.1.1:9955>
Content-Type: application/sdp
Server: TS-v4.5.1-16bW
Content-Length:   312

v=0
o=- 1428055393 1428055393 IN IP4 1.1.1.1
s=-
c=IN IP4 1.1.1.1
t=0 0
m=audio 12514 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=silenceSupp:off - - - -

1.1.1.1 -> 192.168.85.77
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4644379
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=700b0ab5b7382b1bo0
To: <sip:89500090900@ucexpert.ru>;tag=2124713377-3826378969-67119762-156294691
Call-ID: 342e2e3d-f2601d33@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:89500090900@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Reason: SIP;cause=486;text="Busy Here"
Content-Length: 0

192.168.85.77 -> 1.1.1.1
ACK sip:89500090900@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4644379
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=700b0ab5b7382b1bo0
To: <sip:89500090900@ucexpert.ru>;tag=2124713377-3826378969-67119762-156294691
Call-ID: 342e2e3d-f2601d33@192.168.85.78
CSeq: 102 ACK
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="2B83ECA4",uri="sip:89500090900@ucexpert.ru",algorithm=MD5,response="ff194cb2738db4202267e1df476c2d62"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0

Исходящий сеанс связи, заверешенный сообщением «Вызываемый номер не найден / Абонент не существует»:

192.168.85.77 -> 1.1.1.1
INVITE sip:71116279999@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4d8e26b0
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=87ae3b4d1b69e54o0
To: <sip:71116279999@ucexpert.ru>
Call-ID: ecf8d734-266540d4@192.168.85.78
CSeq: 102 INVITE
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="34DE2E02",uri="sip:71116279999@ucexpert.ru",algorithm=MD5,response="c0cde357199c96ed3806a5e1a395b2de"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
Expires: 240
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 393
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 7161 7161 IN IP4 192.168.85.78
s=-
c=IN IP4 192.168.85.78
t=0 0
m=audio 16422 RTP/AVP 0 2 4 8 18 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729a/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

1.1.1.1 -> 192.168.85.77
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4d8e26b0
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=87ae3b4d1b69e54o0
To: <sip:71116279999@ucexpert.ru>
Call-ID: ecf8d734-266540d4@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:71116279999@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Content-Length: 0

1.1.1.1 -> 192.168.85.77
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4d8e26b0
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=87ae3b4d1b69e54o0
To: <sip:71116279999@ucexpert.ru>;tag=3599444922-3826378969-67119762-156294691
Call-ID: ecf8d734-266540d4@192.168.85.78
CSeq: 102 INVITE
Contact: <sip:71116279999@1.1.1.1:9955>
Server: TS-v4.5.1-16bW
Reason: SIP;cause=404;text="Not Found"
Content-Length: 0

192.168.85.77 -> 1.1.1.1
ACK sip:71116279999@ucexpert.ru SIP/2.0
Via: SIP/2.0/UDP 192.168.85.78:5060;branch=z9hG4bK-4d8e26b0
From: "78123375050$home" <sip:78123375050$home@ucexpert.ru>;tag=87ae3b4d1b69e54o0
To: <sip:71116279999@ucexpert.ru>;tag=3599444922-3826378969-67119762-156294691
Call-ID: ecf8d734-266540d4@192.168.85.78
CSeq: 102 ACK
Max-Forwards: 70
Proxy-Authorization: Digest username="78123375050$home",realm="SIP-REGISTRAR",nonce="34DE2E02",uri="sip:71116279999@ucexpert.ru",algorithm=MD5,response="c0cde357199c96ed3806a5e1a395b2de"
Contact: "78123375050$home" <sip:78123375050$home@192.168.85.78:5060>
User-Agent: Linksys/SPA942-5.1.15(a)
Content-Length: 0

В начало