рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Команды протокола MGCP

Команды протокола MGCP - раздел Менеджмент, Устройство управления - Call Agent, выполняющее функции управления шлюзом В Ходе Установления, Поддержания И Разрушения Соединения При Помощи Протокола...

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

При помощи команды EndpointConfiguration устройство управления инструктирует шлюз, каким образом он должен обрабатывать получаемые речевые сигналы, например, использовать для преобразования цифрового сигнала в аналоговую форму закон А или закон |л.

Команда EndpointConfiguration содержит ряд параметров:

ReturnCode

<— EndpointConfiguration( Endpointid,

Bearer Information),

где Endpointid - идентификатор порта шлюза, к которому относится данная команда;

Bearerlnformation - параметр, определяющий закон (А или |i) декодирования принятой речевой информации.

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

Call Agent при помощи команды Notification Request может дать указание шлюзу выявлять определенные события или сигналы и информировать о них устройство управления. В число детектируемых событий (сигналов) входит изменение сопротивления абонентского шлейфа, происходящее, когда абонент поднимает или кладет трубку, а также получение сигналов факсимильных аппаратов и сигналов DTMF.

Команда NotificationRequest включает в себя следующие параметры (в квадратных скобках указаны те из них, которые не являются обязательными).

 

 

ReturnCode

<—NotificationRequest( Endpointid,

[NotifiedEntity,] [RequestedEvents,] Requestldentifier, [DigitMap,] [SignalRequests,] [QuarantineHandling,] [DetectEvents,] [encapsulated EndpointConfiguration])

Здесь NotifiedEntity - идентификатор устройства, которому должен быть передан ответ на команду. При отсутствии этого параметра ответ передается тому устройству, от которого получен запрос Notification Request.

Requested Events - список событий, о которых следует оповестить управляющее устройство. Кроме того, в этом параметре может быть указано, как шлюз должен реагировать на событие. Определены следующие действия шлюза: оповестить Call Agent о событии немедленно; ожидать дальнейших событий; если событие состоит в получении сигнала DTMF, то накапливать такие сигналы в соответствии с требованиями параметра DigitMap; в определенных ситуациях передавать в телефонный канал акустические или вызывные сигналы;

обработать инкапсулированную команду EndpointConfiguration; игнорировать событие и т.д.

Requestldentifier - идентификатор запроса, в ответ на который передается команда.

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

SignalRequests - сигналы, которые должны быть переданы в канал, например, сигнал посылки вызова.

QuarantineHandling - необязательный параметр, определяющий правила обработки событий, которые были обнаружены до момента получения данной команды в период так называемого карантина (quarantine period) и о которых Call Agent еще не был оповещен.

DetectEvents - необязательный параметр, определяющий события, которые нужно выявить в период карантина, но не оповещать о них Call Agent до получения следующей команды NotificationRequest с включенным в нее параметром QuarantineHandling.

Encapsulated EndpointConfiguration - команда EndpointConfiguration, инкапсулированная в команду NotificationRequest.

Остальные параметры команды тождественны описанным выше.

При помощи команды Notify шлюз информирует устройство управления о том, что произошло событие из числа указанных в команде NotificationRequest. Команда Notify содержит следующие параметры:

 

ReturnCode

<- Notify (Endpointid,

[NotifiedEntity,] Requestldentifier, ObservedEvents)

Здесь ObservedEvents - параметр, в котором описываются произошедшие события, например, передаются набранные цифры номера. Остальные параметры были описаны ранее.

При помощи команды CreateConnection управляющее устройство может дать шлюзу указание создать соединение двух портов одного и того же шлюза или разных шлюзов.

Структура этой команды приведена ниже.

