RFC 3624

The Media Gateway Control Protocol (MGCP) Bulk Audit Package

📅 published November 2003, from ietf

RFC 3624: The Media Gateway Control Protocol (MGCP) Bulk Audit Package 💖

Okay bestie, the title block first 👀 This is RFC 3624, "The Media Gateway Control Protocol (MGCP) Bulk Audit Package." It came out of the Network Working Group and was written by B. Foster, D. Auerbach and F. Andreasen, all from Cisco Systems. The category is Informational and the date is November 2003 🎀. The title block doesn't list anything this one obsoletes or updates, so no drama there ✨

Status of This Memo 📜

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution is unlimited 🌸

Copyright (C) The Internet Society (2003). All Rights Reserved.

IESG Note 🚨

Okay this one's important! This doc is being published for the info of the community. It describes a non-IETF protocol that's already being deployed in a bunch of products. Implementers should know about RFC 3015, which was developed in the IETF Megaco Working Group and the ITU-T SG16. The IETF and the ITU-T both consider it the standards-based (including reviewed security considerations) way to meet the needs MGCP was designed to address 🫶

Abstract 🌟

The base Media Gateway Control Protocol (MGCP) has audit commands that only let a Call Agent audit endpoint and/or connection state one endpoint at a time, which is a lot 😭 This document describes a new MGCP package for bulk auditing a group of gateway endpoints. It lets a Call Agent figure out the endpoint naming convention, the list of instantiated endpoints, and the connection and endpoint state for the whole group ✨

Table of Contents 🗂️

1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Bulk Audit Package. . . . . . . . . . . . . . . . . . . . . .   2
    2.1.  Package Definition. . . . . . . . . . . . . . . . . . .   2
          2.1.1. Package Parameters . . . . . . . . . . . . . . .   3
          2.1.2. Bulk Auditing of Non-persistent Virtual
                 Endpoints. . . . . . . . . . . . . . . . . . . .  11
          2.1.3. Package Specific Return Codes. . . . . . . . . .  12
    2.2.  Examples of Package Use . . . . . . . . . . . . . . . .  13
          2.2.1. Endpoint List. . . . . . . . . . . . . . . . . .  13
          2.2.2. Connection Count List. . . . . . . . . . . . . .  13
          2.2.3. Connection Mode List . . . . . . . . . . . . . .  15
          2.2.4. Endpoint State . . . . . . . . . . . . . . . . .  15
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
5.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  18
6.  Authors' Addresses. . . . . . . . . . . . . . . . . . . . . .  18
7.  Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

The reader is assumed to be familiar with the base MGCP protocol [3]. Okay, so, the base Media Gateway Control Protocol (MGCP) [3] has audit commands that only let a Call Agent audit an endpoint and/or a connection state, one endpoint at a time. This doc adds a new MGCP package for bulk auditing a group of gateway endpoints. It lets a Call Agent determine the endpoint naming convention, determine the list of instantiated endpoints, and determine the connection and endpoint state for the group. This is especially important in fail-over situations where gateways have large numbers of endpoints 🔥

Conventions Used in this Document 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] 💅

2. Bulk Audit Package 🦋

2.1. Package Definition 🎀

The package details are literal, so here they are exactly as written:

Package Name: BA

Package Version: 0
Package Description: This package provides the Call Agent the ability
   to audit and obtain high-level view of endpoint and connection state
   for a group of endpoints in a gateway.

2.1.1. Package Parameters 🧚

A new BulkRequestedInfo parameter is defined for use in the AuditEndpoint command. This parameter can be used to request a compact list of EndpointIds, or to request a high-level view of endpoint or connection state for a group of endpoints, like this:

   ReturnCode,
   [EndPointNameList,]
   [InstantiatedEndpointList,]
   [ConnectionCountList,]
   [ConnectionModeList,]
   [EndpointStateList,]
   [NextEndpointName,]
   [ReportedEndpointList]
   <-- AuditEndPoint(EndpointId,
                       [StartEndpointName,]
                       [MaxNumEndpoints,]
                       [BulkRequestedInfo])

Here's the big difference from the normal RequestedInfo parameter in base MGCP: the BulkRequestedInfo parameter in the Bulk Audits package can use "all-of" wildcards to audit a whole collection of endpoints. It's not an error to specify an EndpointId without wildcards, though 🌈

The sub-sections below describe the parameters for the Bulk Audit Command in detail. Sections 2.1.1.1 and 2.1.1.2 describe the parameters that can be included with a request, and sections 2.1.1.3 to 2.1.1.8 describe the return parameters 📚

