Тфоп что это такое

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Популярное и похожее

Рассказываем про FXO и FXS

VoIP кодеки – подробное описание и характеристики

FreeSWITCH – управление XML конфигами через CURL

Cases: рост заказов на 35% с помощью модернизации телефонии

SIP протокол и PSTN?

Подключаемся к ТфОП

4 минуты чтения

Сегодня мы подробно поговорим и модификациях протокола SIP, разработанных специально для взаимодействия телефонных сетей VoIP с сетями PSTN – Public Switched Telephone Network (ТфОП), использующих сигнализацию ОКС-7.

С развитием IP — сетей , преимущества VoIP телефонии становились всё более очевидными, однако подавляющая часть АТС всё ещё имеет дело с сигнализацией ОКС-7, которая используется в таких сетях как ISDN — Integrated Services Digital Network (Цифровая Сеть с Интеграцией Служб), ТфОП – Телефонная Сеть Общего Пользования, а также в Сетях Подвижной Сотовой Связи (СПСС).

В качестве подсистемы, обеспечивающей межстанционную сигнализацию, в данных сетях применяется подсистема ISUP – ISDN User Part. ISUP решает задачи транспортировки сигнальной информации от офисной телефонной станции до станции назначения без обработки данной информации в промежуточных пунктах сигнализации. Прежде всего ISUP необходим для управления установлением соединения.

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

1. IAM (Initial Address Message) — Самое первое сообщение. Служит для информирования АТС об установлении соединения. Содержит такие параметры как: номер вызывающего и вызываемого абонента, тип данных (данные, голос и другие).
2. ACM (Address Complete Message) — Сообщение о приеме полного номера. Отправляется вызываемой АТС, когда был найден необходимый для установления соединения абонент. В этот момент телефонный аппарат вызываемого абонента начинает звонить, а вызывающий абонент слышит КПВ (Контроль Посылки Вызова)
3. ANM (Answer Message) — Отправляется вызываемой АТС, когда вызывающий абонент снимает трубку. Занимаются двухсторонние разговорные каналы.
4. REL (Release) — Отправляется одной из АТС, когда абонент инициирует завершение соединения (кладёт трубку).
5. RLC (Release complete) — Подтверждение разрыва соединения. Отправляя данное сообщение, АТС уведомляет о том, что разговорный канал свободен и может вновь быть использован.

Очевидно, что для сопряжения сетей VoIP с сетями, работающими по сигнализации ОКС-7, необходимо реализовать механизмы прозрачной передачи сообщений ISUP по IP. Для решения данной задачи ITU-T и IETF независимо разработали модификации к протоколу SIP — SIP- I (Internetworking) и SIP – T (Telephony)( RFC 3372) соответственно.

При разработке данных модификаций, были учтены следующие требования:

1. Возможность прозрачной передачи сообщений протокола ISUP
2. Возможность маршрутизации сообщения протокола SIP на основе параметров ISUP
3. Возможность передачи транспортной информации при установлении соединения.

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

Итак, от теории к практике. Рассмотрим простейший пример установления соединения в сети с разнотипной сигнализацией. Допустим, что а Абонент A — пользователь ТфОП, его телефонный аппарат находится за неким узлом связи, Абонент B использует IP Phone, работающий по протоколу SIP. За трансляцию сообщений ISUP в SIP будет отвечать некий многофункциональный шлюз IMG (Integrated Media Gateway) Задержки в сети

Как видно из рисунка инициатором вызова выступает Абонент A, на шлюз отправляется сообщение IAM, содержащее номера телефонов, а также дополнительные параметры соединения, IMG в свою очередь инкапсулирует сообщение IAM протокола ISUP, в уже известное нам INVITE протокола SIP.

Далее легко проследить каким ещё сообщениям протокола SIP соответствуют некоторые запросы ISUP.

Стоит также заметить, что протокол ISUP на этапе разговора открывает некий двухсторонний разговорный канал, идентификатор которого находится в сообщении IAM и называется CIC (Circuit Identification Code).

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

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

ТфОП — телефонный аппарат общего пользования телефон связь ТСОП ТфОП ТфСОП телефонная сеть общего пользования англ., связь ТфОП английский аналог PSTN … Словарь сокращений и аббревиатур

ТФОП — Телефонная сеть общего пользования. [ГОСТ Р 54456 2011] Тематики телевидение, радиовещание, видео EN Public Switched Telecommunications NetworkPSTN … Справочник технического переводчика

ТФОП — … Википедия

ТфОП — Телефонная сеть общего пользования … Универсальный дополнительный практический толковый словарь И. Мостицкого

архитектура эмуляции ТфОП/ЦСИС — Реализует возможности услуг ТфОП/ЦСИС и служит интерфейсом для адаптации пользователя к инфраструктуре IP (МСЭ Т Y.2271). [http://www.iks media.ru/glossary/index.html?gloss >Справочник технического переводчика

моделирование ТфОП/ЦСИС — Определяет возможности служб, подобных КТСОП/ЦСИС, с использованием управления сеансом через интерфейсы и инфраструктуру IP. Примечание Это определение предусматривает возможность моделирования, обеспечивающего полное распределение набора служб… … Справочник технического переводчика

компонент услуги эмуляция сети ТфОП/ЦСИС на основе сервера вызова — (МСЭ Т Y.2271). [http://www.iks media.ru/glossary/index.html?gloss >Справочник технического переводчика

компонент эмуляции услуги ТфОП/ЦСИС — (МСЭ Т Y.2271). [http://www.iks media.ru/glossary/index.html?gloss >Справочник технического переводчика

эмуляция ТфОП/ЦСИС — Определяет возможности и интерфейсы служб КТСОП/ЦСИС, используя адаптацию к инфраструктуре IP. Примечание Не все возможности и интерфейсы служб должны быть представлены для обеспечения эмуляции. (МСЭ T Y.2271) [http://www.iks… … Справочник технического переводчика

T.38 — стандарт Международного союза электросвязи по передаче факсимильных сообщений в реальном времени через IP сети. Для факсов, передаваемых по протоколу T.38 зарезервирован тип image/t38. Содержание 1 История 2 Обзор 3 Операции … Википедия

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

Все началось с "игрушек", затем стали появляться приложения, позволяющие осуществлять переговоры между пользователями локальной сети. И наконец, появилось то, что называется IP-телефонией — телефонные переговоры между абонентами через сеть Интернет.

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

Что такое IP-телефония?

Как уже было сказано, развитие IP-телефонии началось с обеспечения возможности общения между пользователями сети Интернет.

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

Второй сценарий предусматривает взаимодействие компьютера, подключенного к сети Интернет, и телефонного аппарата ТФОП.

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

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

При передаче речевой информации через сеть Интернет должны быть решены две задачи:

• преобразование речевой информации в поток данных;
• управление этим потоком.

В настоящий момент времени отсутствуют международные рекомендации или стандарты, разработанные специально для IP-телефонии. В тоже время для обеспечения совместимости оконечного оборудования и шлюзов различных поставщиков в качестве базового стандарта используется Рекомендация МСЭ-Т H.323, утвержденная в феврале 1998 г. Она регламентирует характеристики системы мультимедиа для сети с коммутацией пакетов. Рекомендация определяет набор стандартов для кодирования аудио и видео сигналов и протоколов управления каналами передачи (рис. 1).

Согласно Рекомендации H.323 для преобразования речевой информации могут применяться алгоритмы, определенные в Рекомендациях МСЭ-Т: G.711, G.722, G.723, G.728 и G.729.

Рекомендации МСЭ-Т G.711 и G.722 определяют только способ аналого-цифрового преобразования без сжатия.

Рекомендация МСЭ-Т G.722 предназначена для кодирования спектра частот до 7 кГц, который превышает ширину канала ТЧ. Поэтому она не может применяться в сценариях, предусматривающих взаимодействие компьютера с телефонным аппаратом.

Для сжатия речи Рекомендация МСЭ-Т H.323 предусматривает использование нескольких алгоритмов кодирования речевой информации. Они определены в Рекомендациях МСЭ-Т: G.723, G.728, G.729.

Кодирование речевой информации согласно Рекомендации МСЭ-Т G.723 обеспечивает преобразование речевого потока 64 кбит/c в поток 6,3 или 5,3 кбит/c.

Кодирование речевой информации согласно Рекомендации МСЭ-Т G.728 обеспечивает преобразование речевого потока 64 кбит/c в поток 16 кбит/c и менее с малым временем задержки.

Кодирование речевой информации согласно Рекомендации МСЭ-Т G.729 обеспечивает преобразование речевого потока 64 кбит/c в поток 8 кбит/c.

Основной задачей при управлении потоком речевой информации по сети Интернет становится обеспечение небольшой и постоянной задержки.

Восприятие речи человеком очень чувствительно к задержкам, причем как к ее величине, так и колебаниям. Для телефонной связи задержка не должна превышать 150 мс при работе по наземным линиям связи и 250 мс при использовании спутниковых каналов.

В телефонной сети, где используются физические соединения, это требование обеспечивается относительно легко за счет систем передачи.

В сетях передачи данных выполнить эти требования несколько сложнее, поскольку параметры задержки должны обеспечиваться коммутаторами или маршрутизаторами. Для этого при обработке очередей пакетов каждый коммутатор или маршрутизатор для каждого пакета должен знать приоритет и допустимое время нахождения его в очереди.

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

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

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

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

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

Существует два подхода.

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

Для резервирования полосы пропускания в сети IP может использоваться метод WFQ (Weighted Fair Queuing) или протокол RSVP (Resource Reservation Protocol), разрабатываемый группой перспективных разработок Интернет IETF (Internet Engineering Task Force).

Метод WFQ позволяет для каждого вида трафика выделять определенную часть полосы пропускания. Оператор через систему административного управления может задать количество очередей (до 10 очередей для передачи данных и одну очередь для системных сообщений). В случае, если одна очередь не использует полностью выделенную ей полосу пропускания, то свободный резерв полосы пропускания может задействоваться для передачи информации из следующей очереди. Этот метод позволяет гибко использовать ресурсы сети. Например, если для очереди с речевой информацией зарезервировано 50% пропускной способности, а используется только 30%, то следующая очередь получит в свое распоряжение дополнительно 20% до тех пор, пока эта пропускная способность снова не потребуются очереди с речевой информацией. Метод WFQ реализован в оборудовании фирмы Cisco.

Протокол RSVP предназначен только для резервирования части пропускной способности.

Используя RSVP, отправитель периодически информирует получателя о свободном количестве ресурсов сообщением RSVP Path (рис. 2).

Транзитные маршрутизаторы по мере прохождения этого сообщения также анализируют имеющееся у них количество свободных ресурсов и подтверждают его соответствующим сообщением RSVP Resv, передаваемым в обратном направлении. Если ресурсов достаточно, то отправитель начинает передачу. Если ресурсов не достаточно, получатель должен снизить требования или прекратить передачу информации.

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

Механизм управления приоритетами должен быть реализован в
следующей шестой версии IP, где предусматривается введение до 16 приоритетов, а также возможность организации нескольких логических потоков в рамках одного физического соединения. Однако в настоящее время аппаратура, реализующая IP версии 6, только начала появляться на рынке.

Другой подход предусматривает построение магистральной транспортной сети Интернет на основе технологии Frame Relay или АТМ (рис. 3). В этом случае пограничные узлы IP взаимодействуют друг с другом через виртуальные соединения сети Frame Relay или ATM, для которых обеспечиваются параметры трафика и качества обслуживания, такие как скорость передачи, время задержки, время отклонения от задержки и т.д. Использование Frame Relay или АТМ позволяет отказаться от применения транзитных маршрутизаторов IP. При этом возможно более эффективное использование полосы пропускания за счет установления соединения для каждого телефонного разговора.

Стандартизация

МСЭ-Т начал работу по вопросам исследования и стандартизации взаимодействия между сетями связи и сетями, работающими по протоколу IP, в рамках работ по созданию Глобальной информационной инфраструктуры GII (Global Informational Infrastructure) только в 1998 году. Предполагается, что работа будет проводиться в тесном сотрудничестве с IETF.

С целью ускорения разработки промышленных стандартов ведущие производители оборудования и программного обеспечения IP-телефонии в 1996 г. объединились в неформальную организацию Форум Voice Over IP (VOIP Forum). Инициатором создания форума стали компании Cisco и VocalTec. В Форум вошли такие компании, как Dialogic, 3Com, Creative Labs, Micom Communications, Microsoft, Nortel, Vienna Systems, U.S.Robotics и другие.

Форум предлагает для аналого-цифрового преобразования речи использовать алгоритмы кодирования, определенные в Рекомендациях МСЭ-Т G.723 и G.729. Для поддержки качества передачи речи в сетях IP Форум рекомендует использовать протокол RSVP, а для управления очередями — метод WFQ.

Указанные выше способы решают проблему обеспечения качества передачи речи и не определяют взаимодействие оборудования IP-телефонии при предоставлении услуги. Для сценариев "телефон–телефон", "компьютер–телефон" необходимо иметь протоколы, обеспечивающие нахождение ближайшего шлюза, взаимодействие шлюзового оборудования, а также возможность создания пользователем приложений, реализующих собственные варианты услуги. Разработкой таких протоколов в настоящее время занимается IETF.

Приложения IP-телефонии

На сегодняшний день IP-телефония представлена тремя типовыми сценариями:

• "компьютер–компьютер";
• "компьютер–телефон";
• "телефон–телефон".

Сценарий "компьютер–компьютер" реализуется на базе бытовых компьютеров, оснащенных средствами мультимедиа и подключенных к сети Интернет. Наиболее распространенным программным обеспечением является пакет MicroSoft NetMeeting.

Для поддержки этого сценария поставщики услуг Интернет должны установить на сети сервер адресов, преобразующий имена пользователей в динамические адреса IP (рис. 4).

Сценарий "компьютер–телефон" находит применение в различного рода справочных и информационных службах Интернет, например, в службах технической поддержки (рис. 5). Данный сценарий реализуется на оборудовании компании, предоставляющей справочную информацию. Пользователь, подключившийся к серверу WWW (World W >
Рис. 5. Сценарий "компьютер–телефон"

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

Услуга по сценарию "телефон–телефон" может предоставляться следующим образом. Поставщик услуги выпускает свои телефонные карточки. Имея такую телефонную карточку, пользователь, желающий позвонить в другой город, набирает номер данного поставщика услуги, затем в режиме донабора вводит свой идентификатор и PIN-код, указанный на карточке. После процедуры аутентификации он набирает телефонный номер адресата.

Возможны и другие варианты реализации этого сценария: вместо телефонной карточки может использоваться информация об альтернативном счете. Счет для оплаты может быть выслан абоненту и после разговора, аналогично тому, как это делается при междугородном соединении в ТФОП.

Привлекательность этого сценария для пользователя заключается в значительно более низкой стоимости телефонных переговоров по сравнению с обычной междугородной или международной телефонной связью. Например, в США некоторые поставщики услуг предоставляют междугородную телефонную связь по тарифам от 3 до 7 центов за минуту, в то время как AT&T требует около 3 долларов за минуту.

Поскольку сегодня транспортные возможности сети Интернет не способны обеспечить качество IP-телефонии, которое соответствовало бы даже таким низким тарифам, то поставщики услуг для соединения принадлежащего им шлюзового оборудования используют выделенные каналы. При этом для передачи речи часто используются не протоколы IP, а технологии типа "Voice over Frame Relay" или "Voice over ATM", применение которых позволяет повысить качество передачи речи и одновременно установить низкие тарифы на услуги телефонной связи. Поэтому передачу речи с использованием IP необходимо поставить на одну ступень с такими технологиями, как "Voice over Frame Relay", "Voice over ATM", "Voice over X.25", статистического мультиплексирования и целесообразно рассматривать как технологию вторичного уплотнения каналов.

Регулирование

Рост популярности приложения "телефон-телефон" вызывает негативную реакцию со стороны операторов дальней связи. Она вызвана двумя причинами.

Первая причина заключается в том, что IP-телефония вызывает естественный отток нагрузки у операторов дальней связи, что ведет к сокращению их доходов. Например, по прогнозам зарубежных экспертов, ожидается, что AT&T к 2001 г. может потерять от $620 до $950 млн.

Вторая причина заключается в том, что при внедрении IP-телефонии увеличивается продолжительность разговора. По данным Федеральной комиссии по связи FCC (Federal Communications Commission) США, обычный телефонный разговор длится 5–7 минут, а продолжительность разговора с использованием IP-телефонии составляет от 17 до 21 минут.

По этим причинам Ассоциация американских операторов сетей связи America’s Carriers Telecommunication Association (АСТА) США, в которую входят такие известные компании как Sprint и MCI, неоднократно обращалась с жалобами в FCC. Ассоциация АСТА требовала применения для компаний, разрабатывающих продукты и предоставляющих услуги IP-телефонии, тех же регулирующих норм и правил, что и для операторов телефонных сетей. Члены АСТА в своих жалобах указывают на то, что реализация услуг IP-телефонии приводит к деформации сложившегося рынка телефонных услуг, так как при действующей системе расчетов между операторами и компаниями-поставщиками услуг Интернет ISP (Internet Service Provider) соответствующие реальные затраты не поддаются оценке и не могут быть отнесены на счет ISP.

Несмотря на обоснованность претензий АСТА, данная жалоба не была удовлетворена FCC, поскольку в соответствии с американским законодательством IP-телефония относится к улучшенным услугам (exhanced services), для реализации которых используются компьютерные приложения. Регулирование улучшенных услуг, по мнению FCC, будет сдерживать развитие компьютерных приложений. Таким образом вопрос, на сегодня, остался открытым.

Позиция же Европейского Союза (ЕС) заключается в том, что передача речи по Интернет пока не может рассматриваться как телефонная услуга, а только как дополнительная, и поэтому не может регулироваться аналогично телефонной услуге. Свою позицию ЕС аргументирует тем, что телефонные услуги, предоставляемые через Интернет, по качеству пока не соответствуют требованиям, предъявляемым к услугам телефонной связи в ТФОП. В то же время ЕС признает, что по мере развития рынка услуг Интернет критерии оценки могут быть пересмотрены.

Данную позицию развивает ассоциация ETNO (European Public Telecommunications Network Operators Association), которая считает, что предоставление услуг передачи речи по Интернет может регулироваться в технических аспектах, таким же образом, как деятельность операторов телефонных сетей. ETNO предлагает в целях регулирования рассматривать отдельно два сценария передачи речи по Интернет: "компьютер — компьютер" и "телефон — телефон".

Первый сценарий не относится к услугам ТФОП.

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

Заключение

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

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

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

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

С другой стороны, назрела объективная необходимость государственного урегулирования вопроса о передаче речи с использованием современных технологий (ATM, Frame Relay и др.), обеспечивающих сжатие речевой информации, что требует разработки соответствующей нормативно-технической и регламентирующей базы.