Подсистема управления сигнальными соединениями SCCP

Подсистема SCCP дополняет уровень 3 МТР функциями, которых тому не достает для того, чтобы соответствовать уровню 3 модели 0SI. МТР и SCCP образуют т.н. подсистему сетевых услуг NSP (Net­work Service Part). NSP поддерживает создание между SP как сиг­нальных связей, нужных для управления соединениями в сети ком­мутации каналов, которую обслуживает сеть ОКС7, так и связей, не относящихся к таким соединениям - в том числе сигнальных связей между несмежными SP. Важную роль здесь играет наличие в SCCP собственной системы адресации, не привязанной, как в МТР, к но­мерам телефонных каналов.

SCCP предоставляет своим пользователям как услуги, не преду­сматривающие создания в сети ОКС виртуального соединения, так и услуги, ориентированные на соединение. Имеется четыре класса услуг SCCP:

0     - базовый класс услуг без соединения; доставка сигнальных со-

общений в заданной последовательности не гарантируется.

1     - класс услуг без соединения; доставка сигнальных сообщений

в заданной последовательности гарантируется.

2- базовый класс услуг, ориентированных на соединение, без управления потоком сообщений.

3 - класс услуг, ориентированных на соединение, с управлением по­током сообщений.

Заметим, что класс 1 сохраняет порядок следования сообщений, используя упомянутый в п.8.4.1 механизм присвоения «сверху» зна­чения SLS в маршрутной этикетке. Благодаря этому на каждом уча­стке маршрута от SCCP-отправителя к SCCP-получателю все сооб­щения SCCP, принадлежащие одному потоку, проходят через одно

и то же сигнальное звено, что гарантирует сохранение очередности их следования по всему маршруту.

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

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

Формат сообщения SCCP в общем виде показан на рис.8.9. Все­го на сегодня специфицировано 19 сообщений (пять из них - для нужд эксплуатационного управления). Из экономии места сообще­ния ния здесь не описываются и перечень их не приводится; сведения об этом можно почерпнуть, например, из [41]. Автор считает более важным обратить внимание читателя на то обстоятельство, что прин­цип свободного использования в формате сообщения полей необя­зательных параметров позволяет гибко модифицировать как пере­чень сообщений SCCP, так и содержание любого из них, когда и если в будущем возникнет потребность в такой модификации.

Подсистема средств транзакций

Средства транзакций ТС - Transaction Capabilities - предназначе­ны для поддержки взаимодействия между прикладными процесса­ми (или между разными элементами одного процесса), размещен­ными в территориально разнесенных узлах сети связи. Любой такой процесс (или элемент процесса) внутри одного узла сети связи яв­ляется пользователем услугами ТС, размещенных на этом узле. С другой стороны, сами ТС того или иного узла являются пользова­телем сетевыми услугами, предоставляемыми размещенной на нем подсистемой NSP.

 

ТС могут поддерживать обмен информацией между:

• коммутационными станциями и/или узлами сети связи,

• станцией (узлом) и базой данных, узлом управления услугами сети
IN, центром технической эксплуатации ЦТЭ и т. п.,

• специализированными сетевыми центрами.
Пользователями ТС могут быть разные приложения, в частности:

• приложения услуг мобильной связи,

• приложения услуг Интеллектуальной сети IN,

• приложения эксплуатационного управления.

 

Все такого рода приложения можно разделить на две категории:

• требующие обмена данными в реальном времени (т.е. без ощу­
тимых задержек); объем данных в этом случае относительно не­
велик,

• не предъявляющие жестких требований в отношении задержек;
при этом объем данных может быть очень большим.

Как видно из рис.8.10, функции ТС образуют два подуровня -по­дуровень компонентов (CSL) и подуровень транзакций (TSL). Чтобы стало ясно, в чем тут дело, нужно определить ряд понятий, связан­ных с тем, как разделены функции между этими подуровнями и ка­кие услуги каждый из них предоставляет подуровню, расположен­ному выше.

Рис. 8.10 Подсистема средств транзакций ТС

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

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

