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

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук

8.4 Команди протоколу MGCP
У ході встановлення, підтримки і руйнування з'єднання за допомогою протоколу MGCP пристрій управління і шлюз обмінюються командами і відповідями, які представляють собою набір текстових рядків. У цьому параграфі дається короткий опис команд протоколу MGCP, серед яких визначені команди управління з'єднанням і команди управління портами обладнання.
За допомогою команди EndpointConfiguration пристрій управління інструктує шлюз, яким чином він повинен обробляти одержувані мовні сигнали, наприклад, використовувати для перетворення цифрового сигналу в аналогову форму закон А чи закон Б.
Команда EndpointConfiguration містить ряд параметрів:
ReturnCode<- EndpointConfiguration (Endpointid,BearerInformation),
де Endpointid - ідентифікатор порту шлюзу, до якого відноситься дана команда;
Bearerlnformation - параметр, що визначає закон (А або | Б) декодування прийнятої мовної інформації.
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 ISecondEndpointId),][Encapsulated NotificationRequest,] about [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 (CallId,Endpointid, Connectionid, [NotifiedEntity,] [LocalConnectionOptions,] [Mode,][RemoteConnectionDescriptor,] [EncapsulatedNotificationRequest,] [EncapsulatedEndpointConfiguration])
Тут використовуються такі ж параметри, як і в команді 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 - дане значення присвоюється параметру RestartMethod, коли порт знаходився поза обслуговування, але в даний момент намагається повернутися в обслуговування.
  • Cancelgraceful - дане значення присвоюється параметру RestartMethod, коли шлюз скасовує попередню команду Restart з параметром RestartMethod, якому було присвоєно значення Graceful.

Параметр RestartDelay визначає затримку рестарту в секундах.
За аналогією з попередніми главами в таблицю 8.1 зведені всі команди протоколу MGCP.
Таблиця 8.1 Команди протоколу MGCP


--Козінцев Олексій 36 гр. 17:13, 29 листопада 2010 (EET)

Отримано з https://wiki.cusu.edu.ua/index.php?title=Команди_протоколу_MGCP&oldid=37261