Разработка автоматического устройства для телефонной сети на основе SIP–протокола
Характеристика особенностей построения пакетной телефонии, основных целей ее создания. Интеграция протокола SIP с IP-сетями. Алгоритмы установления соединения. Сценарий установления соединения через прокси-сервер. Анализ качества обслуживания в сети.
| Рубрика | Коммуникации, связь, цифровые приборы и радиоэлектроника |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 19.06.2016 |
| Размер файла | 2,1 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
На рисунке 1.8 представлен пример ответа на запрос INVITE.
Рисунок 1.8 Пример SIP-ответа 200 OK
В этом примере приведен ответ пользователя Watson на приглашение принять участие в сеансе связи, полученное от пользователя Bell. Наиболее вероятный формат приглашения рассмотрен нами ранее (рисунок 1.7). Вызываемая сторона информирует вызывающую о том, что она может принимать в порту 5004 речевую информацию, закодированную в соответствии с алгоритмами кодирования PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса, показанного на рисунке 1.7. Из примера видно, что это ответ на запрос INVITE с полем CSeq:1.
После того, как мы рассмотрели запросы и ответы на них, можно отметить, что протокол SIP предусматривает разные алгоритмы установления соединения. При этом стоит обратить внимание, что одни и те же ответы можно интерпретировать по-разному в зависимости от конкретной ситуации.
1.5.8 Алгоритмы установления соединения
Протоколом SIP предусмотрены 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Различие между перечисленными сценариями заключается в том, что по-разному осуществляется поиск и приглашение вызываемого пользователя. В первом случае эти функции возлагает на себя прокси-сервер, а вызывающему пользователю необходимо знать только постоянный SIP-адрес вызываемого пользователя. Во втором случае вызывающая сторона самостоятельно устанавливает соединение, а сервер переадресации лишь реализует преобразование постоянного адреса вызываемого абонента в его текущий адрес. И, наконец, в третьем случае вызывающему пользователю для установления соединения необходимо знать текущий адрес вызываемого пользователя.
Перечисленные сценарии являются простейшими. Ведь прежде чем вызов достигнет адресата, он может пройти через несколько прокси-серверов, или сначала направляется к серверу переадресации, а затем проходит через один или несколько прокси-серверов. Кроме того, прокси-серверы могут размножать запросы и передавать их по разным направлениям и т.д. Рассмотрим более подробно сценарий с участием прокси-сервера.
1.5.9 Установление соединения с участием прокси-сервера
Администратор сети сообщает адрес этого прокси-сервера пользователям. Вызывающий пользователь передает запрос INVITE (1) на адрес прокси-сервера и порт 5060, используемый по умолчанию (Рисунок 1.9). В запросе пользователь указывает известный ему адрес вызываемого пользователя. Прокси-сервер запрашивает текущий адрес вызываемого пользователя у сервера определения местоположения (2), который и сообщает ему этот адрес (3). Далее прокси-сервер передает запрос INVITE непосредственно вызываемому оборудованию (4). Опять в запросе содержатся данные о функциональных возможностях вызывающего терминала, но при этом в запрос добавляется поле Via с адресом прокси-сервера для того, чтобы ответы на обратном пути шли через него. После приема и обработки запроса вызываемое оборудование сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing (5), копируя в него из запроса поля То, From, Call-ID, CSeq и Via. После приема вызова пользователем встречной стороне передается сообщение 200 OK (6), содержащее данные о функциональных возможностях вызываемого терминала в формате протокола SDP. Терминал вызывающего пользователя подтверждает прием ответа запросом АСК (7). На этом фаза установления соединения закончена и начинается разговорная фаза.
По завершении разговорной фазы одной из сторон передается запрос BYE (8), который подтверждается ответом 200 OK (9).
Все сообщения проходят через прокси-сервер, который может модифицировать в них некоторые поля.
Рисунок 1.9 Сценарий установления соединения через прокси-сервер
1.6 Реализация дополнительных услуг на базе протокола SIP
Рассмотрим пример реализации дополнительной услуги «Переадресация вызова» на базе протокола SIP .
Данная услуга позволяет пользователю назначить адрес, на который, при определенных условиях, следует направлять входящие к нему вызовы. Такими условиями могут быть занятость пользователя, отсутствие его ответа в течение заданного времени или и то, и другое; возможна также безусловная переадресация. Оборудование пользователя, заказавшего эту услугу, получив сообщение INVITE В, проверяет условия, в которых оно получено, и если условия требуют переадресации, передает сообщение INVITE с заголовком Also, указывая в нем адрес пользователя, к которому следует направить вызов. Терминал вызывающего пользователя, получив сообщение INVITE с таким заголовком, инициирует новый вызов по адресу, указанному в поле Also. В нашем случае пользователь А вызывает пользователя В, а терминал последнего переадресует вызов к пользователю С (Рисунок 1.10).
Рисунок 1.10 Дополнительная услуга "Переадресация вызова"
1.7 Выбор протокола IP-телефонии
При построении телефонной сети на базе IP-телефонии одним из важных вопросов является выбор протокола установления соединений. Существует, как уже было сказано выше, три вида таких протоколов и, следовательно, три подхода к построению сетей IP-телефонии: Н.323, являющийся основным стандартом для сетевых мультимедиа-приложений, SIP, протоколы, использующие принципы декомпозиции шлюзов, например MGCP (RFC 2705). Наиболее распространенные протоколы на базе которых строятся ПТ, это H.323 и SIP, поэтому выбор будет произведен среди этих протоколов. Для того чтобы сделать выбор в пользу того или иного протокола необходимым считается произвести сравнительный анализ данных протоколов.
Прежде чем начать сравнение функциональных возможностей протоколов SIP и Н.323, напомним, что протокол SIP значительно моложе своего соперника, и опыт его использования в сетях связи несопоставим с опытом использования протокола Н.323. Существует еще один момент, на который следует обратить внимание. Интенсивное внедрение технологии передачи речевой информации по IP-сетям потребовало постоянного наращивания функциональных возможностей как протокола Н.323 (к настоящему времени утверждена уже шестая версия протокола), так и протокола SIP (утверждена вторая версия протокола). Этот процесс приводит к тому, что достоинства одного из протоколов перенимаются другим.
И последнее. Оба протокола являются результатом решения одних и тех же задач специалистами ITU-T и комитета IETF. Естественно, что решение ITU-T оказалось ближе к традиционным телефонным сетям, а решение комитета IETF базируется на принципах, составляющих основу сети Internet.
Сравнение протоколов произведем по нескольким критериям.
Дополнительные услуги. Набор услуг, поддерживаемых обоими протоколами, примерно одинаков.
Примеры услуг, предоставляемых обоими протоколами:
* Перевод соединения в режим удержания (Call hold);
* Переключение связи (Call Transfer);
* Переадресация (Call Forwarding);
* Уведомление о новом вызове во время связи (Call Waiting);
* Конференция.
Рассмотрим последнюю услугу несколько более подробно. Протокол SIP предусматривает три способа организации конференции: с использованием устройства управления конференциями MCU, режима многоадресной рассылки и соединений участников друг с другом. В последних двух случаях функции управления конференциями могут быть распределены между терминалами, т.е. центральный контроллер конференций не нужен. Это позволяет организовывать конференции с практически неограниченным количеством участников.
Рекомендация Н.323 предусматривает те же три способа, но управление конференцией во всех случаях производится централизованно контроллером конференций МС (Multipoint Controller), который обрабатывает все сигнальные сообщения. Поэтому для организации конференции, во-первых, необходимо наличие контроллера МС у одного из терминалов, во-вторых, участник с активным контроллером МС не может выйти из конференции. Кроме того, при большом числе участников конференции МС может стать «узким местом» .
Протокол SIP изначально ориентирован на использование в IP-сетях с поддержкой режима многоадресной рассылки информации. Этот механизм используется в протоколе SIP не только для доставки речевой информации (как в протоколе Н.323), но и для переноса сигнальных сообщений. Например, в режиме многоадресной рассылки может передаваться сообщение INVITE, что облегчает определение местоположения пользователя и является очень удобным для центров обслуживания вызовов (Call-center) при организации групповых оповещений.
В то же время, протокол Н.323 предоставляет больше возможностей управления услугами, как в части аутентификации и учета, так и в части контроля использования сетевых ресурсов. Возможности протокола SIP в этой части беднее.
В протоколе SIP есть возможность указывать приоритеты в обслуживании вызовов, поскольку во многих странах существуют требования предоставлять преимущества некоторым пользователям. В протоколе Н.323 такой возможности нет. Кроме того, пользователь SIP-сети может регистрировать несколько своих адресов и указывать приоритетность каждого из них.
Персональная мобильность пользователей. Протокол SIP имеет хороший набор средств поддержки персональной мобильности пользователей, в число которых входит переадресация вызова к новому местоположению пользователя, одновременный поиск по нескольким направлениям (с обнаружением зацикливания маршрутов) и т.д. В протоколе SIP это организуется путем регистрации на сервере определения местоположения, взаимодействие с которым может поддерживаться любым протоколом. Персональная мобильность поддерживается и протоколом Н.323, но менее гибко.
Расширяемость протокола. Необходимой и важной в условиях эволюционирующего рынка является возможность введения новых версий протоколов и обеспечение совместимости различных версий одного протокола. Расширяемость (extensibility) протокола обеспечивается:
- согласованием параметров;
- стандартизацией кодеков;
- модульностью архитектуры.
Протокол SIP достаточно просто обеспечивает совместимость разных версий. Поля, которые не понятны оборудованию, просто игнорируются. Это уменьшает сложность протокола, а также облегчает обработку сообщений и внедрение новых услуг. Клиент может запросить какую-либо услугу с помощью заголовка Require. Сервер, получивший запрос с таким заголовком, проверяет, поддерживает ли он эту услугу, и если не поддерживает, то сообщает об этом в своем ответе, содержащем список поддерживаемых услуг.
В случае необходимости, в организации IANA (Internet Assigned Numbers Authority) могут быть зарегистрированы новые заголовки. Для регистрации в IANA отправляется запрос с именем заголовка и его назначением. Название заголовка выбирается таким образом, чтобы оно говорило об его назначении. Указанным образом разработчик может внедрять новые услуги.
Для обеспечения совместимости версий протокола SIP определено шесть основных видов запросов и 6 классов ответов на запросы. Так как определяющей в кодах ответов является первая цифра, то оборудование может указывать и интерпретировать только ее, а остальные цифры кода только дополняют смысл и их анализ не является обязательным.
Более поздние версии протокола Н.323 должны поддерживать более ранние версии. Но возможна ситуация, когда производители поддерживают только одну версию, чтобы уменьшить размер сообщений и облегчить их декодирование.
Новые функциональные возможности вводятся в протокол Н.323 с помощью поля NonStandardParameter . Оно содержит код производителя и, следом за ним, код услуги, который действителен только для этого производителя. Это позволяет производителю расширять услуги, но сопряжено с некоторыми ограничениями. Во-первых, невозможно запросить у вызываемой стороны информацию о поддерживаемых ею услугах, во-вторых, невозможно добавить новое значение уже существующего параметра. Существуют также проблемы, связанные с обеспечением взаимодействия оборудования разных производителей.
На расширение возможностей протокола, как и на совместимость оборудования, его реализующего, оказывает влияние и набор кодеков, поддерживаемый протоколом. В протоколе SIP для передачи информации о функциональных возможностях терминала используется протокол SDP. Если производитель поддерживает какой-то особенный алгоритм кодирования, то этот алгоритм просто регистрируется в организации IANA.
В протоколе Н.323 все кодеки должны быть стандартизированы. Поэтому приложения с нестандартными алгоритмами кодирования могут столкнуться с проблемами при реализации их на базе протокола Н.323.
Протокол SIP состоит из набора законченных компонентов (модулей), которые могут заменяться в зависимости от требований и могут работать независимо друг от друга. Этот набор включает в себя модули поддержки сигнализации для базового соединения, для регистрации и для определения местоположения пользователя, которые не зависят от модулей поддержки качества обслуживания (QoS), работы с директориями, описания сеансов связи, развертывания услуг (service discovery) и управления конфигурацией.
Архитектура протокола Н.323 монолитна и представляет собой интегрированный набор протоколов для одного применения. Протокол состоит из трех основных составляющих, и для создания новой услуги может потребоваться модификация каждой из этих составляющих.
Масштабируемость сети (scalablllty). Сервер SIP, по умолчанию, не хранит сведений о текущих сеансах связи и поэтому может обработать больше вызовов, чем привратник Н.323, который хранит эти сведения (statefull). Вместе с тем, отсутствие таких сведений, по мнению некоторых специалистов, может вызвать трудности при организации взаимодействия сети IP-телефонии с ТФОП.
Необходимо также иметь в виду зоновую архитектуру сети Н.323, позволяющую обеспечить расширяемость сети путем увеличения количества зон.
Время установления соединения. Следующей существенной характеристикой протоколов является время, которое требуется, чтобы установить соединение. В запросе INVITE протокола SIP содержится вся необходимая для установления соединения информация, включая описание функциональных возможностей терминала. Таким образом, в протоколе SIP для установления соединения требуется одна транзакция, а в протоколе Н.323 необходимо производить обмен сообщениями несколько раз. По этим причинам затраты времени на установление соединения в протоколе SIP значительно меньше затрат времени в протоколе Н.323. Правда, при использовании инкапсуляции сообщений Н.245 в сообщения Н.225 или процедуры Fast Connect время установления соединения значительно уменьшается.
Кроме того, на время установления соединения влияет также и нижележащий транспортный протокол, переносящий сигнальную информацию. Ранние версии протокола Н.323 предусматривали использование для переноса сигнальных сообщений Н.225 и Н.245 только протокол TCP, и лишь третья версия протокола предусматривает возможность использования протокола UDP. Протоколом SIP использование протоколов TCP и UDP предусматривалось с самого начала.
Оценка времени установления соединения производится в условных единицах - RTT (round trip time) - и составляет для протокола SIP 1,5+2,5 RTT, а для протокола Н .323 6-7 RTT .
Адресация. К числу системных характеристик, несомненно, относится и предусматриваемая протоколами адресация. Использование URL является сильной стороной протокола SIP и позволяет легко интегрировать его в существующую систему DNS-серверов и внедрять в оборудование, работающее в IP-сетях. Пользователь получает возможность переправлять вызовы на Web-страницы или использовать электронную почту. Адресом в SIP может также служить телефонный номер с адресом используемого шлюза.
В протоколе Н.323 используются транспортные адреса и alias-адреса. В качестве последнего может использоваться телефонный номер, имя пользователя или адрес электронной почты. Для преобразования alias-адреса в транспортный адрес обязательно участие привратника.
Сложность протокола. Протокол Н.323, несомненно, сложнее протокола SIP. Общий объем спецификаций протокола Н.323 составляет примерно 700 страниц. Объем спецификаций протокола SIP составляет 150 страниц. Протокол Н.323 использует большое количество информационных полей в сообщениях (до 100), при нескольких десятках таких же полей в протоколе SIP. При этом для организации базового соединения в протоколе SIP достаточно использовать всего три типа запросов (INVITE, BYE и АСК) и несколько полей (То, From, Call-ID, CSeq).
Протокол SIP использует текстовый формат сообщений, подобно протоколу HTTP. Это облегчает синтаксический анализ и генерацию кода, позволяет реализовать протокол на базе любого языка программирования, облегчает эксплуатационное управление, дает возможность ручного ввода некоторых полей, облегчает анализ сообщений. Название заголовков SIP-сообщений ясно указывает их назначение.
Протокол Н.323 использует двоичное представление своих сообщений на базе языка ASN.1, поэтому их непосредственное чтение затруднительно. Для кодирования и декодирования сообщений необходимо использовать компилятор ASN. 1. Но, в то же время, обработка сообщений, представленных в двоичном виде, производится быстрее.
Довольно сложным представляется взаимодействие протокола Н.323 с межсетевым экраном (firewall). Кроме того, в протоколе Н.323 существует дублирование функций. Так, например, оба протокола Н.245 и RTCP имеют средства управления конференцией и осуществления обратной связи.
Выводы
На основе проведенного выше сравнения можно сделать вывод о том, что протокол SIP больше подходит для использования в ПТ, где интегрированы различные виды сервисов. Более выгодная, с точки зрения построения, архитектура сети и простота реализации дополнительного функционала делают еще более привлекательным для внедрения.
Необходимо отметить еще один факт в пользу выбора SIP, это то что ключевые архитектурные элементы сети, является практически бесплатными с открытым исходным кодом (Open Sourse), что является более выгодным решением, с экономической точки зрения.
Глава 2. Качество обслуживания в сети передачи голоса
телефония пакетный протокол сеть
Одним из основных аспектов, который должен приниматься во внимание при проектировании сетей IP-телефонии, является обеспечение качества обслуживания. Специфика пакетных сетей состоит в том, что, в отличие от сетей с коммутацией каналов, в одном и том же информационном потоке может передаваться разнородный трафик. При этом каждый из типов трафика характеризуется рядом критичных и некритичных параметров. Для передачи голосового трафика через пакетные сети вводится понятие классов обслуживания, позволяющих оценить качество предоставления услуги в пакетной сети. Определение качества обслуживания в настоящий момент является субъективным и базируется на методе экспертных оценок, т.е. априори невозможно абсолютно гарантировать, что при проектировании сети будут заложены сетевые характеристики, позволяющие однозначно обеспечить требуемое качество. С другой стороны, пакетные сети имеют развитые механизмы обеспечения качества обслуживания, использование которых позволяет влиять на предоставление услуг связи в процессе эксплуатации.
В связи с задачей построения телефонной сети на основе технологии VoIP приведём некоторые сведения о способах оценки качества для телефонных сетей вообще, факторах, влияющих на качество передачи голоса в пакетных сетях и способах обеспечения необходимого качества обслуживания.
2.1 Категории и классы качества передачи речи
В традиционной телефонии применяется несколько наборов критериев, описывающих качество обслуживания. Мы рассмотрим для иллюстрации одну из классификаций, специально разработанную для оценки качества передачи голоса в IP сетях. Она изложена в документе ETSI TS 102 024 - 2, разработанном в рамках проекта TIHPON (Release 5, сентябрь 2003 г.) .
В этом документе определяются три класса качества:
1) широкополосный (wideband), обеспечивающий пользователям качество лучшее, чем в ТфОП. Он требует использования широкополосных кодеков (обрабатывающих аналоговые сигналы с полосой более 3,1 кГц) и сетей IP, спроектированных в соответствии с требованиями QoS;
2) узкополосный (narrowband), обеспечивающий пользователям качество, подобное ТфОП. Он требует использования спроектированных в соответствии с требованиями QoS сетей IP;
3) негарантированный (best effort), предоставляющий пригодные для использования услуги, но без гарантий на характеристики соединения. Могут быть периоды значительного ухудшения качества речи и большие задержки из конца в конец, которые отрицательно влияют на общую диалоговую интерактивность. Этот класс качества обеспечивается в сетях IP, разработанных без учёта требований QoS, например, общедоступного Интернета.
Широкополосный и узкополосный классы обеспечивают гарантии характеристик для 95% всех соединений.
Узкополосный класс делится на три подкласса:
· высокий (high), обеспечивающий качество, эквивалентное тому, которое предоставляется сетями ISDN;
· средний (medium), обеспечивающий качество, эквивалентное тому, которое предоставляется услугами беспроводной мобильной телефонии в условиях хорошей радиосвязи, например в сетях GSM, использующих кодеки EFR, или системами, использующими кодеки по Рекомендации МСЭ-Т G.726 на скорости 32 Кбит/с;
· приемлемый (acceptable), обеспечивающий качество, эквивалентное тому, которое предоставляется обычными услугами беспроводной мобильной телефонии, например в сетях GSM, использующих кодеки FR, или системами, включающими геостационарные спутники.
Каждый из вышеуказанных классов определяется тремя характеристиками:
1) общим рейтингом качества передачи (R);
2) качеством речи, воспринимаемым слушателем (качество односторонней неинтерактивной передачи речи из конца в конец);
3) задержкой из конца в конец (средней односторонней).
Значения этих характеристик для каждого из классов качества приведены в следующей таблице 2.1 :
Таблица 2.1 Характеристики классов качества ETSI
|
Классы качества передачи речи в соответствии с подходом ETSI |
||||||
|
Характеристика |
3 (широкополосный) |
2 (узкополосный) |
1(best effort) негарантированный |
|||
|
2-H (высокий) |
2-M (средний) |
2-A (приемлемый) |
||||
|
Общий рейтинг качества передачи (R) |
(В настоящее время находится на этапе изучения в международных организациях стандартизации ) |
> 80 |
> 70 |
> 50 |
> 50 (ориентир) |
|
|
Относительное качество речи (одностороннее, неинтерактивное) |
Лучше, чем G.711 |
Равно или лучше, чем G.726 при 32 Кбит/с |
Равно или лучше, чем GSM-FR |
Не определено |
Не определено |
|
|
Результирующий общий рейтинг качества передачи (R) |
Не применяется |
> 86 |
> 73 |
> 50 |
> 50 |
|
|
Задержка из конца в конец, мс |
< 100 |
< 100 |
< 150 |
< 400 |
<400 (ориентир) |
Услуга телефонной связи сети общего пользования должна обеспечивать пользователям качество передачи речи, соответствующее наилучшей и высокой категориям по Рекомендации МСЭ-Т G.109 или широкополосному и узкополосному высокому классам по ETSI TS 102 024 - 2.
Качество из конца в конец, соответствующее средней категории или узкополосному среднему классу, может предоставляться при соединениях с абонентами сетей подвижной связи или корпоративным клиентам при наличии с ними соответствующих договоров. Более низкое качество в телефонных сетях общего пользования допускаться не должно.
2.2 Влияние оконечного оборудования и сети
Общее качество передачи речи определяется факторами, зависящими как от сети, так и от оконечного оборудования.
Основные параметры, влияющие на качество передачи речи из конца в конец, и их отношение к терминальному оборудованию и/или сети приведены в следующей таблице 2.2.
Таблица 2.2 Влияние параметров на передачу речи
|
Параметр |
Связан с терминальным оборудованием сетью |
||
|
Тип кодека |
Да |
Нет |
|
|
Потери пакетов |
Нет (1) |
Да |
|
|
Задержка |
Да (2) |
Да (3) |
|
|
Вариации задержки |
Нет (4) |
Да (5) |
Примечания.
1. Предполагается достаточно большая емкость буфера компенсации джиттера, позволяющая избежать потерь пакетов.
2. Обусловлена кодированием/пакетизацией речи и компенсацией джиттера.
3. Обусловлена маршрутизацией/распространением в сети.
4. Предполагается, что вся вариация задержки включена в задержку в терминале.
5. Вариация задержки вносится сетью, но компенсируются терминалом.
В соответствии с Рекомендацией МСЭ-Т I.380/Y.1540 основными параметрами, характеризующими качество обслуживания (QoS) в сетях IP, являются :
l задержка переноса пакетов;
l вариация задержки пакетов (джиттер);
l коэффициент потери пакетов;
l коэффициент ошибок по пакетам.
Последний параметр зависит в основном от используемых на физическом уровне сети систем передачи, и проблем с ним, как правило, не возникает. Механизмы обеспечения QoS в сетях IP направлены на улучшение первых трех из указанных параметров. Именно они и являются основными характеристиками транспортной сети, определяющими качество передачи речи (рисунок 2.1). Эти же параметры, как правило, используются и в соглашениях об уровне обслуживания (Service Level Agreement - SLA), предлагаемых ведущими операторами своим клиентам.
Рисунок 2.1 Взаимовлияние факторов, определяющих качество передачи речи
Перечислим некоторые характеристики сети передачи данных, влияющие на качество передачи голоса.
2.3 Уровни сервиса
Негарантированная доставка данных (best-effort service). Обеспечение связности узлов сети без гарантии времени и самого факта доставки пакета в пункт назначения. Отбрасывание пакета может произойти только в случае переполнения буфера входной или выходной очереди маршрутизатора. Негарантированная доставка пакетов является на сегодняшний день единственной услугой, поддерживаемой в публичном секторе Internet.
Дифференцированное обслуживание (differentiated service). Дифференцирование обслуживание предполагает разделение трафика на классы на основе требований к качеству обслуживания. Каждый класс трафика дифференцируется и обрабатывается сетью в соответствии с заданными для этого класса механизмами QoS.
Следует отметить, что дифференцированное обслуживание само по себе не предполагает обеспечения гарантий предоставляемых услуг. В соответствии с данной схемой трафик распределяется по классам, каждый из которых имеет свой собственный приоритет. По этой причине дифференцированное обслуживание довольно часто называют мягким QoS (soft QoS). Дифференцированное обслуживание удобно применять в сетях с интенсивным трафиком приложений.
Гарантированное обслуживание (guaranteed service). Гарантированное обслуживание предполагает резервирование сетевых ресурсов с целью удовлетворения специфических требований к обслуживанию со стороны потоков трафика.
В соответствии с гарантированным обслуживанием выполняется предварительное резервирование сетевых ресурсов по всей траектории движения трафика.
Гарантированное обслуживание довольно часто называют еще жестким QoS (hard QoS) в связи с предъявлением строгих требований к ресурсам сети.
Гарантированное обслуживание при наличии соответствующего оборудования может быть реализовано в рамках телефонной сети, но, к сожалению, резервирование ресурсов на всем пути следования отдельных потоков трафика невозможно реализовать в масштабах магистрали Internet, обслуживающей в отдельный момент времени тысячи потоков данных.
2.4 Характеристики производительности сетевого соединения
Внедрение механизмов QoS предполагает обеспечение со стороны сети соединения с определенными ограничениями по производительности. Основными характеристиками производительности сетевого соединения являются полоса пропускания, задержка, дрожание и уровень потери пакетов.
Полоса пропускания. Термин полоса пропускания (bandwidth) используется для описания номинальной пропускной способности среды передачи информации, протокола или соединения.
Как правило, каждое соединение, нуждающееся в гарантированном качестве обслуживания, требует от сети резервирования минимальной полосы пропускания. К примеру, приложения, ориентированные на передачу оцифрованной речи, создают поток информации интенсивностью 64 Кбит/с. Эффективное использование таких приложений становится практически невозможным вследствие снижения полосы пропускания ниже 64 Кбит/с на каком-либо из участков соединения.
Задержка при передаче пакета (packet delay), или латентность (latency), на каждом переходе состоит из задержки сериализации, задержки распространения и задержки коммутации. Ниже приведены определения каждого из названных выше типов задержки.
Задержка сериализации (serialization delay). Время, которое требуется устройству на передачу пакета при заданной ширине полосы пропускания. Задержка сериализации зависит как от ширины полосы пропускания канала передачи информации, так и от размера передаваемого пакета. Довольно часто задержку сериализации называют еще задержкой передачи (transmission delay).
Задержка распространения (propagation delay). Время, которое требуется переданному биту информации для достижения принимающего устройства на другом конце канала. Задержка распространения зависит от расстояния и используемой среды передачи информации, а не от полосы пропускания. Поскольку в наилучшем случае скорость передачи информации соизмерима со скоростью света, в случае глобальных сетей эта величина может составлять десятки миллисекунд для наземных линий и сотни для спутниковых.
Задержка коммутации (switching delay). Время, которое требуется устройству, получившему пакет, для начала его передачи следующему устройству. Как правило, это значение меньше 10 нс.
Обычно каждый из пакетов, принадлежащий одному и тому же потоку трафика, передается с различным значением задержки. Задержка при передаче пакетов меняется в зависимости от состояния промежуточных сетей.
Если сеть не испытывает перегрузки, то пакеты не ставятся в очередь в маршрутизаторах, а общее время задержки при передаче пакета состоит из суммы задержки сериализации и задержки распространения на каждом промежуточном переходе. В этом случае можно говорить о минимально возможной задержке при передаче пакетов через заданную сеть. Следует отметить, что задержка сериализации становится незначительной по сравнению с задержкой распространения при передаче пакета по каналу с большой пропускной способностью.
Если же сеть перегружена, задержки при организации очередей в маршрутизаторах начинают влиять на общую задержку при передаче пакетов, и приводят к возникновению разницы в задержке при передаче различных пакетов одного и того же потока. Колебание задержки при передаче пакетов получило название джиттер-пакетов (packet jitter).
Данный параметр имеет большую важность, поскольку именно он определяет максимальную задержку при приеме пакетов в конечном пункте назначения. Принимающая сторона, в зависимости от типа используемого приложения, может попытаться компенсировать дрожание пакетов за счет организации приемного буфера для хранения принятых пакетов на время, меньшее или равное верхней границе дрожания. К этой категории относятся приложения, ориентированные на передачу/прием непрерывных потоков данных, например IP-телефония или приложения, обеспечивающие проведение видеоконференций.
Потеря пакетов. Уровень потери пакетов (packet loss) определяет количество пакетов, отбрасываемых сетью во время передачи. Основными причинами потери пакетов являются перегрузка сети и повреждение пакетов во время передачи по линии связи. Чаще всего отбрасывание происходит в местах перегрузки, где число поступающих пакетов намного превышает верхнюю границу размера выходной очереди. Кроме того, отбрасывание пакетов может быть вызвано недостаточным размером входного буфера. Как правило, уровень потери выражается как доля отброшенных пакетов за определенный интервал времени.
Как правило, хорошо спроектированные сети характеризуются очень низким значением потери пакетов. Потеря пакетов также несвойственна приложениям, для которых были заранее зарезервированы требуемые этими приложениями ресурсы. Что касается волоконно-оптических линий связи со значением частоты появления ошибочных битов (Bit Error Rate - BER) 10е-9, то здесь потеря пакетов возможна только в случае их отбрасывания в местах перегрузки сети. Отбрасывание пакетов, к сожалению, является неизбежным явлением при негарантированной доставке трафика, хотя и в этом случае оно обусловливается крайней необходимостью.
2.5 Методы обеспечения качества обслуживания
Существует два метода обеспечения качества обслуживания: IntServ и DiffServ. Хотелось бы более подробно рассмотреть ключевые аспекты данных методов, так как качество обслуживания в ПТ ЯНЦ УФ АО «KAZTRANSCOM» реализовано именно с помощью дифференциального метода.
2.5.1 Архитектура интегрированных услуг IntServ
Integrated Service (IntServ, RFC 1633) - модель интегрированного обслуживания. Может обеспечить сквозное (End-to-End) качество обслуживания, гарантируя необходимую пропускную способность. IntServ использует для своих целей протокол сигнализации RSVP, позволяет приложениям выражать сквозные требования к ресурсам и содержит механизмы обеспечения данных требований. IntServ можно кратко охарактеризовать как резервирование ресурсов (Resource reservation).
Протокол RSVP
Данный протокол позволяет приложениям посылать сигналы в сеть о своих QoS-требованиях для каждого потока. Чтобы определить количественные характеристики этих требований с целью управления доступом, используются служебные параметры.
Протокол RSVP сигнализирует о запросах резервирования ресурсов по доступному маршрутизируемому пути в сети. При этом RSVP не производит собственную маршрутизацию; напротив, этот протокол был разработан для использования других, более мощных протоколов маршрутизации. Как и любой другой IР-трафик, при определении пути для данных и управляющего трафика RSVP полагается на применяемый в сети протокол маршрутизации.
Работа протокола RSVP
Конечные системы используют протокол RSVP для запрашивания у сети определенного уровня QoS от имени потока данных приложения. RSVP-запросы передаются по сети при прохождении каждого узла, который применяется для передачи потока. Протокол RSVP пытается зарезервировать ресурсы для потока данных на каждом из этих узлов.
RSVP-резервирование ресурсов для потока можно разбить на два главных типа: индивидуальное и общее.
Индивидуальное резервирование (distinct reservations) применяется в тех приложениях, в которых несколько источников данных могут отправлять информацию одновременно. В видеоприложениях каждый отправитель генерирует индивидуальный поток данных, для которого необходимо осуществлять отдельное управление доступом и планирование очереди на всем пути к получателю. Следовательно, для такого потока необходимо осуществлять отдельное резервирование ресурсов для каждого отправителя и для каждого канала в пути.
Самый простой случай индивидуального резервирования ресурсов наблюдается на примере приложения с одноадресным трафиком, где есть только один отправитель и один получатель.
Общее резервирование (shared reservations) применяется в тех приложениях, в которых несколько источников данных не склонно передавать информацию одновременно, например цифровые аудиоприложения, такие как приложения VoIP. В этом случае, поскольку в любой отдельно взятый промежуток времени разговор ведет небольшое число людей, информация передается лишь небольшим ограниченным количеством отправителей. Такой поток не нуждается в отдельном резервировании ресурсов для каждого отправителя, для него нужно всего лишь одно резервирование, которое при необходимости можно будет применить к любому отправителю в группе.
Типы услуг
Протокол RSVP предоставляет два типа интегрированных услуг, которые получатели могут запрашивать с помощью сообщений RSVP: службу регулируемой нагрузки и службу гарантированной битовой скорости.
Служба регулируемой нагрузки (controlled load service) обеспечивает гарантию того, что зарезервированный поток достигнет своего пункта назначения с минимальным вмешательством со стороны трафика, доставляемого без гарантий. Более того, в реализации этой услуги компанией Cisco предусмотрена изоляция отдельных зарезервированных потоков. Изоляция потока позволяет исключить влияние других присутствующих в сети зарезервированных потоков при резервировании ресурсов.
Как правило, служба регулируемой нагрузки применяется при передаче трафика Internet-приложений, чувствительных к перегрузкам в сети.
Служба гарантированной битовой скорости (guaranteed bit rate service) обеспечивает ограничение задержки без отбрасывания дейтаграмм, удовлетворяющих параметрам трафика, в условиях отсутствия сбоев в работе сетевых компонентов или изменений в информации о маршрутах во время жизни потока. Эта служба гарантирует минимальное вмешательство со стороны трафика, доставляемого без гарантий, изоляцию зарезервированных потоков и числовое выражение максимальной задержки.
Служба гарантированной битовой скорости может обеспечить только максимальную, но не минимальную или среднюю задержку дейтаграмм.
Служба гарантированной битовой скорости лучше всего подходит для тех приложений масштаба реального времени, которые позволяют воспроизводить аудио- и видеофайлы.
Масштабируемость протокола RSVP
Недостатком протокола RSVP является то, что объем требуемой информации о состоянии потоков увеличивается с ростом числа резервирований ресурсов для потоков трафика.
Так как в Internet-магистрали в любое время могут существовать многие сотни тысяч одноадресных и многоадресных потоков, использование информации о состоянии каждого потока считается неподходящим решением для магистралей Internet.
Кроме того, даже в пакетной сети препятствием для использования протокола RSVP может являться требование его поддержки всеми маршрутизаторами на пути потока.
2.5.2 Архитектура дифференцированных услуг DiffServ
Архитектурную модель diffserv можно сравнить с мостом, соединяющим механизм гарантированного качества обслуживания модели intserv с механизмом негарантированной доставки трафика. Модель diffserv обеспечивает дифференцирование трафика путем его разбивки на классы с различным приоритетом.
Главной задачей подхода diffserv является определение стандартизированного байта дифференцированной услуги (DS) - байта типа обслуживания (Type of Service - ToS) из заголовка пакета IPv4 и байта класса трафика (Traffic Class) пакета IPv6. От данной маркировки зависит принятие решения о продвижении пакета данных на каждом переходе (per-hop behavior - РНВ), т.е. в каждом промежуточном узле.
Архитектура дифференцированных услуг обеспечивает базовую основу, которая может быть использована операторами для предоставления своим клиентам большого диапазона различных предложений в зависимости от предъявляемых требований к качеству обслуживания. Клиент может выбрать требуемый уровень услуг путем установки соответствующего значения поля кода дифференцированной услуги (Differentiated Services Code Point - DSCP) для пакетов определенного приложения. Код дифференцированной услуги определяет цепочку решений о продвижении пакета в каждом промежуточном узле сети оператора (РНВ-политика).
Рисунок 2.2 Архитектура DiffServ
Архитектура метода DiffServ
РНВ-политика - политика пошагового обслуживания, определяет поведение сетевого узла в отношении пакетов с определенным значением поля DSCP. Все пакеты потока трафика со специфическим требованием к обслуживанию несут в себе одно и то же значение поля DSCP.
Все узлы внутри diffserv-домена определяют РНВ-политику, которая должна быть применена к пакету на основе хранящегося в нем значения поля кода дифференцированной услуги. Кроме того, пограничные узлы diffserv-домена выполняют важную функцию формирования поступающего в diffserv-домен трафика. Формирование трафика включает в себя выполнение таких функций, как:
· классификация пакетов (установка значения поля DSCP);
· ограничение трафика.
Формирование трафика обычно выносится на входной интерфейс поступающих в diffserv-домен пакетов. Формирование играет решающую роль в управлении поступающим в diffserv-домен трафиком, поскольку в этом случае для каждого пакета сеть может определить соответствующую ему РНВ-политику.
Формирователи трафика
Формирователи трафика - это различные функции качества обслуживания, которые должны быть реализованы в пограничных устройствах сети. Граничные функции классифицируют или маркируют трафик путем установки соответствующего значения поля DSCP, а также проводят мониторинг входящего в сеть трафика с целью проверки его соответствия установленному профилю.
Код дифференцированной услуги представляет собой поле, на основании значения которого определяется способ обработки пакета в diffserv-домене. В качестве обрабатывающей трафик функции может выступать функция классификации пакетов, функция маркировки DSCP-поля или же функция дозирования трафика, наделенная либо полномочиями выравнивания трафика, либо полномочиями отбрасывания пакетов.
Классификатор пакетов выбирает пакет из потока трафика на основании анализа части содержимого заголовка пакета. Наиболее распространенный способ классификации пакетов заключается в анализе поля DSCP, однако теоретически возможна классификация пакета на основании значения других полей его заголовка. Функция классификации пакета определяет соответствующий этому пакету класс трафика.
Функция маркировки предназначена для записи/перезаписи поля DSCP в зависимости от класса трафика, к которому относится данный пакет.
Функция дозирования проверяет трафик на соответствие заданному профилю на основании дескриптора трафика, такого как корзина маркеров. Результаты проверки могут передаваться функции маркировки трафика, а также либо функции выравнивания трафика, либо функции отбрасывания пакетов - для принятия соответствующего решения в отношении "плановых" и "внеплановых" пакетов.
Функция выравнивания трафика (traffic shaping) осуществляет задержку пакетов путем их буферизации с целью удовлетворения параметров заданного профиля.
Функция отбрасывания пакетов осуществляет отбрасывание всех пакетов, не удовлетворяющих параметрам заданного профиля трафика. Это действие часто называют также ограничением трафика (traffic policing).
РНВ-политика
Сетевые узлы с поддержкой дифференцированного обслуживания используют поле DSCP в заголовке IP-пакета для определения соответствующей этому пакету РНВ-политики.
РНВ-политика может быть определена в терминах приоритета в предоставлении ресурсов по отношению к другим РНВ-политикам или же с помощью таких измеряемых характеристик трафика, как задержка пакетов, уровень потери пакетов или дрожание трафика.
В качестве стандартной РНВ-политики в diffserv-сети можно рассматривать негарантированную доставку трафика. В соответствии с архитектурой дифференцированного обслуживания каждой РНВ-политике рекомендуется назначить определенный код DSCP, однако поставщик услуг волен выбрать отличные от рекомендованных значения поля DSCP для своей собственной сети. Рекомендованное значение поля DSCP для политики негарантированной доставки пакетов равняется 000 000.
Существуют две стандартные РНВ-политики - РНВ-политика немедленной передачи (EF РНВ) и РНВ-политика гарантированной доставки (AF РНВ).
РНВ-политика немедленной передачи пакетов (Expedited Forwarding РНВ - EF РНВ)
Используется для обеспечения сквозного обслуживания пакетов в узлах diffserv-домена, характерными чертами которого являются низкий уровень потери пакетов, малая задержка, незначительное дрожание трафика, а также гарантированная полоса пропускания. Политика EF РНВ применяется для обслуживания трафика таких приложений, как передача голоса по сетям IP (Voice over IP - VoIP), приложений видеоконференций, а также для обеспечения таких услуг, как передача информации по виртуальным арендуемым каналам, поскольку эта услуга представляет собой двухточечное соединение конечных узлов diffserv-домена. Подобный тип обслуживания достаточно часто называют также услугами высокого класса (premium service).
Один из способов избежать задержки пакетов, связанной с возникновением больших очередей, - ограничение максимальной интенсивности входного потока трафика минимальной интенсивностью его выходного потока. РНВ-политика немедленной передачи пакетов предусматривает установку значения интенсивности выходного потока трафика, в то время как интенсивность входного потока контролируется формирователями трафика, реализованными в пограничных устройствах сети. Как правило, интенсивность входящего и исходящего потоков измеряется с интервалами, равными времени, которое требуется для передачи MTU-пакета (пакета максимального размера, который может быть передан через интерфейс маршрутизатора) по данной линии связи. Когда речь идет о передаче трафика через перегруженный сегмент сети (а это предполагает наличие больших накопленных очередей), данная функциональная возможность может быть реализована за счет применения различных механизмов обслуживания очередей.
Глава 3. РНВ-политика гарантированной доставки пакетов (AF РНВ)
РНВ-политика гарантированной доставки пакетов (Assured Forwarding РНВ - AF РНВ) представляет собой средство, с помощью которого поставщик услуг может обеспечить несколько различных уровней надежности доставки IP-пакетов, полученных из diffserv-домена клиента. Политика AF РНВ является приемлемой для большинства ТСР-приложений.
РНВ-политика гарантированной доставки пакетов подразумевает наличие различных уровней обслуживания для каждого из четырех классов AF-трафика. Каждому классу AF-трафика соответствует собственная очередь пакетов, что позволяет проводить эффективное управление полосой пропускания. Каждый класс AF-трафика характеризуется тремя уровнями приоритета отбрасывания пакетов (низкий, средний и высокий), что позволяет реализовать механизм управления очередью по типу механизма произвольного раннего обнаружения (Random Early Detection - RED).
Интеграция с городской станцией происходит с помощью SI2000 ГТС и подключенного к ней шлюза Mediant1000 по потоку E1 c сигнализацией DSS, а также Media Pack 114 FXS на удаленном конце (абонентский терминал). Пример построения городской телефонии на основе конфигурации WiMAX изображен на рисунке 3.6.
Рис. 3.1 Схема организации телефонной сети УФ АО «KazTransCom».
3.1 Сопряжение VoIP-сети с телефонной сетью общего пользования
Для сопряжения VoIP-сети с ТфОП необходимо использовать медиа -шлюз чтобы произвести преобразование SIP трафика.
Mедиа-шлюз (Mediant1000) выполняет функции трансляции SIP протокола (VoIP-сети) в поток E1 далее он попадает на ГТС SI2000 где в последующим коммутируется.
3.1.1 Детальное описание Mediant 1000
Высокопроизводительный универсальный шлюз с расширяемой архитектурой Mediant 1000 обеспечивает превосходное качество и оптимизацию пакетной передачи голоса поверх протокола IP (VoIP). Mediant 1000 имеет модульную архитектуру и поддерживает до 4 потоков E1 или T1, а также до 24 аналоговых портов FXS/FXO в различных сочетаниях, обеспечивая непревзойденную гибкость при внедрении технологий VoIP в сетях масштаба предприятия.
Кроме функций голосового шлюза Mediant 1000 позволяет размещать приложения и служит IP-PBX платформой.
Шлюзы серии Mediant 1000 полностью совместимы с большинством популярных шлюзов, софтсвичей, прокси серверов, IP телефонов и межсетевых экранов.
Технические характеристики
Интерфейсы
Поддерживаемые модули
6 слотов для инсталляции аналоговых модулей
4 слота для инсталляции цифровых модулей
Поддержка до 24 аналоговых портов
Поддержка до 4 цифровых потоков
Цифровые модули
Поддержка 1,2 или 4 цифровых потоков E1/T1, RJ-48c
Поддержка до 4 цифровых модулей одним шлюзом (но не больше 4 цифровых потоков)
Возможность резервирования цифровых потоков (1+1 или 2+2)
Аналоговые модули FXO/FXS
2 или 4 порта на одном модуле, RJ-11
Поддержка до 6 аналоговых модулей на одном шлюзе
Одна линия бесперебойного питания для FXS модулей (для случая отключения питания или проблем в сети)
Модуль конференцсвязи
Поддержка модуля конференцсвязи для работы с соответствующими приложениями
I/O
MOH (Music on Hold, проигрывание музыки во время удержания звонка), NB (Night Bell, ночной режим)
Сетевые интерфейсы
2 порта Ethernet 10/100 BASE-T, RJ-45
RS-232
Debugging
Обработка голосовых данных
Голосовые кодеки
G.711, G.726, G.723.1, G.729A, GSM-FR, возможность независимого выбора используемых кодеков для каждого канала
Эхо компенсация
G.165, G.168-2002, 32, 64, 128 msec
Обеспечение качества
Динамически настраиваемый/адаптируемый размер буфера для компенсации временного джиттера, VAD, CNG, 802.1p/Q VLAN tagging, DiffServ, мониторинг качества голоса, G.729B
IP Transport
VoIP (RTP/RTCP) для IETF RFC 3550 и 3551
Факсы и модемы Обеспечена совместимость с T.38 (прием факсов в режиме реального времени), автоматическая переадресация на PCM или ADPCM
Платформа OSN Server
Интеграция шасси
Встроенная плата
Процессор
Intel Celeron 600 MHz
Память
1 слот для инсталляции модуля памяти SODIMM емкостью 512 Мб или 1 Гб
Система хранения данных
Одиночный или двойной жесткий диск
Интерфейсы
1 порт 10/100 BASE-TX, USB, RS-232, NИ (Night Bell), MOH (Music on Hold)
Сигнализация
Цифровая - PSTN протоколы
CAS: MF-R1: T1 CAS (E&M, Loop, Start, Feature Group-D, E911CAMA), E1 CAS (R2 MFC) для разных стран и протоколов
ISDN PRI: ETSI/EIRO ISDN, ANSI NI2 (а также DMS100, 5ESS), QSIG (основной вызов), IUA (SIGTRAN), VN3, VN4, VN6
Аналоговые сигналы
FXS, идентификация звонящего абонента, приоретизация вызовов, выборочный обзвон
Управление и настройка
Протоколы управления SIP, H.323 (MEGACO - только для цифровых каналов, не все каналы PTSN поддерживаются некоторыми протоколами)
Конфигурация и настройка
Система управления AudioCodes Element Management System, встроенный HTTP WEB сервер, Telnet, удаленная настройка и инталляция конфигураций через TFTP, HTTP, HTTPS, DHCP и BootP, поддержка Radius и сервера Syslog (для событий, предупреждений и CDR)
Безопасность
Безопасность IPSec, HTTPS, TLS (SIPS), SSL, Web листы доступа, RADIUS login, SRTP (может снизить плотность)
Физические характеристики
Питание
Одиночный универсальный блок питания 90-260 AC V, резервный блок питания
Установка
Шасси может быть установлено в стойку 19», высота - 1U
Рис 3.1.1 Общий вид Mediant 1000
Mediant 1000 принимает решения и поддерживает функции централизованного управления, управления вызовами, маршрутизации и генерирования записей.
Другой подход предназначен для клиентов, у которых установлен Media Pack 118/FXS. Для передачи вызовов в сеть ТфОП оператор обеспечивает стандартный интерфейс FXS по SIP. Заказчик в этом случае подключается к операторской сети через маршрутизатор доступа который при необходимости, используется и для передачи данных, создавая единый для голоса и данных канал передачи от клиента до сети оператора.
Подобные документы
Этапы построения модели установки соединения передачи сообщений между АТС с помощью шлюза без привратника. Исследование порядка, особенностей процесса установления соединения шлюзом без привратника в IP-телефонии. Сценарий установления соединения шлюзом.
контрольная работа [776,2 K], добавлен 20.02.2011Использование IP-адреса в протоколе TCP/IP, его роль в организации подключения к сети Интернет. Понятие маски подсети. Данные, необходимые для настройки протокола TCP/IP. Механизм тестирования его конфигурации и соединения с сетями с помощью утилит.
презентация [543,5 K], добавлен 02.11.2014Построение городской телефонной сети (ГТС). Схема построения ГТС на основе коммутации каналов и технологии NGN. Расчет интенсивности телефонной нагрузки сети, емкости пучков соединительных линий. Распределенный транзитный коммутатор пакетной сети.
курсовая работа [458,9 K], добавлен 08.02.2011Разработка схемы построения ГТС на основе коммутации каналов. Учет нагрузки от абонентов сотовой подвижной связи. Расчет числа соединительных линий на межстанционной сети связи. Проектирование распределенного транзитного коммутатора пакетной сети.
курсовая работа [2,4 M], добавлен 08.01.2016История деятельности Московской городской телефонной сети. Структура протокола TCP/IP. Взаимодействие систем коммутации каналов и пакетов. Характеристика сети с коммутацией пакетов. Услуги перспективной сети, экономическая эффективность ее внедрения.
дипломная работа [2,5 M], добавлен 10.07.2012Структура протокола TCP/IP. Взаимодействие систем коммутации каналов и пакетов. Характеристика сети с коммутацией пакетов. Услуги, предоставляемые ОАО "МГТС" с использованием сети с пакетной коммутацией. Расчет эффективности внедрения проектируемой сети.
дипломная работа [2,3 M], добавлен 22.05.2012Основные функциональные блоки. Процесс, моделирующий работу модема во время установления соединения с модемом провайдера. Выделение компонент, на основе которых строится множество ситуаций. Запрос на поиск драйвера в базе драйверов. Построение сети Петри.
контрольная работа [102,1 K], добавлен 14.04.2011Разработка межстанционных протоколов H.323 и SIP для связи абонентов и предоставления услуг по сети интернет. Исследование схемы работы сервера и методы установление соединения в рамках протокола SIP. Рассмотрение сигнализации для передачи голоса по IP.
реферат [539,8 K], добавлен 27.05.2014Зарождение концепции многоуровневой иерархической структуры сети телефонной связи. Электронная технология, позволившая перевести все средства телефонии на элементную базу. Развитие IР-телефонии, обеспечивающей передачу речи по сетям пакетной коммутации.
реферат [25,4 K], добавлен 06.12.2010Рассмотрение особенностей разработки комплекса по автоматизации анализа попыток внешних проникновений и контроля локальных соединений для сервера телефонии. Общая характеристика протокола SSH, основные версии. Анализ обычной парольной аутентификации.
курсовая работа [367,8 K], добавлен 22.02.2013