2.1.1.1. StartEndpointName and MaxNumEndpoints Parameters 🌸

Wildcarding might not be enough to narrow down the endpoints you care about, so you can add more qualification with a StartEndpointName (the first endpoint of interest) and a MaxNumEndPoints (the maximum number of endpoints of interest). These parameters follow this Augmented BNF (ABNF) syntax (see RFC 2234 for ABNF syntax definitions [1]):

   "BA/SE" ":" 0*WSP LocalEndpointName

   "BA/NU" ":" 0*WSP MaxNumEndpoints

Here, MaxNumEndpoints is the decimal number of endpoints, with a value in the range 1 to 65535. The MaxNumEndpoints parameter SHOULD only be included when requesting an audit for an EndpointStateList and/or ConnectionCountList. If it's included in a request for the EndPointNameList or InstantiatedEndpointList, it MAY be ignored 🙈

Only the LocalEndpointName (see the ABNF grammar in [3]) goes in the request and response parameter lines for this package, not the full EndpointName. This keeps things compact, since the domain name portion is already in the command line of a given request, so it's left out 💖

If the list of endpoints defined by the StartEndpointName and MaxNumEndPoints falls outside the range set by the wildcarding, a report is only returned for endpoints up to those specified within the wildcard range 🫶

2.1.1.2. BulkRequestedInfo Parameter 🍓

The BulkRequestedInfo parameter line follows these ABNF syntax definitions:

   BulkRequestedInfo = "BA/F:" 0*WSP
          *( EndpointOrInstantList *("," EndpointOrInstantList))
        / *( EndpointOrConnState *("," EndpointOrConnState))

   EndpointOrConnState = "BA/C" / "BA/M" /  EndpointStateParam

   EndpointOrInstantList = "BA/Z" / "BA/X"

   EndpointStateParam = "BA/S" "(" StateType
                                      0*("," 0*(WSP) StateType)")"

   StateType = "I" / "D" / "N" / "S" / "H"

Here's what each BulkRequestedInfo parameter means:

  • BA/Z is a request to return EndPointNameList
  • BA/X is a request to return InstantiatedEndpointList
  • BA/C is a request to return the ConnectionCountList
  • BA/M is a request to return the ConnectionModeList
  • BA/S is a request to return the EndpointStateList

Each of the parameters can be provided at most once in the BulkRequestedInfo 🔥

EndpointStateParam Parameter: 🌟

Like the ABNF says, the EndpointStateParam is itself parameterized with one or more StateType parameters that define the conditions to evaluate for the endpoint:

  • "I" means the endpoint is in-service ✨
  • "D" means the endpoint is disconnected (see sections 4.3 and 4.4.7 of [3] for a discussion on disconnected endpoints) 💀
  • "N" means the endpoint is in the notification state 🔔
  • "L" means the endpoint is in lockstep state (i.e., waiting for an RQNT after a response to a NTFY has occurred while in lockstep mode) 🔒
  • "S" means there is an active on-off (OO) or timeout (TO) signal on the endpoint ⏱️
  • "H" means the endpoint is in some state other than "idle." The meaning of this last one depends on the type of endpoint:
    • It has no meaning for endpoints that only provide bearer services (with no state the endpoint is aware of). In this case, the condition is always evaluated to false (corresponding to "idle").
    • For endpoints that have a state machine associated with them (such as a CAS endpoint), the endpoint MUST be in some state other than the "idle" state in order for the condition to be evaluated as true. 👑
    • When the endpoint has hook-state associated with it, the hook-state MUST be off-hook. For digital channel associated signaling (CAS) connections, hook-state may be provided in either direction. If the hook-state in either direction is off-hook, the endpoint is considered non-idle, i.e., the condition is satisfied.

The list of StateTypes may be extended in the future. If an unknown StateType is encountered, the command MUST be rejected with error code 803 (i.e., "unsupported StateType") 🚫

The report from this request says either "True", "False", or "Out of Service" for each endpoint. If the endpoint is in-service and any one of the criteria holds true, the report for that endpoint evaluates to "True." A "False" indication is only reported if the endpoint is in-service and all criteria evaluate to false. So the report basically gives you the logical "OR" over the conditions audited for in-service endpoints. No matter what state is being audited, an "Out of Service" indication is always reported if the endpoint is considered out-of-service 🫠