Множество функций, связанных с обработкой компонентов, об­разует верхний подуровень ТС - подуровень CSL. Через границу между этим подуровнем и ТС-пользователем компоненты проходят индивидуально. Пользователь (инициатор) может передать к поду­ровню CSL один за другим несколько компонентов до того, как они будут переданы (в одном сообщении) второму ТС-пользователю (партнеру). Несколько компонентов, принятых в одном сообщении, всегда передаются пользователю-адресату по одному и в той после­довательности, в какой они были переданы пользователем-отпра­вителем.

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

Диалоги могут быть неструктурированными и структурированны­ми. При неструктурированном диалоге ТС-пользователь передает компоненты, на которые не ожидается откликов, так что связь меж­ду двумя ТС-пользователями в явном виде не определена. Компо­ненты передаются в однонаправленных сообщениях, и сам факт пе­редачи однонаправленного сообщения говорит о неструктурирован­ном диалоге. Пользователь может иметь дело сразу с несколькими операциями; максимальное число операций зависит от количества доступных в данное время уникальных значений идентификатора Ю обращения. Если при приеме однонаправленного сообщения обна­ружена ошибка протокола, для уведомления об этом факте отпра­вителя также используется однонаправленное сообщение.

При структурированном диалоге связь между двумя ТС-пользо­вателями определяется в явном виде - ТС-пользователь указывает начало, продолжение и окончание этой связи. Два ТС-пользователя могут вести одновременно несколько структурированных диалогов, идентифицируя каждый из них с помощью уникального ID диалога.

Поскольку для каждого ID диалога существует свое пространство имен ID обращений, один и тот же ID обращения может повторяться в разных диалогах. Структурированный диалог предполагается дву­сторонним - на фазе его продолжения возможен дуплексный обмен компонентами.

Подуровень CSL предусматривает организацию соответствия между запросами и откликами. Связанное с запросом операции зна­чение ID обращения вводится в отклик на этот запрос. Возможны 4 класса операций:

• класс 1 - предусматривается отклик и при удаче, и при неудаче,

• класс 2 - предусматривается отклик только в случае неудачи,

• класс 3 - предусматривается отклик только в случае удачи,

• класс 4 - отклик не нужен ни в том, ни в другом случае.

Смысл и содержание каждого компонента определяется его ти­пом. Существуют компоненты следующих пяти типов.

• INVOKE - обращение. Этот компонент запрашивает выполнение встречной стороной определенной операции. Он может быть связан с другой операцией, к которой обращалась встречная сторона.

• RETURN RESULT (NOT LAST) - часть данных с информацией о результате выполнения операции. Имеется в виду, что все данные с информацией о результате не могут быть целиком размещены в одном компоненте, так что ТС-пользователю пришлось разделить их на несколько сегментов. Данный компонент содержит один из этих сегментов, за которым последуют другие.

• RETURN RESULT (LAST) - последняя (или единственная) часть данных с информацией о результате выполнения операции. Этот компонент свидетельствует о том, что операция успешно завершена.

• RETURN ERROR - успешно завершить операцию не удалось. Этот компонент содержит информацию о причине того, что операция не была завершена.

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

Рассмотрим теперь функции и услуги подуровня транзакций (TSL). Очевидно, что расположенный выше подуровень CSL является пользователем подуровня TSL (или, для краткости, TSL-пользователем); другие TSL-пользователи в настоящее время не опреде­лены, однако подуровень TSL устроен так, что они, в принципе, мо­гут существовать.

TSL предусматривает средства, поддерживающие обмен компо­нентами между TSL-пользователями и обеспечивающие использо­вание услуг нижележащих уровней (подсистем SCCP и MTP) для дву­стороннего переноса через сеть ОКС сообщений между двумя взаи­модействующими подсистемами ТС, размещенными в разных пунк­тах этой сети.

Поддержка неструктурированного диалога TSL-пользователей заключается в том, что TSL обеспечивает передачу сообщения, со­держащего один или несколько компонентов (связанных с операция­ми класса 4), от «своего» TSL-пользователя, являющегося отправи­телем, KTSL-пользователю, являющемуся адресатом. Если для под­держки такого диалога требуется передать несколько TSL-сообщений, логическая связь между ними (то есть их принадлежность од­ной и той же транзакции) в явном виде не определяется.

Поддержка структурированного диалога базируется на том, что каждый TSL-пользователь идентифицирует транзакцию уникальным Ю транзакции, который присутствует во всех TSL-сообщениях, от­носящихся к этой транзакции. Для каждой транзакции TSL-пользо­ватель указывает ее начало, продолжение и окончание; на фазе про­должения возможен дуплексный обмен между TSL-пользователями сообщениями «внутри» этой транзакции.

Отметим, что в настоящее время специфицированы средства транзакций, использующие только такие услуги SCCP, которые не предусматривают создание в сети ОКС сигнальных соединений. Использование услуг, ориентированных на сигнальные соединения, изучается ITU-T.

Подсистема ISUP

Подсистема ISUP - это подсистема-пользователь МТР, поддер­живающая межстанционную сигнализацию в ТфОП и в ISDN. При поддержке сигнализации в ISDN ISUP пользуется также услугами SCCP, как это показано на рис. 8.6.

Средства адресации МТР дополнены в ISUP идентификатором канала, поскольку для того, чтобы указать, к какому телефонному соединению относится сообщение, ISUP указывает номер того ка­нала, который занят в этом соединении. Дело в том, что ISUP реали­зует два метода сигнализации - эстафетный, когда сообщение пе­редается от одной станции к другой и на промежуточных станциях может изменяться, и сквозной, когда обмен сообщениями происходит между конечными точками соединения. Сквозной метод обычно использует услуги SCCP - либо без создания сигнального соедине­ния, либо ориентированные на соединение; в последнем случае про­цедуры значительно упрощаются.

Сообщений ISUP слишком много, чтобы рассмотреть их все в этой, и так самой длинной главе учебника. Назовем лишь основ­ные категории сообщений:

• Сообщения управления базовым соединением

• Сообщения управления дополнительными услугами

• Сообщения модификации соединения во время связи

• Сообщения эксплуатационного контроля и управления

• Сквозные сообщения

Принципы форматирования сообщений в ISUP подобны принци­пам, принятым в SCCP и описанным в п. 8.4.2 (в этом легко убедить­ся, сравнив приводимый ниже рис.8.1 1 с рис.8.9). Однако SCCP уст­роена так, что маршрут, по которому проходит «сквозное» сигналь­ное сообщение, никак не связан с маршрутом, по которому прохо­дит соединение телефонных каналов, a ISUP опирается на «каналь­ный» подход идентификации транзакции

Рис. 8.11 Структура сообщения ISUP

Теперь рассмотрим пример установления базового соединения в ISDN. В этом примере (рис.8.12) терминал вызывающего пользова­теля А передает по каналу D в интерфейсе UNI сообщение Q. 931 SETUP в сторону своей АТС (исходящей), которая анализирует его, удосто­веряется в его правильности и передает начальное адресное сооб­щение IAM протокола ISUP к той транзитной АТС, через которую, со­гласно таблице маршрутизации исходящей АТС, должно пройти уста­навливаемое соединение. Одновременно исходящая АТС передает вызывающему абоненту сообщение Q.931 CALL PROCEEDING.

Рис. 8.12 Пример установления базового соединения ISDN Транзитная АТС находит в своей таблице маршрутизации входя­щую АТС и переправляет ей сообщение IAM. Предположим, что в со­общение IAM не был включен адрес вызываемого пользователя (СРА), а входящей АТС этот СРА необходим для завершения уста­новления соединения. Тогда входящая АТС направляет к транзитной АТС сообщение протокола ISUP «Запрос информации» (INR), содер­жащее параметр (индикатор запроса), который говорит о том, что требуется СРА. Транзитная АТС переправляет это сообщение к ис­ходящей АТС.

Исходящая АТС формирует сообщение протокола ISUP «Инфор­мация» (INF) с недостающим СРА и направляет его к входящей АТС. Входящая АТС передает сообщение Q.931 SETUP к оборудованию вызываемого пользователя Б, которое отвечает на это сообщением Q.931 ALERTING. Входящая АТС передает в обратном направлении сообщение протокола ISUP о приеме всего адреса (АСМ). Когда ис­ходящая АТС получает это сообщение, она передает к оборудова­нию вызывающего пользователя сообщение Q.931 ALERTING.

