ОАО Московская государственная телефонная сеть (МГТС) установлен статус признанной эксплуатационной организации - оператор местной сети электросвязи общего пользования Российской Федерации, которая является одной из крупнейших местных сетей в мире. По числу абонентов, сложности кабельной сети и объему оборудования МГТС сравнима с национальными сетями таких стран, как Бельгия, Норвегия, Дания. На МГТС установлено более 500 автоматических телефонных станций (АТС). Дальнейшее расширение емкости МГТС путем введения кода "499" в дополнение к существующему коду "495" снимает проблему нехватки номерной емкости.

Начало деятельности Московской городской телефонной сети относится еще к 1882 году, когда была введена в эксплуатацию первая телефонная станция ручного обслуживания ёмкостью всего на 800 номеров. В списке ее телефонных абонентов числилось 26 человек. Это были в основном богатые коммерсанты, промышленники, способные позволить себе такую роскошь. Телефон удовлетворил насущную общественную потребность, сделав возможной связь через большие расстояния без использования промежуточных кодов, громоздких телеграфных аппаратов и посредников-телеграфистов. Общаться по телефону людям стало так же легко, как разговаривать, находясь лицом к лицу.

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

В течение последних лет были разработаны устройства, обеспечивающие передачу голоса по сетям, изначально нацеленным на передачу данных - сетям компьютерной телефонии. Основные выгоды, получаемые от таких способов передачи голосовой информации, следующие: во-первых, одну и ту же линию можно использовать и для передачи данных, и для передачи голоса. Пропускная способность линии используется более эффективно, чем при передаче цифровых данных по аналоговым сетям через модем. Цифровые данные передаются непосредственно в цифровом виде как соответствующая принятой кодировке последовательность импульсов, а голосовая информация перед передачей сжимается. Современные алгоритмы сжатия позволяют без потери качества сжимать голосовой поток 64 кбит/с в 10 раз (до 6,3 кбит/с), а с некоторыми издержками до 2,4 кбит/с. Во-вторых, при передаче голоса в виде пакетов возможно динамическое использование пропускной способности имеющихся каналов связи: суммарная емкость канала расходуется только на фактическую передачу информации. При работе с коммутацией каналов временной канал выделяется в течение всего времени соединения, независимо от того, действительно ли передается информация.

Таким образом, перспективным направлением развития телекоммуникационных сетей, в том числе и Московской городской телефонной сети, является эволюционный переход к цифровым сетям и в последующем переход от технологии коммутации каналов к технологии коммутации пакетов. При постоянно усложняющейся сетевой инфраструктуре и быстро растущем наборе услуг такой оператор перспективной телекоммуникационной сети, как ОАО "МГТС" должен располагать набором универсальных решений - совокупностью специализированных шлюзов для взаимодействия сетей и оборудования разного типа.

телефонная сеть коммутация протокол

Глава 1. Структура протокола TCP/IP

1.1 Стек TCP/IP

Бесклассовая адресация

Со второй половины 90-х годов XX века классовая адресация повсеместно вытеснена бесклассовой адресацией, при которой количество адресов в сети определяется только и исключительно маской подсети.

Особые IP-адреса

· В протоколе IP существует несколько соглашений об особой интерпретации IP-адресов:

· если весь IP-адрес состоит только из двоичных нулей, то он обозначает адрес того узла, который сгенерировал этот пакет; этот режим используется только в некоторых сообщениях ICMP;

· если в поле номера сети стоят только нули, то по умолчанию считается, что узел назначения принадлежит той же самой сети, что и узел, который отправил пакет;

· если все двоичные разряды IP-адреса равны 1, то пакет с таким адресом назначения должен рассылаться всем узлам, находящимся в той же сети, что и источник этого пакета. Такая рассылка называется ограниченным широковещательным сообщением (limited broadcast);

· если в поле номера узла назначения стоят только единицы, то пакет, имеющий такой адрес, рассылается всем узлам сети с заданным номером сети. Например, в сети 192.190.21.0 с маской 255.0.0.0 пакет с адресом 192.190.21.255 доставляется всем узлам этой сети. Такая рассылка называется широковещательным сообщением (broadcast).

Динамические IP-адреса

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

Для получения IP-адреса клиент может использовать один из следующих протоколов:

DHCP (RFC 2131) - наиболее распространённый протокол настройки сетевых параметров,