Note that the criteria "D", "N", "L", "S" and "H" can only be true if the endpoint is in-service. So requesting "I" at the same time (although it's allowed) would be unnecessary, i.e., redundant 🙄

Example time 🎀 If the request for EndpointStateList for one or more endpoints includes this parameter line:

   BA/F: BA/S(D,N)

it's asking for a report on whether endpoints are disconnected or in the notification state. If a given endpoint is in either a "disconnected" or a "notification" state, the report indicates "True" for that endpoint. If the endpoint is in neither state but is in-service, the report indicates "False." If the endpoint is out-of-service, the report indicates "Out of Service" 🧁

If the Call Agent only wants to know whether an endpoint is in-service or out-of-service, it should make a request with only the "I" StateType parameter 💅

Part 1 of 3 is done, bestie! Part 2 is coming up next, so stay right here 💖🦋

2.1.1.3. EndPointNameList and InstantiatedEndpointList Parameters ✨

Okay so, the EndPointNameList parameter is the list of endpoint names 📋 (the naming convention for the endpoints the gateway has configured for service). It's qualified by the wildcarded EndPointId and possibly the StartEndPointName and MaxNumEndpoints parameters. The list can have one or more lines in this ABNF format:

"BA/Z:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)

RangedLocalName is a LocalEndpointName that can include the ranged wildcard notation from Appendix E (section E.5) of [3], which is basically:

RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]"
NumericalRange     = 1*(DIGIT) [ "-" 1*(DIGIT) ].

Example:

ba/z: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]

or simply:

ba/z: ds/ds1-[1-3]/[1-24]
Heads up bestie 🫶: range wildcards use [ to mark the start of a range, so the [ character MUST NOT be used in endpoint names that use range wildcards. Keep that one in your back pocket 🔥.

The ranged wildcard notation (RangeWildcard above) also lets you put commas between ranges, like this:

ba/z: ds/ds1-1/[1,3-5,8-24]

Now for virtual endpoints 🦋. These are created and deleted on the fly by the gateway, so there's a difference between reporting the endpoint names (the "naming convention" used to describe them) and reporting the actual endpoints that are instantiated when the request is made. For this case:

  • EndPointNameList is a request to return the naming convention and
  • InstantiatedEndpointList is a request to return the "real" (or instantiated) endpoints.

InstantiatedEndpointList Parameter 🌸: the syntax of the InstantiatedEndpointList value is the same as the EndPointNameList value, so a number of lines may come back with this syntax:

"BA/X:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)

For hard-wired or physical endpoints (like DSO's) or other persistent endpoints, nobody really asks for the InstantiatedEndpointList, since it would normally not be requested. But if someone does ask, the InstantiatedEndpointList and the EndPointNameList will be the same 💖.

For virtual endpoints that aren't persistent, an "all of" wildcard (*) shows up as the leftmost term of the name in the EndPointNameList 👑. That tells you arbitrary names apply and the endpoints are virtual and non-persistent. The "all of" wildcard notation MUST NOT be used when returning the EndPointNameList for persistent endpoints, though. Here's how it looks:

ba/z: announcement/*
ba/z: foo/bar/*
ba/z: foo/foo/*

The "all of" wildcard is telling us that "announcement" is just the leftmost term for a dynamic set of non-persistent virtual endpoints. To instantiate one of them, you'd put the "any of" wildcard (e.g., announcement/$) as the LocalEndpointName in the EndpointId of a request (like a NotificationRequest or CreateConnection). The response then includes the SpecificEndpointId showing which endpoint got instantiated 🎀. Also, peep the example above: "foo" defines two different levels of non-persistent virtual endpoints. Iconic 💅.

2.1.1.4. ConnectionCountList

The ConnectionCountList tells you how many connections are on a series of endpoints. It's a bunch of lines with this ABNF syntax:

"BA/C:" 0*WSP NumConnections 0*(NumConnections)

where NumConnections is either:

  • a hexadecimal digit showing the number of connections on the endpoint at that spot in the list, or
  • the letter "Z", meaning there are more than 15 connections on this endpoint 😭.

2.1.1.5. ConnectionModeList

The ConnectionModeList shows the connection modes for all the connections on a series of endpoints. It's also a bunch of lines, with this ABNF syntax:

"BA/M:" 0*WSP ModeOrCount 0*(ModOrCount)

ModeOrCount = ConnCount / ConnMode

ConnMode = "I" / "S" / "R" / "B" / "C" / "L" / "T" / "N" / "U"

where ConnCount is either a hexadecimal value for 0-15 connections on an endpoint, or the value "Z", meaning more than 15 connections are present.

ConnMode is the connection mode, where:

  • I indicates "inactive" connection mode
  • S indicates "sendonly" connection mode
  • R indicates "recvonly" connection mode
  • B indicates "sendrecv" connection mode
  • C indicates "confrnce" connection mode
  • L indicates "loopback" connection mode
  • T indicates "conttest" connection mode
  • N indicates "netwloop" connection mode
  • U indicates some other connection mode

For a definition of MGCP connection modes, check section 3.2.2.6 of [3] 📚.

Here's how it works ✨. If an endpoint has no connections, ModeOrCount gets the value 0. If there's one connection on the endpoint, you get the symbol for its connection mode (ConnMode). If there are from 2 to 15 connections, you get a symbol for the number of connections (ConnCount), followed by a list of symbols for the connection mode (ConnMode) of each connection. If there are more than 15 connections, Z shows up for ConnCount and no connection modes are given for that endpoint's connections 🙈.

2.1.1.6. EndpointStateList Parameter

The EndpointStateList gives you an overview of the endpoint state for a series of endpoints. It's a bunch of lines with this ABNF syntax:

"BA/S:" 0*WSP EndPointState 0*(EndPointState)

EndPointState = "T" / "F" / "O"

where:

  • T indicates "True"
  • F indicates "False"
  • O indicates "Out of Service"

The "True" or "False" call is based on the criteria supplied in StateType parameters when the request is made.

Note that the EndPointState indicator does not say anything about the connection state of the endpoint 🧚. Don't mix those two up, bestie.

2.1.1.7. NextEndpointName Parameter

The NextEndpointName parameter gets included in the return if there are additional endpoints in this gateway covered by the wildcarded endpoint name that weren't reported, but whose information was available to report 🍓.

Note that NextEndpointName is the LocalEndpointName (as opposed to EndpointName) of the next endpoint after the last one reported. The syntax is:

"BA/NE" ":" 0*WSP LocalEndpointName

A gateway may send back a report that's shorter than the request if the full report would turn into a message that's too large (meaning the report is bigger than the maximum datagram size) 🫣. If the gateway gives a response for fewer endpoints than were requested, the gateway MUST supply NextEndpointName in the response.

To keep the audit going on the next set of endpoints, the Call Agent can make another request and use the NextEndpointName as the starting point (for example, as the StartEndpointName in a following request) 🔁.

2.1.1.8. ReportedEndpointList Parameter

A ReportedEndpointList MUST be provided in a response line before any list(s) of EndpointStateList and/or ConnectionCountList, so it's crystal clear which endpoints are being reported 🔍. The ABNF syntax is:

"BA/EL:" 0*WSP LimitedRangedName 0*("," 0*WSP LimitRangedName)

where LimitedRangedName is a LocalEndpointName that may include a ranged wildcard notation (the RangeWildcard syntax from earlier). Unlike RangedLocalName, which lets the range wildcard notation show up on multiple terms of the local name at the same time, LimitedRangedName only lets the range notation be used on the last term. So this is valid:

ba/el: ds/ds1-1/[1,3-5,8-24]

or

ba/el: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]

But this is NOT valid, sorry bestie 🙅‍♀️:

ba/el: ds/ds1-[1-3]/[1-24]

A single bulk audit request can ask for both ConnectionCountList and EndpointStateList. However, the resulting report that includes both MUST cover the same endpoints 💜.

A single bulk audit request can also ask for both EndPointNameList and InstantiatedEndpointList. However, requests for either an EndPointNameList and/or an InstantiatedEndpointList MUST NOT include a request for either ConnectionCountList or EndpointStateList 🚫.

2.1.2. Bulk Auditing of Non-persistent Virtual Endpoints

Heads up 🦋: gateways with non-persistent virtual endpoints may have instantiated endpoints that are disjoint with respect to the name space. The ReportedEndpointList in front of a ConnectionCountList and/or EndpointStateList describes exactly which endpoints are being reported.

Example:

A Call Agent asks about the EndPointNameList for the endpoints on a conference bridge:

AUEP 1200 *@gw1.x.net MGCP 1.0
BA/F: BA/Z

Response:

200 1200 OK
ba/z: cnf/*

This shows the naming convention, but in fact not all of these endpoints are instantiated. A request for the list of instantiated endpoints, like this:

AUEP 1201 cnf/*@gw1.x.net MGCP 1.0
BA/F: BA/X

might yield:

200 1201 OK
ba/x: cnf/[1-3]
ba/x: cnf/[6-12]

which indicates that only these particular endpoints are instantiated 🌈.

Now suppose the Call Agent asks for the ConnectionCountList, like this:

AUEP 1202 cnf/*@gw1.x.net MGCP 1.0
BA/F: BA/C

The resulting instantiated virtual endpoints may be disjoint, which would be shown by the ReportedEndpointList in front of the ConnectionCountList, e.g.:

200 1202 OK
ba/el: cnf/[1-3]
ba/c: 035
ba/el: cnf/[6-12]
ba/c: 3450333

or alternatively:

200 1202 OK
ba/el: cnf/[1-3], ba/el: cnf/[6-12]
ba/c: 035
ba/c: 3450333

or

200 1202 OK
ba/el: cnf/[1-3], ba/el: cnf/[6-12]
ba/c: 0353450333

2.1.3. Package Specific Return Codes

These return codes are specific to this package 🎀:

800     Invalid NextEndpointName
801     Invalid StartEndpointName
802     Invalid or unsupported BulkRequestInfo Parameter
803     Invalid or unsupported StateType
804     Bulk Audit Type not supported
805     Incorrectly specified endpoint range
806     Requested StartEndpoint unknown or unavailable

Note that package specific error codes include the package name after the error code. For example, if error code 801 happens in response to a request with a transaction ID of 1001, it would be sent as:

801 1001 /BA

2.2. Examples of Package Use ✨

2.2.1. Endpoint List

This section has examples of how to get a list of endpoints 📋.

Example 1: This is a gateway with a single OC3 that has a single level of hierarchy at the T1 level.

The request is made:

AUEP 1200 *@gw1.x.net MGCP 1.0
BA/F: BA/Z

This may result in a single "BA/Z" term with ranges specifying all of the endpoints:

200 1200 OK
ba/z: ds/ds1-[1-84]/[1-24]

Example 2: In this one, the gateway has 10 analog lines and a single T1. The same request is made as in Example 1, but now the response is:

200 1200 OK
ba/z: aaln/[1-10]
ba/z: ds/ds1-1/[1-24]

2.2.2. Connection Count List

Okay, so the Connection Count List is where the Call Agent asks how many connections each endpoint has, and it's giving "show me the receipts" energy 💅✨. Example 1 audits a single E1:

AUEP 2111 ds/e1-3/*@gw1.net
BA/F: BA/C
200 2111 OK
BA/EL: ds/e1-3/[1-30]
BA/C:  012111210001000001000001000010

Example 2 is the DS3 version 🧚. The gateway only sent back the first 192 endpoints, and "BA/NE" tells the Call Agent where to pick up:

AUEP 1144 ds/ds3-1/*@gateway.net
BA/F: BA/C
200 1144 OK
BA/EL: ds/ds3-1/[1-192]
BA/C:  010000010001000001000001
BA/C:  001000000101000000001001
:
BA/C:  011000100010000010000010
BA/C:  011111010001000001000001
BA/C:  011000001100000001000001
BA/NE: ds/ds3-1/193

If the ds-3 has a T1 hierarchy, the "BA/EL" and "BA/NE" values show that hierarchy too, e.g.,:

200 1144 OK
BA/EL: ds/ds3-1/ds1-1/[1-24]
BA/C:  010000010001000001000001
BA/EL: ds/ds3-1/ds1-2/[1-24]
BA/C:  001000000101000000001001
:
BA/EL: ds/ds3-1/ds1-6/[1-24]
BA/C:  011000100010000010000010
BA/EL: ds/ds3-1/ds1-7/[1-24]
BA/C:  011111010001000001000001
BA/EL: ds/ds3-1/ds1-8/[1-24]
BA/C:  011000001100000001000001
BA/NE: ds/ds3-1/ds1-9/1

The Call Agent can keep asking by using the returned "BE/NE" value as the "BA/SE" value in its next request, which is basically a little relay baton passing 🫶:

AUEP 1145 ds/ds3-3/*@gw1.net
BA/F: BA/C
BA/SE: ds/ds3-1/ds1-9/1

Example 3 asks for the connection state of 12 DS0s, starting at the endpoint with the LocalEndpointName "ds/ds3-1/ds1-6/4" 🌸:

AUEP 1146 ds/ds3-1/*@gw1.net
BA/F: BA/C
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
200 1144 OK
BA/EL: ds/ds3-1/ds1-6/[4-15]
BA/C:  011000010001
BA/NE: ds/ds3-1/ds1-6/16

2.2.3. Connection Mode List

Here we audit the connection modes on the endpoints of a single E1 🦋:

AUEP 2111 ds/e1-3/*@gw1.net
BA/F: BA/M
200 2111 OK
BA/EL: ds/e1-3/[1-30]
BA/M:  0R2BRBBB2RRB000B00000B00000B0000B0

Here's what that string is saying:

  • Endpoint ds/e1-3/1 has no connections
  • Endpoint ds/e1-3/2 has one connection and it is in "recvonly" mode.
  • Endpoint ds/e1-3/3 has two connections which are in "sendrecv" and "recvonly" mode
  • Endpoints ds/e1-3/4 to ds/e1-3/6 each have one connection - in "sendrecv" mode in all cases
  • Endpoints ds/e1-3/7 has two connections, both in "recvonly" mode
  • etc.

2.2.4. Endpoint State

Endpoint state requests and responses are a lot like the last example, so this one is basically a sequel 🎀. It's like example 3 from the previous section:

AUEP 1150 ds/ds3-1/*@gw1.net
BA/F: BA/S(I)
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
200 1150 OK
BA/EL: ds/ds3-1/ds1-6/[4-15]
BA/S:  TOOTTOOTTOOT
BA/NE: ds/ds3-1/ds1-6/16

For an in-service request, "True" means the endpoint is in-service, and "O" means it's "Out of Service" 💀.

Adding parameters changes things up a bit:

AUEP 1151 ds/ds3-1/*@gw1.net
BA/F: BA/S(H,N)
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
200 1151 OK
BA/EL: ds/ds3-1/ds1-6/[4-15]
BA/S:  FFFTFFFFFFFO
BA/NE: ds/ds3-1/ds1-6/16

So at least one of the StateType parameters "H" (off-hook) and "N" (notification state) came back true for the endpoints with a "T" next to them, which are ds/ds3-1/ds1-6/7 and ds/ds3-1/ds1-6/16 (since the request started at ds/ds3-1/ds1-6/4). Everything else is neither off-hook nor in the "notification state". Also, ds/ds3-1/ds1-6/15 is marked as out-of-service, so it's not vibing today 😭.

You can even ask for connection state and endpoint state in one request 👑:

AUEP 1151 ds/ds3-1/*@gw1.net
BA/F: BA/S(H,N), BA/C
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12

The response might look like this:

200 1151 OK
BA/EL: ds/ds3-1/ds1-6/[4-15]
BA/S:  FFFTFFFFFFFO
BA/C:  011000010001
BA/NE: ds/ds3-1/ds1-6/16

3. IANA Considerations ✨

The MGCP package title, "Bulk Audit", with the name, "BA", has been registered with IANA as indicated in Appendix C.1 in [3].

4. Security Considerations 🔥

Okay, this one is seriously important, bestie 😭. Section 5 of the base MGCP specification [3] talks about security requirements for the base protocol, and they apply just as much to the package defined in this document. You need a security Protocol like IPsec [4, 5], which gives you per message authentication and integrity, so you know requests and responses come from authenticated sources and nobody tampered with the messages. Without that, gateways and Call Agents are wide open to attacks 🚨.

Think about it: audit requests from unauthorized sources won't change the media gateway state, but the info they get back could be used to find idle endpoints, and then somebody could make unauthorized calls 📞. Even worse, if someone changes a response to an audit that's headed to a Call Agent, that can cause a denial of service attack. The Call Agent would get fake info about endpoint state and might take valid calls out of service 💀.

5. References

[1]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
     Specifications: ABNF", RFC 2234, November 1997.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[3]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
     (MGCP) Version 1.0", RFC 3435, January 2003.

[4]  Kent, S. and R. Atkinson, "Security Architecture for the
     Internet Protocol", RFC 2401, November 1998.

[5]  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
     (ESP)", RFC 2406, November 1998.

6. Authors' Addresses 🧚

Flemming Andreasen
Cisco Systems
499 Thornall Street, 8th Floor
Edison, NJ 08837

EMail: fandreas@cisco.com
David Auerbach
Cisco Systems Inc.
170 W. Tasman Drive
San Jose, CA,  95134

EMail: dea@cisco.com
Bill Foster
Cisco Systems

EMail: bfoster@cisco.com

Copyright (C) The Internet Society (2003). All Rights Reserved. The legal bits are important, so here they are word for word 📜:

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from