Когда вызываемый абонент отвечает на вызов, его оборудование передает сообщение Q.931 CONNECT к входящей АТС, которая, в свою очередь, передает на транзитную АТС сообщение протокола ISUP «Ответ» (ANM). Транзитная АТС пересылает сообщение ANM к исходящей АТС, а та передает к оборудованию вызывающего поль­зователя сообщение Q.931 CONNECT. В результате между вызываю­щим и вызываемым пользователями устанавливается соединение.

 

8.5 Сигнализация при конвергенции сетей связи

В последнее время система ОКС7 стала универсальным ключом, своего рода Bluetooth сигнализации для более тесного объедине­ния различных сетевых инфраструктур мобильной связи, проводной связи и IP. Именно этим объединяющим свойством ОКС7 вызвана ассоциация с прозвищем «Голубой зуб» (Bluetooth), которое носил король Дании Гарольд II, собиратель датских земель в X веке н.э., и которое, к сожалению, уже получил другой интерфейс с такими же объединяющими свойствами.

Рис. 8.13 Стек протоколов Siatran

Эффективное и повсеместное развёртывание мультимедийных и других услуг зависит от успешной реализации всего стека прото­колов ОКС7 (а также ОКС7-по-1Р, о чем речь пойдет чуть ниже), про­токолов IP-телефонии Н.323, SIP, MGCP, MEGACO/H.248, MPLS, RSVP и др., рассмотренных в книге [50]. Эти протоколы, в первую очередь MGCP и ОКС7-по-1Р, не только решают задачи собственно IP-теле­фонии, но и обеспечивают взаимодействие между IP-сетью и теле­фонной сетью общего пользования.

 

Что же касается переноса сообщений ОКС7 через IP-сеть, то это является одним из направлений деятельности рабочей группы Sigt-ran, входящей в IETF. Протоколы Sigtran (рис.8.13) обеспечивают на­дежную транспортировку сообщений ОКС7по IP-сетям. Во-первых, это протокол передачи информации для управления потоками SCTP (Stream Control Transmission Protocol), который поддерживает пере­нос сигнальных сообщений между конечными пунктами сигнализа­ции SP в IP-сети. Для организации сигнальной связи один конечный пункт предоставляет другому перечень своих транспортных адре­сов (IP-адреса в сочетании с портом SCTP). Протокол SCTP позво­ляет независимо упорядочивать сигнальные сообщения в разных потоках и обеспечивает перенос сигнальной информации с подтвер­ждением приема, без ошибок и дублирования, доставку сообщений каждого потока в заданной последовательности, возможность объ­единения нескольких сообщений в один пакет SCTP, фрагментацию данных по мере необходимости, устойчивость к перегрузкам и т.п.

Во-вторых, для выполнения функциональных и качественных тре­бований к МТР рабочая группа Sigtran рекомендовала три новых про­токола: M2UA, М2РА и M3UA. Каждый из них будет кратко рассмот­рен ниже, но прежде приведем установленные ITU-T требования к пе­реносу сообщений МТР как по сетям с временным разделением ка­налов, так и по IP-сетям:

• Для одноранговых процедур уровня 3 МТР требуется время отклика в пределах от 500 мс до 1200 мс.

• Допускается потеря из-за транспортных сбоев не более одного из 10 миллионов сообщений.

• Вследствие транспортных сбоев допускается несвоевременная доставка (включая дублированные сообщения) не более одного из 10 миллиардов сообщений.

• Не более одного из 10 миллиардов сообщений может содержать ошибку, не выявленную транспортным протоколом (согласно спецификациям ANSI - не более одного из миллиарда сообщений).

• Доступность любого пучка сигнальных маршрутов (полная совокупность разрешенных сигнальных путей от любого пункта сигнализации в направлении любого пункта назначения) должна быть не ниже 0.999998 (что соответствует времени простоя приблизительно до 10 минут в течение года).

•      Длина сообщения (принимаемая к обслуживанию полезная нагрузка) должна составлять 272 байта для узкополосной ОКС7 и 4091 байтов для широкополосной ОКС7.

Протокол M2UA уровня адаптации для пользователей уровня 2 МТР (МТР Level-2 User Adaptation Layer) предусматривает набор ус­луг, эквивалентный тому, который предоставляетуровень 2 МТР уров­ню 3 МТР в обычной сети ОКС7. Протокол используется между шлю­зом сигнализации и контроллером транспортного шлюза в VoIP-се­тях. Шлюз сигнализации принимает сообщения ОКС7 через интер­фейс уровня 1 и уровня 2 МТР от конечного или транзитного пункта сигнализации. Он служит окончанием для звена ОКС7 на уровне 2 МТР и транспортирует информацию уровня 3 МТР и вышележащих уровней к контроллеру транспортного шлюза или к другому конеч­ному пункту сети IP, используя протокол M2UA поверх SCTP/IP.

Протокол М2РА уровня адаптации для одноранговых пользова­телей МТР2 (МТР2 User Peer-to-Peer Adaptation Layer), в отличие от протокола M2UA, используется для полномасштабной обработки сообщений уровня 3 МТР, которыми обмениваются любые два узла сети ОКС7, взаимодействующие через IP-сеть. Пункты сигнализа­ции IP-сети функционируют как обычные узлы ОКС7, используя IP-сеть вместо сети ОКС7. Каждый пункт сигнализации сети с комму­тацией каналов или IP-сети имеет код пункта сигнализации 0КС7.

Протокол М2РА предусматривает тот же набор услуг, который пре­доставляет уровень 2 МТР уровню 3 МТР. Протокол может использо­ваться между шлюзом сигнализации и контроллером транспортно­го шлюза, между шлюзом сигнализации и пунктом сигнализации IP-сети, а также между двумя пунктами сигнализации IP-сети. Пункты сигнализации могут использовать протокол М2РА для передачи и приёма сообщений уровня 3 МТР по IP или уровень 2 МТР для об­мена этими сообщениями по стандартным звеньям ОКС7. М2РА об­легчает интеграцию сетей ОКС7 и IP благодаря тому, что он позво­ляет узлам сети с коммутацией каналов иметь доступ к базам дан­ных IP-телефонии и к другим узлам IP-сетей, используя сигнализа­цию ОКС7. И, наоборот, протокол М2РА позволяет приложениям IP-телефонии получать доступ к базам данных сети ОКС7.

Итак, протоколы М2РА и M2UA имеют следующие различия:

• М2РА - шлюз сигнализации является узлом ОКС7 с кодом пункта сигнализации;

• M2UA - шлюз сигнализации не является узлом ОКС7 и не имеет кода пункта сигнализации.

• М2РА - соединение между шлюзом сигнализации и пунктами сигнализации IP-сети представляет собой звено ОКС7;

• M2UA - соединение между шлюзом сигнализации и контроллером транспортного шлюза не является звеном ОКС7. Оно представляет собой расширение МТР от шлюза сигнализации к контроллеру транспортного шлюза.

• М2РА - шлюз сигнализации может содержать функции верхних уровней ОКС7, например SCCR

• M2UA - шлюз сигнализации не содержит функций верхних уровней ОКС7, поскольку он не содержит функций уровня 3 МТР;

• М2РА - для выполнения функций эксплуатационного управления опирается на соответствующие процедуры уровня 3 МТР;

• M2UA - использует собственные процедуры эксплуатационного управления;

• М2РА: пункты сигнализации IP-сети обрабатывают примитивы уровня 3 МТР и уровня 2 МТР;

M2UA: контроллер транспортного шлюза переносит примитивы уровня 3 МТР и уровня 2 МТР к уровню 2 МТР шлюза сигнализа­ции для их последующей обработки.

Протокол M3UA уровня адаптации для пользователей уровня 3 МТР (МТР Level-3 User-Adaptation Layer) связан с переносом по IP-сети средствами протокола SCTP сигнальных сообщений подсис­тем-пользователей уровня 3 МТР (например, ISUP, SCCP). Подсистема SCCP может переносить сообщения своих пользователей ТСАР или INAP, с помощью либо протокола M3UA, либо другого продукта группы Sigtran - протокола SUA, который рассматривается ниже. Протокол M3UA используется между шлюзом сигнализации и кон­троллером транспортного шлюза или базой данных IР-телефонии. С концептуальной точки зрения, он расширяет доступ куслугам уров­ня 3 МТР шлюза сигнализации, охватывая удаленные конечные пунк­ты IP-сети.