BOOTP (RFC 951) - простой протокол настройки сетевого адреса, обычно используется для бездисковых станций,

IPCP (RFC 1332) в рамках протокола PPP (RFC 1661),

Zeroconf (RFC 3927) - протокол настройки сетевого адреса, определения имени, поиск служб.

Постоянный IP адрес

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

Также постоянный IP адрес пригодится для того, чтобы к вашему компьютеру можно было получить доступ из сети Интернет. Когда вы соединяетесь с модемным пулом, то ресурсам машины, к которым вы пожелали открыть доступ можно получить доступ из сети. Но для этого нужно знать IP-адрес вашего компьютера. При входе в сеть интернет вам выдается динамический адрес, но этот адрес будет вашим только в течение данного сеанса связи, и в следующий раз он изменится. Поэтому пользователь, который захочет установить с вами соединение (например, для онлайн игры, или соединению по протоколу FTP) не будет знать имени вашей машины.

1.2.5 Протокол RTP

Основным транспортным протоколом для мультимедийных приложений стал протокол реального времени RTP (Real-Time Protocol), предназначенный для организации передачи пакетов с кодированными речевыми сигналами по IP-сети. Передача пакетов RTP ведется поверх протокола UDP, работающего, в свою очередь, поверх IP (рис.1.5.).

Рис.1.5 Уровни протоколов RTP/UDP/IP

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

Для передачи речевого (мультимедийного) трафика RTP использует пакеты, структура которых показана на рис.1.6.

Пакет RTP состоит, как минимум, из 12 байтов. В двух первых битах RTP заголовка (поле бита версии, V) указывается версия протокола RTP (в настоящее время это версия 2).

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

Рис.1.6. Заголовок RTP

Если он используется, то первое слово расширенного заголовка содержит общую длину расширения. Далее, четыре бита СС определяют число CSRC-полей в конце RTP-заголовка, т.е. число источников, формирующих поток. Маркерный бит М позволяет отмечать то, что стандарт определяет как существенные события, например, начало видеокадра, начало слова в аудиоканале и т.п. За ним следует поле типа данных РТ (7 битов), где указывается код типа полезной нагрузки, определяющий содержимое поля полезной нагрузки - данные приложения {Application Data), например, несжатое 8-битовое аудио МРЗ и т.п. По этому коду приложение может узнать, что нужно делать, чтобы декодировать данные. Остальная часть заголовка фиксированной длины состоит из поля порядкового номера (Sequence Number), поля метки времени (Time Stamp) для записи момента создания первого слова пакета и поля источника синхронизации SSRC, которое идентифицирует этот источник. В последнем поле можно указывать единственное устройство, имеющее только один сетевой адрес, множественные источники, которые могут представить различные мультимедийные среды (аудио, видео и т.д.), или разные потоки одной и той же среды. Так как источники могут быть на разных устройствах, SSRC-идентификатор выбирается случайным образом, чтобы шанс получать данные сразу от двух источников во время RTP-сеанса был минимальным. Однако определен также и механизм решения конфликтов, если они возникают. За фиксированной частью RTP-заголовка могут следовать еще до 15 отдельных 32-разрядных CSRC-полей, которые идентифицируют источники данных.

RTP поддерживается протоколом управления транспортировкой в реальном времени RTCP {Real-Time Transport Control Protocol), который формирует дополнительные отчеты, содержащие информацию о сеансах связи RTP. Напомним, что ни UDP, ни RTP не занимаются обеспечением качества обслуживания QoS (Quality of Service). Протокол RTCP обеспечивает обратную связь с отправителями, а получателям потоков он предоставляет некоторые возможности повышения QoS, информацию о пакетах (потери, задержки, джиттер) и о пользователе (приложении, потоке). Для управления потоком существуют отчеты двух типов - генерируемые отправителями и генерируемые получателями. Например, информация о доле потерянных пакетов и абсолютном количестве потерь позволяет отправителю при получении отчета обнаруживать, что перегрузка канала может заставить получателей не принимать потоки пакетов, которые они ожидали. В этом случае отправитель имеет возможность понизить скорость кодирования, чтобы уменьшить перегрузку и улучшить прием. Отчет отправителя содержит информацию о том, когда был генерирован последний RTP-пакет (она включает в себя как внутреннюю метку, так и реальное время). Эта информация позволяет получателю координировать и синхронизировать множественные потоки, например, видео и аудио. Если поток направляется нескольким получателям, то организуются потоки RTCP-пакетов от каждого из них. При этом будут предприняты шаги для ограничения ширины полосы - обратно пропорционально скорости, с которой генерируются RTCP-отчеты, и числу получателей.

Следует заметить, что хотя RTCP работает отдельно от RTP, но уже и сама цепочка RTP/UDP/IP приводит к существенным накладным расходам (в виде их заголовков). Кодек G.729 генерирует пакеты размером в 10 байтов (80 битов каждые 10 мс). Один RTP-заголовок, размером в 12 байтов, больше, чем весь этот пакет. К нему, кроме того, должен быть добавлен 8-байтовый UDP-заголовок и 20-байтовый IP-заголовок (в версии IРv4), что создает заголовок, в четыре раза превосходящий по размеру передаваемые данные.

1.2.6 Кодеки VoIP

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

Революционным толчком, позволившим прийти к передаче речи средствами IP-телефонии, стало появление процессоров цифровой обработки сигналов DSP (Digital Signal Processor), архитектура которых оптимизирована для выполнения операций, характерных для типичных алгоритмов обработки сигналов, например, умножение с накоплением или выборку операндов с бит-инверсной адресацией для выполнения быстрого преобразования Фурье. Физически DSP выполняются в виде интегральных микросхем, содержащих в одном кристалле ядро процессора, память и периферийные устройства для обмена информацией. Наличие встроенной памяти обеспечивает быстрый доступ ядра к ее содержимому для получения максимальной производительности. Функционально на DSP реализуются кодеки для использования в приложениях VoIP.

Различаются эти кодеки, в частности, по требуемой полосе пропускания канала. Для узкополосных кодеков скорость передачи информации лежит в пределах 1.2-64 Кбит/с, что определяет качество передачи речи. Существует несколько подходов к проблеме определения качества, наиболее популярным из которых является оценка MOS (Mean Opinion Score), которая определяется как среднее значение оценок качества по пятибалльной шкале, данных большой группой слушателей. Экспертам предъявляются для прослушивания разные звуковые фрагменты - речь, музыка, речь на фоне того или иного шума и т.д. Оценки интерпретируют следующим образом: 4-5 - высокое качество, которое аналогично или выше качества передачи речи при разговоре по сети ISDN; 3.5-4 - качество ТфОП (toll quality), обеспечиваемое при большинстве телефонных связей через ТфОП, а мобильные сети обеспечивают качество чуть ниже toll quality; 3-3.5 - качество речи по-прежнему удовлетворительное, однако его ухудшение хорошо заметно на слух; 2.5-3 - речь разборчива, однако для ее понимания требуется концентрация внимания.

Кроме того, еще одной функцией кодеков в шлюзах VoIP является подавление периодов молчания (VAD, CNG, DTX), позволяющее уменьшить объем информации, передаваемой в течение таких периодов, и освободить на это время занимаемую полосу пропускания. В двустороннем разговоре такие меры позволяют сократить объем передаваемой информации до 50%, а в децентрализованных многоадресных конференциях за счет большего числа говорящих - и более. Технология подавления молчания имеет три важных составляющих: детектор речевой активности VAD (Voice Activity Detector) определяет моменты времени, когда пользователь говорит, оценивает энергию входного сигнала и активизирует передачу, если она выше некоторого порога; прерывистая передача DTX (Discontinuous Transmission) вынуждает кодек прекратить передачу пакетов в то время, когда VAD обнаружил период молчания (а возобновляет ее снова VAD), генератор комфортного шума CNG (Comfort Noise Generator), создающий у говорящего ощущение присутствия собеседника на другом конце при отключенной передаче. Совершенные кодеки, например, G.723.1 Annex А или G.729 AnnexВ имеют возможность предоставлять удаленному декодеру информацию для восстановления шума с близкими к исходному параметрами.

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

Как было показано в предыдущем параграфе, к кадру, сгенерированному кодеком, добавляется необходимая дополнительная информация: заголовки IP (20 байтов), UDP (8 байтов) и RTP (12 байтов), поэтому большинство реализаций VoIP использует пересылку нескольких кадров в пакете. Число таких кадров ограничено максимально допустимой задержкой. В большинстве случаев в одном пакете передается до 120 мс речевой информации.