ReturnCode, Connectionid, [SpecificEndPolntId,1 [LocalConnectionDescriptor,] [SecondEndPointId,] [SecondConnectionId] <— CreateConnection(Callld,

Endpointid,

[NotifiedEntity,]

[LocalConnectionOptions,]

Mode,

[{RemoteConnectionDescriptor I

SecondEndpointId), ]

[Encapsulated NotificationRequest,] о [Encapsulated EndpointConfiguration])

Callld - уникальный параметр, идентифицирующий сессию, к которой относится данное соединение.

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

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

метод кодирования, размер речевых пакетов, полоса пропускания, тип обслуживания, использование эхокомпенсатора, использование режима подавления пауз в разговоре, использование режима подавления шума, использование резервирования ресурсов и другие поля. Кодирование трех первых полей должно производиться в соответствии с протоколом описания сессий SDP (Session Description Protocol), причем Call Agent может у казать только полосу пропускания и оставить за шлюзом право выбора метода кодирования и размеров речевых пакетов.

Mode - параметр, определяющий режим работы для данного конца соединения. Определены следующие режимы: передача, прием, прием/передача, конференция, данные, отсутствие активности, петля, тестовый режим и другие.

 

RemoteConnectionDescriptor - описание подключения к соединению на другом его конце. Данный параметр содержит те же поля, что и параметр LocalConnectionOptions. Эти поля также должны кодироваться в соответствии с протоколом SDP. Стоит отметить, что при создании соединения между двумя шлюзами, при передаче первой команды CreateConnection параметр RemoteConnectionDescriptor отсутствует (ему присваивается нулевое значение), так как информация о подключении к соединению на другом его конце в этот момент отсутствует. Не имея такой информации, т.е. не получив команду ModifyConnection, шлюз может только принимать информацию (работать в режиме receive only).

SecondEndpointId - этот параметр может включаться в команду CreateConnection вместо параметра RemoteConnectionDescriptor при установлении соединения между двумя портами одного и того же шлюза.

Encapsulated NotificationRequest - инкапсулированная команда NotificationRequest.

В ответ на команду CreateConnection, кроме описанного выше параметра ReturnCode, шлюз возвращает следующие параметры:

Connectionid - уникальный идентификатор подключения данного порта к соединению.

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

LocalConnectionDescriptor - параметр, содержащий информацию об IP-адресе и номере порта RTP в соответствии с протоколом SDP.

SecondEndPointId - параметр, означающий, что команда CreateConnection создала два соединения.

SecondConnectionId - идентификатор подключения для второго соединения.

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

ReturnCode,

[LocalConnectionDescriptor]

<——— ModifyConnection (Call Id,

Endpointid, Connectionid, [NotifiedEntity,] [LocalConnectionOptions,] [Mode,]

[RemoteConnectionDescriptor,] [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration])

Здесь используются такие же параметры, как и в команде CreateConnection, но добавляется обязательный параметр Connectionid, который идентифицирует подключение к соединению данного порта оборудования, так как один порт может одновременно иметь подключения к нескольким соединениям.

Данная команда может использоваться для передачи информации о другом конце соединения в параметре RemoteConnection Descriptor, для активизации/деактивизации соединения при помощи параметра Mode, для изменения алгоритма кодирования, периода пакетизации передаваемой информации или для управления подавлением эха.

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

Если параметры соединения на ближнем конце были изменены, например, был изменен номер порта RTP, то в ответе на команду ModifyConnection может возвращаться параметр LocalConnection-Descriptor.

Устройство управления может разрушить существующее соединение при помощи команды DeleteConnection. Кроме того, при помощи этой команды шлюз может передать к Call Agent индикацию того, что существующее соединение больше поддерживаться не может.

Команда DeleteConnection, передаваемая устройством управления, имеет следующий вид:

ReturnCode,

Connection-parameters

<— DeleteConnection (Callld/

Endpointid,

Connectionid,

[Encapsulated NotificationRequest,]

[Encapsulated EndpointConfiguration])

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

В общем случае, команда DeleteConnection передается обоим шлюзам, подключенным к соединению. После завершения соединения в ответ на команду DeleteConnection шлюз возвращает статистические данные, собранные за время соединения - connection-parameters:

• количество переданных RTP-пакетов,

• количество переданных байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),

• количество полученных RTP-пакетов,

• количество принятых байтов информации, не считая служебной информации (заголовков IP/UDP/RTP),

• количество потерянных RTP-пакетов,

• вариация времени между поступлениями RTP-пакетов,

• средняя задержка RTP-пакетов.

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

RetumCode,

<— DeleteConnection (Callld,

Endpointid, Connectionid, Reason-code, Connection-parametera)

В параметре Reason-code указывается причина, по которой шлюз передает данное сообщение. Остальные параметры были описаны ранее.

Чтобы получить информацию о статусе какого-либо порта шлюза, управляющее устройство может передать запрос Audit EndPoint, который имеет следующий вид:

RetumCode,