К тому же, протокол M3UA не ограничивает длину сообщения 272-мя октетами, как это установлено уровнем 2 МТР ОКС7. По этой причине M3UA/SCTP позволяет переносить крупные блоки инфор­мации, не прибегая к процедурам сегментации/сборки в верхнем уровне. Шлюз сигнализации будет устанавливать 272-октетное ог­раничение только тогда, когда он подключен к обычной сети 0КС7.

Протокол SUA уровня адаптации для пользователей SCCP под­держивает перенос по IP-сети средствами протокола SCTPсигналь­ных сообщений пользователей SCCP 0KC7 (например, ТСАР или INAP). Протокол SUA используется между шлюзом сигнализации и конечным пунктом сигнализации IP-сети и между конечными пунк­тами сигнализации IP-сети. Пример применения SUA приведен на рис. 8.14.

Рис. 8.14 Уровень адаптации SUA для пользователя SCCP

SUA поддерживает как услуги SCCP без соединения с неупоря­доченной и упорядоченной доставкой, так и услуги, ориентирован­ные на соединение, с управлением или без управления потоком дан­ных и с обнаружением потерь сообщений и ошибок вследствие не­своевременной доставки сообщений (т.е. классы услуг SCCP с 0 по 3). В случае услуг без соединения SCCP и SUA стыкуются в шлюзе сигнализации. С точки зрения пункта сигнализации ОКС7, пользо­ватель SCCP находится в шлюзе сигнализации. Сообщения ОКС7 направляются к этому шлюзу на основании кода пункта сигнализа­ции и номера подсистемы SCCP, а тот направляет сообщения SCCP к удаленному конечному пункту IP-сети.

Протокол уровня адаптации для ISDN-пользователя (IUA) поддер­живает перенос через IP-сеть сообщений Q.931. Протокол IUA ис­ключает использование в системе сигнализации части протокола МТР. Протокол IUA позволяет приложениям верхнего уровня непо­средственно взаимодействовать с транспортным протоколом SCTR

Sigtran является не единственной рабочей группой IETF, участвую­щей в определении новых протоколов для обеспечения интеграции сетей ТфОП и IP Следует еще упомянуть PINT (PSTN and Internet In-terworking - взаимодействие ТфОП и Интернет) и SPIRITS (Service in the PSTN/IN Requesting Internet Service - запросы услуг Интернет в ТфОП/IN). В PINT услуги ТфОП активизируются путем запросов из IP-сети. Java-клиент SIP, встроенный в сервисное Java-приложение на Web-сервере, создает запросы инициировать телефонные вызо­вы в ТфОП. Цель состоит в том, чтобы обеспечить Web-доступ к ре­чевому контенту и осуществлять телефонную/факсимильную связь из Интернет. В SPIRITS услуги IP-сети активизируются путем запро­сов из ТфОП. SPIRITS, в первую очередь, касается таких услуг, как уведомление о поступлении нового вызова в сети Интернет, предос­тавление идентификатора вызывающего абонента из сети Интернет и переадресация Интернет-вызовов.

Желательно также упомянуть рабочую группу ENUM в составе IETF, которая разрабатывает схему преобразования телефонных номеров Е.164 в IP-адреса, используя сервер доменных имён DNS сети Ин­тернет таким образом, что любое приложение, включая SIR может найти ресурсы, связанные с уникальным телефонным номером.

Рабочая группа IPTEL разрабатывает протокол TRIP маршрутиза­ции телефонных вызовов по IP-сети (telephony routing over IP), кото­рый представляет собой управляемый стратегией межадминистра­тивный доменный протокол, информирующий серверы адресов о доступности телефонных адресатов и объявляющий атрибуты мар­шрутов к этим адресатам. TRIP позволяет поставщикам, во избежа­ние избыточного назначения ресурсов или дублирования шлюзов, обмениваться информацией маршрутизации, используя стандарт­ные Интернет-протоколы. Не без участия таких рабочих групп про­токолы сигнализации и передачи данных для управления соедине­ниями и потоками данных, проходящими через сеть, продолжают развиваться прямо на глазах.

Глава 9

Программное управление

Египетский царь Птоломей I спросил Евклида :

- Как побыстрее познать геометрию ?

- Царских путей в геометрию нет .

- ответил Евклид .

---

Дата добавления: 2019-02-26; просмотров: 448; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!