Еще одним фактором работы шлюзов VoIP является чувствительность к потерям кадров, являющимся неотъемлемым атрибутом IP-сетей. Применяются коды с исправлением ошибок, позволяющие снизить количество потерь кадров при данном числе потерянных пакетов. Некоторая избыточная информация распределяется между несколькими пакетами так, что при потерях некоторого числа пакетов кадры могут быть восстановлены. Но положительный эффект при введении избыточности для борьбы с потерями кадров не столь легко достижим, так как потери в IP-сетях происходят пачками, т.е. значительно более вероятно, что будут наблюдаться потери сразу нескольких пакетов подряд, чем потери всего одного из нескольких последовательно передаваемых пакетов. Так что, если применить простые схемы введения избыточности, например, повторяя посылку каждого кадра два раза в соседних пакетах, то это, скорее всего, окажется в реальных условиях бесполезным, приводя лишь к передаче значительного объема избыточной информации. Кроме того, введение избыточности отрицательно сказывается на задержке воспроизведения сигнала. Например, если мы повторяем один и тот же кадр в четырех следующих один за другим пакетах, для того чтобы обеспечить возможность восстановления информации при потере трех подряд идущих пакетов, декодер вынужден поддерживать буфер из четырех пакетов, а это вносит значительную дополнительную задержку. Влияние потерь кадров на качество воспроизводимой речи зависит от используемого кодека. Если потерян кадр, состоящий из N отсчетов кодека G.711, то на приемном конце будет отмечен пропуск звукового фрагмента длительностью N*125 мкс. Если используется более совершенный узкополосный кодек, то потеря кадра может сказываться на воспроизведении нескольких последующих, так как декодеру потребуется время для того, чтобы достичь синхронизации с кодером - потеря кадра длительностью 20 мс может привести к слышимому эффекту длительностью 150 мс и более. Кодеры типа G.723.1 разрабатывались так, что они функционируют без существенного ухудшения качества в условиях некоррелированных потерь до 3% кадров, однако при превышении этого порога качество ухудшается катастрофически.

Отметим, что G.711 - наиболее известный, часто называемый просто ИКМ, цифровой кодек речевых сигналов, поддерживаемый всеми шлюзами VoIP, был стандартизован ITU-T в 1965 году, его типичная оценка MOS составляет 4.3 Рекомендация G.723.1 утверждена ITU-T в ноябре 1995 года. Кодек G.723.1 имеет длительность кадра 30 мс с длительностью предварительного анализа 7.5 мс и два режима работы: 6.3 Кбит/ с (кадр имеет размер 189 битов, выровненных до 24 байтов) и 5.3 Кбит/с (кадр имеет размер 158 битов, выровненных до 20 байтов). G.723.1 обеспечивает оценку MOS 3.7 в режиме 6.3 Кбит/с и 3.9 в режиме 5.3 Кбит/с, имеет детектор речевой активности и обеспечивает генерацию комфортного шума на удаленном конце в период молчания.

ADPCM кодек G.726 (рекомендация принята в 1990 г.) обеспечивает кодирование цифрового потока G.711 со скоростью 40, 32, 24 или 16 Кбит/с, поддерживая оценки MOS на уровне 4.3 (32 Кбит/с), что часто принимается за эталон уровня качества телефонной связи (toll quality). В приложениях VoIP этот кодек практически не используется, так как он не обеспечивает достаточной устойчивости к потере информации.

Кодек G.728 использует оригинальную технологию линейного предсказания с малой задержкой LD-CELP (low delay code excited linear prediction) и обеспечивают оценки MOS, аналогичные G.726 при скорости передачи только 16 Кбит/с.

Кодек G.729 очень популярен в сетях Frame Relay, использует технологию CS-ASELP (Conjugate Structure, Algebraic Code Excited Linear Prediction) и обеспечивает скорость передачи 8 Кбит/с. В рамках спецификаций G.729 определены алгоритмы VAD, CNG и DTX.

Еще одной задачей шлюзов VoIP является передача сигналов многочастотного набора номера DTMF. Узкополосные кодеки, чтобы достичь низких скоростей передачи информации, опираются на тот факт, что сигнал, который они кодируют, представляет собой именно речь, а сигналы DTMF при прохождении через такие кодеки искажаются и не могут быть успешно опознаны соответствующим приемником на удаленном конце. В ряде случаев, а именно, когда пользователь ТфОП вынужден ввести какую-то дополнительную информацию в удаленную систему при уже установленном соединении (например, номер дебитной карты или номер пункта меню автоинформатора), необходимо обеспечить возможность надежной передачи DTMF-сигналов через сеть VoIP. Существуют две процедуры передачи DTMF-информации по сетям VoIP:

обязательный метод, в соответствии с которым специальное сообщение протокола Н.245 (Userinputindication) может содержать символы цифр и знаки "*" и "#". Используется надежное TCP-соединение, так что информация не может быть потеряна, однако из-за особенностей TCP могут иметь место значительные задержки;

нестандартный метод, предложенный VoIP форумом, может быть использован в терминалах H.323v2 при использовании процедуры fastStart и отсутствии канала Н.245. В этом случае для передачи DTMF открывается специальный RTP-сеанс, в котором передаются кодированные значения принятых цифр, а также амплитуды и длительности сигналов. Использование RTP позволяет четко привязать сигналы DTMF к реальному времени, что является важным преимуществом этого метода.

1.2.7 Сценарии IP-телефонии

Сети Н.323

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323. Сети на базе протоколов Н.323 ориентировались на интеграцию с телефонными сетями и вначале рассматривались как сети ISDN, наложенные на IP-сети.

В частности, процедура установления соединения в сетях IP-телефонии по Н.323 базировалась на рекомендации Q.931 и аналогична процедуре, используемой в ISDN.

Протокол Н.323 подробно рассматривается в главе 5 книги, а здесь отметим, что рекомендация Н.323 включает в себя довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов, а обеспечивает работу мультимедийных приложений в сетях с не гарантированным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видео и данными. Протокол RAS (Registration, Admission, Status), входящий в семейство протоколов Н.323, обеспечивает контроль использования сетевых ресурсов и поддерживает аутентификацию пользователей и начисление платы за услуги. Основными устройствами сети Н.323 являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit).

В контексте Softswitch целесообразно заметить, что рекомендациями предусмотрен еще один элемент сети Н.323 - прокси-сервер Н.323. Этот сервер функционирует на прикладном уровне и может проверять пакеты с информацией, которой обмениваются два приложения. Прокси-сервер может определять, с каким приложением (Н.323 или другим) ассоциирован вызов, и производить нужное соединение.

Входящий в состав Н.323 протокол Н.225.0 (Q.931) специфицирует процедуры установления, поддержания и разрушения соединения, а в качестве транспортного протокола использует протокол TCP. По протоколу И.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP, которые рассмотрены выше и представлены на рис.1.6.

В этом же параграфе была упомянута еще одна важная проблема - качество обслуживания в сетях Н.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы. Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, этот протокол используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IP-телефонии, характерная не только для сетей Н.323.

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

SIP-сеть

Более популярный сегодня подход к построению сетей IP-телефонии был предложен рабочей группой IETF с музыкальным названием MMUSIC в документе RFC 2543. В его основу положен протокол SIP (Session Initiation Protocol). Эта архитектура включает в себя также протокол резервирования ресурсов RSVP (Resource Reservation Protocol), рассмотренные выше в этой главе транспортный протокол реального времени RTP (Real-Time Transport Protocol; RFC 1889) и протокол передачи потоков в реальном времени RTSP (Real-Time Streaming Protocol; RFC 2326), протокол описания параметров связи SDP (Session Description Protocol; RFC 2327), а также протокол уведомления о связи SAP (Session Announcement Protocol). Сразу же подчеркнем, что функции протокола SIP не зависят ни от одного из этих протоколов.

Сообщения SIP могут переноситься как протоколом TCP, так и протоколом UDR. Там же протокол SIP поддерживает услуги Интеллектуальной сети, такие как преобразование (мэппинг) имён, переадресация и маршрутизация, что существенно при использовании SIP в Softswitch сети общего пользования, где приоритетной задачей Оператора является предоставление широкого спектра телефонных услуг. Другой важной особенностью протокола SIP является поддержка мобильности пользователя, т.е. его способности получать доступ к заказанным услугам в любом месте и с любого терминала, а также способности сети идентифицировать и аутен-тифицировать пользователя при его перемещении из одного места в другое.

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации. Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент UAC (User Agent Client) и агент пользователя - сервер UAS (User Agent Server). Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и передает обратно ответы, т.е. выступает в качестве вызываемой стороны. Кроме того, существует два типа сетевых серверов SIP: прокси-серверы (серверы-посредники) и серверы переадресации.