EndPointIdLietl{ [RequestedEvente,] [DigitMap,] [SignalRequests,] [Requestldentifier,1 [NotifiedEntity,] [Connectionldentifiers,] [DetectEvents,] [ObservedEvents,] [EventStates,] [Bearer Information,1 [RestartReason,] [RestartDelay,] [ReasonCode,] [Capabilities]}

<- AuditEndPoint(Endpointid, [Requestedlnfo])

Requestedlnfo - необязательный параметр, описывающий информацию, которую запрашивает устройство управления.

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

 

 

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

Observed Events - необязательный параметр, в котором приводится текущий список обнаруженных событий;

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

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

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

При помощи команды AuditConnection устройство управления запрашивает параметры соединения, в котором участвует порт шлюза.

Команда имеет следующий вид:

ReturnCode, [Callld,]

[NotifiedEntity,] [LocalConnectionOptione,] [Mode,]

[RemoteConnectionDescriptor,] [LocalConnectionDescriptor,] [ConnectionParameters]

<— AuditConnection (Endpointid,

Connectionid,

Requestedlnfo)

Все параметры команды уже были описаны ранее. Если никакой информации не требуется и указанный порт существует, то шлюз проверяет, что соединение существует, и возвращает подтверждение.

Команда RestartlnProgress передается шлюзом для индикации того, что один или группа портов выводятся из рабочего состояния или возвращаются в рабочее состояние. Данная команда имеет следующий вид:

ReturnCode, [NotifiedEntity] <—— RestartinProgress (EndPointId,

RestartMethod, [RestartDelay,] [Reason-code])

Параметр RestartMethod специфицирует вид рестарта. Определено несколько видов рестарта:

• Graceful restart - постепенный рестарт, при котором порты оборудования выводятся из обслуживания после определенной задержки. Установленные соединения не разрушаются, но и новые не создаются.

• Forced restart - принудительный рестарт, при котором разрушаются установленные соединения.

• Restart - рестарт, при котором порт оборудования возвращается в обслуживание после определенной задержки. При этом порт в момент рестарта не участвует ни в каких соединениях.

• Disconnected - данное значение присваивается параметру Restart-Method, когда порт находился вне обслуживания, но в данный момент пытается вернуться в обслуживание.

• Cancel-graceful - данное значение присваивается параметру Re-startMethod, когда шлюз отменяет предшествовавшую команду Restart с параметром RestartMethod, которому было присвоено значение Graceful.

Параметр RestartDelay определяет задержку рестарта в секундах.

По аналогии с предыдущими главами в таблицу 8.1 сведены все команды протокола MGCP.

 

Таблица 8.1 Команды протокола MGCP

 

Команда Направление передачи Назначение
EndpointConfiguration (Конфигурация порта) СА -> MG Call Agent инструктирует шлюз, каким образом ему нужно обрабатывать получаемые речевые сигналы
CreateConnection (Создать соединение) СА -> MG Call Agent дает указание шлюзу создать соединение
ModifyConnection (Модифицировать соединение) СА -> MG Call Agent дает указание шлюзу изменить параметры существующего соединения
DeleteConnection (Завершить соединение) СА -> MG, MG -> СА Call Agent и шлюзы завершают соединение
NotificationRequest (Запрос уведомления) СА -> MG Call Agent инструктирует шлюз, какие события необходимо обнаруживать.  
Notify (Уведомить) MG -> СА Шлюз информирует Call Agent о том, что произошло событие из числа тех, которые были специфицированы в команде NotificationRequest
AuditEndpoint (Проверить порт) СА -> MG Call Agent запрашивает информацию о каком-либо порте шлюза
AuditConnection (Проверить соединение) MGC -> MG Call Agent запрашивает параметры соединения
ReStartlnProgress (Идёт рестарт) MG -> MGC Шлюз информирует Call Agent о том, что один или несколько портов выводятся из рабочего состояния или возвращаются в рабочее состояние

 

 

– Конец работы –

Эта тема принадлежит разделу:

Устройство управления - Call Agent, выполняющее функции управления шлюзом

Принцип декомпозиции шлюза... В недавнем прошлом рабочая группа MEGACO комитета IETF разработала протокол управления шлюзами Media Gateway Control...

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Команды протокола MGCP

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Модель организации связи
Для описания процесса обслуживания вызова с использованием протокола MGCP рабочей группой MEGACO разработана модель организации соединения - Connection model. Базой модели являются компоненты двух

Структура команд
Команда протокола MGCP обязательно содержит заголовок, за которым может следовать описание сеанса связи (session description). Заголовок команды и описание сеанса связи представляют собой набор тек

Структура ответов на команды
Протокол MGCP предусматривает подтверждение получения всех команд. Структура ответов на команды в протоколе MGCP идентична вышеописанной структуре самих команд. Ответ на команду также представляет

Описания сеансов связи
При установлении соединений Call Agent предоставляет портам шлюзов, участвующим в этих соединениях, необходимую информацию друг о друге - описание сеансов связи. Описание сеанса связи вводится в со

Установление, изменение и разрушение соединений
В данном параграфе будет показано, каким образом при помощи протокола MGCP устанавливаются, изменяются и завершаются речевые соединения в сетях с маршрутизацией пакетов IP. Пример охватывает взаимо

Реализация оборудования с поддержкой протокола MGCP
Рассмотрим реализацию протокола MGCP на примере оборудования IPConnect производства компании Nortel Networks. IPConnect -это набор совместимых аппаратно-программных средств, объединенных единой иде

Возможности и перспективы протокола MGCP
Для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии сегодня подходят протоколы Н.323 и MGCP. Подход с использованием MGCP обладает весьма важным преимуществом перед подход

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги